From ulrich.wiehe@nsn.com Sun Dec 1 11:38:34 2013 Return-Path: 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 4BB331AD8E2 for ; Sun, 1 Dec 2013 11:38:34 -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 qwqTvE2eQuvn for ; Sun, 1 Dec 2013 11:38:28 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id D8F491ADFE0 for ; Sun, 1 Dec 2013 11:38:27 -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 rB1JcIwH004032 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 1 Dec 2013 20:38:18 +0100 Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rB1JcHCW031658 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 1 Dec 2013 20:38:18 +0100 Received: from DEMUHTC014.nsn-intra.net (10.159.42.45) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sun, 1 Dec 2013 20:38:17 +0100 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.152]) by DEMUHTC014.nsn-intra.net ([10.159.42.45]) with mapi id 14.03.0123.003; Sun, 1 Dec 2013 20:38:16 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: "ext Nirav Salot (nsalot)" , "ext lionel.morand@orange.com" , ext Jouni Korhonen , Ben Campbell Thread-Topic: [Dime] DOIC: Self-Contained OLRs Thread-Index: AQHO67/t2PaAGa/GgUyaCwjRxXVUh5o5m/0AgAC8o/D///ghgIAAFu+wgAGHVQCAACqasIAAMwWAgANxipA= Date: Sun, 1 Dec 2013 19:38:16 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519BFAE@DEMUMBX014.nsn-intra.net> References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D90006681519BC90@DEMUMBX014.nsn-intra.net> <6390_1385631044_52970D44_6390_18593_1_6B7134B31289DC4FAF731D844122B36E30748E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BD19@DEMUMBX014.nsn-intra.net> <17872_1385720008_529868C8_17872_2613_1_6B7134B31289DC4FAF731D844122B36E3096B8@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BF1B@DEMUMBX014.nsn-intra.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.106] 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: 13402 X-purgate-ID: 151667::1385926699-00006154-D3C12094/0-0/0-0 Cc: "dime@ietf.org list" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2013 19:38:35 -0000 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 O= LR is out-of-context. Similary, when the client sends a request containing destination host and g= ets 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 respons= es received within the context. Best regards Ulrich=20 -----Original Message----- From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com]=20 Sent: Friday, November 29, 2013 4:49 PM To: Wiehe, Ulrich (NSN - DE/Munich); ext lionel.morand@orange.com; ext Joun= i 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 i= n the answer and additional OLRs (not created by the reporting endpoint) ma= y just be present as an optional optimization i.e. optionally inserted by t= he reporting endpoint and optionally ignored by the reacting endpoint. Ulrich =20 -----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 subs= equent request towards the origin-host of the answer containing the OLR. Us= ing 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.=20 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=A0: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Envoy= =E9=A0: jeudi 28 novembre 2013 11:30 =C0=A0: MORAND Lionel IMT/OLN; ext Jou= ni Korhonen; Ben Campbell Cc=A0: dime@ietf.org list Objet=A0: RE: [Dime] DO= IC: 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 act= ual OLR created by the reporting end point and which OLR is an additional O= LR created by another node. We have two cases: a) The request sent by the client (reacting end point) contains no Destinat= ion Host. The agent (reporting node) (after forwarding the request to the s= elected server and receiving the answer) returns a realm-type OLR as the ac= tual 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 Destinat= ion 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 stat= us. It could be provided an agent inserting this info in answers received f= rom a server behind but also from a server that would know this info by som= e internal magic. But in any case, if we assume that the client will received a successful an= swer from the server for an initial request with only Dest-Realm AVP, it sh= ould be possible to have both report types in the answer: one for the serve= r itself, one for the realm for new request sent to the realm with only Des= t-Realm AVP. Lionel -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN= - DE/Munich) Envoy=E9=A0: jeudi 28 novembre 2013 10:26 =C0=A0: ext Jouni K= orhonen; Ben Campbell Cc=A0: dime@ietf.org list Objet=A0: Re: [Dime] DOIC: = Self-Contained OLRs Hi, I don't see how the possibility to send more than one OLR in an answer is a= ligned with the "endpoint principle". If the ReportType is "realm" this ind= icates 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 wrote: > Hi, >=20 > I mentioned in another thread that I prefer putting an explicit=20 > ReportType AVP in an OLR, rather than The more I spent time thinking/writing the actual procedures on the endpoin= ts, the more it makes sense to me to keep the ReportType in the OC-OLR. Eve= n if the baseline does not have agent overload etc, the ReportType fits wel= l to the "endpoint principle" we have in the draft. It indeed gives more to= ols to make a host vs. realm base decision on the reacting node and is plai= n 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 Diam= eter request that corresponds to the answer containing the OLR. My reasons = for that go beyond just ReportType, so I'm starting a separate thread. >=20 > As currently described, a consumer of an OLR must infer several things fr= om other context. In most cases, that context is in the Diameter answer tha= t carries the OLR. For example, the OLR implicitly refers to the applicatio= n 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 meani= ng in the context of the enclosing answer. If you moved an OLR from one ans= wer to another, it's meaning may change completely. >=20 > I think this approach is a mistake. I would greatly prefer that we explic= itly include such values in the OLR itself, for multiple reasons: >=20 > 1) It's more complex to interpret implicit, contextual values than explic= it values. The consumer cannot simply look at the OLR; it must look in vari= ous other AVPs to find all the information it needs. For example, I think a= common software design for overload control processing to be separated fro= m application processing. The consumer cannot simply hand the OLR to that m= odule 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 "con= text" avps that must be interpreted can grow large. This approach is error = prone, and will likely encourage brittle, hard-to-maintain code. Self-conta= ined OLRs would keep all the information related to overload in one place. = making for simpler implementations. >=20 > 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 r= eporting node realizes that it is overloade, it has to wait for the right a= nswer that contains the right context before it can send the OLR. This is p= articularly troublesome for agents, since they will typically have to inser= t OLRs into answers created by other nodes.=20 >=20 > If the reporting node screws this up, the meaning of the OLR may change s= ignificantly. So again, implicit meaning gives us error prone implementatio= ns. Self-contained OLRs are simpler to create and send. >=20 > 3) Implicit values don't work at all for certain problems. For=20 > example, if an agent needs to originate an OLR, it typically needs to=20 > insert that OLR into an existing Diameter answer created by a server.=20 > It can't create its own answer without affecting the application=20 > state. If the responding node assumes the OLR comes from or refers to=20 > the node identified by the Origin-Host AVP in the enclosing answer,=20 > things break. (For examples of when an agent needs to send OLRs that=20 > are distinct from those sent by a server, see Steve's agent overload=20 > draft, or my dh/dr example.) >=20 > OTOH, explicit values will work for all cases where we need to associate = some arbitrary value with an OLR. >=20 > 4) Implicit values seriously constrain the future evolution of Diameter O= C standards. For example, lets say we find a good reason to allow OLRs to b= e sent out of band, or be sent in a dedicated Diameter application. If over= load 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 transpo= rted, this won't work. We would have to create a new or significantly modif= ied OLR format if we found a need to transport OLRs in different ways. Self= -contained OLRs would allow much greater flexibility. >=20 > So, in summary, I think that self-contained OLRs would lead to simpler im= plementations, less brittle deployments, and more flexibility for future ev= olution of standards. >=20 > Thanks! >=20 > 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 confiden= tielles 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. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation 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 dele= te 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 confiden= tielles 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. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation 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 dele= te 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 From nsalot@cisco.com Sun Dec 1 22:05:08 2013 Return-Path: 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 E20791AE269 for ; Sun, 1 Dec 2013 22:05:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.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 9-4kMmdd12UM for ; Sun, 1 Dec 2013 22:05:06 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 25A341AE15C for ; Sun, 1 Dec 2013 22:05:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15716; q=dns/txt; s=iport; t=1385964304; x=1387173904; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=TtGRIHRIx8hNINjMYJ9a0Xlc4EL8UKlE2Z8pDRgljC4=; b=jOEUvlYnRfmPFuTsS1wn+o/SElXYcJormvBCrseU7czJmram/+z+3I2w eu81U5skoZBQ4g/mdQjakOk0iWtcx46MU19zvY670xJzVzgfTrkOkouFL ndVrY74dp8bOjAnXp4/sBdzG338LzcXswBZOOIEhCJzkNOim2xoQpDtqU c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAEoinFKtJV2c/2dsb2JhbABZgwc4U7hWgSEWdIIlAQEBAwEBAQFkBwsFBwQCAQgRAQMBAQsdBycLFAMGCAIEAQ0FCBOHYAYNvlUTBI4mEAIBHjEHBoMagRMDiQqhHYMpgio X-IronPort-AV: E=Sophos;i="4.93,808,1378857600"; d="scan'208";a="288660537" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 02 Dec 2013 06:05:03 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id rB2653Ng007736 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 2 Dec 2013 06:05:03 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.250]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Mon, 2 Dec 2013 00:05:03 -0600 From: "Nirav Salot (nsalot)" To: "Wiehe, Ulrich (NSN - DE/Munich)" , "ext lionel.morand@orange.com" , ext Jouni Korhonen , Ben Campbell Thread-Topic: [Dime] DOIC: Self-Contained OLRs Thread-Index: AQHO67/s/vGpiVuf2UayvwQoJbzwfZo6EVYAgACzUoCAAAFygIAAEJwAgAGNqACAAB+RgP//2REwgAPJ1wCAAEThgA== Date: Mon, 2 Dec 2013 06:05:02 +0000 Message-ID: References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D90006681519BC90@DEMUMBX014.nsn-intra.net> <6390_1385631044_52970D44_6390_18593_1_6B7134B31289DC4FAF731D844122B36E30748E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BD19@DEMUMBX014.nsn-intra.net> <17872_1385720008_529868C8_17872_2613_1_6B7134B31289DC4FAF731D844122B36E3096B8@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BF1B@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681519BFAE@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681519BFAE@DEMUMBX014.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.63.248] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dime@ietf.org list" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 06:05:09 -0000 Ulrich, When the client sends request containing destination-realm (and not contain= ing destination-host), it gets back answer containing origin-host (set by t= he 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.=20 On the other hand, we discussed - as part of Maria Cruz's alternative solut= ion - to define the response message's context based on the request message= . And hence if the request message was sent to destination-realm, the corre= sponding response message can only contain realm-type OLR. But this requires the client to remember the context of the request while p= rocessing the response and hence it was considered as introducing unnecessa= ry complexity.=20 If we strictly want to ensure that the realm-type OLR is not sent out-of-co= ntext, then we should agree to Lionel's alternative solution - to send real= m-type OLR only when the destination-realm based request is rejected. So ba= sically, realm-type OLR is never included in a response message which conta= ins origin-host AVP. (And I am ready to reconsider the same if we want to e= nsure the context of the response message and the OLR it contains). However, as per our current agreement, we are introducing Report-Type AVP t= o allow the inclusion of host-type and realm-type OLRs in the response mess= age. If we say that the client can ignore one of the OLRs, then what is the poin= t of including two OLRs and what is the point of defining Report-Type AVP? 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. 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 ign= ored. Regards, Nirav. -----Original Message----- From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 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 O= LR is out-of-context. Similary, when the client sends a request containing destination host and g= ets 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 respons= es received within the context. Best regards Ulrich=20 -----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 Joun= i 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 i= n the answer and additional OLRs (not created by the reporting endpoint) ma= y just be present as an optional optimization i.e. optionally inserted by t= he reporting endpoint and optionally ignored by the reacting endpoint. Ulrich =20 -----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 subs= equent request towards the origin-host of the answer containing the OLR. Us= ing 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.=20 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=A0: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Envoy= =E9=A0: jeudi 28 novembre 2013 11:30 =C0=A0: MORAND Lionel IMT/OLN; ext Jou= ni Korhonen; Ben Campbell Cc=A0: dime@ietf.org list Objet=A0: RE: [Dime] DO= IC: 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 act= ual OLR created by the reporting end point and which OLR is an additional O= LR created by another node. We have two cases: a) The request sent by the client (reacting end point) contains no Destinat= ion Host. The agent (reporting node) (after forwarding the request to the s= elected server and receiving the answer) returns a realm-type OLR as the ac= tual 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 Destinat= ion 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 stat= us. It could be provided an agent inserting this info in answers received f= rom a server behind but also from a server that would know this info by som= e internal magic. But in any case, if we assume that the client will received a successful an= swer from the server for an initial request with only Dest-Realm AVP, it sh= ould be possible to have both report types in the answer: one for the serve= r itself, one for the realm for new request sent to the realm with only Des= t-Realm AVP. Lionel -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN= - DE/Munich) Envoy=E9=A0: jeudi 28 novembre 2013 10:26 =C0=A0: ext Jouni K= orhonen; Ben Campbell Cc=A0: dime@ietf.org list Objet=A0: Re: [Dime] DOIC: = Self-Contained OLRs Hi, I don't see how the possibility to send more than one OLR in an answer is a= ligned with the "endpoint principle". If the ReportType is "realm" this ind= icates 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 wrote: > Hi, >=20 > I mentioned in another thread that I prefer putting an explicit=20 > ReportType AVP in an OLR, rather than The more I spent time thinking/writing the actual procedures on the endpoin= ts, the more it makes sense to me to keep the ReportType in the OC-OLR. Eve= n if the baseline does not have agent overload etc, the ReportType fits wel= l to the "endpoint principle" we have in the draft. It indeed gives more to= ols to make a host vs. realm base decision on the reacting node and is plai= n 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 Diam= eter request that corresponds to the answer containing the OLR. My reasons = for that go beyond just ReportType, so I'm starting a separate thread. >=20 > As currently described, a consumer of an OLR must infer several things fr= om other context. In most cases, that context is in the Diameter answer tha= t carries the OLR. For example, the OLR implicitly refers to the applicatio= n 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 meani= ng in the context of the enclosing answer. If you moved an OLR from one ans= wer to another, it's meaning may change completely. >=20 > I think this approach is a mistake. I would greatly prefer that we explic= itly include such values in the OLR itself, for multiple reasons: >=20 > 1) It's more complex to interpret implicit, contextual values than explic= it values. The consumer cannot simply look at the OLR; it must look in vari= ous other AVPs to find all the information it needs. For example, I think a= common software design for overload control processing to be separated fro= m application processing. The consumer cannot simply hand the OLR to that m= odule 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 "con= text" avps that must be interpreted can grow large. This approach is error = prone, and will likely encourage brittle, hard-to-maintain code. Self-conta= ined OLRs would keep all the information related to overload in one place. = making for simpler implementations. >=20 > 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 r= eporting node realizes that it is overloade, it has to wait for the right a= nswer that contains the right context before it can send the OLR. This is p= articularly troublesome for agents, since they will typically have to inser= t OLRs into answers created by other nodes.=20 >=20 > If the reporting node screws this up, the meaning of the OLR may change s= ignificantly. So again, implicit meaning gives us error prone implementatio= ns. Self-contained OLRs are simpler to create and send. >=20 > 3) Implicit values don't work at all for certain problems. For=20 > example, if an agent needs to originate an OLR, it typically needs to=20 > insert that OLR into an existing Diameter answer created by a server. > It can't create its own answer without affecting the application=20 > state. If the responding node assumes the OLR comes from or refers to=20 > the node identified by the Origin-Host AVP in the enclosing answer,=20 > things break. (For examples of when an agent needs to send OLRs that=20 > are distinct from those sent by a server, see Steve's agent overload=20 > draft, or my dh/dr example.) >=20 > OTOH, explicit values will work for all cases where we need to associate = some arbitrary value with an OLR. >=20 > 4) Implicit values seriously constrain the future evolution of Diameter O= C standards. For example, lets say we find a good reason to allow OLRs to b= e sent out of band, or be sent in a dedicated Diameter application. If over= load 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 transpo= rted, this won't work. We would have to create a new or significantly modif= ied OLR format if we found a need to transport OLRs in different ways. Self= -contained OLRs would allow much greater flexibility. >=20 > So, in summary, I think that self-contained OLRs would lead to simpler im= plementations, less brittle deployments, and more flexibility for future ev= olution of standards. >=20 > Thanks! >=20 > 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 confiden= tielles 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. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation 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 dele= te 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 confiden= tielles 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. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation 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 dele= te 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 From jounikor@gmail.com Sun Dec 1 23:55:42 2013 Return-Path: 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 73AE81AE359 for ; Sun, 1 Dec 2013 23:55:42 -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 40OukC5vu9SL for ; Sun, 1 Dec 2013 23:55:41 -0800 (PST) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id E117A1AE355 for ; Sun, 1 Dec 2013 23:55:40 -0800 (PST) Received: by mail-la0-f41.google.com with SMTP id eo20so8067775lab.14 for ; Sun, 01 Dec 2013 23:55:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version; bh=Oyql5kz3A2IfjO4sxD/kbOZCbtLKWW1cgwYmpq7GPXQ=; b=X3IPY0rlBsMcYeZbRMLiF48P1TkXk9yGrkOR1+qhxGaFHWhxW6fv7WDg/NaSc3sZNQ d0lynis22XCnXq5bwzDZgM18Djio/nvdFTyLZCk+gBEifYScYrjkWpNy/uJwIgcGsWeD atglVkE29I3aLU1DHoyuczDZu/cyr1KUeVaWRI/+zEx3hnzZIIjoa1xUlgTcwP4xTd8d yg2bL2nPPT55AIn8MA4XDUlsDgo/voZC0uDIcqTFN6XroBq+RjcR/AO76uIrw005xyPE 5849L5+S+0Jc0DGT5vGPKpqKYPdhyfeoArSXb9Hm6FAuV14c4PCuD5DvuS6fBrjHcoIo qxOA== X-Received: by 10.112.29.147 with SMTP id k19mr42568493lbh.9.1385970937928; Sun, 01 Dec 2013 23:55:37 -0800 (PST) Received: from [188.117.15.107] ([188.117.15.107]) by mx.google.com with ESMTPSA id rb4sm2296860lbb.1.2013.12.01.23.55.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 01 Dec 2013 23:55:36 -0800 (PST) From: Jouni Korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 2 Dec 2013 09:55:35 +0200 Message-Id: <16E13E52-0DB9-4E72-964A-FE658536155B@gmail.com> To: "DiME@ietf.org" Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-Mailman-Approved-At: Sun, 01 Dec 2013 23:56:43 -0800 Subject: [Dime] draft-ietf-dime-ovli-01 questions #1 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 07:55:42 -0000 Hi, In Section 2 on Diameter routing it says: defined in [RFC6733]. Application level routing specifications that expand on [RFC6733] also exist. What does this "expand" actually refer to? RFC5729? RFC7075? - Jouni From lionel.morand@orange.com Mon Dec 2 00:04:54 2013 Return-Path: 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 4DA6E1AE355 for ; Mon, 2 Dec 2013 00:04:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 OkXA39Fcuthw for ; Mon, 2 Dec 2013 00:04:52 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 177571A1F55 for ; Mon, 2 Dec 2013 00:04:51 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id F0F193B4127; Mon, 2 Dec 2013 09:04:48 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id D84BF4C015; Mon, 2 Dec 2013 09:04:48 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0158.001; Mon, 2 Dec 2013 09:04:48 +0100 From: To: "DiME@ietf.org" , Jouni Korhonen Thread-Topic: [Dime] draft-ietf-dime-ovli-01 questions #1 Thread-Index: AQHO7zQNzQCE3TCNBEalkDVXC4zCcJpAi+8I Date: Mon, 2 Dec 2013 08:04:48 +0000 Message-ID: <10629_1385971488_529C3F20_10629_5138_1_emlwd34vyt318xrd8i01xiee.1385971482719@email.android.com> References: <16E13E52-0DB9-4E72-964A-FE658536155B@gmail.com> In-Reply-To: <16E13E52-0DB9-4E72-964A-FE658536155B@gmail.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.12.2.11814 Subject: Re: [Dime] draft-ietf-dime-ovli-01 questions #1 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 08:04:54 -0000 It was my understanding. Envoy=E9 depuis mon Sony Xperia SP d'Orange Jouni Korhonen a =E9crit : Hi, In Section 2 on Diameter routing it says: defined in [RFC6733]. Application level routing specifications that expand on [RFC6733] also exist. What does this "expand" actually refer to? RFC5729? RFC7075? - Jouni _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. From jouni.nospam@gmail.com Mon Dec 2 00:25:06 2013 Return-Path: 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 60C871AE45B for ; Mon, 2 Dec 2013 00:25:06 -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 RBxlGDS_Tq4q for ; Mon, 2 Dec 2013 00:25:05 -0800 (PST) Received: from mail-bk0-x236.google.com (mail-bk0-x236.google.com [IPv6:2a00:1450:4008:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id E35D81AE459 for ; Mon, 2 Dec 2013 00:25:04 -0800 (PST) Received: by mail-bk0-f54.google.com with SMTP id v16so5312049bkz.27 for ; Mon, 02 Dec 2013 00:25:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version; bh=v8PU9NBiefJqRVMAATbsnDQrHS5L6FS6M8P0+xx0fN0=; b=0vm+GW2yCIiSH/uDUHIR9AgfyEChDMWAc+XFvcEZOj9I+2IJjLmWAQY3/QkojEvmj9 XHVC+2D6BbLW2Vjzzla0cVj6J4LrTN9MeLyOQuG0cRxKWExOGe/Qh5gSBDtOTKP0kVlU U3OF7BwxnX6UgiVbcfRL0zD8zTaMQVePL1a0EAewjXVnxu1wWSxlB7jvixHkHWqv9Nzc qZs2r68UMzipdzSr2AssK8N/va9zwq7IX/brfv0N0GUrL0UMkEoodtXpl+vqUBUIB2PZ JlMNs2Q699ahw6Tg0/PrLdd8XSAGpZlZuyLPu0NEO9JU+C83lfT/TEMLqj1pZnqtVZ7X 4c/A== X-Received: by 10.205.18.73 with SMTP id qf9mr15398893bkb.12.1385972701832; Mon, 02 Dec 2013 00:25:01 -0800 (PST) Received: from ?IPv6:2001:1bc8:101:f101:403:b3e3:4af7:8d0a? ([2001:1bc8:101:f101:403:b3e3:4af7:8d0a]) by mx.google.com with ESMTPSA id o5sm21382367bkz.4.2013.12.02.00.25.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 02 Dec 2013 00:25:01 -0800 (PST) From: Jouni Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 2 Dec 2013 10:24:59 +0200 Message-Id: <2D60D862-45C5-4B13-96E6-F9621AF33759@gmail.com> To: "DiME@ietf.org" Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Subject: [Dime] draft-ietf-dime-ovli-01 questions #2 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 08:25:06 -0000 In Section 3.1.1 where pseudo-session applications are discussed shouldn't we also state that the pseudo-session application is somewhat a SDO specific jewel? IMHO it is not really what RFC6733 session-less application is, although from the base protocol point of view it is compliant. - Jouni From lionel.morand@orange.com Mon Dec 2 01:06:40 2013 Return-Path: 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 7A12D1AE25C for ; Mon, 2 Dec 2013 01:06:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 AkIqn_vFoCok for ; Mon, 2 Dec 2013 01:06:38 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id 876BC1AE38A for ; Mon, 2 Dec 2013 01:06:35 -0800 (PST) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 5DA9D2AC48A; Mon, 2 Dec 2013 10:06:32 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 05189158072; Mon, 2 Dec 2013 10:06:32 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0158.001; Mon, 2 Dec 2013 10:06:31 +0100 From: To: Jouni , "DiME@ietf.org" Thread-Topic: [Dime] draft-ietf-dime-ovli-01 questions #2 Thread-Index: AQHO7zgFymEqO+XoAkOsBov9JhbWn5pAmZqQ Date: Mon, 2 Dec 2013 09:06:31 +0000 Message-ID: <19936_1385975192_529C4D98_19936_10950_1_6B7134B31289DC4FAF731D844122B36E30F190@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <2D60D862-45C5-4B13-96E6-F9621AF33759@gmail.com> In-Reply-To: <2D60D862-45C5-4B13-96E6-F9621AF33759@gmail.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.12.2.53015 Subject: Re: [Dime] draft-ietf-dime-ovli-01 questions #2 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 09:06:40 -0000 Hi, Not sure that it is so "SDO" specific. But it is true that we should clarif= y that this concept is not clearly described in RFC6733 and it is up to the= application to define the specific session states when not relying on the = session-id and the session state machine defined in RFC6733. Lionel -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Jouni Envoy=E9=A0: lundi 2 d=E9cembre 2013 09:25 =C0=A0: DiME@ietf.org Objet=A0: [Dime] draft-ietf-dime-ovli-01 questions #2 In Section 3.1.1 where pseudo-session applications are discussed shouldn't we also state that the pseudo-session application is somewhat a SDO specific jewel? IMHO it is not really what RFC6733 session-less application is, although from the base protocol point of view it is compliant. - Jouni _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. From ulrich.wiehe@nsn.com Mon Dec 2 02:59:49 2013 Return-Path: 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 AC2251AE282 for ; Mon, 2 Dec 2013 02:59:49 -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 T-kdqV6aFcch for ; Mon, 2 Dec 2013 02:59:46 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 47FCA1AE2DC for ; Mon, 2 Dec 2013 02:59:45 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rB2Axc18032008 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 2 Dec 2013 11:59:38 +0100 Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rB2Axbto003867 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 2 Dec 2013 11:59:38 +0100 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.123.3; Mon, 2 Dec 2013 11:59:37 +0100 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.152]) by DEMUHTC013.nsn-intra.net ([10.159.42.44]) with mapi id 14.03.0123.003; Mon, 2 Dec 2013 11:59:37 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: "ext Nirav Salot (nsalot)" , "ext lionel.morand@orange.com" , ext Jouni Korhonen , Ben Campbell Thread-Topic: [Dime] DOIC: Self-Contained OLRs Thread-Index: AQHO67/t2PaAGa/GgUyaCwjRxXVUh5o5m/0AgAC8o/D///ghgIAAFu+wgAGHVQCAACqasIAAMwWAgANxipCAAKJuAIAATHjQ Date: Mon, 2 Dec 2013 10:59:37 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519C017@DEMUMBX014.nsn-intra.net> References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D90006681519BC90@DEMUMBX014.nsn-intra.net> <6390_1385631044_52970D44_6390_18593_1_6B7134B31289DC4FAF731D844122B36E30748E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BD19@DEMUMBX014.nsn-intra.net> <17872_1385720008_529868C8_17872_2613_1_6B7134B31289DC4FAF731D844122B36E3096B8@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BF1B@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681519BFAE@DEMUMBX014.nsn-intra.net> In-Reply-To: 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: 18326 X-purgate-ID: 151667::1385981979-000022AE-B54ACA6E/0-0/0-0 Cc: "dime@ietf.org list" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 10:59:49 -0000 Hi Nirav, please see inline. Regards Ulrich -----Original Message----- From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com]=20 Sent: Monday, December 02, 2013 7:05 AM To: Wiehe, Ulrich (NSN - DE/Munich); ext lionel.morand@orange.com; ext Joun= i 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 contain= ing destination-host), it gets back answer containing origin-host (set by t= he 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.=20 [Wiehe, Ulrich (NSN - DE/Munich)] But we do not purely take the response me= ssage perspective. The client sends a request of type x (destination host = =3Dx1, destination realm =3Dx2 application=3D x3) and gets back an OLR in t= he answer which says "please throttle request of the type you just sent". T= he client either remembers, or deduces from info received in the answer, wh= at the type x was. E.g. it deduces from the value of Origin Realm in the an= swer the value of Destination Realm in the request; it deduces from the val= ue 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 solut= ion - to define the response message's context based on the request message= . And hence if the request message was sent to destination-realm, the corre= sponding response message can only contain realm-type OLR. But this requires the client to remember the context of the request while p= rocessing the response and hence it was considered as introducing unnecessa= ry complexity.=20 [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-co= ntext [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 includ= ing out-of-context OLRs) , then we should agree to Lionel's alternative solution - to send realm-typ= e OLR only when the destination-realm based request is rejected. So basical= ly, realm-type OLR is never included in a response message which contains o= rigin-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 me= ssage. [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 th= e reporting node and must be processed by the reacting node; the out-of-con= text 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 info= rmation 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 ign= ored. [Wiehe, Ulrich (NSN - DE/Munich)] Not the Report-Type AVP is the optimizati= on 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]=20 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 O= LR is out-of-context. Similary, when the client sends a request containing destination host and g= ets 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 respons= es received within the context. Best regards Ulrich=20 -----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 Joun= i 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 i= n the answer and additional OLRs (not created by the reporting endpoint) ma= y just be present as an optional optimization i.e. optionally inserted by t= he reporting endpoint and optionally ignored by the reacting endpoint. Ulrich =20 -----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 subs= equent request towards the origin-host of the answer containing the OLR. Us= ing 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.=20 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=A0: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Envoy= =E9=A0: jeudi 28 novembre 2013 11:30 =C0=A0: MORAND Lionel IMT/OLN; ext Jou= ni Korhonen; Ben Campbell Cc=A0: dime@ietf.org list Objet=A0: RE: [Dime] DO= IC: 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 act= ual OLR created by the reporting end point and which OLR is an additional O= LR created by another node. We have two cases: a) The request sent by the client (reacting end point) contains no Destinat= ion Host. The agent (reporting node) (after forwarding the request to the s= elected server and receiving the answer) returns a realm-type OLR as the ac= tual 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 Destinat= ion 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 stat= us. It could be provided an agent inserting this info in answers received f= rom a server behind but also from a server that would know this info by som= e internal magic. But in any case, if we assume that the client will received a successful an= swer from the server for an initial request with only Dest-Realm AVP, it sh= ould be possible to have both report types in the answer: one for the serve= r itself, one for the realm for new request sent to the realm with only Des= t-Realm AVP. Lionel -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN= - DE/Munich) Envoy=E9=A0: jeudi 28 novembre 2013 10:26 =C0=A0: ext Jouni K= orhonen; Ben Campbell Cc=A0: dime@ietf.org list Objet=A0: Re: [Dime] DOIC: = Self-Contained OLRs Hi, I don't see how the possibility to send more than one OLR in an answer is a= ligned with the "endpoint principle". If the ReportType is "realm" this ind= icates 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 wrote: > Hi, >=20 > I mentioned in another thread that I prefer putting an explicit=20 > ReportType AVP in an OLR, rather than The more I spent time thinking/writing the actual procedures on the endpoin= ts, the more it makes sense to me to keep the ReportType in the OC-OLR. Eve= n if the baseline does not have agent overload etc, the ReportType fits wel= l to the "endpoint principle" we have in the draft. It indeed gives more to= ols to make a host vs. realm base decision on the reacting node and is plai= n 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 Diam= eter request that corresponds to the answer containing the OLR. My reasons = for that go beyond just ReportType, so I'm starting a separate thread. >=20 > As currently described, a consumer of an OLR must infer several things fr= om other context. In most cases, that context is in the Diameter answer tha= t carries the OLR. For example, the OLR implicitly refers to the applicatio= n 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 meani= ng in the context of the enclosing answer. If you moved an OLR from one ans= wer to another, it's meaning may change completely. >=20 > I think this approach is a mistake. I would greatly prefer that we explic= itly include such values in the OLR itself, for multiple reasons: >=20 > 1) It's more complex to interpret implicit, contextual values than explic= it values. The consumer cannot simply look at the OLR; it must look in vari= ous other AVPs to find all the information it needs. For example, I think a= common software design for overload control processing to be separated fro= m application processing. The consumer cannot simply hand the OLR to that m= odule 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 "con= text" avps that must be interpreted can grow large. This approach is error = prone, and will likely encourage brittle, hard-to-maintain code. Self-conta= ined OLRs would keep all the information related to overload in one place. = making for simpler implementations. >=20 > 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 r= eporting node realizes that it is overloade, it has to wait for the right a= nswer that contains the right context before it can send the OLR. This is p= articularly troublesome for agents, since they will typically have to inser= t OLRs into answers created by other nodes.=20 >=20 > If the reporting node screws this up, the meaning of the OLR may change s= ignificantly. So again, implicit meaning gives us error prone implementatio= ns. Self-contained OLRs are simpler to create and send. >=20 > 3) Implicit values don't work at all for certain problems. For=20 > example, if an agent needs to originate an OLR, it typically needs to=20 > insert that OLR into an existing Diameter answer created by a server. > It can't create its own answer without affecting the application=20 > state. If the responding node assumes the OLR comes from or refers to=20 > the node identified by the Origin-Host AVP in the enclosing answer,=20 > things break. (For examples of when an agent needs to send OLRs that=20 > are distinct from those sent by a server, see Steve's agent overload=20 > draft, or my dh/dr example.) >=20 > OTOH, explicit values will work for all cases where we need to associate = some arbitrary value with an OLR. >=20 > 4) Implicit values seriously constrain the future evolution of Diameter O= C standards. For example, lets say we find a good reason to allow OLRs to b= e sent out of band, or be sent in a dedicated Diameter application. If over= load 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 transpo= rted, this won't work. We would have to create a new or significantly modif= ied OLR format if we found a need to transport OLRs in different ways. Self= -contained OLRs would allow much greater flexibility. >=20 > So, in summary, I think that self-contained OLRs would lead to simpler im= plementations, less brittle deployments, and more flexibility for future ev= olution of standards. >=20 > Thanks! >=20 > 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 confiden= tielles 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. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation 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 dele= te 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 confiden= tielles 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. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation 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 dele= te 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 From nsalot@cisco.com Mon Dec 2 03:24:58 2013 Return-Path: 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 9FAAA1AE3C7 for ; Mon, 2 Dec 2013 03:24:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.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 d4Ck2M750mkL for ; Mon, 2 Dec 2013 03:24:55 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id F0D251AE3C3 for ; Mon, 2 Dec 2013 03:24:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18971; q=dns/txt; s=iport; t=1385983493; x=1387193093; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=taSqbf/sD8jMOdU0g3ha45VUE/KHI0wzdNwjcRauIVU=; b=EhAGOrEZnS2tytesZgoKUJK/dVKkHIW48xNLOrUH221reJiTLrs1AP9b wPjvnJwoZTDU+gyCLlFMl9NtDzJELwgvh7xvhUMNONq8Lj8ZMfXMFxC7W jNIXGNnp1aH53cHEaStpsDwC0qmfW7Iv0SiNyJvd6sr2DUrx2uDewHCDQ c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkAFAExtnFKtJXG8/2dsb2JhbABZgwc4U3y3XIEkFnSCJQEBAQMBAQEBZAcLBQcEAgEIEQEDAQELHQcnCxQDBggCBAENBQgTh2AGDb8zEwSOJhACAR4xBwaDGoETA4kKoR2DKYIq X-IronPort-AV: E=Sophos;i="4.93,810,1378857600"; d="scan'208";a="3605715" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by alln-iport-5.cisco.com with ESMTP; 02 Dec 2013 11:24:52 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id rB2BOqZr031435 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 2 Dec 2013 11:24:52 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.250]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0123.003; Mon, 2 Dec 2013 05:24:51 -0600 From: "Nirav Salot (nsalot)" To: "Wiehe, Ulrich (NSN - DE/Munich)" , "ext lionel.morand@orange.com" , ext Jouni Korhonen , Ben Campbell Thread-Topic: [Dime] DOIC: Self-Contained OLRs Thread-Index: AQHO67/s/vGpiVuf2UayvwQoJbzwfZo6EVYAgACzUoCAAAFygIAAEJwAgAGNqACAAB+RgP//2REwgAPJ1wCAAEThgIAAvIuA//+diaA= Date: Mon, 2 Dec 2013 11:24:51 +0000 Message-ID: References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D90006681519BC90@DEMUMBX014.nsn-intra.net> <6390_1385631044_52970D44_6390_18593_1_6B7134B31289DC4FAF731D844122B36E30748E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BD19@DEMUMBX014.nsn-intra.net> <17872_1385720008_529868C8_17872_2613_1_6B7134B31289DC4FAF731D844122B36E3096B8@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BF1B@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681519BFAE@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681519C017@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681519C017@DEMUMBX014.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.63.248] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dime@ietf.org list" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 11:24:58 -0000 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 thi= s OLR applicable for realm or host? I am trying to understand which is out-of-context OLR here: realm-type or h= ost-type? Regards, Nirav. -----Original Message----- From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 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 Joun= i 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 contain= ing destination-host), it gets back answer containing origin-host (set by t= he 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.=20 [Wiehe, Ulrich (NSN - DE/Munich)] But we do not purely take the response me= ssage perspective. The client sends a request of type x (destination host = =3Dx1, destination realm =3Dx2 application=3D x3) and gets back an OLR in t= he answer which says "please throttle request of the type you just sent". T= he client either remembers, or deduces from info received in the answer, wh= at the type x was. E.g. it deduces from the value of Origin Realm in the an= swer the value of Destination Realm in the request; it deduces from the val= ue 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 solut= ion - to define the response message's context based on the request message= . And hence if the request message was sent to destination-realm, the corre= sponding response message can only contain realm-type OLR. But this requires the client to remember the context of the request while p= rocessing the response and hence it was considered as introducing unnecessa= ry complexity.=20 [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-co= ntext [Wiehe, Ulrich (NSN - DE/Munich)] That was not my proposal. My propos= al 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-typ= e OLR only when the destination-realm based request is rejected. So basical= ly, realm-type OLR is never included in a response message which contains o= rigin-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-ty= pe 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/Mun= ich)] 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 a= gent wants to offer this optimization), and may be processed by the reactin= g 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 info= rmation 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 ign= ored. [Wiehe, Ulrich (NSN - DE/Munich)] Not the Report-Type AVP is the optimizati= on 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 O= LR is out-of-context. Similary, when the client sends a request containing destination host and g= ets 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 respons= es received within the context. Best regards Ulrich=20 -----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 Joun= i 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 i= n the answer and additional OLRs (not created by the reporting endpoint) ma= y just be present as an optional optimization i.e. optionally inserted by t= he reporting endpoint and optionally ignored by the reacting endpoint. Ulrich =20 -----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 subs= equent request towards the origin-host of the answer containing the OLR. Us= ing 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.=20 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=A0: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Envoy= =E9=A0: jeudi 28 novembre 2013 11:30 =C0=A0: MORAND Lionel IMT/OLN; ext Jou= ni Korhonen; Ben Campbell Cc=A0: dime@ietf.org list Objet=A0: RE: [Dime] DO= IC: 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 act= ual OLR created by the reporting end point and which OLR is an additional O= LR created by another node. We have two cases: a) The request sent by the client (reacting end point) contains no Destinat= ion Host. The agent (reporting node) (after forwarding the request to the s= elected server and receiving the answer) returns a realm-type OLR as the ac= tual 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 Destinat= ion 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 stat= us. It could be provided an agent inserting this info in answers received f= rom a server behind but also from a server that would know this info by som= e internal magic. But in any case, if we assume that the client will received a successful an= swer from the server for an initial request with only Dest-Realm AVP, it sh= ould be possible to have both report types in the answer: one for the serve= r itself, one for the realm for new request sent to the realm with only Des= t-Realm AVP. Lionel -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN= - DE/Munich) Envoy=E9=A0: jeudi 28 novembre 2013 10:26 =C0=A0: ext Jouni K= orhonen; Ben Campbell Cc=A0: dime@ietf.org list Objet=A0: Re: [Dime] DOIC: = Self-Contained OLRs Hi, I don't see how the possibility to send more than one OLR in an answer is a= ligned with the "endpoint principle". If the ReportType is "realm" this ind= icates 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 wrote: > Hi, >=20 > I mentioned in another thread that I prefer putting an explicit=20 > ReportType AVP in an OLR, rather than The more I spent time thinking/writing the actual procedures on the endpoin= ts, the more it makes sense to me to keep the ReportType in the OC-OLR. Eve= n if the baseline does not have agent overload etc, the ReportType fits wel= l to the "endpoint principle" we have in the draft. It indeed gives more to= ols to make a host vs. realm base decision on the reacting node and is plai= n 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 Diam= eter request that corresponds to the answer containing the OLR. My reasons = for that go beyond just ReportType, so I'm starting a separate thread. >=20 > As currently described, a consumer of an OLR must infer several things fr= om other context. In most cases, that context is in the Diameter answer tha= t carries the OLR. For example, the OLR implicitly refers to the applicatio= n 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 meani= ng in the context of the enclosing answer. If you moved an OLR from one ans= wer to another, it's meaning may change completely. >=20 > I think this approach is a mistake. I would greatly prefer that we explic= itly include such values in the OLR itself, for multiple reasons: >=20 > 1) It's more complex to interpret implicit, contextual values than explic= it values. The consumer cannot simply look at the OLR; it must look in vari= ous other AVPs to find all the information it needs. For example, I think a= common software design for overload control processing to be separated fro= m application processing. The consumer cannot simply hand the OLR to that m= odule 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 "con= text" avps that must be interpreted can grow large. This approach is error = prone, and will likely encourage brittle, hard-to-maintain code. Self-conta= ined OLRs would keep all the information related to overload in one place. = making for simpler implementations. >=20 > 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 r= eporting node realizes that it is overloade, it has to wait for the right a= nswer that contains the right context before it can send the OLR. This is p= articularly troublesome for agents, since they will typically have to inser= t OLRs into answers created by other nodes.=20 >=20 > If the reporting node screws this up, the meaning of the OLR may change s= ignificantly. So again, implicit meaning gives us error prone implementatio= ns. Self-contained OLRs are simpler to create and send. >=20 > 3) Implicit values don't work at all for certain problems. For=20 > example, if an agent needs to originate an OLR, it typically needs to=20 > insert that OLR into an existing Diameter answer created by a server. > It can't create its own answer without affecting the application=20 > state. If the responding node assumes the OLR comes from or refers to=20 > the node identified by the Origin-Host AVP in the enclosing answer,=20 > things break. (For examples of when an agent needs to send OLRs that=20 > are distinct from those sent by a server, see Steve's agent overload=20 > draft, or my dh/dr example.) >=20 > OTOH, explicit values will work for all cases where we need to associate = some arbitrary value with an OLR. >=20 > 4) Implicit values seriously constrain the future evolution of Diameter O= C standards. For example, lets say we find a good reason to allow OLRs to b= e sent out of band, or be sent in a dedicated Diameter application. If over= load 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 transpo= rted, this won't work. We would have to create a new or significantly modif= ied OLR format if we found a need to transport OLRs in different ways. Self= -contained OLRs would allow much greater flexibility. >=20 > So, in summary, I think that self-contained OLRs would lead to simpler im= plementations, less brittle deployments, and more flexibility for future ev= olution of standards. >=20 > Thanks! >=20 > 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 confiden= tielles 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. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation 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 dele= te 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 confiden= tielles 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. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation 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 dele= te 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 From ulrich.wiehe@nsn.com Mon Dec 2 03:57:56 2013 Return-Path: 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 885D41AE451 for ; Mon, 2 Dec 2013 03:57:56 -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 rXVBLt9vtTGj for ; Mon, 2 Dec 2013 03:57:53 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 713AB1AE3FC for ; Mon, 2 Dec 2013 03:57:52 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rB2BvjaS019258 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 2 Dec 2013 12:57:45 +0100 Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rB2BvhK2023745 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 2 Dec 2013 12:57:44 +0100 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.152]) by DEMUHTC002.nsn-intra.net ([10.159.42.33]) with mapi id 14.03.0123.003; Mon, 2 Dec 2013 12:57:44 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: "ext Nirav Salot (nsalot)" , "ext lionel.morand@orange.com" , ext Jouni Korhonen , Ben Campbell Thread-Topic: [Dime] DOIC: Self-Contained OLRs Thread-Index: AQHO67/t2PaAGa/GgUyaCwjRxXVUh5o5m/0AgAC8o/D///ghgIAAFu+wgAGHVQCAACqasIAAMwWAgANxipCAAKJuAIAATHjQgAAM5ICAABPPEA== Date: Mon, 2 Dec 2013 11:57:43 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519C087@DEMUMBX014.nsn-intra.net> References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D90006681519BC90@DEMUMBX014.nsn-intra.net> <6390_1385631044_52970D44_6390_18593_1_6B7134B31289DC4FAF731D844122B36E30748E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BD19@DEMUMBX014.nsn-intra.net> <17872_1385720008_529868C8_17872_2613_1_6B7134B31289DC4FAF731D844122B36E3096B8@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BF1B@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681519BFAE@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681519C017@DEMUMBX014.nsn-intra.net> In-Reply-To: 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: 19685 X-purgate-ID: 151667::1385985465-00006154-DB19AA92/0-0/0-0 Cc: "dime@ietf.org list" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 11:57:56 -0000 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 answe= r 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 OL= R in the answer would be in-context. Ulrich -----Original Message----- From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com]=20 Sent: Monday, December 02, 2013 12:25 PM To: Wiehe, Ulrich (NSN - DE/Munich); ext lionel.morand@orange.com; ext Joun= i 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 thi= s OLR applicable for realm or host? I am trying to understand which is out-of-context OLR here: realm-type or h= ost-type? Regards, Nirav. -----Original Message----- From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 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 Joun= i 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 contain= ing destination-host), it gets back answer containing origin-host (set by t= he 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.=20 [Wiehe, Ulrich (NSN - DE/Munich)] But we do not purely take the response me= ssage perspective. The client sends a request of type x (destination host = =3Dx1, destination realm =3Dx2 application=3D x3) and gets back an OLR in t= he answer which says "please throttle request of the type you just sent". T= he client either remembers, or deduces from info received in the answer, wh= at the type x was. E.g. it deduces from the value of Origin Realm in the an= swer the value of Destination Realm in the request; it deduces from the val= ue 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 solut= ion - to define the response message's context based on the request message= . And hence if the request message was sent to destination-realm, the corre= sponding response message can only contain realm-type OLR. But this requires the client to remember the context of the request while p= rocessing the response and hence it was considered as introducing unnecessa= ry complexity.=20 [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-co= ntext [Wiehe, Ulrich (NSN - DE/Munich)] That was not my proposal. My propos= al 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-typ= e OLR only when the destination-realm based request is rejected. So basical= ly, realm-type OLR is never included in a response message which contains o= rigin-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-ty= pe 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/Mun= ich)] 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 a= gent wants to offer this optimization), and may be processed by the reactin= g 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 info= rmation 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 ign= ored. [Wiehe, Ulrich (NSN - DE/Munich)] Not the Report-Type AVP is the optimizati= on 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 O= LR is out-of-context. Similary, when the client sends a request containing destination host and g= ets 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 respons= es received within the context. Best regards Ulrich=20 -----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 Joun= i 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 i= n the answer and additional OLRs (not created by the reporting endpoint) ma= y just be present as an optional optimization i.e. optionally inserted by t= he reporting endpoint and optionally ignored by the reacting endpoint. Ulrich =20 -----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 subs= equent request towards the origin-host of the answer containing the OLR. Us= ing 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.=20 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=A0: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Envoy= =E9=A0: jeudi 28 novembre 2013 11:30 =C0=A0: MORAND Lionel IMT/OLN; ext Jou= ni Korhonen; Ben Campbell Cc=A0: dime@ietf.org list Objet=A0: RE: [Dime] DO= IC: 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 act= ual OLR created by the reporting end point and which OLR is an additional O= LR created by another node. We have two cases: a) The request sent by the client (reacting end point) contains no Destinat= ion Host. The agent (reporting node) (after forwarding the request to the s= elected server and receiving the answer) returns a realm-type OLR as the ac= tual 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 Destinat= ion 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 stat= us. It could be provided an agent inserting this info in answers received f= rom a server behind but also from a server that would know this info by som= e internal magic. But in any case, if we assume that the client will received a successful an= swer from the server for an initial request with only Dest-Realm AVP, it sh= ould be possible to have both report types in the answer: one for the serve= r itself, one for the realm for new request sent to the realm with only Des= t-Realm AVP. Lionel -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN= - DE/Munich) Envoy=E9=A0: jeudi 28 novembre 2013 10:26 =C0=A0: ext Jouni K= orhonen; Ben Campbell Cc=A0: dime@ietf.org list Objet=A0: Re: [Dime] DOIC: = Self-Contained OLRs Hi, I don't see how the possibility to send more than one OLR in an answer is a= ligned with the "endpoint principle". If the ReportType is "realm" this ind= icates 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 wrote: > Hi, >=20 > I mentioned in another thread that I prefer putting an explicit=20 > ReportType AVP in an OLR, rather than The more I spent time thinking/writing the actual procedures on the endpoin= ts, the more it makes sense to me to keep the ReportType in the OC-OLR. Eve= n if the baseline does not have agent overload etc, the ReportType fits wel= l to the "endpoint principle" we have in the draft. It indeed gives more to= ols to make a host vs. realm base decision on the reacting node and is plai= n 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 Diam= eter request that corresponds to the answer containing the OLR. My reasons = for that go beyond just ReportType, so I'm starting a separate thread. >=20 > As currently described, a consumer of an OLR must infer several things fr= om other context. In most cases, that context is in the Diameter answer tha= t carries the OLR. For example, the OLR implicitly refers to the applicatio= n 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 meani= ng in the context of the enclosing answer. If you moved an OLR from one ans= wer to another, it's meaning may change completely. >=20 > I think this approach is a mistake. I would greatly prefer that we explic= itly include such values in the OLR itself, for multiple reasons: >=20 > 1) It's more complex to interpret implicit, contextual values than explic= it values. The consumer cannot simply look at the OLR; it must look in vari= ous other AVPs to find all the information it needs. For example, I think a= common software design for overload control processing to be separated fro= m application processing. The consumer cannot simply hand the OLR to that m= odule 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 "con= text" avps that must be interpreted can grow large. This approach is error = prone, and will likely encourage brittle, hard-to-maintain code. Self-conta= ined OLRs would keep all the information related to overload in one place. = making for simpler implementations. >=20 > 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 r= eporting node realizes that it is overloade, it has to wait for the right a= nswer that contains the right context before it can send the OLR. This is p= articularly troublesome for agents, since they will typically have to inser= t OLRs into answers created by other nodes.=20 >=20 > If the reporting node screws this up, the meaning of the OLR may change s= ignificantly. So again, implicit meaning gives us error prone implementatio= ns. Self-contained OLRs are simpler to create and send. >=20 > 3) Implicit values don't work at all for certain problems. For=20 > example, if an agent needs to originate an OLR, it typically needs to=20 > insert that OLR into an existing Diameter answer created by a server. > It can't create its own answer without affecting the application=20 > state. If the responding node assumes the OLR comes from or refers to=20 > the node identified by the Origin-Host AVP in the enclosing answer,=20 > things break. (For examples of when an agent needs to send OLRs that=20 > are distinct from those sent by a server, see Steve's agent overload=20 > draft, or my dh/dr example.) >=20 > OTOH, explicit values will work for all cases where we need to associate = some arbitrary value with an OLR. >=20 > 4) Implicit values seriously constrain the future evolution of Diameter O= C standards. For example, lets say we find a good reason to allow OLRs to b= e sent out of band, or be sent in a dedicated Diameter application. If over= load 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 transpo= rted, this won't work. We would have to create a new or significantly modif= ied OLR format if we found a need to transport OLRs in different ways. Self= -contained OLRs would allow much greater flexibility. >=20 > So, in summary, I think that self-contained OLRs would lead to simpler im= plementations, less brittle deployments, and more flexibility for future ev= olution of standards. >=20 > Thanks! >=20 > 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 confiden= tielles 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. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation 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 dele= te 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 confiden= tielles 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. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation 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 dele= te 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 From jouni.nospam@gmail.com Mon Dec 2 04:23:48 2013 Return-Path: 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 B86E41AE45B for ; Mon, 2 Dec 2013 04:23:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.78 X-Spam-Level: X-Spam-Status: No, score=-1.78 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_FREEMAIL_DOC_PDF=0.01] autolearn=no 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 NYAhllg-N6Gd for ; Mon, 2 Dec 2013 04:23:47 -0800 (PST) Received: from mail-bk0-x22a.google.com (mail-bk0-x22a.google.com [IPv6:2a00:1450:4008:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 1CD0C1AE464 for ; Mon, 2 Dec 2013 04:23:43 -0800 (PST) Received: by mail-bk0-f42.google.com with SMTP id w11so5394124bkz.15 for ; Mon, 02 Dec 2013 04:23:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:message-id:date:to:mime-version; bh=P7XYFOdylZguNkgF8fBI44myFCCn2s1b8Du0IFtOdiI=; b=DOIAhQChxGpCjEMJixj5MbrEWByPkUEd9OXeir2mSgT/wArfzuKh/hPwKTBBbOoSfW soey6wh6g0MZEjp8Cr3UUIupQoReeWMa+K60x98CbQBBLIeK6GrqQvEwiFzKlyWiijq1 xIlGb1yO46UkSXhq9uMBxkmyD6fIV/oowHmBQ583BZy+5Qmhf/o+4pgK8BFczQUH5BK4 eesMmBqbtShV85uGExSSGGhCbhk1hRG5x8e/dKZLDwgkI+Gcc47NAoFkJ2/gRY2M9Wzh snl10NkRYfvEJ3Kdzd1lc48UgmOFRKbl4HH3JgcSIKXUB4mGM59R5kZvzOBszBFGPyPa 6rxQ== X-Received: by 10.204.173.69 with SMTP id o5mr282680bkz.74.1385987021043; Mon, 02 Dec 2013 04:23:41 -0800 (PST) Received: from ?IPv6:2001:1bc8:101:f101:cc46:9d76:ef6:8824? ([2001:1bc8:101:f101:cc46:9d76:ef6:8824]) by mx.google.com with ESMTPSA id it12sm7966962bkb.12.2013.12.02.04.23.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 02 Dec 2013 04:23:39 -0800 (PST) From: Jouni Korhonen Content-Type: multipart/mixed; boundary="Apple-Mail=_BBD37F06-C332-4C95-90E9-50F0D84297CC" Message-Id: <73887CFF-1459-4229-A8AF-78FF88457BCD@gmail.com> Date: Mon, 2 Dec 2013 14:23:37 +0200 To: "dime@ietf.org list" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) X-Mailman-Approved-At: Mon, 02 Dec 2013 04:24:18 -0800 Subject: [Dime] latest -01 WIP snapshot and diff to -00 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 12:23:48 -0000 --Apple-Mail=_BBD37F06-C332-4C95-90E9-50F0D84297CC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Folks, = https://github.com/jounikor/draft-docdt-dime-ovli/blob/master/draft-ietf-d= ime-ovli-01.txt for the latest snapshot, which contains a fair amount of comments from = Lionel. See the attached PDF for a diff between -00 and work in progress -01. - Jouni --Apple-Mail=_BBD37F06-C332-4C95-90E9-50F0D84297CC Content-Disposition: inline; filename=wdiff-00-01.pdf Content-Type: application/pdf; x-unix-mode=0644; name="wdiff-00-01.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjMKJcTl8uXrp/Og0MTGCjQgMCBvYmoKPDwgL0xlbmd0aCA1IDAgUiAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PgpzdHJlYW0KeAHFXVtT28i2fvev6MrLgapBUeuueSPA1MmcJDDBM6dO7cyD sQVoj205kkzCv9/faqkvshpjg8yZVA1iIVndq7+1el3b39kf7DvjCUtcl4VhyryAlRn7X7Zk788q zqYVc8W/akr3icuT5sd0wT6Mmeu4ruuz8XQUN3+MWchjJ3ZDzk4SfPB4wd6Px9xx8fT4lv2LHXHv vfee+8z71fPZ1THoR5+P2d9s/Du7GNN4Rpb3qE/HRz7xuT+OMZqQHc2O2YnrBOwoPx7hAh9/S3/x 9U8m71C3loLisaOJvJDP1Cf0cDDCp9HH4tMyeVHLe5pbOm9u712Ih41nTo5HYmyF+BCM6aG9Yy4/ Vb1Hfqorb1UXjqBgTPVP+bf6BXMiDqk5tax62ZyIQ+yondNonzlxOYF2Tsyc0/FIo6LFacBfBFOs HOF0NJ4yhaTQDxzP9SN2EgQWmF4RFLDcdxmxFhc0VPxofysALvx22/7qNX+MO0C2CYx6PQHZfDFQ 38jHfYuIul7hQwVnf5UX73sXtUKSuphL3Ff0SQC14q2x3u3Cq/VW96iPaWVidHRHHwPBUi9X0iIF YCqGhTcpgVJvkrfg598jKeLtYkYhFjNhsW8qHY+UDhf/oHTApThNnYQHIVuwMI7Vr6O5+BWfMae7 xM97dmvqK4zadZM0alQYWCl/NT91uhhJPYYVwBv9Vsv5LGF+2CLDkwrs6DyfLLI6K9nnSb6ss+Vk Oc3YZDljFz/xW5UXy4rZ/vvdYf9TlPfFMlv+wi5mzvFo/O9W4RF7dxmoUrj9gYbuqNG0eqDfjs4/ fr74dmwbzG60D2UxmU2LxbBDjcLeUD+CkeUyq0/Oy8ltvdvg9F3XDjsvlsXDZDnsQJM+T2mgy1k2 Y1U9qdfVr+y6xtJPylnFxuVk+o8elOXqg8POJovVTTaHhA65+Gmfoxc/V3mZYYDHTL6p2VXFRr4L 3kbGBr+JtzhxPM4Dn6V9+fg8eWRe9It+bxg7PA6TURxC3/peCjlOAif0Uh4xRZubNN+JfY9DrttH cZsiQcRHhkmyy0xYMxNDsLnvOQl0P8bfw6LBMbwHgsmhQBLohEE4xwPXiTzMXHHOV5rl9/UyY6HB OVfMdOf3tvMUW93mivE0BPPd0Dpjz+WBBa9Pky6B9Xk2LIg574vb0yPY+hfC3kjYkntifhsHAz92 3ChNmG2gX4qHbHGDTcHzjPXz/MhJPexMcRA5MZYA0PcSH7tZwhUN+1iH5vEkAvQ7z7a0F2xv26QY U/H68ruVs1v+qNHwQrHpMJ8sNUNggyBwkpjDLFAj1nJznk1b5hu81zoCBvfrdtfQh8wmcGjw8r66 gPD4Wtl932Mvx8BglG5KKlYlfH5VlBVy+ZCVc2zT7ONylk8nNewPdlYsH7JHMkz0ouwzMMzBPrB4 VxHVDNlTArfhlccpdGecMh67PbNsRpbDSZ7VtyezfJGdFA/z/MR1nfpnrZnA3dhJ4yBlMY+cKApj EkjuO0ECDa9oED6TxqMgIRuzfXZE97W0FwjkNpRj6ZPnl76RQc1hQ9ywXwyzWyhOJxLxWtzsnOaC 08rY0OK3k0BsW/YEy9HnyulNVWMXqjUfdkP4M2+Cm7FpR4Pf4/u8YtUqm+a3UsZmxXS9yJZ1xSas L4yQwLos5gw2+OUZTPCbSTWwLHqRVRarYr4WOoA8kvo+Y7O8qrJFvmw0Q3EriNitGqVRZquirFm+ vC3KhbhlYL/ES/vD/Jp9X8M4Fdwbdvl8r68YxPJl7J/skf0oyFB/9/nP6/G7X5qf7MuluP568cef H79enBP9+r9PP31SF80dWofsBrOOmPfdSl+KlXbXME68+fLPT+0Y6EqP7uzy8+eLL+fNAD+f/h+G Ryv87vJq/PHyy+mnd1hDLG1eDTxQi1+JgUrwswmChXXBbjK8Hi7cqoRnPGOTis2yalrmN/gF4/r6 2xlkmKfsX7iii78HRplvcdXgmcFDYwLxkN7P2QKRDekL7baI23VFwJ8AG9624dCS9ljfLPKauAOG 3K7nczYtGqmj+MGPvL4nyRx29QKbvcLYqiwe8iZQAe58OLticSLQJC5TRIIGZZPdmulyCFoUSIJ8 /pMv7xS82tXLFDvZxfIuX2ZZibsGZpXdtBlPqn/Yb0WJJfp29PFi/Nu3Y4exL0UN2N9PalZgzUp2 VxbrVcUW8Hwn86ognVsD/Ot66PVUu3FHbfTZBgHc4C9GPcZuMMfISCSm67LE5qXvGpabsLf7hjJj IrpTMUgDWHeP+Oav79/PJpBTCp1kpUPWm1OUd++FiVG9b0f5fmBtAXveNroNjglEioEYeHyYzPMZ w2aJXX8x+Zkv1gtiZ5X/ZAts+fcDq98wsO4TpPkJbFC76xUYmM1+QdZmNZ9M6QqDK25gBwhVfPPY YlSqbMH7yfJx4AW3WyM1LHEg7yMsDCz7crKC6lmVOUZMu8a60pLdRP4wuAozuc0AzqGdlzC28hJW D9TJZE5sw5imuRDtDMsqRBtSvqRBvSMhI9WNGdwhsFY574blYORahycszy4ysVlg98hEgI/B29Pq Wvtar/Z5fTdwgiDxmG1cvRAfHDInSKOUBWnixHEEt4qnsZOECLFJEjyoljQikhfDoQbNfLKlvcCr andqI2Lgh6njhjGnCfRNes0zw3sSMb7RbqbBNvvOjyJMPQkM3mnvqR/kE+mGnd22bTZJ4HEniGLf PmeK8pl7+6sxgqSLmR9pElhHZ8Xqsczv7mvaJnNI8Z7WBDi7JSEDp72/mgwRD/nSb0dT+FsUlGG0 XyMsv8aWJ72hVVZWlKDJZ9j94Mw1xurghldksUc7ZvO6vi/KCqrxFKIsuEV6r8rKhwyZoT05tg0S FNZ42kyVmwKpZxio/86mNSlBwyQEaww+/lfFPmV3k4HTF7HdTL3SZurXbA7nFJYhBidW9Vx63wPz KrDy6ttRa6zUBKYs04bKHABfVtkJOdCAHfaH7PaWuAi9TKyjzRkGwrBbRRxat4rV+gbDMfx8LKpc YCDtap4hCAGUPeTZDxocfpF/Hthsie3G9BQ2Pnk+j/BdKxrBo3IT2WOxLqUgkLBCGGBCTymUUTXe ESgIwBjBvNcragiH3aIGzMiXVvwB+86KWYb/LVaUwEXUJ/spwk9QILdlsejezhaAybBrjvocm82a L6fzNQZ2nS9W80affbg+Z58aWLIao+x549fgIkWJA2d4aCbcCk0ShUYRC/XBDNGmxSbfD3bVA7Ty TCx2sa7Zj0lZTpY1XKqB0ZnYzf9OxIIGbOfpwNo5QXHCZsBxPLmZ09JQHB/p5hplHMIhH1HZxGuT GSj1soTksDlxMtQpajlbN/hw2L7/WDAs6FO7TexhpOOsRFCzmBd3AAggdHpzQ5pNaD/UXzw38sFH 6lnF08dIr2VEljI1Qvc+Ozpz9EyzVJv3+6DAsInDiDtYfc5Sy3AjvZV6qLiB8R8yH9nqNPUpTeK7 vuOHkadpc0Ub0X1B6lGapPNsS3u5QW9NRIUR8kApUtaYRk94mOEPGbb9CzIjJuMSZM9TPzUYpy36 UDNu0KxHahrXqIdCddgR5JQx3yFZPS2n93BWp/W6hPd6WlXrxarZLp/F12EwZYlpWzHli3yb38GU pJmYQo1GGqdBB1OadjBMWbneWWJZEzIUphTj3gBToU1iFKoErlawJGQieT6pKp3zMvXS5vVhMGVJ P6DEUoanta7xQieNoqSDKUkzMQVaEKHM2dRTmnYwTFm5rudxAD2lGPcGmLK75FJT0W59amBq/LjK mK5aILu1QVvV01uHwZSl/jDRa6ExxRMnQI1wB1OSZmIK5e5piLIUE1OadjBMWbmu53EATCnGaUwZ Cn7YvS/ZqqfIrqIsMpxEqrtcVigEEIUvz+urw2DKEu9J9VoYmII9tYEoQdF4Yj6HLeWnnOrClB3W 0oCxg+HJynE9hwPgSTFN48kQxGHxpMotO5kzqaMCE0+76yfaA19rntstXJTKukkCe9NSoMrRB6J3 wNAJAzcVpnhApYampQ6TXdA0uka+C6vKC0WFIUpC22cV7WDosvJfz+MA6FKc0+gyRHJQdHHXHmOV 8AoBL1UjdBDAqPJeGkovUHSO3GDxSPU27BrxykmZF1t8ZI5GlxZfI85DJ05dD6oIFhb3uYkvRdP4 EvcF3POgqTrPEg0ajfA1RAyDu/aYseR4ZHBczQbFuahrjHmMgtvE8dNU5Kk4fOIEn6ZoNPKGhvuQ xEqTmPZ2/ayiDSwtHG8LvNRDqaGqcjXU1ekdLeCH7H7ykFO0dNMC7/5+EJiFUi9Z+c/RBNVTTIqt hmJSNA0csF+xlXAlFJNB2x0427Mh3LWH+CVwYiO+J5ccY3OBEcQ+FixG44AboYlB0eZdmp+Efhcu aD1saJiDKOjfv0jTCEVwF7EZDkVPM+lJuj34MVjzAsxaj6NYyOCi1q7mvrSbjD+3VKpySL+E1gn/ UQgkMpZqyE4JzWBrnsUIC1/8RDsPQrVGKCZ7KvZ4aHm0jNWsS9cyFSOOFyNUZ8qjpJnySEhHzwJh Wcmjpr1c9RlYVoE87qqlNhSe1iaGeTBUkh6thBSyjIFlxToNM2MPFOn5PUT2OVBbatdbSJOnrEv3 KQFAaQjtKusCf6vuPzTCLEk9Hug10iiJQpQ/pJ0AHyzThmYiDDSfyiRMhGna0Aiz8V2P/rAIU6x7 E4Q93UPgO56IHat5t632O1efbCt7QXeMg2Y5CJQlqfolu0M1SJOcpnzNXyjEgMdOOX3DblHjwnkE 1CYXwvAMYaoFYTpCp4aXOjDNcHJASxP7rKLBfkD1PhoJ9aOS1MXSqwtfVJ2NdapPZCCG2oR1Hxr4 3KY/NKzOLz+eoct0NbnJ5zmSp+d5NaVqf6Peb0/XZ9uSR4jHw+OI7Gve3wr1+u6Zy9qmVGPsSqGH VnpajV4+yFRRAYra0jAIRgpACwbHxImjFD6BBpVBkwiSj+I2SSJQfX81lmBMcZy9MV6McEyGsfmJ PQF2jod/SHdSkGuBVg6KcrUbw2ndFhmzvybzdcauJnkpUsVN66O0XjFiWK8+DvaABCFPl/gBSVVL g+41ab6PVhvt7IBRsF4bWleG9slANiGOJzv6munTKSHG9A2lYNi0EjUDFOmFaMmEfwHo4v09O9pE DRqVncj3Se1oRsrInKLRJtZkTU2mdZ59OSNb+HdMpzaV26Jng31a0A6xscn8q8E6rYFML3BPVbNN yklOLG1grelEAWFlKMGGmuUiHmz0RJrbTO/6wKYTBt5HmJE21qZTAOMcW6hpm7ck03AKYJpTC7Fp OGnaCwTVhq82x27n+mHxpUxzzbg3wZdvTTpQcNiqa/v7m6m1zOtD48tS0cSt+PJhhpOvZQJM0kyE gYYKcBH3Us6fpg2NMBvf3wphinVvgjB7eylDLR6l3i/PTn7L0LVWZid/obADHQmnf13thrJDI8zS iGJHmIfS/hSHd5gIkzQTYR4OCUs5xYm19tO0oRFm4/tbIUyxzkCYcWLAwHukpZ5Q7JE4ewUI03OG KfWC+hVrtiqlEy18RNM5t7QBAdSXn77qF0ewwVMEEOHOuegVQXAd58Eg1e6jfEOR4MU1pBGRPNwG oHSebGkvB4p1Kup4FppKz5cw+WfYVUPxkYcwST2ccGbwUWNGKwdZD4qz8gYEjwcLwvVhVdinvrMm ava9g+ijCCcvBCkiDDacNe/lRkWC76EPhyISClZQSvDymvi9RN981KG1uOo8+2qsGYZ7hLOTUpeS PFaEaTkxADZUzDNK6BgaiJ7BQA0wM1w8IK7IcI/7fnmrlMhw13M+jFKyNP6N0ZiIBvEFTtiTGSut XXD4B+KVlO2Ba+jwkIIDkjYfGTSKHOAQLFMziWiCoA2tmTA+pAVp7azc1BMxgDOYZlLngeDlrSuj gbOp4QcEjwcRDnwYrPZZk1Iy7eznrg+jldwE5ciUFdPM0ZEMbtQr+ojJJCnQoeAEhYTDhWIX5RGK BiuppY08DSfjWQW7l0PMVEheAFsfjZp2FltxNZhCUvFDzTqNK1pNMxAzIK5osVLbBg+1hMbXN1BK liYMhPFyBC4ez1HRTeELzXqtm1zUY4Q4vhK6CdZySBUZXktDeUWHhtAUZe86z7a0lwPHajXheDJE yIDrJ5iqJ3IA3eTRMa5kPNLLbbrpmgoF0U5+8mVNR7R1BjNUUN6PAwd1xcgmWmG1q546jH5Kcdoi hNtkkNZPEDFTQ1GeLkbbtwQV+XEJR8U77HRFg4ZqaSOitaDyzWdfDTRDQ6E/FGZLu8J9o7yzoLI2 fygNFaMzAfJGVrEFXYfTTuBrf6ZkM2EtD6+d8PZewPKrOCqKqrc1w5Vu4dTR7yeU84V9CQsbTeiS RnpJ0+D2Q1hMvUTHArS0gfUSjxEk9yIg385OPZED6CVdzaW5qfc22ExS3Z/09f2AOx3UMsrYAzjn Vh7sppm0XjIYtY/u7CQRNzJBUUDnxZPbq0eoGWVGmb7vlHV6JosAZ7CVLP2S1hmhqkEsTIP0E9Go 0PKnw4AXT3zjHDAqiggCyphjTD15MwxbjVM4SPu8fRsr/JBDc6MXht7e0zXmpsAR4EkDLx5BBTqx h+MTkUl0OQwROotR0hDIM2kIZEDI5aPitoZEMj5I2tQTnVqWtCm2Yizk16xtZD25ynB+07Ke4CR3 LKdmpsqQcpzJimPJQtQYcMQHYugnSaI5KBIMb+6K0mnsn6KQlCeK1tVdr84Le9hhXRx7iuVR/WF6 1zbAsenz6Pm9UFa3gSagXCjF7GhUPTEaXlZV41RPVmMpq0+ssjpge09d2tFUGwKrDsVBqYtFYNWi 6CUYUl4BtSCCSU8v78ur0TnhoYIxjH0+glMFz5ScBVRtogoVtVaSBGk1SdiDRTqxfVLc1tKGk1fR sWSVV1vVLYPF5/AEOxed+y+OENckdTT4iEcxDudFizJmpKRS07pSuc/+YRqg8rhzTh0Wm+36Rvxq U+IGqFNAyM6FW4dVt7Rfbcp+87sZAx1my1S9QT0xTMwiXNqcRoPUkqkD5jnqrPtbozUfy27nkztW rufZluaGQzfsWMfLjcYTle1C+BeqFEdaG5kyRTMyZUTDKVmdTJlBGwTguhAX7H5jgOtCXL3UGmam HbKnJt+2jyFagIXoz5Qx8q7MShJxjO8lzo1qahftEtelamNxT/W/be/RrRcYeE8i7AjDtyZw+soU E2GSZiIs9BC8gH9t5GJReilpQyPMxne9Yx5AhRoIU6x7C4Shk9OGMMKYyPbLQ5jpmBc6LPpiOVsV OR0u1MVT/7cDIwwD3xFhAQyMAIE/E2GSZiIMNHxdSKfUG9/oI2kDI8zK9zdCmGbdmyDM1idGziyC ctBjV/nd3eMNzlalMusrHJo7zaldpY+nPuXQCLO073lGUYTeJX0YgT5O5zcRJmkmwvDtHGjL6rSr cE0bGmE2vr8VwhTrNMI83bIpAgTDtavgZJ+ndBilbo1K89PlslgjzC7aTHfA2KERZumOewJhsMM4 XP4OwlpaB2Gww6jxztwlkahraUMjzMb3t0KYYt2bIMzW+iUCctBizVFH8qiHzzh3l6I4H5co751Q fZzcMqlvqsLxcY2V1tr/h0aY6hvTcRnP1hCFWAm6JHB6lIkwSTMRBgc2QiLWBJgiDY0vG9ffCl+K cQa+jN7hYe1839b4pfFF++TpsvpBX+jXhRdtmv+v+FJdY8/hC036Ic7K6+BL0kx8gUZfh9gBmKYN jTAb398KYYp1b4IwS9uRABjC+2SFlUVdTMm+b74gsu3M6ttcfcqhNZilUc+z1Y2js8pxY4QITQ0m aSbC8B1JYYxGeVOFadrQCLPx/a0QplhnIMwwYIfVYYHoENvo8SGIQfCBMBWvaDJXhLgpdNlGc6XV JjswwjDwnif5BMJwsGmEL+PtIKyldRCGChR8CVgXYYo2MMKsfH8jhGnWvQnCnuqtajBG8Qo174M0 DQeWHqlr+q7VJ408NR7d8YtEpYsv7EwokSe/f0DSgBhNQ8doezap6hZONc1E0QAhfPVVBNw2SYOx 5Lt1Clh2PCtnW6RTVybh5a0rpwGlNIeMQdG3JhnfWrOnGtsawFQNl1Yu9De/hqJXec9g6jamxAGn PjvUqGimGEaWsQX6Ser4np+OFIygoAAt9Dt4TNGgoBRNw0g+i1NjFdwArdefAROjUQA9NkgFWlmp WXYAPKHiGTUAKDs0WKfxJFdRedo4s3pADCFsH6iGLb1gjTUvNsNekwtev3NGahtk1OkGGEAvIvIV 30CaI5yr/AW9rSr9giOEQz8ScQaOihc3RPOTokE3GTS3PRZDPjvCfZJm6qYd1UNHKjeKb6idPQpQ 1ECM7c1ru256fY0Dzp3xAh+9EHpVNZa+ZnSqI5ywL83R+x0HXwKt/xMuuMr975b97PBnI+VPiLM0 cBmIa86ipK9RlGPtyN9Q+NNlrhhPf6Fs8Y8+bzRnXqgZWlYZufEQwdggiUiVWvi0mR0eRhZ1776V F6aBuRsCtgk+IcDaC8aoykgczCC+Q3NjBfrMt1EwVAXWP/4D8Jqz0QplbmRzdHJlYW0KZW5kb2Jq CjUgMCBvYmoKNjQwMwplbmRvYmoKMiAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDMgMCBS IC9SZXNvdXJjZXMgNiAwIFIgL0NvbnRlbnRzIDQgMCBSIC9NZWRpYUJveCBbMCAwIDU5NSA4NDJd Cj4+CmVuZG9iago2IDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNl IDw8IC9DczIgOSAwIFIgL0NzMSA3IDAgUiA+PiAvRm9udCA8PAovVFQxLjAgOCAwIFIgL1RUMi4w IDEwIDAgUiAvVFQzLjAgMTEgMCBSID4+ID4+CmVuZG9iagoxMiAwIG9iago8PCAvTGVuZ3RoIDEz IDAgUiAvTiAzIC9BbHRlcm5hdGUgL0RldmljZVJHQiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+Pgpz dHJlYW0KeAGdlndUU9kWh8+9N73QEiIgJfQaegkg0jtIFQRRiUmAUAKGhCZ2RAVGFBEpVmRUwAFH hyJjRRQLg4Ji1wnyEFDGwVFEReXdjGsJ7601896a/cdZ39nnt9fZZ+9917oAUPyCBMJ0WAGANKFY FO7rwVwSE8vE9wIYEAEOWAHA4WZmBEf4RALU/L09mZmoSMaz9u4ugGS72yy/UCZz1v9/kSI3QyQG AApF1TY8fiYX5QKUU7PFGTL/BMr0lSkyhjEyFqEJoqwi48SvbPan5iu7yZiXJuShGlnOGbw0noy7 UN6aJeGjjAShXJgl4GejfAdlvVRJmgDl9yjT0/icTAAwFJlfzOcmoWyJMkUUGe6J8gIACJTEObxy Dov5OWieAHimZ+SKBIlJYqYR15hp5ejIZvrxs1P5YjErlMNN4Yh4TM/0tAyOMBeAr2+WRQElWW2Z aJHtrRzt7VnW5mj5v9nfHn5T/T3IevtV8Sbsz55BjJ5Z32zsrC+9FgD2JFqbHbO+lVUAtG0GQOXh rE/vIADyBQC03pzzHoZsXpLE4gwnC4vs7GxzAZ9rLivoN/ufgm/Kv4Y595nL7vtWO6YXP4EjSRUz ZUXlpqemS0TMzAwOl89k/fcQ/+PAOWnNycMsnJ/AF/GF6FVR6JQJhIlou4U8gViQLmQKhH/V4X8Y NicHGX6daxRodV8AfYU5ULhJB8hvPQBDIwMkbj96An3rWxAxCsi+vGitka9zjzJ6/uf6Hwtcim7h TEEiU+b2DI9kciWiLBmj34RswQISkAd0oAo0gS4wAixgDRyAM3AD3iAAhIBIEAOWAy5IAmlABLJB PtgACkEx2AF2g2pwANSBetAEToI2cAZcBFfADXALDIBHQAqGwUswAd6BaQiC8BAVokGqkBakD5lC 1hAbWgh5Q0FQOBQDxUOJkBCSQPnQJqgYKoOqoUNQPfQjdBq6CF2D+qAH0CA0Bv0BfYQRmALTYQ3Y ALaA2bA7HAhHwsvgRHgVnAcXwNvhSrgWPg63whfhG/AALIVfwpMIQMgIA9FGWAgb8URCkFgkAREh a5EipAKpRZqQDqQbuY1IkXHkAwaHoWGYGBbGGeOHWYzhYlZh1mJKMNWYY5hWTBfmNmYQM4H5gqVi 1bGmWCesP3YJNhGbjS3EVmCPYFuwl7ED2GHsOxwOx8AZ4hxwfrgYXDJuNa4Etw/XjLuA68MN4Sbx eLwq3hTvgg/Bc/BifCG+Cn8cfx7fjx/GvyeQCVoEa4IPIZYgJGwkVBAaCOcI/YQRwjRRgahPdCKG EHnEXGIpsY7YQbxJHCZOkxRJhiQXUiQpmbSBVElqIl0mPSa9IZPJOmRHchhZQF5PriSfIF8lD5I/ UJQoJhRPShxFQtlOOUq5QHlAeUOlUg2obtRYqpi6nVpPvUR9Sn0vR5Mzl/OX48mtk6uRa5Xrl3sl T5TXl3eXXy6fJ18hf0r+pvy4AlHBQMFTgaOwVqFG4bTCPYVJRZqilWKIYppiiWKD4jXFUSW8koGS txJPqUDpsNIlpSEaQtOledK4tE20Otpl2jAdRzek+9OT6cX0H+i99AllJWVb5SjlHOUa5bPKUgbC MGD4M1IZpYyTjLuMj/M05rnP48/bNq9pXv+8KZX5Km4qfJUilWaVAZWPqkxVb9UU1Z2qbapP1DBq Jmphatlq+9Uuq43Pp893ns+dXzT/5PyH6rC6iXq4+mr1w+o96pMamhq+GhkaVRqXNMY1GZpumsma 5ZrnNMe0aFoLtQRa5VrntV4wlZnuzFRmJbOLOaGtru2nLdE+pN2rPa1jqLNYZ6NOs84TXZIuWzdB t1y3U3dCT0svWC9fr1HvoT5Rn62fpL9Hv1t/ysDQINpgi0GbwaihiqG/YZ5ho+FjI6qRq9Eqo1qj O8Y4Y7ZxivE+41smsImdSZJJjclNU9jU3lRgus+0zwxr5mgmNKs1u8eisNxZWaxG1qA5wzzIfKN5 m/krCz2LWIudFt0WXyztLFMt6ywfWSlZBVhttOqw+sPaxJprXWN9x4Zq42Ozzqbd5rWtqS3fdr/t fTuaXbDdFrtOu8/2DvYi+yb7MQc9h3iHvQ732HR2KLuEfdUR6+jhuM7xjOMHJ3snsdNJp9+dWc4p zg3OowsMF/AX1C0YctFx4bgccpEuZC6MX3hwodRV25XjWuv6zE3Xjed2xG3E3dg92f24+ysPSw+R R4vHlKeT5xrPC16Il69XkVevt5L3Yu9q76c+Oj6JPo0+E752vqt9L/hh/QL9dvrd89fw5/rX+08E OASsCegKpARGBFYHPgsyCRIFdQTDwQHBu4IfL9JfJFzUFgJC/EN2hTwJNQxdFfpzGC4sNKwm7Hm4 VXh+eHcELWJFREPEu0iPyNLIR4uNFksWd0bJR8VF1UdNRXtFl0VLl1gsWbPkRoxajCCmPRYfGxV7 JHZyqffS3UuH4+ziCuPuLjNclrPs2nK15anLz66QX8FZcSoeGx8d3xD/iRPCqeVMrvRfuXflBNeT u4f7kufGK+eN8V34ZfyRBJeEsoTRRJfEXYljSa5JFUnjAk9BteB1sl/ygeSplJCUoykzqdGpzWmE tPi000IlYYqwK10zPSe9L8M0ozBDuspp1e5VE6JA0ZFMKHNZZruYjv5M9UiMJJslg1kLs2qy3mdH ZZ/KUcwR5vTkmuRuyx3J88n7fjVmNXd1Z752/ob8wTXuaw6thdauXNu5Tnddwbrh9b7rj20gbUjZ 8MtGy41lG99uit7UUaBRsL5gaLPv5sZCuUJR4b0tzlsObMVsFWzt3WazrWrblyJe0fViy+KK4k8l 3JLr31l9V/ndzPaE7b2l9qX7d+B2CHfc3em681iZYlle2dCu4F2t5czyovK3u1fsvlZhW3FgD2mP ZI+0MqiyvUqvakfVp+qk6oEaj5rmvep7t+2d2sfb17/fbX/TAY0DxQc+HhQcvH/I91BrrUFtxWHc 4azDz+ui6rq/Z39ff0TtSPGRz0eFR6XHwo911TvU1zeoN5Q2wo2SxrHjccdv/eD1Q3sTq+lQM6O5 +AQ4ITnx4sf4H++eDDzZeYp9qukn/Z/2ttBailqh1tzWibakNml7THvf6YDTnR3OHS0/m/989Iz2 mZqzymdLz5HOFZybOZ93fvJCxoXxi4kXhzpXdD66tOTSna6wrt7LgZevXvG5cqnbvfv8VZerZ645 XTt9nX297Yb9jdYeu56WX+x+aem172296XCz/ZbjrY6+BX3n+l37L972un3ljv+dGwOLBvruLr57 /17cPel93v3RB6kPXj/Mejj9aP1j7OOiJwpPKp6qP6391fjXZqm99Oyg12DPs4hnj4a4Qy//lfmv T8MFz6nPK0a0RupHrUfPjPmM3Xqx9MXwy4yX0+OFvyn+tveV0auffnf7vWdiycTwa9HrmT9K3qi+ OfrW9m3nZOjk03dp76anit6rvj/2gf2h+2P0x5Hp7E/4T5WfjT93fAn88ngmbWbm3/eE8/sKZW5k c3RyZWFtCmVuZG9iagoxMyAwIG9iagoyNjEyCmVuZG9iago5IDAgb2JqClsgL0lDQ0Jhc2VkIDEy IDAgUiBdCmVuZG9iagoxNCAwIG9iago8PCAvTGVuZ3RoIDE1IDAgUiAvTiAzIC9BbHRlcm5hdGUg L0RldmljZVJHQiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAGdlndUU9kWh8+9N73Q EiIgJfQaegkg0jtIFQRRiUmAUAKGhCZ2RAVGFBEpVmRUwAFHhyJjRRQLg4Ji1wnyEFDGwVFEReXd jGsJ7601896a/cdZ39nnt9fZZ+9917oAUPyCBMJ0WAGANKFYFO7rwVwSE8vE9wIYEAEOWAHA4WZm BEf4RALU/L09mZmoSMaz9u4ugGS72yy/UCZz1v9/kSI3QyQGAApF1TY8fiYX5QKUU7PFGTL/BMr0 lSkyhjEyFqEJoqwi48SvbPan5iu7yZiXJuShGlnOGbw0noy7UN6aJeGjjAShXJgl4GejfAdlvVRJ mgDl9yjT0/icTAAwFJlfzOcmoWyJMkUUGe6J8gIACJTEObxyDov5OWieAHimZ+SKBIlJYqYR15hp 5ejIZvrxs1P5YjErlMNN4Yh4TM/0tAyOMBeAr2+WRQElWW2ZaJHtrRzt7VnW5mj5v9nfHn5T/T3I evtV8Sbsz55BjJ5Z32zsrC+9FgD2JFqbHbO+lVUAtG0GQOXhrE/vIADyBQC03pzzHoZsXpLE4gwn C4vs7GxzAZ9rLivoN/ufgm/Kv4Y595nL7vtWO6YXP4EjSRUzZUXlpqemS0TMzAwOl89k/fcQ/+PA OWnNycMsnJ/AF/GF6FVR6JQJhIlou4U8gViQLmQKhH/V4X8YNicHGX6daxRodV8AfYU5ULhJB8hv PQBDIwMkbj96An3rWxAxCsi+vGitka9zjzJ6/uf6Hwtcim7hTEEiU+b2DI9kciWiLBmj34RswQIS kAd0oAo0gS4wAixgDRyAM3AD3iAAhIBIEAOWAy5IAmlABLJBPtgACkEx2AF2g2pwANSBetAEToI2 cAZcBFfADXALDIBHQAqGwUswAd6BaQiC8BAVokGqkBakD5lC1hAbWgh5Q0FQOBQDxUOJkBCSQPnQ JqgYKoOqoUNQPfQjdBq6CF2D+qAH0CA0Bv0BfYQRmALTYQ3YALaA2bA7HAhHwsvgRHgVnAcXwNvh SrgWPg63whfhG/AALIVfwpMIQMgIA9FGWAgb8URCkFgkAREha5EipAKpRZqQDqQbuY1IkXHkAwaH oWGYGBbGGeOHWYzhYlZh1mJKMNWYY5hWTBfmNmYQM4H5gqVi1bGmWCesP3YJNhGbjS3EVmCPYFuw l7ED2GHsOxwOx8AZ4hxwfrgYXDJuNa4Etw/XjLuA68MN4SbxeLwq3hTvgg/Bc/BifCG+Cn8cfx7f jx/GvyeQCVoEa4IPIZYgJGwkVBAaCOcI/YQRwjRRgahPdCKGEHnEXGIpsY7YQbxJHCZOkxRJhiQX UiQpmbSBVElqIl0mPSa9IZPJOmRHchhZQF5PriSfIF8lD5I/UJQoJhRPShxFQtlOOUq5QHlAeUOl Ug2obtRYqpi6nVpPvUR9Sn0vR5Mzl/OX48mtk6uRa5Xrl3slT5TXl3eXXy6fJ18hf0r+pvy4AlHB QMFTgaOwVqFG4bTCPYVJRZqilWKIYppiiWKD4jXFUSW8koGStxJPqUDpsNIlpSEaQtOledK4tE20 Otpl2jAdRzek+9OT6cX0H+i99AllJWVb5SjlHOUa5bPKUgbCMGD4M1IZpYyTjLuMj/M05rnP48/b Nq9pXv+8KZX5Km4qfJUilWaVAZWPqkxVb9UU1Z2qbapP1DBqJmphatlq+9Uuq43Pp893ns+dXzT/ 5PyH6rC6iXq4+mr1w+o96pMamhq+GhkaVRqXNMY1GZpumsma5ZrnNMe0aFoLtQRa5VrntV4wlZnu zFRmJbOLOaGtru2nLdE+pN2rPa1jqLNYZ6NOs84TXZIuWzdBt1y3U3dCT0svWC9fr1HvoT5Rn62f pL9Hv1t/ysDQINpgi0GbwaihiqG/YZ5ho+FjI6qRq9Eqo1qjO8Y4Y7ZxivE+41smsImdSZJJjclN U9jU3lRgus+0zwxr5mgmNKs1u8eisNxZWaxG1qA5wzzIfKN5m/krCz2LWIudFt0WXyztLFMt6ywf WSlZBVhttOqw+sPaxJprXWN9x4Zq42Ozzqbd5rWtqS3fdr/tfTuaXbDdFrtOu8/2DvYi+yb7MQc9 h3iHvQ732HR2KLuEfdUR6+jhuM7xjOMHJ3snsdNJp9+dWc4pzg3OowsMF/AX1C0YctFx4bgccpEu ZC6MX3hwodRV25XjWuv6zE3Xjed2xG3E3dg92f24+ysPSw+RR4vHlKeT5xrPC16Il69XkVevt5L3 Yu9q76c+Oj6JPo0+E752vqt9L/hh/QL9dvrd89fw5/rX+08EOASsCegKpARGBFYHPgsyCRIFdQTD wQHBu4IfL9JfJFzUFgJC/EN2hTwJNQxdFfpzGC4sNKwm7Hm4VXh+eHcELWJFREPEu0iPyNLIR4uN FksWd0bJR8VF1UdNRXtFl0VLl1gsWbPkRoxajCCmPRYfGxV7JHZyqffS3UuH4+ziCuPuLjNclrPs 2nK15anLz66QX8FZcSoeGx8d3xD/iRPCqeVMrvRfuXflBNeTu4f7kufGK+eN8V34ZfyRBJeEsoTR RJfEXYljSa5JFUnjAk9BteB1sl/ygeSplJCUoykzqdGpzWmEtPi000IlYYqwK10zPSe9L8M0ozBD uspp1e5VE6JA0ZFMKHNZZruYjv5M9UiMJJslg1kLs2qy3mdHZZ/KUcwR5vTkmuRuyx3J88n7fjVm NXd1Z752/ob8wTXuaw6thdauXNu5Tnddwbrh9b7rj20gbUjZ8MtGy41lG99uit7UUaBRsL5gaLPv 5sZCuUJR4b0tzlsObMVsFWzt3WazrWrblyJe0fViy+KK4k8l3JLr31l9V/ndzPaE7b2l9qX7d+B2 CHfc3em681iZYlle2dCu4F2t5czyovK3u1fsvlZhW3FgD2mPZI+0MqiyvUqvakfVp+qk6oEaj5rm vep7t+2d2sfb17/fbX/TAY0DxQc+HhQcvH/I91BrrUFtxWHc4azDz+ui6rq/Z39ff0TtSPGRz0eF R6XHwo911TvU1zeoN5Q2wo2SxrHjccdv/eD1Q3sTq+lQM6O5+AQ4ITnx4sf4H++eDDzZeYp9qukn /Z/2ttBailqh1tzWibakNml7THvf6YDTnR3OHS0/m/989Iz2mZqzymdLz5HOFZybOZ93fvJCxoXx i4kXhzpXdD66tOTSna6wrt7LgZevXvG5cqnbvfv8VZerZ645XTt9nX297Yb9jdYeu56WX+x+aem1 72296XCz/ZbjrY6+BX3n+l37L972un3ljv+dGwOLBvruLr57/17cPel93v3RB6kPXj/Mejj9aP1j 7OOiJwpPKp6qP6391fjXZqm99Oyg12DPs4hnj4a4Qy//lfmvT8MFz6nPK0a0RupHrUfPjPmM3Xqx 9MXwy4yX0+OFvyn+tveV0auffnf7vWdiycTwa9HrmT9K3qi+OfrW9m3nZOjk03dp76anit6rvj/2 gf2h+2P0x5Hp7E/4T5WfjT93fAn88ngmbWbm3/eE8/sKZW5kc3RyZWFtCmVuZG9iagoxNSAwIG9i agoyNjEyCmVuZG9iago3IDAgb2JqClsgL0lDQ0Jhc2VkIDE0IDAgUiBdCmVuZG9iagoxNyAwIG9i ago8PCAvTGVuZ3RoIDE4IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAHFXVtz 28ixfsevmLdIqRUMDO77ktLK3hOnjteOrWTr1K4rBZGQhCxI0CToy78/Xw/mBmJIkTSUlGtLVAsg enq6v74O9hP7O/vEwpzlQcCSpGA8ZuuK/cqW7MXNJmSzDQvEv82MrhMfr/ofswX76ZYFfhAEEbud eVn/x4wlYeZnQRKyqxxffLtgL25vQz/A3bf37Dd2EfIX/EUYMf4jj9i7S9Av3lyyj+z2b+zVLfHj OZ6jvx1fued7v1yCm4RdzC/ZVeDH7KK+9PABX39Pf4nMT6au0JeuBYWzi1J9UPd0V3Rz7OHb6Gvx bZX60Klr+ksGT5bXLsTN1j1Xl57grRVfAp4+yysa9a36OepbA3Wp/uALCnjqvqq/dWesiSSk1yRF dd6aSELsQq7JO2VNoVqAXBOz13TpGa2QehqHZ6kpdo701LudMa1JSRT7PIhSdhXHDjV9R6qA7X6o SLT4wPsf8rcWykWqNfxjNlBkl8Hox5Mi2w+G1vf28Sg1outWQjiQ7I/qw4vRh05rkv7QKL3f0DdB qbVsrf2WG6/3W1+jv0bahHfxQF8Dw9IP19aiDGAm2MKTtEHpJ6lL8POjp0xcbmaaYDNzlkU26HAC nVD8A+hASllR+HkYJ2zBkizTv3qN+BXf0dBV4ucju7fxClwHQV6kPYRBB9SvuD6k7U95wWYLT+EY dgBPjCTKRQxXxVkhdYMrCLtgjGU+Y6+vf7lmN+1yU8+rddnV+MSYf/Q/nl56t/+WkEcCPoZVDbku VovY69F2wCoxG4Ld63++Y7N2Xp3EZL+cyVlNgmIfqxys/lJ9gRd6qDfduga/x8vUZ9Ozyp1SzcHm h2q2XdfdtzOVYHpWoz1SzYUCvGu7atnVZcNuH9dV2bE3QhuOkS7PJtbVJHFKlbHcJwV4WS2Jz/Ye Ml5/rmcVu+66cvbHEbrL86lZTfdKNSJdbZdXN+1i1dTlssNvJxjY9Kzme6Uag9VXy/lV14ofWnVf bzbbI0xselYLp1QLsAlIhd3fbbt2fZrt95pstr8PI0Xk+r3wCn31gzwv4DYcjEeIzBSU8yLxkzgo 4NUSPy2KHG4rCiI/SlJuaI2meXRdWOCrGza4V9LOcGleH5pbjixJC/ASxoL9sT8z3MNTwhGFcJk5 vOBm5n36bs8En+3HBc9s0UXal/Ji8HDxUGQax+yXXKaI7BzuMMVyHe4wDHyEbGq3lIpMsM6U+5Aa qQiePPJu17M/lu2Xppo/VAug8KmKDQ3TwUJc+FEaJDHLOIA9T+OBhima0TBcl/lpnlCgpO71LBpp 2HESR6x0KABBNDVaN2KlMERsqQTOEZsEWYgwjgd+miH+WrA48eOEFzAPRQOjkgZGkXRlnKzDvrUn nW8cTq2BkedBBjsNKTAcKc/76r5aV8vZEXjpcqr2Hk4j73isZ5A3c+j3kRt8yKTiDDuXRgmEo9MW E2hik+1tjkOAIPbUy8LIB2ZS8J6iCJBHMbZZ0RqbBvNJ8pR0VN6L6zQNG+1ZhYhj4OEpZU2cymoL bxcMpxUiii29hhkwBDbZQgzEkifxX3nqByFhcOpa9i/teoEE5nPFTlbx6ZU6+y8pdTZ2F1BqbmGX UkwvLQC8EU9tpdY0S6nTAsAbAewspbZoz6DU+X9ZqeH+HEptC/FZlNq17NfL+3PV2vhaFR8cafqH MMeEkKmD3QiFMO0jVQiZFvCRYRHaDl7TjIOHPgI4wjwiJ2nfK2nne0lnCAn2x77RcL+LmhOEViaE NKIzqGlH3yf6iEP+DsWfLBhjAtzr9WpVLef1V3aNbEUmUE113zEoHLvfdltU0Deralbf1zNZF9qN B7DdOp6bJBbIwj2Wf90Xf+bzmipUSKq7dXkPxlh5V3YiFmVl89CijvG4cKbX07Ma7UH4a5H7Xz8g PmZvP1frpi3nJxV/pmc13itVyv1fvr5+8+r21ft/3b59+6+f/vHh/9isKdcHtt2owfSspk6pal39 CfwaIz0R1w7ZCRyhn6OODnNBKrIbNCOZFzCMqJmh9vC++rSt10+mQBE35pHHPgLJMEWFFzafhJQx 6IRa0wwa4jruJ0kYAg3VvZ5FIzScxuQyp3Joid9YoYPOXVIkNkmUUzycpT4i4SJiioaK9oAWRBnF w4N7Je18SHcmPiFadjzMCPKc9e5XX0tUuE4tHZs9PFHdjnOjYHWUbsZON2pkbhRH0YzieLQPSuba jRra8YpzyFxIxsXYTkTediOwOvqfd+/Yh7Rk9bKr1vclLKdVaFjD7/Q+xQmMWL52K0ZtotwPOPqx tt0omlk+S6MMlob8zKicZ9GOX/6h7cPy833F/xuB/2L5725uzPI3zvU7BLBn+cgWQ+DHYPmSNlg+ TCMMKFhXosPyNW265bsbCqh7+pETMcANyogc/Cfo5GRomKWK1Hg2KS4yEQKqOgldJmnn44UVAmYo zodhDKTPMSawi/SWd3mGEFAnsHi0tHorArSs/gxop66wtUxS0UiFuOYhwkJ/GiboolN4dIJ+CBYs 2epnm+oKY28QbqId8rLadPVSBJVX76uyWbB1u+2qOdpln1DHR12xXM4NBpwhjHELNN/XqxESGbD0 13ZDgwgqkTkR9g/Jh/PUjyPUMEOwM9K9dSWkoJ/shVHoxzxA0BBkfgE3C+sJk9zPkOVrEvrGFimm aB8k+06iwSufYT0SAy214jnqXzFKZ7SCkeOypLZrPUdGKwell+d+Hieo/xjpGc3uVUgLj02YokfU BEkiggzXorXWmsB4+MkwNaEupUHgYypgjy7ZIUQU5n6Rp5mndQZOBJqYo0Vi69GAJhVJ3SuukzQo 0pllTEuR0hCmUKDP4BSpkdgz6FHKYz+ieS+nHvkMWY02fjweaz0aHJ8KGtxd2Ott94g24Z/Y9Xy+ rjabM0rzBi1PVLFDHJtiT+5g3FYxU7CBVsJEh+mNopk4xUMD0i9gylatx5DOQCqJG5aCmW4hmB9h 7QGkmrTUYwRnkCpKBvo1Ybcwh0HtRjQ0NfMaveh2vp1R8UQ+26PppQk6EIW7XXb7WG+G5SM2r+7r JVS7ZHflBrWlttkSP6Le1D1W7GVdLirkCrpqYnR6Gk7djSbRqG8b9vvFy7c3v19CWrdghjBdp/hU ESMONcslamMYkZihwY+oZfpgpXD1Nxib15vZFvAwR1YhGJq1a+DFqkU+tXwgjuqH5ZD1eTvbUqt2 alm6+xtGr09EoUNun0KZIMoxTFc4uhu/vb566ddVd381rxfVlcoxr7CBm4++WXYU+RlAP2YJWoB5 GtFEQ5gEAKE8NzQKpixaRB1UoJa816N7Je0MjBpA7Thcp+mJXeNFcGpk+gyu0JKtfroBqt/e/3yT BWkOOfYOEaABJk4BrMGad6LyMCj8GL08bKyjl0BDSR3KbY+Y8SLjUzuL8T9Cs8ZYYw8s0ijqjdnz KWCDQ2fGcS7bxbYWwLZsO1b2HhzVaNSod3GkwSxgb7yGxxMN5ZA8kxCVn5wnzMnzE4aiIx6O6l0Q cBgFlUQjOH5Ei0Xk8yjEoKukkVHYtAgDyHDl9q09aWgmmBr/3gFRTkHr7cLDOL6dWf6HzEQ+nQ4D /OfNhB7uUMVrttwu7uA3kVmPjGRdNWiQzNk9RiXR0YH3heuiNo/RwGmsxN0OUZ7T2U96rlq+zlFR zx9n2R8qzGHq3peIPhat8OddWWO0SXlZCk0QLelKpMqy6WAInBGMAtVHVBphKD2F/IRFiQK0PE1y ThcRSSbi0wjd3dhBMrGpFGTjKIoqBIJRDNIXKRURVcVNk0wRDmPNfiZjc1WEs2hDiz4qhDzk3XOg lbNaL8IwHXHtYPwO/ErUhXoT5qpA0uzdNNJ2T6aPTO6u6r5UFQK0Ly1Dh3XVogK+QXi5geJhYlXE vBiWRKg5MYPwpw54YD9v15DKmpT8ByEfLVSE6H3MCK1HW6tcrZpv9KH6CkdFESUiW9kKnppVXf8c gLjaOcGKajv/oCJa8rBs9lguH2ij28Fei5xiaibdk+irddu1MwQgFB6lWRR9FHISwlw17bfyrqko QK+Wn+t1u+wHJb9gByiBWFRTM+mqSKGpq5KppZjlnrciOqmp/0UMDWW3q8JTs+goHiCw1Wp40LYt HDvOip8Am9CRItOw/i0spF62TfvwTWzn9d3duvpc95MPEwuEu3NmOiUAN/5zucaBO1V9nmTRXI/p DcwNm3DNNlUnavJKYTaCC0JSBN6zcslgcHNodLn8purzwmmW7AGzdpaDPI7TQwEsfAF3J5akLjt8 ElopiMD+/foI501qTaUFuYTNdrVq10LZp95BZ8ICLtkGRQzFq82igN5vTBrissL87QZTFgBcShUe S4wtgvmJ2YzcuYtic1auyhmO/kB810tA1rz+XM+3mK7pBcjuoYlsUT88Iq9pNi1T8iynZtMZ1wpp bu/kvpNj34KvjVQ+DXCigWSjxBRJRhQ7kwywZCwzPC0TPoRLemSb9w+m/MJY6m9vMaklJrR+xKAW s6SPtn4/c45RenTHMfqAooboFYF/TUMQqmlJgZgV9VBrNj0ytDNiu4E97xQ1MCOAw4mI7pzLsmU5 Lm2csotW1TfEyAOPAuTARpLI1PpjqRfXZve+p46xs0ykGZi4wICs9UyzewNjMs9X2jNBtRlW7scx euv0/FEEWOJs1KIP8LT9sg2iO8AlDtA1i79YTGWo3hdQD6U7lPurYz+KRrm/phndwZyhvNfQSJ+O cwuHrANuIXIMZRE+ULEWbqre/ABkRVRYdwakXCgMkDPYpfOiiGataCRgQU/yC46alKahrGHTghA5 pTVcQddJ2vnWYylwjPmVAGPYYs2jzbTgZ2wy352Loa/r5xlmzix5mzLHovzGkFl2Wl3ObAI6Z7do vY5JqH6PS6Wv+tHyTPrRfblD6hVylM1QVCIGRgXY3kI+mgfnGGbmYcK9iGaqAhyRsyFX0WzIhVDp 0JK6kUWSMJlx0Dk9R+H4gwwnkYN0dFyS1uCJd1MYxefowqGovmBF6vOE5h8jSWqGpDiLqJoxuJNo U5YzYne+BR24FidoKTZWi0E+/eHnV79fwvTRUEI5WFaKKWC9q9gKI2eYmwfs3SHAcpl8GPtFnFEd h+cRCjoo6USKhnXatDjGYSqzdo+uk7Tj93DgJ3cK4VD+2J3GYe060CnFSPHVFasw5QxZYNko7n0z qmk2B+4+jqIM6G1QWdKwEIsGsItQ6jWLA7Rrmo1nk7op52LRYzNLUd5xAu+hhzdIxiM7KRnS+a/f GMQqEp5NjVqNrOAYtcH5RB8Hj2JIp5csqY0artQ0SNHQtBTVvd4eyR65RKk/lqfQ3Xm38hhhPoOn SHAMLi8CeAojVMtTbJuuRqWhjy82Vp3re6Iuh9G4T4prizEimFCfwiDEcZYE0Vacj/Vp1tTiYCxV zkqNWsij+hwLmCVyaolP7DNSwHZrtaxSjDhhVgfxa4GxR/TeSNMQRhchWpeaBk0ztNAvAuT3OLEl 7/UwaK5o0wGU48R4753vt0tR1OwzM8rT7PSRIjKyKRTE7gV4t/dUbaHxgHo5a7YoQBo70wjGMfOe F4i0yM7QJYwxa65pZGcWLSrQ8jII5tF1kjbZ6hEdjmMxsXwq6TFgF2XxaMDQ8u/bpmm/UP1Uiwav vlEFHbVGj+NIOUIOEUDgiF2ewPtqGlDa0DCqhdDELFE02nqSWOEpudK+6CsRx2FHbTWs8c9j3vGC Eo53AVDArM5iaxIyS3m02+OEEgkfBA4WzfYvR6KgjOMsFNQH1nm/gmHqbLmUXRScwKNRxgM4SBk9 W+qHQcH3mOaEElhbfyL6HQpaETIkjmmI3iI1AEoWjIEdl4w9Eauke6tKRlMmBFxTHMGDRw78z1aE hGgIcZE4cHVXNuVyBvGbtetiCUcTGwgipmlV0qppVniEjjcaYQB5q1hi0SYDl9TdOyXTY+x/6fjY m3KJ6E/M8YxwhOHIi88zzLIj2sMEQFYE3NM0LEfScB2O6mRo4ttAYmjHL+cJvUxF7WzHDoViYjlv 1RkQa0m6xaqgES1BtCDh07AiNcisSFiQTeIJAnezII8uk7TjF/SUvu9NTLGg23bVNw3+WtMQlrEA vZiwiDF6BBS09kfTrP0hGtTLTjXgBDTt+OU8sT+ZO13s1U0ljVT5fT1HKENvhjq4V1Tkw4sS6WQH zl75WADePKFoZE0WjQcosli7RddJ2vHLe2K3sr1ZpF1H/VVUk0VO3L+8zGxXijeqZTiGTNtFL5zJ cg8vi+hptF09jV4ggXMswGCzHptG6zkP7y3nZiqLWNUI+p7XuXEMC+SYeedGoMa3qR73Eu+NKuf/ xuku1Bj6ViOSUnrdmR40xQDCeXJwRioxQlvsDmqtTolQ+GVMMJzu1RMJzlDh7TNIeIw4TI0XI2mz aiX6aKhV9XUX0TyhNIBifhQjDFu6uKDUCnl6jJl0vF8oFSok1A9Ox6YpVVOFCUv9jjedp5DBkSD3 EYU4xEfnruUIKoZjNgjjX7bsC8L9rkbwu6yoyEyjJzShR+JwBfYhDZ6Qh0Bgn+AEQBrTK5UkDZZk aKmfouhrjMsL8beedIZtDUBjp36PWCpzjYiLpZtt2w0gTwtZndpsQhvDgDGyl6NjUnj7oYlnTrSq gQR2cmmOEyKIQsjYXb16zFoYMUwY2XFkCjikhsTWLN8YVfV11ZSo16uIx0OF3sd/sBHclyIlEy5H dh00jVyORcM8L0U8g3uJNtWBKNN8cYpOc08gOHgp2QTqA1/rQ4ZIjY38jPrMaZgeMw1406/IPacd 3o1y1CdShBJ7VGYIxNO1SmOOcXBM3dhrNjqzqGg+qN4s/oJDD53oCS3/hApEVS1YU/9REVyhi0xp Ojrb29mj/9EYFMYy8AISuF+tS4TLOcowAUIapXOEyxZN6pe6F0qKL+l1bmqYQuQRRag7mc02Czdl YqNxxlK/v0CAYgT6FuR2HQAxznSxQ35Mb1LQYqNKAU4uRgiYNK3xBjQptsG9lig/fXd/i4DeMf7T u7jdpBmjcdJ+nH5MvHdXvM4XLPanCNAZRG8INMCNTQvRWRo4MlwnaeeriB0lphgDiKmDhdWNy1RG IZ4BghAOAYKEVmrJGggS3TMq/X15rGd4I7RqQE3ouiwcci1+JyB8FhzSCzfmiKqmOuE8GK5a0NQP xhddoKO0By13xAVhgvKapVEDmtaoHrBwUHigUcdZyqGAAJaCl1WPdUmYipq2dWZPeEsjMJSSXd3w ROdE0OByLRqCuRC4agI8FuJMqqSdYRdPxLa5612I+yO8qQ59mggPDIxKhPLksIid8ZpzVSI+0TwO rZyCZs7xvnnuFMBuZDfVssMc+E8vw6THjtRINzAN5oq3AFC2hNF8NdZnBAKF8nOcbPEo+04KvD8d 6QPybwHnmgZVsmlBge4JJez9vSJzlzSo15nDCxbsmlTUtUYrYn4G2MXJaR8nD6xNNaBL7e91S/OF 1Zy6TuN3G9BL1GmaQwz13U09dJg7auG9i13hAAoKBWZfp1R0dZgM7Z9xlZh8kHksAqPJFD0W8yBo AZhlGzeAjj1eqt/8YB6NVxggg8HLORC6BzleU2OqTIZGSqsqT9DehMowwE59qyYRTB4N9gf+BwE8 3zsgPChcgGd67a2HZqSfZHi7Mg6SwP+nOYbfNA3/RwObhmGmQe+KrpO0SczQNGGwiBHUWLv+DGao 33diCdAYIsUeEuGlAkybglEJCK9EQvrsXPkA259h8WbU0miPWbwMErTmn4m3zrKJqRs4F44SnHxv oarFaS6mnBuLkM+IVwlbm29Mf0sjliPotUYhqEUT5eguacOhWUu0cuhssqbRrKVFU8Yk7xWGaIzp 1EKrjAAtn6bfUelWKSPHZ9CnJMfoboE6tyVPo0+1+D+UUOJubOlo6Dvwvm+e6xMH5mE7GaFIY6wR 8yndVobohKdIrMHHuMLfD0qoMQIadrMOy+jzR5ZWTSOSvacbrOgMp0g/V414cxNpujI5+apQMUyF Ch6FdDhIqVk1ic8knBZ7W9EithEH2ayN+/v/AyuQxooKZW5kc3RyZWFtCmVuZG9iagoxOCAwIG9i ago2MDIzCmVuZG9iagoxNiAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDMgMCBSIC9SZXNv dXJjZXMgMTkgMCBSIC9Db250ZW50cyAxNyAwIFIgL01lZGlhQm94ClswIDAgNTk1IDg0Ml0gPj4K ZW5kb2JqCjE5IDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8 IC9DczIgOSAwIFIgL0NzMSA3IDAgUiA+PiAvRm9udCA8PAovVFQxLjAgOCAwIFIgL1RUMi4wIDEw IDAgUiAvVFQzLjAgMTEgMCBSID4+ID4+CmVuZG9iagoyMSAwIG9iago8PCAvTGVuZ3RoIDIyIDAg UiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAHFW0tz3DYSvs+vQPmyUpVF8wG+sifH iSveihPHnsoe4hwoDkfDFB9jkmNF/36/BgEQlEC9lt61Dxq1OAT6/XWj8YX9xr4wL2GJ67IwTJnP WVewf7OGvXrTeyzvmSv+9zk9Jz5ejD/ymn2/Za7jum7AtvkmHv8Ys9CLndgNPXaR4MXbmr3abj3H xbe3e/YHO/P8V/4rL2D+d37APpyDfvb+nP3Jtv9iP25pPxvLOvrteOXCe6/PsZuQne3O2YXrcHZW nm/wAa/f01+C6SdTT+hHO0Hx2VmmPqjvDBf0Zb7B2+i1eFuhPgzqmfGR2cry2Vp82fjOxflG7K0V L8GevsonKvVWvY56q6se1R8cQcGehr/V34Zn8EQS0jxJUT2PJ5IQO5M8bZ7Ck6cYkDwxk6fzzWQV 0k659ywzhebITjfbnGlLCgPu+G4QsQvOLWb6gUwB6r4qSLT4EIw/5G8tjItMS/7qj3+MZ4Zscxi9 PBmyuTCsfvSPg7SIYTjipUKy36kPr+58GLQl6Q+Vsvue3gSj1rI19C0Vr/Wtn9GvkT6xObui18Cx 9OLaW5QD5GJbWEk7lF5JPYKff26Ui0tlRiGUmbA4MIOOT0HHE/8RdCClOE2dxOMhq1kYx/rXTSV+ xTsqekr8PLC9Ga+wa9dN0mgMYRCl+hXP+36UOpwHLK83Ko5BA1gxkFEuYHgq5ZG0DV+FsDPGoPTt X2O0GmOVCI/T+2lB+3IbI2zeXi7wHO4GiWdf9Ycyq4uh6C6q7KaABrZ/bUS4DAInDlyXQzChk7hx ADklicODiEQnSdWMFLgRh9Rm3yQaRPo8CepMcJslkmAcbcYksCBBCAuK8aCmBGJbW5Kx0l+g9ack yW5J0sh0j1ElLGeRb4+7TuR70QL7P7fZjn2fVVmTl80VvFtZ0xchi4ds9j4jShiMQfE8kzjMds45 q2gbl2obLKuq9rqfHuqKL6eiH3o2tOyyON88bZP3iYc26Xs2s8Amd2U/dOXlaSh2LMu7tscGDgXr i4G1e/zovhZd74CZYl825VC2DdGHQ9mvvcXAarnY4v7U5GLhsmftaejLXTHuMW+PhdoN27X5qS6a AaFVOevj9PuQ6CLrviYr+hYxCfHhrlUJO36fNdlVQYx+Nylgii1B6ERpmiAqpZHjh8i4CPiSVs1p XpqkRlza0HOSRnFpHeGlVuFBqVtYkNZsVpXDDSua/tQVZH/ZIBSct03fVuUuI+MU7tMP+Mz2bTfx 7sPt3NhDqvIRBWI/Be9+6jlREIB3RavmNC/2wbr66oYeG0mrce55Sx43uhf5FdtnXc0gh7ytqiIH ly9Z1uzYsWvzou+LHfxuC2cs/s7yAQHjqu3K4VDbePcCxwtTyto+EjjnSchiRSPeNc13ojCJZsx7 mrYe9/6S3qE7sFsfTwNisdCyUKzU+Ke3P5I8yvpYCRvPhN/3xyIv92XOEKZszLswcCAH4j10Qu6m DBWRIBHrBgm4xpuxjsckbT3W+ZLii6Y9XR0QU+usGcCNiKMFpNF8LW6UhZcNJFSPfDdFsbuTD5TR sihNHC/wBd9x6qQeUImmgfGJFsMZ4CCGwUeppq3HeLikc6k/sNi3o3fvCFvVSCg9CeKyOGRfSzKM rMEvMhDsHIuuoxRO7qUeKTtCRQG4CqYlDQyaNM9LgjnT8PKRth7TiZXpX+Hdwq7NcK1xx6TCGMaZ ojCvGeKFkyR+uIkUDUBb0hjR3NQjGDn7rqQ9npsHsAxhKAt6FOG6YNI5KX4h/VDEFpH61OwAEQYE rhE6zKJ2KwVhU2UE3BeF3PTbSNHAqHJcogEuU+WhmN8YtMcz/0Ci94Mlx9VZR8SrEROJ2I34/K9T j9CMkDVQ4LLBExvrIfBx6IlUlaB/44cxSipJA5sTzXfC0JvFrCjUtPVY51Yrht4J6GloRdB09OUb dmivWTahVymUPKvyU4UcTQIxEKJSHIMenTBAdoL/JgEqTRRgmkacGzQ3QDlhKh3flbT1OI+WlK4s lwntv5QKziqEMJuW70jKpvYgcVwfKcjIVJGigVFt8UHshD6fQZRooq3HvL1YhNpnWm6E5xuqpQgw Fw9BMukcVDdYeYe3e4gvxLtEZ1EgacS7QXM9d56t8Jykrcd7uqT4qeYRGFXVFWxX9DkqJZg22T7J gAIisEx9asqcbN7GNiwfeNwntmMg1RTajxQNbJs0nqKdYNo7npO01dhGYbFQCOqUZSIQOLyuYt9U JcJ+L+qrsRujvHoTeaHDEx4Tl4S8ojBimgaOJhp30iRIDC7xnKaBy82KbQHUvYG9qNy2x7Zqr27Y T+XuG7QEAkvxBqfCv1sLU8qo2rYvqhuYFwpsKsL7Ef+M8Bi4uJl0MBnYKtUZul8LxjAoAZnGkF0i 8Ekvn8oXidnQR8gpJoCDfdcaNco6O12sI7V51qiYUBn3wNcNYpDsE2QopgolWuy/2WXdDft8Ntwc 4bMV5J41K0uVL1Z+2W6EvB3g/dcCabXOyubzuajyqOpp8uqEKMPay/2pR0QhE0CzA1hrXwJiUW24 9l4X67Rst0MtTpua6hEULFrcAgGWlOeb2yYBft4ZddoqBsAXqyqyP5GVpfjYQfi02FRzqi9RZmPf X7OubE9Gu83Y/9oyXayDKGfM0eO7Ubs3QtOGpImpNs9PHYkX5eLN2nuMlzxfK/j1IPuCF79n1alg H7ISJvj57PXvH/rP58BDwlpp47925VXZXPzU9sPLtfdpL68QSX9Ar7RsRJ08rsw+wueLi49F3nbo o3zo2r9vLt5Bpi/ZJxgyGpcX734Q7ZUWejAaSKvYJ1rqC6GU5GXkzMet9kCdFgZo/Yuj3lnP2daT xAGoOodZPie5rzLS5yQBVr3D4yfRIGZvqZE1GjPKQmvRq3uUoes7cYJ3oegNEyeOOVMk4AKT5Cc+ YeDZNyXt8YDoIVFGVlHCwh5gDa7w6e2795/PKYlnrC7yQ4Z+Ro3Ag6Q9ZsXJGxRUYpxquzCikl93 5TSNcLDs1BHND1EdG4DQoD2e//t0C4QULtYAJzQg2SUV+SPSBRZELhXZNWM9HL8qpnQwpinVEriH exyRcp/60wankmZyj+ZVzFEgm9xPtPW4X6wCFPf5iHpF6VugN6vjo3leczuw2/QOpI/mtOh2qCKX Kxq4NGm+jwJ5xrnvSNpqnEeLhYCoeoi7ctaMp2KnbncERXoz5M8QQmmAqcnko9Dx0Z0mpavOBlc0 Yl12QDiad7E351yT1mN88Sgsa/prglko6SitEYxVB2B2lPMayOOK0Ca5vE3nIc3m+GOzQzGpaCbj oPkuamNT5xNtPdbt1RBi3bHoCOb1KGnfvWfZ8VhkhDcpsCnAQtIgOx8d4h89fYfaBARlbZ1aHqLb moydWtXY0DQwqmk8dSJ0PmfMT7T1mLef420PXTsMFRRuHAxPpktnYqjXYbpxBOMM0oBxScP5vUHj qHoxzDBpEM9p2uOZeCBbRelyg1bxIVHA5jfdLmWczreQv8FGwtFaSmFrmoZpBU3zoIsAczImG5L2 LcYVgthef0xA5luOK9DqEkZN4wp37QGCfBxoeyDTIutL+DStBtfDv2nNGeNrzWfgkMhJ6CQ4wBbu 4kbAF/JrlMmn8ZhdnktNxZNOdSL5AwesXjPHi/WIqNNuRImsDFyAK1XtZTIgsV3XHo8Ut9VuXzL0 JNff6WJFMqaCrviLYqKxD3aNQ1uKqdhgV9L5ddF12Bqy6xEH3AWqg3WHPZLFWkS28EQVJLaLZKfK 5/xAjSjCObAEpH6cOA9jbAQMVDJde6eecolZHQOXwDb6tkabGabZqeMmCE2X7Xl2zC6BQGGswN07 CuBkxvXqwrQfjXwsjm0n1PxLu8OM6tOmdR6I8okeo7otltcT/mywLjhGrQEIUqClBFhGXQN18tiJ HcJxPp8JRFdnN3CItRW4iJ9puaYd6DiXogsGGE6i3ab2B6MiDpzP51p4m1XCbOpTQbfBGPRMeB8L bIGM5Bvoi5r6lnIcZmzVFx2QYlSJ1EUzVxj5OiEQAGpplf3SIkrMQeU6srFjIGz0BU2Y0DZeoC2J rZHqmoKmUNA4Q5e0LmBbY5qQchT2h6iG+og4Wdmw0sXWdHYJU6f5p2kg5p90OFeXV4cBXfQcpSiF j11RFVcUbYWP7NrrBoNuRVav3aJKF1vTaN1dH8r8gBiLwIotijblJRpUQvnsxahvMkoS5ouVJ9e4 awdXv/788RuN1MYYn/aojqGl73gEDphoJGJydxx4+1GCwRQ/5E4SANoCnopJztCfaICnJi0IEjob nH2XaOvDU8/HcTNaEAty1HzQAPPaI7V6otWQ5IQaIUkxXaK3sOapGYAiTtmhFTvfY+J7ckMT2Pie wW/uWoBpgNz1qa0wKIbgSCx/LQvcOhGZdiVMzl0LmsMkHVZ+3eWHcgAKOnVZxV73iNhH2gmm/NfM 9TgsuuspoiQALO8JSYL56eSZIvABge6iKuBNLJttktKJGi5bNxxzz9L6xS6zSSxjmJ2E45FbrDNf 7qEJhC4KZ7SNO2FFjB9VN3rljeei2A1ThBU0mn0eUvvF8zFRQd/WNHSaJ5qHZiMGCEGbvjvS/quw Ylxu8L2EKmt0D6yi1Lv/FsEEly9wQQFyMOQ3BZNRfuWEYVcNJrgbkXBMN9nZJnPWDVUV1dibthm6 tmLvVUv9ydHmfnzNPUvPn7xe+D0hGjp7hd+9qWDgNHgqfl3bpezQeQuR7DEO3F4TLhBHC/lsG1Tx aJkJ/DVuT8DJlffo25vEqhoUVTm2SGf/J3HERhsmqIjaEQhMTuRjVC4fWvQTBRI74h7I2tu0t3TL RsDAvKTDP+wrAzCU5xlagPrcQlbjJdWUNMykisq1t2pvwbbzqm3tA0Pu2ydSPskEg0FiMqs/Pr59 E8VB8KccRoHGrlGHD4Si6wz5sAHUF0qkAW2cDF3jXt7TsuH9PTKcDN09YkSewbQGVsYOTXt/iWQ3 nutWNKhA2W8KoyL9bB59vem+bSFqOzxEerDuTu3hEhgfE8saHHgYSnaDUGQZzPGKmT+O8w2O23CU eYiG5OJPtAiDzS61waevahI1kCmfPj2jGjmIY3IUFySQRyHmO3nUEN5tQLtCYc4xxMtjXP80hDjl oJkQZ0o2JPo8/sVVVHB766oh9+2ddAq/6NLVmBLSulyB/QSnAbABS19CryKvrz7aZO/LcfrMXq5K l8KnbgjO8PYY1MJYUYawTBu4dbfRw40QN8H86XS3UZOmu40wYCdMcMnGOKFXtLVg01QHQXx3hg/u MdlHtuzvE6LHca/Tx30iQ4iTySoh5go4oSR5ooXeF3QmzGZl/LIYrotCdGSoZ2sLj5SKga8m+3pc B+k+iZAVWwp7BOiq3BdDSf1a3DyWGWElt8Ed9P+D24hV527zSU8Rjen5ltPgRo0b4g6d2cTQNKOJ gXt5YTheZ1CDLRuD9oxIL+3IiPS6dRHYxua0hshgV+9cqMMmHH+qJDN5jZbhzpThin5DJmo/S3oL ULecZ16SrxjxRJWvKxhxgGjqc9zNs+5MbamcGmPMiznupuPGS4I4HLjjXDVu8/EEl7YVjcCDpiES 40CdGmPTdyfaM2xKhgHDpgIAGp+OwomN/zF6CHDVzY3gW4YIbUY1s+xngCUrWOA45XfjaIlxhFkx K4RaY0AVvS4eDiz9KYTb+lQNJa5I6nM5zKdgfT2WJY3KAE+//QdmU4TkCmVuZHN0cmVhbQplbmRv YmoKMjIgMCBvYmoKNDI4NAplbmRvYmoKMjAgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAz IDAgUiAvUmVzb3VyY2VzIDIzIDAgUiAvQ29udGVudHMgMjEgMCBSIC9NZWRpYUJveApbMCAwIDU5 NSA4NDJdID4+CmVuZG9iagoyMyAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29s b3JTcGFjZSA8PCAvQ3MyIDkgMCBSIC9DczEgNyAwIFIgPj4gL0ZvbnQgPDwKL1RUMS4wIDggMCBS IC9UVDIuMCAxMCAwIFIgL1RUMy4wIDExIDAgUiA+PiA+PgplbmRvYmoKMjUgMCBvYmoKPDwgL0xl bmd0aCAyNiAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBvV1bc9tGsn7Hr5ja J6nKgnG/5GXLcbx7fOokcSLW2YfYtQVTkISEJGSCtKLz68/Xg5npATmkKWa0m3KJagHEdE/319fB fhG/iC8irkQVRSLPa5FkYt2Kf4mVeP12iMV8EJH8b5jTdfLj1fhjvhTfz0QURlGUitk8KMc/liKP y7CM8lhcVfji2VK8ns3iMMLds1vxm7iIk9fJ6zgVyXdJKj5cgn7x46X4JGb/Ld7NaD2B4znm2/GV B7738RKrycXFzaW4isJMXHSXAT7g62/pLyn/FPoKc+laUhJx0egP+p7NFd2cBfg2+lp8W6s/bPQ1 4yWTJ6trl/Jm656ry0CurZdfgjV9VVcs9Lea5+hvjfSl5kMoKVjT5k/9t80ZPJGEDE9KVOfxRBIS F4qn4Dk8xZoBxZOweboMWCuUnmbxWWqKnSM9DWZzYTQpT7MwidJCXGWZQ00/kCpgu+9aEi0+ZOMP 9VsP5SLVUr8m4x/LiSK7DMY8nhTZfjC0frSPe6URm80DvlRK9jv94fXeh43RJPNhofV+oG+CUhvZ WvutNt7st7nGfI2yieDijr4GhmUebqxFG8BcLgtPMgZlnqQvwc9PgTZxtZlFjs2sRJnaoJMQ6MTy P4AOpFTWdVjFWS6WIi9L82uwkL/iOxZ0lfx5L25tvMKqo6iqixHCIEr9K65Powjbj6fPl4HGMewA npgqlEtFJbIs0RCWaAi7EEK8X4mhHYauX10t8FM0Dw+Lbt5sQBheic19Kxbdbbvplq3ob+Xvl8Hs 9xHfRnSTgMoroiUeXKAB2t0FZkkcZkWZynUGI9TyOvUKO+yKfniS1GEcg8eyqsKkTmtINSmqMK7K wtAgWosGNK9TCNm6VZPOkHcw+g1Lyhn2Nzskal45JIT9i7GbFWRF4gOS6g09T3x5VIZJFSe2+FKz zddqg99b4hs16eS9U8xK8Nndu7zKxw1w61gHpWLm/zqvJOAMjnoZwB2zjkCXh251t2jFD12zbDft GoCmleWZmnqM2zgvwiQBeqtVUFDAq9ism9XQzMl8gEOz3wMZCNS4JQdCQy+jEP8y6GqcpSH+ka4q GqzfpiVlTYig7w3oOkUjbf0itegEUDhocyTIEp5ExjXMAgQ5g9mn//zw4eqmve1W7Y24LhobGQTt 6Uq0fzbLBwgcwNBMUIQhIsH3RmUMsCvysMzBLqy0SgGDVcw0mKRNg6xKaabjvQHdq2j+OK8qF+cW /IWjHG77xaJ/hGa9EvP+oYMwbtf9EuzKTRZlCOAiCQCOkjJ55WI9B0BlUSxZB+AkOcShacS6oeFD WicT1nND88Z6TuHD/qa3fxLyd5vFkxg2zaYdgPbNRu8rNhzhdIf9VtfAwJbdCtfdQBVu5LVO3qHc SVES73UcFmkKI8gVDbzbtIScGKGz3nZcp2j+eI+d205+bmjXXwEaNz04X/UbsWy61Qb/tARGqSCA 0aDCC4XZJnGaEJNRDDUva1FqGhhiWhKWMXIFZhLXGRqYDLxYdQ4n5IBHGPbfvm83j227ko78xx/f qa1rxX9dX8vPn62/X//z+qfdC1xbnJDTLQjTEnKAWZWLUtNoiw2tDIsqJ0xjySWG5m+LC6d6g3ub OcX8/m5i7VFYlAnFE3Fch0VdVoGhAaMVTV4Xl7a1WiTi5jwXa8UT8BhhlAI8s7wghzd1NZZ7240o PKhREkdhBWOlRyu04IDC8nKvRBe20tWNMeF5TDvjihQmlOVZcYB9slnevjigJ58czyBYPugX0ypB LBrVNu/sHt+9//UVhxgqMh3EcN8sFtAwCyJ5cUlUh3mZxqxHS5GWKXQLCYOlWxOa0i11645ueQmj 8vIQTjC4wwu+WVlMCf6TxZ+B7BhBTY64BbZTY1NTQIEmwXQMKQmLvCosJMBlhiZtx+N2shrBkves SO0ghTTMkMd4MUvLMCpqBFujuKdG3K9acduvxeN9N78nVLYANi3COkE2aCQIpQEipHmRMG1h04wI E3VvsCNWP+6l1ojAVgF0xf8Ou1AKKES3AqtLmVuq4Gq+6NoVYgxpPHC6FvdKpQQKcGEBELC9iyLZ zgUkZNaxpVIB3alo3pwLcrZ9FVK8IwpqVk+oOl412819v+7+T7IqsL1aybTxID3AdV+27bBBmNXv bLxmHVoTIqwYec/DPAMmGRoxb2jwouQnLM8Kt6Vp/phPjm+85Qa0h8d64U3jmoLfMgmrqIBj1TRk 5xNaHFeT2IiuU7TTeTiWu8EIi9zhSeUGUtJjUsfPzdCKh3W/6ef9Aoo7X2xvZETcijfY3CudUl9L xX7zvx9EMziUtyixRTUiPkt7Dc1SX6JFdZxNdpBpp3N/zK8R98Uh9SVvumzn982qG5YSkohC8X67 hIkqTUbtay/6xXeGEYowEvPLsEJ6IQyNQN/QSjhBhMaspbjO0MCjxHxfTjyvwygvkaY7eeZEhjk6 DRy/pV9Q4T0fI5xe04sPJ8/ijvWZMY/eLM9gwyUcUDY+eOrNdDSkgSD4BV4PMVyCpBaGhw2JKaxG IaNI4tyiLWxaEuZ5TEhu3TvSABjeTAEpygEkJyBQjunjxejSPl4qH6WQAIggOkC3wfCPF+t2eEDN tB1wLUzHBQYpDCWBj7LBQNNsMEDEkCeZnVkEBdP8SSA7BOcHIG5oN8pZia/NYtuKn37+9/Xszezd v3988/6nGf69+0F8vIg/XrrKIEWKKmccT72ZphH72puBFsXR1JsxzR/7+SEFaAYBsJ+vu88obmCn f/v1H29Rm04/UTCMVsQuBIoC7q6uqyRA2FsgCKvgizUNejyhZTWq3DYE4l5FI9Z0/vS8FM5OGlEO rxBrigw1JoaisSlzYcW4u0nj6RXFg22GBMXKIps8mpPG5hbRDwtPMhr4SdhShIg5Jatged+oG4tp j1CYGg8zETT6Peh+XcwJCxDgrebt2EZRsbEj1GUPqdQIAIGoD0ALtLTUaEJTKqPvDeg6S41O82Xf iBZKd3UY0ZKpjVHAK6uFdnAvms/9FlBxj5xKuQTa97EWjnWOFeEihmuooC2AQ53qGBoMhGlZWFfp pDRYxIZmG83pKkzJv2U0nKQ5eZ5o7U7v5qQy/LGgAX2EsCrh8DI8WxksW81uT8MqvbCL0aDxPP6d RZciBwxHeSZX47AlJDksDY/WVNQZeQfCDiMFTi8pFh1dsno4IosUXYGqrBBFsCJlaIXWOZrRhoYo gmlGaax7R5rXyMLdWqD8WOe5MAuVLSr7MAEiMkOWr7aVoEB/r0YdALYS12lYZ2iQGBrF2BYtK9Ff sh0M7lU02MqZMbZlK2keoxuDCZsMQf++hvDqz3Qwx2zFwlwkHGOczbbSiFX7KK6522k61V7gsDJ9 E34kNhUgd9eu2rVshVAtp21QytGZ5EQcz6lQHhMDqkKos8M7ZFgT+3jlenRUimiFreWZpnrMM7AC sETYVH9qO1jrWsbAJlKyFBRjINQfsUE/GmnUrNegn6NrUCOIsXSbSaeHgMeEiHSYx7p4/bIWIJN8 U8G5+h89AkGJ/gpbTHik9WyG2Qhyd/Q3XQVmaNYmLFAGgN0Cmij6V50wQwPnNg397UmbhK5TtNN5 P7aFxHt6KPp/QCpDVTlEvia/Ac8mwQn/xkqt2QtoCCBLKbeJyypM4yQRmoQ9ZBLgNkUr1MKnvDI0 6cv9VX6JS9O9mOzwP9QePmzXDz0geJxtgSXfdMN8K8dhXunQZX8uhlqhvMN+sMVVmhbidruWxnTT fe1uZDJCxcJH/Ht6GFdtNawH3ZuEc/SyqNpd7JQ1r71hIf1wOYd5yjzLN2yzRsTnKKTAPH/VhdNH IA2UFLMHVIXbXZG4b762sFYo7mKcZ7rvHpC/et65Oj9kR9IP9LR/qtpNIxXILNVIBVyqtXmOkQrf Cz1Y+2PxsWE/018c20yUsMOKpl+yutjfU0sGsmw0ZgnABFSNUCygGVyMigBWUgxaJJGhAFVsSory KVBlch/RVGB3XoRsRT0JEjKgci6Z+A9HPQnNd6aQnSVADkEsAYrfSMUwjEWjKJ9eoavUYmijX2Gk ozERCcZYlkuMbPhWr0rbAS9t9KUEq0rpdQe+0QU2Gh2h2SE5ekG/wF5VPmnV0/2gWa2j1d0F6mwW AKsXSBgrU/j5dtMBRqy0a7DU9Dy1ciZelcgjd0nyw9Bub/ornSlY+z18Z0I8wK5HkzUBJq1pD4b/ dd9h6kum9/NFM0jvaa1KjtCwdsUY46lzhOsZDTrRJIMVARmaFQERDQkGJTH63sCiySBB1snOKx7R 6LRl2CR3u1Cmg2ipu4yHL5DMmFq6tQBWTUugahLrxnJdHhVPT3rQKvaBjSahWAo+VSzDMHRaZ27x bwccTtB1Vj0WGWRoF2IyR45PkvQKTB0ZGmmLRUsSzCGBhu6/HLOk6xQNGvTX0+AE8xtJhqEvt9x4 9S+gORj1DSPKJZyag3jnCaBvVnAmr06USnWp1c015UXmuT4BKS0zlHhrnMlxGatOtk1O9v4Hxp+E pgWKHGNErD2Yow3rGHUSQwP+2DSlKfpeqXmsPaZK/7w420KdHIlTRUVNtxxZhi+gPTmaKRjEw/kT liXjjk5rzbA4sgmPaIMBCjlSd4BxSqKZeY9wg7YEznLRoRtmmlNCZFXzfi0ThdYkvbJub2d6KWY1 YfGW1izRo4yp3ULVMIVN1Le0aEpr9L27mvTlpPrx8Vwe0/869mKWTOyFQW3Z7UZ0069v2jVGmVnC On+nwQjMsIKPZWDiakOzYu2syDDDalcncKsmneGaVeJgmYaJtImtvdjD0o5d03hey8wJbybStkTK poHiHkvuORuH8x04tLV7boKM31HFHDdOq+OkHgyOAebnhT07J4LiTDbhkU5hDftuHwPtzKpHM4xL mAbNg1uss87aUTbnDE+M5YBsDNNBLVBDhDkn46ChKn4bGtRVF8SJhvlrGjXU9wYW7QyFVaZoKayp h7pFyXLcVdgTvcex3NoUxC15ssJaMSSGe4ahuUPRaEQ5TOy/TDhZoJqLk2o4EOdUrBeLEIoULp2y FUsSrFmWJKz0LcX0BSYtkJqwOqVUyIyRpRgaRixtmlInfa93dcKgATphqHm4Bfii6lRmMWq3OCRn CZHVacC5Kl0VpWWMpZrnACGcnRsIY3dvBVj4GaV1ZANCFtL006+0ElsjpWpoDdUGVdUNGTc8BjA5 uo1RBeTJec2sZ/LMEG/Rc2Rz0ElgBHLfDUovMSkovv1zUk9k5p8J38diDU56sKg9r/Hbur1FwQkj D59YBJyUIXrCnCPN/+ipBTquKGmo0k1ocYm5ANBMQofrFO0MyN6PMRg2ncLl1e9CtocYIy0w2oGm BxTIyJBtjCt4SW1J8ZkKfMxlZJjXTMqsls/fVyzYz87RPtak56jzYVM/3Hg6WOiSmK1eqnBSwHxM AHARhO+O5gLvO9vMXz6bS1XqKCU8x1P3bebnh3b1fhi27Xfih148thgkHrbAWXn4js6UmB6cbHU8 TGTEWwOnUdJJcIEaOYbGMeWMKltZAG7hEg2NslxNo3NMKWoIcG/q3gAtZU0jM/Oz3e7OFhpYOGa+ QKVi1SIzQQJ2h66WnIQXys9QTfjvlg3oXAXLBGokQEVrGsLQ7OAP18XJpNlIl40kiSM+e4044LsP iYDp2UvVRGjSEDEWDBlP3lPnZj7vt6sNsr2JW9CVeHus0Rzye7tubzq8J8TMTaBGlxY0DZRiins8 12PKJJpkVU6IFNVIspEDqzsDi+ZNpxL3QYS3/Wqz7vH+EV041BqD5SPwqJC2LjEZhE/Ixg0Nvodp FQ5q4ZACGOB7mebF91QwwBjzOygBOUCIF/8CrgdZURWnNZI+liC7HrX7e1L06HvMiUY381aUbtI/ pahZFBWfBGsmA/RJ/uBYUMMOkaXCER0de1YH3e3R35wm0kujRIS2+qCrVjaaZzE0ViKcZB9vZZIX vcqhxVWNKoNbti+qWHlBB2VxfsWpWJOQYrIOXwNRBcoKGBknKHQZVW+dWznNqX0jfkjcwwkT3vSc 6BkVG7u4YKIHPFNFD2yy1os1PFopMmkUvuFTciefptquOpJXdFgKY6HGa3i0TS4GMvuWbVovq7FC RFPApJO8OabxKVDAxyTGYRlNo5TDpqGsRCcuJvcqmhfzTHHUvcoRjbiF6lQdaR4+Ug7TtWEpWkrE UrSE6FGfSJEckx8qNsKRs5sFhSmoOfYI+RZ9c4Og96Ff44DNcjtgkLz5g+Jh/MPUk3zbCK+Yte40 wz7mCGidZoqBtQzrxJsgxnkATGFh0BNF2VeI0/W0GJQfXupavREE/cYwsYpMXtaVxvupw/ggHElh aYgZSehnLcX38nUd4/ATK5iPc2d45RgFL3uv4JmNM//ju1HUMB1qjjRKYUQ3yErNstt0d1gabbxa r+e9TF39bKFUC3v2eTIVg4nHbvMkJ7VoYMXMAWKxmAikYbvxrRmkg74X6m7f0Gt1eGuxMlvDUr1E t3S1UfleqatXIHAabN31W3McTk0nYvpIiaxZ3+HomJrygXT/WPWP+FMv35eAAb6V52Ui395LtGHF Ws+w93LGiAek/U7PxOgkF8iTBE5s74f49i7mR3eRpYLYBvP/qNlQQFknkXzVDBqOUY02rqFRJmbR kM3TSTN9byCD0ZHmLRPLTAlrgpda/YzICQGQWgI4BzGGC8qcVnjhTL/+A+H+w6J/oqPGzLVJwXB+ FDUUuBBE2foVb4YGrpkWoweAJianb+Da0Pxx7S5hDfN2RZZgeVFmAZOJFb3uAxkoDujVFTokiaJR BmrT8A6oSYOVrlO080ORQ5X3zF0KQ9UCRXeGQVQFrboUOeMB3bpNe/e0i+b4G2+hF+eHgyYucx5j BBiztmuaoQWooIixnY8BA/2FamikYjKukIPtY5nJ9yLdb8XQa8MyLQ+D00w9yuQPGx3NPNl+ENOG bbMhWwA7npeJsN4tS/0yConVWC2dZEEh2Fq/iftHRkja3YomTF9kne4Sjxw6ZK1Ug9V43d99f0Nt IllJVArQ31I34kbIjcdiJ+8X8aKYuUnJJug3PLTz7pZeFSfnb6mDhVrcgqJE+R4JscZ5EdpwU9qF RjZYHi43Y7q+9909pq620nbIzWca7uwxPo+4XJrR8hW9w6TTXCxb6MW6/Z3iXcySmLTPj0jdU+rz di3fxaYlho2nMxzWVDN626vNK14XC/exW+BFsrom6GeV7jRhO2xlSVtKSB0Ko31GGLfuH9YdvQSH rWi9Bgd8qkZx5HulZup5oqJmFeOpyoNyI79MRxW3eLeBTMHsiNTzUgtHjoOojfZZFeDwsrGJEt7h WAyJFxNOiC7Gt9aS6pJ7GjXb9xLdE9pKK2kt9GgjXIp4O+mK8CJF+ouOdoBGn7cD8g+Ilta7tmZc vCho4X63Q3NHLzTEcRicSbESwpNKqN8oidFUjqOldu06moOTSn7tsXQH/NCe75/GSrKMPWkP6C2W 5AtgedaxID33T3qEo1YwY4MfvpfqjphlkeHQUSag3RsEYAQW2wVATmZW9Kt02sQPxTW+F+oOcimP IthaNE+jtz0eJFwJdR6Uodr3OjNnRIN1Xo/HSqZ+4g35CXElzZFOYZPRaobo84gbYu49KS0d3V8s Ev+b3/c4hEhAQOj6JJem465JLAi8oPeLjbu+sSI13yJ1B9xYKoGYXhq2fxSWbyipHO1MPJsBK5YT yTQH6bE7j6fuRcb66A2B2O3W6izqlrmgjide7UidRSSp6Kejo65pyOuYVqDpU+Dd79xup1c7a5r/ vI6Gyx14zEK0+otntCic6SSPOuDpSphcZ9bCHM/nTxbiqw/EU61O9q3gRR6dMk6IFeokV3isiMxH p1gGHHqNMhjLT1Aou8AHgIdvahYD/n8LdLCqzz8JdCqiNMpKvGHIvChJ06jaoV+ehIMhODc5HpzX 564s2ukVkG94++rga/T4MKktbSqQ00QLA5WpjOBkBw55ypKWeVGSoaF8pV+oBBoGedEas4o7Fo1Y ++X/AeFbdzcKZW5kc3RyZWFtCmVuZG9iagoyNiAwIG9iago2MDA3CmVuZG9iagoyNCAwIG9iago8 PCAvVHlwZSAvUGFnZSAvUGFyZW50IDMgMCBSIC9SZXNvdXJjZXMgMjcgMCBSIC9Db250ZW50cyAy NSAwIFIgL01lZGlhQm94ClswIDAgNTk1IDg0Ml0gPj4KZW5kb2JqCjI3IDAgb2JqCjw8IC9Qcm9j U2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczIgOSAwIFIgL0NzMSA3IDAgUiA+ PiAvRm9udCA8PAovVFQxLjAgOCAwIFIgL1RUMi4wIDEwIDAgUiAvVFQzLjAgMTEgMCBSID4+ID4+ CmVuZG9iagoyOSAwIG9iago8PCAvTGVuZ3RoIDMwIDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+ PgpzdHJlYW0KeAHFXVtz2ziWfuevwGNcFTO8X/KW9VzKWzU7aUdb+9CVB1qibXbr4ohUnPz7/Q4I 4EAiqUhqqCaZjO1jUgAOvnM/QH8Tv4lvIixEEQQiTUsRJWJbi/8Ta/Hhrg3FvBWB/NvO6Tn57W3/ Zb4S/zUTgR8EQSxmcy/vf5mLNMz9PEhDcVvgg2cr8WE2C/0Ab8+exO/iXRh9iD6EsYg+RrH4fAP6 u3/diK9i9t/i7zOajzcyjvl0fOTE577dYDapeLe4EbeBn4h3zY2Hb/DxT/SbmL8K/YR5dCspkXhX 6W/0O90tvZx4+DT6WHxarb/p9DP9I3sjq2dX8mXrndsbT85tIz8Ec/qunljqTzXj6E8N9KPmG19S MKfuh/5dd8GaiENmTYpVl62JOCTeqTV556wp1AtQaxL2mm48RoXCaRJeBFPsHOHUm82FQVIaJ34U xJm4TZIRmH4mKGC7n2tiLb5J+y/qpw3ARdBSP0b9L/M9II8JjBmegGwPDNT38vGiENF1r/hQydmP +psPg286gyTzzVLjvqVPAqgNb639Vhtv9ts8Yz5GyYT37pk+BoJlBjfSogVgLqeFkYxAmZH0I/j6 1dMirjYzS7GZhchjW+lEpHRC+RdKB1zKy9IvwiQVK5HmufnRW8of8RlLekp+fRFPtr7CrIOgKLNe hYGV+kc8H+dx6Qc5Rlt5Wo9hBzBirLRcLAqRFmWqsBFpFfZOyD83YvZHr7Dw8fjkEOMUXiCkpuSh aOzJkY0GPRw5TfwiyLNITsDrdWhsJvCPzVa8tvVusblt67ZtNmtRvb4um3nV4fv2/d7UMP7JU/Is pX44pThI/CQp+ikNedK91DAcTQt5kHzxflPoP3lw7MQkP+Ii8pMsKG1+8IasN0Lz4W9Ntaq7eiva ruqgqfUeRUHpp3kcirwo/KiMS6ApDnI/yuLCM7SloeE5WLEyBrisVzWJcPZN7vqv4HWMo4BXGQZD Vkp4rapm3eFfvRCPdfdW12vRbat1W83lHvtCzBTH34uXzVv9vd6+v/HMcsGcIA8hLUXg41+C5UZJ 4WdJmTANa7NpUQ6wg6beBVugPXraZYLF20mK1xIsbKWf5FC94wyo1qJZAc9Y+2a7qLfN+llsoEA0 sE5j/TE8EeujVAkWA6mX7G39bVe3XQsef2pFBYeo3S2792JRzxsSNtAeN7tOvL00cyhrt7NKgolZ MZZ79+hkuToGQdYzZTJEog040W3AiD/qeScqZgptiwFdkvpJGpWRyLPUz1Ns70qEJSxvnDIJytoi RWmUA3L6TY/eVLTLIWcBLU5izCkhoI0xlnlq6XBnCjMNsRb41DS2knLW4Rpk4OtbtV20zMbeWp28 vcdgnuQZbByZkdHlV2tmwDkyBRcW3tShgSCZSqes5Qb6abmpFhDpet013U/LTlzI+8OFe9a+hyVw FAfwL3hKzHsDZV7+mUw/JlMRMJwkIe37GDvmm91yIbrqz1rAZgre9zPF+nD5tn6NIWJRFtG+p0Mt N9+sVtV6cTvfLGwLGUJUigD+VgoLmWB7YTKgp+McYZqmwemyaDCHMcQdNH7X0C6QX8VVax+TIvaL PE8meLm3f9oHk/LrnYNnWPIRPCdl6GdwA2wmMoYUE8U+Ex3CKC0AYXJUxmG0eSL4GAY4WC/Jb06K ykPAPmETBZySDda8bhvYZeluSk8Eft9zvQZlufwpVjX8FMyu6hjcf307aHrFEMy9yd6zVEt4flvM VMpXS8Z8Pa9hqfYcKNG+SEF8rMVz871eu51qBjxN2PHVBn7yU/V9s60el9AB27rqVtCJxLA1eNe2 1XPdirrawgEaLMN3Pc9wiqWzF2wq/vdYz6tdWws577fN9k/xQg7AEvNe/MRv4ZguNutaPP6U/NYO uOt5xlP8XMM7plk9ISjqXjaY6R4YCIZiM5/vtmIUF84Zmkwx9EF6T+TLQnBXECKyA71vSWBt1nOw tFW/F2QsBQI7shFqia5Zmk2xFPtLw+7xcQKPYtU8v8AlXLYbTBPWHerhsXY903yKp9v6FeJTL5C9 0KHPaZrmmAFHMiGE69BH3XuKkEdhYw1nSKcVSPufH+vHoZ8EcRHKUQdK4wvFsU87pAf1AuMYZjdA SJfBOGKiOQx1lvglYkmLtvQsWuRnQVLAUFvvGtrlhnrUbBL34PAf5Z7l8bnKmFhcjDVa2Fp/6dMk t49VWyNHpVnp0FyHceQXSCdOrN7OzyCbN/vD63PdJyURjrl6xO5ML3gPrLCM/1ZeN1T2erEk1UJa ktfPKD5pHseEJooyP4nh8NJ0BrsvszE2iuGsA/ZRkCFxh21K4S4jWMwAygJZC0NDtMi0yE/TMASK rXd7GtzSC1Cs2Gq5mxGSQ0UCiRrnKTPOArCrcDEqM6Rn+qEV/xi/Kr3F+O3hcyZ+j+EoLgs/yCC4 40u38StWuxbuCkUw5A4yV9yo3kIHy4do3nM7pYWShp+NzYW7sseWg0xVREWCOCMpM/PibSEjzcs/ czeOSpOOIa1hLXZUbbuZN2T4xFvTvSD72XUk3btXZsZpm7G39kH6O0McPbBIvcfNy3aoREw6igYe KBE7XWEyRsjf+kGEaiOqAzGCXqk+NA0lAqblfholFK3qd0UWGxrUBywR/T038WKpjxxZzTAIodNG +cYsuxCoxxCTI2gPw4Tsj2EdAxXqf290V1YXchGFU26kTmETMiudoe+Tqu1u/vJeivAgG3QmnI4B mHXa2CSNTdS5KeZQhBJ2XBRwp2J4dyF2FLkQSkWE5KYpGuVCbFoQBpTL3HtX0cg4nSaPx7aYmB0N xaKXR4S3KFhqx8bk8PEGPENUbeAjoghfxJAAQ1vu05Iyl/UOKBpZO6DnFM2JeBRIRobI99IqhlqF J38F6Shp7+ISkskcZOlo6/WCQKpzso6VKJJpark8pEpb9LlfgcBfg/BK7mkUoviDbDgYYJLRlkHR UbtOzpKbWF0rN6kdDeYLz2TgKFryFCKvWsBDskpZmaYtPVPKykIEQ0VM4Q7LItMucBSVUFqa3hSw xtk5jWUHebokg6rPk1Ju5QBYA0/R1KjPsW2/UkNjiW0JactPVKmBDsJlFY/W9Zs2BUbergM0U/zI UIUZ6JvHGhjn/KmIUsQv0v9GVbjMsdeAWV76fVStaYCUonkZaEmOkBs0+11FcwKzFBq4ICjTEgb+ kBXIHapMBzBLYeayAo6VxT7WX6/bhvJtlvNPvtMZ3tOvECYz0dQ6xrqh15l9EZLUNYKPbWU6ILTy hoNxj36IxaKhQvl7A7Zex7tW7ZMZaT0dJQU6zQytukS1Hv0bxECqg8FwP9a99aHqKlz6yioGnuY1 HHOCAB5kiwb4P2SmbqA4MIWDNKV+jhT1zvlEJ7PRPYuo6g5+tT/XczBNdUUgU2nM1xw583WH9DR0 Tltvkf6gKj5vukPnkuUjHpn1/6C2hvYr449pRxEdTFApOTUzxUHsxykVZzWN2k96mke0JMwy0i72 u4p2uXaZytnFaLAaydkBJrwKS8u4CiA44sMEBsbsE3c1ofuibZ5RYrK46lDlsH80yghZRbAYIZO+ suPrHJ13TExN1Rhe2pARb7JYQA0oC+Tlr6N1TY8VzWCIBdX8sWoWWuWyWLnRUpP1CKNL35rl0pQZ dDoIfTg1yhVU/alViwp1xDXr79WyWSBJ4lxLTZYjaAaMkjOVzVGLqEOnGKrjUEyVSua2P8+EemmS +wVSJFA3ZeTHCf4IQ1vu0+IsKqFu9t4lmqvkaohesyTCGEi7aIRbxp35ZqmZc6TrGP9CeGhRhOZh GlsxkJ0ZxUAzgwszQaOqFZkHv4gRd40umuxUtTbNMOh+v8LiowKRP+386OL7CiQcELV8NG6eqVeP qbVYN0GNr197E/MlegZud6/XkR7TyWExgJEndfuqolq2jEiaLdUTTVdbhDoanH70YbAsxUkGYUKL jKHBdNs0JUv6XY+eU7QLTLdisBV/ZmmKqmPab+nQtzNIvgacsgw+SgDXxOImy9LrdjOvFzugStdk 3QIK7mwSDNUHKqF+DFfvoe/dFDPulRV3S+TLmyfVHs28Oc1qHVMrNJnxWuf9eoHSNP4PjR1qTh8Z U6eNfEyuaOTJst8nsn48vjKf1Myx3tBBEe2VhlLST054H+MEV84wrYGFqsRrtZWuu85RUnu4ruyl QYQeZfRmI+IOUj/LUvRrahr8X5sWFehqs6qC9BzRlJFyw9hiKlwyccahxTBN0yKhzsOspCwV8sHI JCSlZ2iYuKLhucTPs0JmqaCLZMLVol2gJdT2WFoiRK4ig+4CVkzxivWeBYRDo+MgfRCifz6hZmAa e+DYzzfbbU39ODI1RBZwI1047ekxRs+0RccwSjJjaiMWH/rE1XrxnjqbuTKxbJ7qrln1nWNw7NSe 3zYLkiTyPpF+kA366HlBbcpYDCcgTCfLKhDt5nuz2FVLu0NHa1t5oO+UlpRfcCodSxML8UU1Utyv kV5B/x/SMFdSb2muYXO4VZ94K3gWlpIjL7yRv1nqfjrEBq67ETM0aA4tr8QSDg+gt69pX9DHV3Fy QgEIVmqGGX66ezCzW9RPEkiNaxShD3Fijr8//OMuy+P4K4EZ9Yf6R4UjFxLsplZ323NR7rLir+UY OYE5clNjE7xj/XAMccaSnTaXX0A+w0Gxw9iqT5Nhv9C0WeGfUkxuTzdx7xCmMGDHHD1L7Xv0X7Yd q8UiQTW7RGESzhCawFCqhL2JUM5Gb4yhwShatARNYAh+lsJ619Cc2BtOooyykmd/BXvD/UfMQ/ZK JQ8pUYAOW5zlaQjpShw1yGGKtPXpG1zQxgh8OezTykzYyxPr8WWZQ4oI0Z2PHmAc/OpbalscabO1 CKU1KcvdQXTZ6pxpKI85lymcFASNsN08ZUsJw4mEevvJ23ma9GHEIycts6yckj4eyMKN+wQkJqBk j7eHTAlhZ28K8Jqd+MwhugxQoYRbMrp21cAe//PzZ/H57u46WewoweHaGIcCaQ4D1VNt5y9Nh6oE 4jlOLwm0mfj4lwk6ZxIUIWWzQ5TYywTVfU0j5WNoBU5fFmj2A828yzQnyoczDaPc3NtB10dF4hRn idMc6SXmIoPI5qL4nfYTLWV09PyrxdMzxfeYKUszuP1l2O/p0KJBC9qFz29/uYEZAMZ9Dxho7OCI UbfTG+CgNSaMUvSWINDpJ0J1Q4v/r4g+EYjjaIoVFl9Fc5omTsxjIE2sw6/KiziHVcdRnklm6IPi ahZu8zPcGTHKAmV04XLuYfAvtx8TBqP/sAHBBAYGBMe1EajZxtKhoLMBGV37oVdBXbvIccq+twnv goXiZJvOh7yH7aO5acW33Afp8vTFWarNGh8+dJeNYnUwkp2jg008Ks64o4Uxjbw4g/ecwOlBqQTF gpR6+Q0NpRKbFuDABjnS6l35nKLBljnInhCcU4LzmEqlgE20rygGIgVA3gnVxKsjoTnY/M8f4u7u 4faeN1i3CGLyMOIR3BCr4cXQuOFFkJFLkdrCwvW7nkUjI+4GNJN5TeOfk5P88EN8+mRCaKlQdBDb EkMs9GtPf2zxKU4QUNssFo/MHbIeJRaqaFioTQtCXFSyt3iguqe5W7xJlh1KzDAWNxl25Hz0jqAM AUsYYBUUD8YI+dLEMzSKB3sankMEaa3GEE5fyjEfBAAuJu+2+P3fSI3ft+2u/ihTIa/b+nuz2bWU Ja6et9XriyzytgjInuCr4PRm638d27wI/Vk4HIy9oy3DuY1YUbBLFgVXTdCxEeYRniLaX6psjlb7 aNmm23NvB+9ls9IXdV3LQ1+mkCeB1K1XLkxgMdk1JUsCyFfqqFfHujL7Y36QpTAc9sQtLiabacVc 5wQ+e/HlwaEK5IWpUx8VJJ4wu2sUc1HIyzr6NLXyKzgWui7BQ/XRt9qU23sko+kMLk2ATrSCEUj1 Wim5M033HgsOjKNxFIuxLCJab69hFuMIoE1xxB91B80MBqnWkshvy/ZfNNGpQ76cz1wwLhC4+nGI agyS/DjAiCMyaGmCiBUltKmhoS7KtNAvA9yHAS2k3vWQwtI00juXMdiqeOAKJoQ+FFKP8pW5eiGq j2EMB6fQLo8YhJnLSNMqzszAZY8BbikAF6nWMrpqnbrFdTZUGIQWMLM40WIfWzZ4XeLywPHEqcKU UTB8SQAdFsYxYzotjNauJY7go+xOP0vxl61710jalyO9er0W0G5xP35/qxadyLaz3+qQuckdqlT+ l9kDy8VpyuqYbiCOjqfFMVN1QQB4pksG4lgqX234lVq2StOqxmqk56Z21a7m4SfS94YJwRwG4CNX 939lEyh9N9Pwaw+5lgRB9lWGosbc4QQoMlsFrjlBv1S61wWuSfAkdGN4hG6pIo3Iu+AXe5LLijSu lhtmEySjn3ZbAHa75/lO9EUbofeMIxRR+yUdi4EHpa9wMTQs06bFMa5CsZwoeo5oV3GiypFkJNb7 ub/0ThlsXXlsP14pjOTDn5jPAGT9ZLRDRdztawU4/e7HaNoVEW4YRBZdtgKoO68MiZKjMMYIT4kU h7iRECT7TaJdg7d5YNIUh0JrEEKGeC9H6sBOmE5fmoBiJttHtbPKXjAzL/MIRn3zEI1cOCmK++9G OaA1lizzWXlCVh7MHoepigRnUIOsxLVLzBbeFwS63JXAXMGJZL9ExzBCGnSRFLhDEwJMFxZGiIEM DcJq06ICZ4ZAU+9CC6Cxrac58b1SnLpN0Gw6wV/m3lXAhfRMkWc2FxlclC5Y4H4SND/Bp2c2OgQX 7d9ksotcCl6+Q/DoE5U09kA/KUDbTSJWudC0+dIZuSjHvc9IGEAVRUjpyHNzkkY6ydAyP89R6+EW YS+Cy6toTiCE89nQiThjO85M5uEVIGQqYRYzGUKyBqvsDgWKjzvrciuHODJHlsc5YLUgIOnjEEmW GhqBEklOh+s4zQZ4WoswVKCBcDARbV8Z06BtmGagYr3b0xy6Sig6TLlK3ea5Pyewo0uWzFI4LUQX veZAPwQhwE3fKKF4mgQ5UCR5HWyUAqO2L4Q3Fe0COVDRlRXGWqZKZoEPzsHx3A/lwEHqOczhv0YZ ro5lVrIcWFlVdCf0TXvKaN+qjj6e3Wmh0PHgMg9MPynPoo8xmjXyFCt5CR2146nbcq+VsGHVNJaf vpqKN837FiPYPzhsSEVzotWhFeImR7o8MaIm2QQnSCGjxnPQNPYI8Fzo5wluSwXc+1chAIZ0AbJV lGsh29IzY2xk7Bwi24EHiiMQuEwSNwhZrGRM6SyJmYLLDI3pqKGhR0K5mWwwM0O71OymG8BaNQOo /tHYbWXm/KEFGU7gMWQsmsGHfteGETBzIRstzJik3jjzmGtXwIxO6lnMY8hI5lm1xECu9eTeoGM5 IHPIYnzNWu557W507VibuFS21rn+/mpPlUrpW0dRi6RWbuuy7j2v01JJp03zGGfI0568lUheWqmu /KTeZNQB7VAOqU9zgzriOrrWG3dcItGtrtN3m8WDqpnyRZTJVPnDT/cP78W/UMykQOULvppY1O4B 0xm/ux+upzl2HcvhrsuwWDUJy/rqwX+AQE/Z9V6HI3c30GGfBLx70Id9fr7WfNfdPV0dr/5TCI7l Ixwpm4BR0N56y8ScDhuhgIaDurjn+onusMcmfoGA0KFUeUwJHRjf0aFuTRPlJsd7Go03fo9eYa/n jsMP5k7c7mW76bolZv/UbNuO0rgmRXqhmt0T6sOKoL5rGY0sw+QQ+Ot4I9HxMUhBYSOfNkvczkCK A9378rySgjXUmb6md1s/4752ekbxiL5FSwYOvuFUBmIkwycnug63mA+aijBTnFR53mE4XOoIsMl6 3dhZ+b7lmaBW0x3D/awdX8+K3IF2adg0YoraRpmrjaSTvt3QoYw5qi1Nu4IRaefb5rEXko5uHF5s 5juaqms9gmvLx/j49x/o0EINCiJJF5qMbq687lCWqfqSyyvy7ZY9tGYKybi4Rn5QIIaZi8aT4PfD o32t40aCHJXiQT4JW4o/Y6OjCWlNdTx5kbaAUpZHk7TA9F331Z8AH8vGb/8P2jq5NgplbmRzdHJl YW0KZW5kb2JqCjMwIDAgb2JqCjYwMjUKZW5kb2JqCjI4IDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9Q YXJlbnQgMyAwIFIgL1Jlc291cmNlcyAzMSAwIFIgL0NvbnRlbnRzIDI5IDAgUiAvTWVkaWFCb3gK WzAgMCA1OTUgODQyXSA+PgplbmRvYmoKMzEgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0 IF0gL0NvbG9yU3BhY2UgPDwgL0NzMiA5IDAgUiAvQ3MxIDcgMCBSID4+IC9Gb250IDw8Ci9UVDEu MCA4IDAgUiAvVFQyLjAgMTAgMCBSIC9UVDMuMCAxMSAwIFIgPj4gPj4KZW5kb2JqCjMzIDAgb2Jq Cjw8IC9MZW5ndGggMzQgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AcVdW3Pj NrJ+169A7ZOnaszwfslbdpJU5VTlJLtxVR42eaBl2taOJDoiNc78+/M1CHSDIqWRHChns8nYPaQA NPp+0x/qX+oPFZWqDEOVZZWKU7Vr1K9qq7760EVq2alQ/9Mt6Tn94+3wx3Kj/nmnwiAMw0TdLRfF 8JeFyqIiKMIsUrclPvhuo766u4uCEG/fPar/qJso/ir+KkpU/HWcqJ/fAX7z4zv1u7r7H/XdHe1n MbMOfzo+8sjnvr7DbjJ18/BO3YZBqm5W7xb4AR//SH+TyJ/KPsGP7jQkVje1/cG+09/Sy+kCn0Yf i09r7A+9fWZ4ZLSyeXajX3beuX230Htr9YdgT5/ME2v7qbyO/dTQPso/BBqCPfV/2r/r33AmwhCf yaDqbWciDKkbc6bFJWeK7AHMmZR7pncLoQpDp2n0JjLFzRGdLu6WiikpS9IgDpNc3abpDJn+TKSA 635qCLX4IR/+ML+1IC4iLfNrPPxlMSLkOYbh5YmQ3YVB9QN/PBuK6PsXfKjG7Nf2h68mP/RMSfzD 2tJ9R58EombcOvdtLp7vm5/hjzE8sbh5oo8BY/HizC2WAZZ6W1iJGYpXso/gz98XlsXNZeYZLrNU ReIKnZiETqT/gdABloqqCsoozdRGZUXBvy7W+ld8xpqe0n8+q0dXXmHXYVhW+SDCgEr7K55P0yIJ yrJQy83CyjHcAFZMjJRLlN5aYWgjtiLsRun/9c+7tu/Xq+2TemiWq27Vbrvg3eLuv0aKEc7OWZ2l 6NzqRbEYBOho9XfKrjJISi2cz1lu4Qjtw+WSKEjDpIxwHcDy4aq/NB2d8Ha5a+oeZ5aDJklQJGGY qqIMA/yb4p6qPIgz8JbA1mNYXFR0b/bdBb1rYG+7Q8Ei8fj4DtNweh5coWAR9IG7ikAoJe7eMzZl 9YQpyGJztV31qwN8Ovr2nCsF/crZD+g3KqKgjHPwDDYxJaRd88e+6fruaxcXHikqzrMgTaNKL38B RUVZGFRZCe7DBxQZJPRGxVESpCXuh2HrMQz0VpAkMO8u6DkDuwJFJbMUdW2iytKgDIs8BkJ5A38/ UVVAbBJmehPHiQpm5Muu6ZptrzYtTMrXdvdR9c/1Vq22D81Lg/9se2HBP2AW/WVxmWYxyGwBe3Mk LnEt7Q7L9rv6thvkGHY30H7g0v6hHFj88ZeFeAwtE6cJXVkWG2zJlf0IzLSfmt17ZfZ1ayRC88A7 dHB01m5OyXiwTwpxMAh32YbWZ6rGLfWfX1bLer3+rB7b9bp9xT7uP6u2f2522NC67gGwW7W/MypF J3iUYbTl0mLu8Fq/6VS3Xz6/v64sj+IsgHbQG5ngru5A1Y3a1Kutau//2yz71adGtY8aSne7busH tWxBfe1arfA0LEervv86fRF6KivbD2901zzsl7hU7K9v+3qttvvNPW4Su7OXhtsEh/btaLu4ZEBX /ef3slW/V5pFx650zqxSm9XTc68e609H+VgRqmW3XhALjTKVb5pXhCc9qkuR7qTKDg0wy3VTAyyF ls3iCiImzII8JW0ZhUVQgTAYBMXogmBNR1CW9s0FvWlg/pVllpJUpijAIfsKGg8lL4IN5+iDU7LO QSdvQBjEovPaFhgrS2BhSkyWC6GFftg+rD6tHvbgUkGLR+pKijTIswq24Nx9WHRMqSsmosqzXOVV GURJrI2xHD+WhQODMSawIsiTiIwx++4irxj2dvpyjPoULmEK0TeLVEHfNagKbBSXEZhN0Pi3UxWd PDsmmyxNqSVsrftGPUEfbRXMHVBWT97bhiT+6zOAm/ojua8icn0L0GKG5rUAdTxm9mX/OssDL3k4 K2w+tDtrrjB5mDDj2e7eSU8LMc84KoYNTPh8wl185iIPiiipEpWDfcICPg+Ed1LBwEYs1sIQ6XBg RYAoSAXuct5l2Bu4y8hQh7viFIJaRwJmsckIpDjJyG/2YS+nCPYkFaIJWHtiL1tEOlKbUXmhgXJK dSQVohF5DCafRYDlMETltCG3oHDWOerqFAUR6ST2xIeK8hv178FfAa/WPYy3br/uO7g0qlbb5lXd w6cCJ78ntiYrHgafAZHFue+aB8+cnafHxM8jTLRdu6cYEdmZ3f6+o62PfL2zkHXqgghZcIO/ZFVY 9emBLsWawMJfZHA2r98Ls1hjS+UJWD2GAQZWT4sAmZJ4wTCwuoHhObA1eNEx1FyYH1bPoJjTMD+C T9n9NVidw0OC0lOqlJFq3ZWu3iAXc5kv9SWq4tCn7GTwjrtmR466rBcuSOL40R4hzJkIEewinwv4 ciSlc0IpzkYOpPCZwugUJmDhBGGK7ARtyLCZIIQ82tHywIQXPCRRjGAJIsPzeNDRIxuL4PCNjQHI js4TxqfOT/IFDtW8fIF07RohxsE3haFlzCg4zzrg9ajVxLZHLEU27lkMF3NhXU2vRkdRQKdBWsIv lyBDMIebn7tm/9BOQmxf+z50fkz33M2kZBDI2qmX+Z1pE7mvPyI6SXrT9z6Phq1IWxtfz9oS6nHV U4hSAjGIwiE4Q6oTIRwnYuN7lxw9OjQ6Xlf9MywMMiYG/NnIH7xVY45Q7Av2CEUOm3q3XiG2NLzh eZNwuCY614plg6FjbFg/PcFc6uAEWUZklNPefW/0aMioXS73O0URVIsjvl3f7Flms+z5w2wA3DcC yuPMSaapDjK/tmq5rjtY80TYo8B8x4IVVHYH0ntc7ToUN3DI1Np0Z2q5UyZ3loRBXsIQg9813TUM 59puRuRnXCJrHCFLmiEonMBNgxWX4HOKEGrLwuCwOTAkbWKETRAOkXcZ5sWKy+M0QAqW0q1IaE+0 luz+ClYcnJYgCiNYkIJEMRX0Ncv652nm4c6QEELJxmGWGpq5Yhdf1hmEAaLs3QoJzZG4hOpb6Lqi Cx3EU5QTRyG8VOAbe5kKJi0T5dAXUuwpuyRmc12QIGIbOTVUfFh72PoRC6rHAsHC28hj0DsicwYC X8OFJGFFQWH7nn7KwAyVvsHOc8MKZRmUKWTTPNZk54dUeiarn0QcKhLgs84TD0TyZrWFZOYtaNPe l1Gb50GZlbClZ4mldrQqybuuARU75vV5LHPq7MQyuPSJWNA8w0c2tUrd0quzjIUn/DEvWNk9zsBb cZVTnLmKgwReSApSHGAQrAKD04QqEoozy7sC8yJYo7QM0jhGHmUWg4K8Q5L1gMQoQxFNjHo3Wtsg UQReuxVqPZM/viRWkaQeaERWYbHaI705JDq7ph+JV1bMPsUrJ82ruZDY9eRrEkPpZFRlgoUnHLNy pWtRBnBX40UWxqh6SrR8LfMgiguQq4VBmrqwGIYASVjzrn7OwECubxQ6joRNEuRqMq2X5vB2nFzP pKBTUiZJUaCTIfvooE4ICWbfaPU3aJJZcyAR4Tp3Yop8XiedlqIeKYeQck4rihheHIT4p+azle2w I03tRA81g6xM/9o0WzFqYxiTKJeDZraUA6uyQGgO9g+DYFQ6IEM39k1Nh0JLuoTxcgXm0FIBq6GK MsRiZnlwdJujJIAHWiqAjiLKR2wotHT/ebS4Chdegk9FGoGjkYqZPzC5wd+uEHEkB24JV9d7RLuC fTKvpOvtARX7Yh8IpxASC0eeiecPEU/HOc0RFCwTBKQRokN+BLnkjYJNlya4KQatLWiRVmlQ5Ehp rZXzJsM8KWi4cDF5H7PYGxHKiEp9KGgxDhh7QqUD9ihUTaVBpD91JKXdPrWUGjGZLNWRQHBwDC3q 63JtknzubpX6xRTCCYo8+inIUAZpZQhrQtTwUwgFJg5DGxgctIRy68iECDFBCoJ0KpSnCAxiUGBM TfZdl+reQGEjp29aSVydkXQ6NAU9yENJPskGhNKs++LgtBPV4tMsY693JgWmuud2v0a5oBsIX4PI 1CgCt9oKwflxbThBIfp3MFvb3QNENRiQV/Sa8bdFgdVMyuZj07yMWZz3gE4rklioVEU5M7IdsU75 24pnC6OUP8MKODpURg3Ryu8KjKjcDyaPZjxMXIXqRmZMF4RpYCyotIAhHCNzj0BDBP1NEQqG4Tgu LI5LKv+PcWX07oKeM7C3M61jvERcdlVVMwEauYwrMCvsOFRPACHoW7E+hDDr065eNo97qrC1fEs+ v26u6N4rBP3bV5gXTb293b/A0boKIzvieQ49ZOoIijyqhTzKoRbIm2bMCNMONpUiW8fmWtm3RNkZ Kt/BAkxQ0AyoKUNZzIjIRjBDUPZdP0Q2eCETzYD2yWPGm2DyCsTGmsHZgBCb9TqQAGn3uyXC7b/d NMFTYAlusD5+e3cVIkuyCA0YKGOirU2CQPqeBTUeiYyLdxyUCJW9tGC1e3DfUBstJ+cGk5QaRyLs G00nEEuI60eKYZBZAoPxEWkxZnpTFmluQV6kWGZrDecxKNi7BmFBXIdlnOnbm8SFnhAE2q0eSD4N 8WaUQHk0NLIKNFxBRc4fHPJJzn6e6jsd+ypDxGXmXS9ZyCOJOlw7s7DVBrz0guObiJ4j04Rb2aBA wVQOMsypCCRYTEkZJzZqYTAtvFBnZEseCXtT/ubdT6oEPVgrtiPDuTiRetsGQR9k/XkHHnw9apDX RQ/UXCRLGUMTBHmsv+j9IGjINie1at2+Tb2tnxqqxL2OqU775X4jkX7Dflebl3qJKK7xSE2PCjd9 mMTrQ/NYo8pQoWXrQXe5IlWri29EZl7CeyhSmk3nleHRco5RYti6i6iB0s0g5GegWIIKmgmzm6HC GYLdqWz2vdOjBR1SQe30Auv8NVLew37rddeSc1S/vKzRYtWjmVatG1Ql+N7k0XoObcXDJdJrd4Qn Tbddu+FqpqFcSCfpdbMNaIL6aoZ7993djKKOqV2QBFGQgQI51MZczAkqH/IjNWEj2sNE8n/bvKzb z7pM/pdls613q9bhUo54Uc9MiLweJVbzICsROkwtDP6OwNB4ERZkKJhXF2nIoPO9t1Fo4qDRF+we zTcE3D0j3Yacoqa3h1W33Ouyi090qL2Tz7CuGMxqMCo+bYFjWQ/UwnAEgZUVzozKUXHjVCIwV8Vc Jn8dN44biOl0ck3DpIQbx0d5owEElB7t/efGTWdtEfzfPJEz/M/muf4EPGpVM8SwvIhE9NZMEn4Q 3T8MAht83Dd/6iwcGFj440ID7FQyh/1nlLo4iAcLYkTFzYQ5Yf1daB2dImYH84wHUWFb5E6olRg9 xJZJO2ZSKX4gEyvPU6RMYMdSWmqziGGdY8ZAJTCQrsDSIMsQeyQS53cZ5pIzBtRcUOzvkHNaRUFe AKFjrP4t5GyCwc7KQsw/GQsABPZgVdMHnb+qqfbwt5tvf/rhw5W8REiueK6GRh04iG/k8FNETrUv YVnCQcUOJi4ODAsITTLbMBDFtnlcyGKnqJxLC+bPT8aisPaF3HXq1GBolDQgbOKcWrgLpqG1TrRy GIRaFGGOBDmDSY6WhBTdb6QcyqBArptBxDgCCjFLhHjJfZNgvrwPrlCfR5+g7gqEE9tCJgeFwk3c 873awgnZaGvrvTb+H/dbrYfRiHfPmoNjXB5pC5VOcBNROjKPHBjygh+PpAXZFlThMdLqn1uUzTti e9M+NGvU6jl58AQUFOaot2Gq2qC4p0KmHTTHMHJqHZghNfvugp4zsLHYPqvtaMSz0zgfmvzEELH6 8NQMCQ/WKk/mKWV1oTe2lOFQwp2kAuzHHUwEqtIZAqmIKzfdC2YU6cEO/PzLrv1z1XROj78X4yXm QgzZI4wX8spp+AH5QMt2s2m32s+EdUr/37y0u77W+YVljaoNJI30YTb1Z0VymKq3PTtK8UzSFvt8 qXf9arl6oToNU8vOVsWFLHpSDNvRPCX2MaUo1+kmXuUK1lES+0zaOkXSYmzJPuTeaidb5/HwjgCd OzxLUCOl/JqXXDJEmJ/ErdBrBUp0O2YQR8MQInTcJgjDIYShA8MYXBVGMB0Ytl7EAoPZSG6RvDgA zvf1TlEOWUzzOc87CjBZW1jBxdOFMgPpiH8XVzQagjQ4vFAEXxKVGBDUtQvCgDSqBx69STBfKpyn U9F5JhfhqKgrqPAI+dMczoCLSyF7eFgPGMxFA92U+h79Q82fNQyjxruo5OybrA0RBNvvM6pG6F+0 JiEK1qzXK+1wbsnve24pt7y2Pr2dPSfi8UJOHYmHg8ACBovAZcFQ0BIm4/SO7msqsEMk6yr2BPdn 0OITGUkW8jCkCFa6bsU2lG67LBJQbpojQkEdGiW10pYgdQOjDg2GocSEJmOA1s27iyRm2PlcewqR 4FqsPcUgRlMNfS7DsKyl488L4yEPlCYIPzsV0VTvQjAwI1dEJ2EeoFiPfFjnXYa9wRj6ghyiPc2k TYQYHM71VdUkxhCd/rBgmVWHsLDbsquTVGdXC546vbhRs0iAzBAswMT2dfo4KjFcJcVoSjm9eG81 eu2HbkFn8RguWwRJHmNmSkWerhOvtDBQEccrCYZqE+29ue8a2NupyImEoL5ft2PQKaYUJJt36AdX 56U3IYGKSzFRzMWgSF9dq/REth9TkuPGDearbO88e/kUGZFY0EPraDySbANKALHarhnaUh7UQ/u6 7SjXsXEmjHoU8w5ZzWaN2GcYzHLfGMBtnBQj4qNeEnmbTTg54mMmmwNZ/OvzavksEU54IbAEUDnR 7V/IMpSj29mlqAgoggRxRYqY26C/hUEUOzAUsejJLc6rFjRmq0uOOctWLkb/lviiw1a8ttAzGTMI lYOroLV3ThBAjJbzeOlLKpaTX7I2eMnWwfR199FpWd62PbbyuNrChnHrEi1jXZa3mCc321CCmTZW W4m81lEhoSgh87MiFafkCsYHIexdIAKEdSfM9e1PH2DS9g26JRF9YfcyQkVVmSFuh9puip5TmQGM JkhqVPUxDMaFC0toNhio3LyLKHsVGJg3yymdSRTiWo3lVG/avVuMz7ZPTIH8pCIDsIQHFlcoiLAw aLwRDNagNgBxObqakZ4zsDFrXnI1DmtichragIHbEoeZXIhjLFxB5UWc7RRECn+wbCdjXiEo1LfL FtPobR/peYx5ihih5NKZEXy4wf/8+/sP8ECT34eaA6y/2i7X+4cGlZCIEGGCkJYXmm8RQ21f2nX7 BFGyGqYdocaDw6fnbfML8gM1MhOTEtvUWk/HobAlDPysUT1P02DU9zrQ9h1KFn+7+eX77357p6dN 1JhUudvI1qw8eUu45tAfg6uOSXs5MMpbdeTJKLJ7SElnLn/qJuFOBQgBDMsbKp5SEtOOBwFKtFOQ eTApvDGxTad34mwSOJr0xWpot5ocDCTwCwhzGKzVtWtMt4LPK6oDcpyy7BRifbQJtM0eYwtIw9zD bPt4FWLIIOnKEjlL2vTUtSQHma/i0gTtKSrI0H9RVmhNc5AlRGgTtMyte4x6xgyHtqVZwoII7Wek qANHUBt5WcQYEOtHgTAmDkEDWRhi/QJDyZupuCQfBe8u0PpjYW8Q0yNpMI31o01+KqmvXpqCqGFO 7QEYTDFdfiiSlrqNBcYGllUJVR1T67OuWuXh+xbkzN4nUJxhGgB6stw3CWbiemdz0dGx80SQM6FV 0diI/yOa9icGDEsFKb74hRV3RJ1jCMGQq2oSiAuGwdawSUWCxejCdQMeDuwNFGHI3lXcnC/Fmabk IAx2KG49CD8pwxB8irgd6WtRpYoG8mzRXrDaQI1i+A1+X9LYlWcaVU35F+FBP3fN3UCyN9w1zVXa agmIRTHsZY8yM8mA0t0jTYXvx7F2htWSHvCWIG5RZqCfMuO9iYDSVjdbPbKByF90COP5EVqviBFm OsYGzeV4QbpalS2ZOEHIDqVP6B2noaJQ9ghgIu4DNi8EhgCmwKgWGDkBmObm3QX1nRvYG9jACEaH DfIQE08qbGoepYLFQzbwYHWgSiNAt+kIm0JqJlOohwK8Uguab/Lm5ISsCfLWal2NedBk9THOH/E/ ofrBfBzT/n3zmcZ88KX74USO0Y+2SoYA0/toxzC7v3t8HGbW6/FYMGM26D0aRj1wdN3zNlENOWdl z4sDH/TDhT5YeSrCa0aOoWJP81xLTJCdWmUgHbdcwKPQIW9XfzsILTw5plN3LMfkxgLUVwYR/Hxy lU1HN4O4bhUFPjDPUFTndBUYkLEdrAw/89KmYkZc1VnkXVXMSEWW4E/4SDOxnfgLY8Xj+E8Itnw2 7EoRDjnydUiFo8+iIP+XvyWCpYZDPRwKRdQM3w3CjxjTlOr2RF4IgWGmdARXBRElY7tj0NQAgtYS EIzfBGErobBFhLkMBvZ2TTYE5w5MfPFjgP4Jw7ionyq1SyK0s5FB7sF07l6o7YdHha+fOzSNzmSr U76b6NLZM/Ntioy4kOxGPtVB9AKBCxgl+IYw58xCdsahl2Nzn7+lFNhBqDDH1L3KIR4LcgnFeXNE PH9cEr2bvTbiVQ5wy94h03/FuEzMvabJL93KtlnoeNCrTikgY6/7fTiTwLpf/B7YrXBuyO+JkYBG lkyhP2EAUU7XgiCFI4QpCGQaqCM0yBrY25nEMfeokaGkgWl02qkSkzuacsZfRrEdreMgWhhjsKXM N0uhcKxHJQR4xenPeJsOmr1sMXpnsXC1AEuObwBA+/wRWhtF73V2eyh84IIGphlqksbXTyXoUmUY /AaBMdHYdxe+CQlfQoOZWCjC+H8gpALmShWja3yWkv6BMSRwTx+afyDYjJguZulTjY3orvOExSl5 RxfIaR+hYW0CuuFk9HWMQ9sKweSZugUfrrEdse3szBFjVyNp6QanuUGH2V7xNAadRxV/oNKKciVR hEYjDNnQQhHEFEFMMYxEoAMLK4wiomSU8y7BfJmnKUQwvkANWRy5Vwd71xWLHPoXDApNDbQrFgMK Ti4f/zUrBFMECjHUjriIadk5MzxGOfaFtsIpQ8U2rMhhZVGay2tUAMrrkVZeY+qrMC5/FRGTCQQh etlQ7wmFaskJgtCFGdKx7y7oOQPzolHzPMGMXkyMm0ej4PAKGjVHsTG+/2u4QsN8QjrE80iC1zbn 58v9LXhot6w1iL4HfOsoDVw12efhC3Mv1NunaEe8SOxhImyoMF7QDZL1VZwlBa1ydCFap/OBi3Qd f5JLbyNIaLSV6jotMzwSxGhgkG0GpqPgGQ0hBsyW7VJk3MCIaM/TYKcwCQ1WcOpWzoJrhGv6QU/B U7e3tyYf6rAgntV5dJQFoA5Bj8mmzekuIoY5oXwkLbIsx5c8O0atAzv/NF/Qx8X8V1KNT/Mj+t5X yFBQT/nqU72GWWBbKYRw2PYucVaUv5CCYsXDMEcZ4Ts1UIOgB9bad9EJyDAccfGv/wNyxKzJCmVu ZHN0cmVhbQplbmRvYmoKMzQgMCBvYmoKNjk1OAplbmRvYmoKMzIgMCBvYmoKPDwgL1R5cGUgL1Bh Z2UgL1BhcmVudCAzIDAgUiAvUmVzb3VyY2VzIDM1IDAgUiAvQ29udGVudHMgMzMgMCBSIC9NZWRp YUJveApbMCAwIDU5NSA4NDJdID4+CmVuZG9iagozNSAwIG9iago8PCAvUHJvY1NldCBbIC9QREYg L1RleHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3MyIDkgMCBSIC9DczEgNyAwIFIgPj4gL0ZvbnQgPDwK L1RUMS4wIDggMCBSIC9UVDIuMCAxMCAwIFIgL1RUMy4wIDExIDAgUiA+PiA+PgplbmRvYmoKMzcg MCBvYmoKPDwgL0xlbmd0aCAzOCAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngB vV1tb9xGkv7OX9HYLyshHprNdxqHXThOgvUCWSdrLe4OcS6hZyiJF85QnhlZNs733/epZndXc0hR MwoV7QaSSuR0V3W9v7Q/iB/FByFzkQeBSJJChLHYVuI/xUY8f7WTYrkTgfrfbknPqR8X3bflWnx9 IQI/CIJIXCy9rPtjJhKZ+VmQSLHI8cEXa/H84kL6Ad6+uBQ/iTMZPg+fy0iEL8JI/HAO+Nn35+Jn cfF38e0F7ccbWcd+Oj7yns+9O8duEnG2OheLwI/FWX3u4Qd8/CX9JeLvwjxhH90qSCjOSvODeWe/ oJdjD59GH4tPq8wPe/NM90hvZf3sWr3svLM499TeWvUh2NNH/URjPtWuYz41MI/aH3wFwZ72n8zf 9o/AiShkcdKkehxORCFxpnHyTsFJGgQ0TsLF6dxjrtB8GstHsSlOjvjUu1gKy0lJFPthEKViEccj bPoDsQKO+6oi0uKHrPumf2vBXMRa+tfQPsNbHhUYuzwxsrswuL6Tj2vNEfv9DT5UUfaF+eH54Ie9 5ST7Q2P4fkefBKa2tHXOWx+8PW/7jP0YLRPe2RV9DATLLm6lxQjAUm0LK1mBsiuZR/D9Z8+IuD7M NMFh5iKLXKUTktKR6n9QOqBSVhR+LuNErEWSZfZXr1G/4jMaekp9vxaXeJE0ltJX2HUQ5EXaqTCQ 0vyK55MwyKGmoOLWntFjOAGsGGktFwmoRSyseSM0KuxMCNEK8aqpq81eLBYL8fLK/PT9bbOvb5pK VB9u649lQ/Bdtf1YbXfn3sX/dgouxEcFmSRUEj8PsgiYhVHkBzIvGNb0YVGQxsDUvOvRuxpGWH+g IzoGWau0x5CNY6/T1w8i+5OD+M/q5x/K7b7e1+2mWmmUxzDOAz/Lg5gwTkI/SUAEAwJyDigEgj18 8ZiGzYdvdgS+366gAboT7pBmQIf4/wl76t/aUx/DPU38LIG+Ae5g6TjOE5EZGJB3YaBE1sMez2nY fNjnxdhpg7vfdhwrvgj3UA30/8/FkJOT3A/jQHprIdPUT/IiEpmGkXwyDL5BVIQObnjOwo7HzXPc jxFOLmTxsNi+rXY78Kt41W63VVPu683VmChPH2oc+aGMQjrUrPALCd7ODAyHyrDQzyQcHleEYws7 HnHoqykRLqJRluZDHTu8KPHTosiBQxZCIaUh1JCGQcv2YLKAjmIc1HMadjwODx0eNN2IGvrpzU21 eb3b3VYvxDewUooJvR+tSsRGAz/NsPk19LYfRylshwE1PZDM+hyIpwACroSD4/CeoFMdsyFj7COU qYDpGTkNPgGsBKUtYaDyU0zWFPlkDMxD0IDW1lSEZYFVhHNxtoVZqnb7nag3UNXlHqr6/WfxTV2u q321FUtl0nbPWHk9jhbK2TqUyhjKHacT30OV/TX5WUaxnGjEpygSFxLr5plLETZvf1rfb7H/JJbl rtqJ5XW5gQ24bLdMmDCF8wjPhDlsLeI49oMogEljruvBNNvpVz16rAMdLzoPiX82qtOBBWm6xW6P M7+8bUR5c9PUS6i8drP7q4A4ibtKbCrww74Vq3pHuvC23l2zH7OsHOStAyMjXyYw1GsRBZEfJWko MgNrXBjOPslTR3N40IYG9nip6ziN3HpH/uC2FYVhfj5q6EB8MY89gfQlMflzIIKzAZa+dltf1Zuy Ebv2duvSc0Ypk5n08zAlbi9GdA942KHAjFIWysDPI7jMY5Q37Ke1Dtlcq4k+kjLab8uFfsj+5a8/ M8PBcPppkMC0BjBVMblQUZT7SRhDxWsQ2M0FIWCQYDfzpkePadhc0lYE4QiJhbiAKrtsm6a9I4+i RhRm1Jrx3kVawETIQgKRIiXPDrGphTUWpp6TMnfdBhf2CMHRqtIRF5lgByECa8JnaHh594cC4/3+ oENCFwYhDtahJQsM2YQlOWe7m3azImKWm90dYil8N0HGwpoy3ugH5Fh+bzBUBBG5kB6SV7yhToUY 3vWFeOkc7olSPGWznCNRu6AUmqPIyr4Me6eFu/e6jxLOagqjhsOIhmakgVVgEssg84ssLkSawwQE iOPg+RsptTBH/tIc6j6AvALG71rYLJxslJA+uwOq8eafgJFDmftpFEcu7ZhvljCz5HptltUzQVz9 zZvXr8S6Is+i3q3F9/96eyH+8eZCNFX5G+/zOPmaYqQc+4F0dd4076fj43oDc7BWToBeE970iVw8 5Y9YP5j2MAw1W8qdGc04oymyJtBBnYVnW91AnyAvA7w/0kG8Eqvqpmk/r1WuZlltym3d7l44xieA jkqRpUmzxE8KxHCI9VIklDP8aGGIiVxYUCBxRKzevevRcxo2n/nJR6iqclPf1NtquYfu3Gzwnezt +2p/V1UbUSqMO0eftKg9AY9tE/BIUnAN0AwKP8kiKVIDA5ouDEkpN0ujniPYXKFUBK0RpwGppDFk 7e6JbecOpSLY6DANQ7X2QISUFJvAadOuECe8r65r2KV6D8NwcV3vlCuDkyDOYnY6Tqin5IqEujAK +lCo1xVsJHRMicTj7RK5ZCNhJwr2lFZxJAwR0CBUfyrzhIxnGAWJiz3LNQlyl2lllKVExg2eBZLD IFOCnBCMFPnoKWJjAwOrOjDKSUrlOPK7Fna85E5RD8cnEaAPyNZJLtDQ0kmZ5Q2CNsKstBlmB89h QjmFBwx3itxKJKX8OEdiwcIgugzLyHl2kyBeGlnY8Xg+wKaIDYd6fwzPe3G07GvUkweJ9JGsooyb LDI/T1B+tDCcpQuLC6htJ1tFz2kYcJzBf6WzREKs8xOZGWFfUSH4hz485zyBJ7OnQUmkyiGCSw6U Ion8TZB6FgaUNEw9F2fIMLoo4V0No2N7nJQ70UAYpkidJZCyDrE/1Imiihyl7WhtzTis30yaign4 OGRHs1MhwrA0zu7BuhM/XljC5Z7J6Y4SifgPlXcHZ2Yk0gGOxFtpkEXkFzFqBJZNIPFI/aUxEh8G Bs3Wg2k26b3rsM5xhukBzRbem3i/RxqGSgwuFnBDaZSlQViYIw0Ei8GqjjR4DuwR0qC12ag0ALGh KmOOAD/M7X+EVhqYqCwN5RJp3BL/F+/L5W+LfbtQ3ztO7aUqjzvXBzQ5NjMQyC6KUKHMze32pkUG B57P39q7LsTRzlGPRlpqfnd8HsGvRgENvhlvjKVGm0teecboIkoKuBIZsiVYeWDESV6/rz8JxDbK pMEd1CacHUBroZI8gapVxtrU/gwIksug2C8iFKrZtnlJbmGzsHmSImtYYI1xcjIhn4DNkxRZB4qW HIIym9cbMBNcacrEU9a6KpH9QY4a7jdTdB4Oj42A8+qawyc4+aiy+5TOlOiWCmUGmxcimzJwCk3z gNH88/gslOQZ8Vn4nOcUGDg0QZQTb6lV+w4F3CQSFMdFYlfXKT4/f1tdURiFAoVjDq3tQPNEFgVw jFCAIEambFSY5r7Ms5RhECoXFuUoeVLWuHvXo3c1jIRqFqaKAsNUjnYac4At1nwG1j1MYri5cOOp uB4V8JDgLRgYaQUXFlHx1nEP6TkNczXFaWzkGkTUrLvTBGrMrl3z0pmT0HmkpoAZurcdBwKCGgMc HKhDszbLqtIUSLyX2/UzJN3F7qZa1pf1UmsLUa/Rl0M81CW8LO/Mc862EsAb6pQHZaqdBNNdDXVG Oq1CdqBs1mOmct4sXFQgJkzhJhWR3aTDjAPXVoUQR7dPTak2W/GllZlXdC2aTOW9Es66PURRNYup YQtV9YiCPdR+0FmiuhQsDGJsYRCHnNxg8n67d72EYfOJ9kiOvDvywzQEC3IE7RSllIaAIoL6oQY4 DYOz3oNFaBRy5RiPdSBXjI9UUvqQHDGWAYriMoH/FI0VGFgJHYrxaYpjNNSSSCDGEqjT2gOnEpLb iUu1QkviEySvYGnpCAaWVmllXtFYwBkQtlVhWngQRByYv4razaw1EAe/OsYPtPFUv3QMLzIJ0VNF jdews2T6dHZaQ8jwORBoT/Ime+8RTCdt51GINkHp6Boh3B6e150abMrdXiBLg/KSgHbe1tXumSi3 6LI2h2/kx0sCNEzlnccMBkbjGAyhgQFJFxbmyNy6AoTnNAwSpOL3uSJ4NLfl8MjBV6NIMyKHwnSa +I4KEyfIsbhmajZBr9F1a6iIxUXgHa3Yp+JBx6SMYUzGjdc1gjQDsjFSlEEKr40oPZBgJTQ75R+i y4HCLseKRKlfhKRuDbtQxwo8b7hVDKOOFQdmWEi/q9iPWehIfKboCERiaeLqnpxAztH/YM/OSICI KQeeFuTfIqUNdxZdxBbWwM5ZGCxfmpN/67xrYccbwSn7Ttu3Hey8fdSD/dTR3WYDHtLRaBINqc/Q 6h4Lc/RRjDo0TH7Pj3VgM4sva2cgM9DO3BzHpzEjR6NzFO06cGpGKflSZf2/rq7LjzVahpidEf5D 46PD0JIPoQG6TvGfA0NoYGFMUvOu1yfpTOw83lH9esPUM+wgYuppRoWA2EH6CdkwhoEdNMyL0SOS STfNh8cMaBZvCDFS0LnIcTZ0VB1ddqjAZ3UOsPbAG+ocgVWL6uKm3VMMg+6XdoMuPiaoUuzHDzxM SXSIVuw0DlKw4xghDhT7fElwm31nGrA+QRV7X33aI6fGONuGcoeJQmoESxMIgGYsyn8zzHCM86oB zcJEURajnxGqeZx2vPcnYCL2ApiA7AXoHBLXp5/1NnNKJWOKecgcqFpYP8PTxUTEOqaAowSq811P VKVTxpR7prCLgR5/gxGcpi1X4jUaybrGV/T9bz5Wn0s05Yh3Z5TGfnfOhLFteTGNJ6CoSn41QtA8 QtnUwsBhLgweKEVt5l31nIY93mo5YRt1E+cZ6tNE6QGOE4rqSO0+dbwczfMpM4+t6rJpr24ryryg w7x8D3/+mtrLdd9Jl+BzhqBO1FpTJ5+hgbGgGsk4VSgDw+d6IsdNUYRGsAo4hON8j/QOWm/Qs3iY rUbsi4Z0FKYtF8EAoj0IBh3OnOE2GEAXprnIvOvRc8xZKmdzejjjcBZaElB0w6bGacj0O9ReM3BW gT74jKahHP3BnPU0GfAEyeLx7k5il3LzuYfxXCqSUx/d+geasjVKSi+OROCJ7DolJkiGo7UAeYIC iw+Uh9MM6JgHKVEYyqH84gSzCrlqWJbItGVwDwwIZtaCkKFF1EGBN7/JsFnsbJhjmJziDkJjEAQ6 kn7IqTM4ayHminKInktC5lSHhEjuLiv0F6r5mtKUN+7a24ZUorjctpgMt5H5fI4UbDDanAaHyzaY Vz2Rs6YUYZ5idhXNCLT24EQubzeqBRFzD2iQ6yIZ8uVsAh61x6CzqqgtoE+Suvsl2K1IEL/GBkZM 5sBkhmYNpEz1ux49p2HEZR+OqstNSQtR0ta82RkFJa0boxMOSOfjPDHoi6KvVlbPYAOp/FA2jTNe dbNtP1F2i1HnWAjjdpJ6DeFkQEwzOOICrQ0dDE4Gw+BkptDbHNd7MfoENGw+1G0xtIc6TQip8it4 eNmu1+3GtDrC7CM4abf7EoR4Xy3LW6rXUvy6E+vysyBb+LFqPo/hHlLQgQEt4E6zWhHGSNDa0sGA pwuTMSqlLu54TsPmw31saE+IG5pvXtY3vdiLD5BmuaKEqhNZinA1wgAs+rgUDAqSYRIaMoL2YiQQ 6VrYLBqSS8qJnQF0jpFVwBNoSBmiz5lcMSyt1RAryE46RL0CW6A012lHigzeqMmoxd9a5IC7v+4/ U/fyvqwxTk4b7sKFGZ3GBHmfIEe84uzUIZKu0TGtZlSXKRzAGAlMWnmgLjERsGrIbYQ2KTfCugSg xkqN11OPzXdIcFafSqpoOtokQuteTsQ3jAdmTDCXEGZo57MwXJtgYcx45l3vgBnnUaTjU4k4+c9K OazL3xA4IMpvmlqlvDYU71+3N9CnjW5gX0Gd0gwj2qzRCrIS7WZMldBMIUYxSJWYyevYwCBxLkyG VAQxAgy8YUAUaD5FMjaBhzKT8fL4SJ8JHGh5dbWtrqBe+AnXo0AY8d7peTEbFzENtqE7nnA27Q0W BgQZBjMRZG4ezYvRRqVhs2GNbv0x/wNDpbtqjfFH6uFYtXeb3R4R0nokTywitPB2Q6VwKvwE7a+e AcEL0CD1VID8uXOILuzxmnS0zgJ3IB0pYneOlfUIrLrQVxjNUm2xKhUbGFDWMbHwrcA6EKqt03Bg d4Qbnkg0UPKluYYglwnaSWx6zMCImCZlhl4YXOSAZCBm5+27DDueYSZdR9B1rAIt4EHjSgbwyr7c /aYHGlAVVGnQVXVJdgEqY0QHUC4sQWEE8oC2Kj+S8KosDPzjwjDW4xYJPXpOwx7BP9qddKLqCB5A kKAJn5AcnN1ErHKkAztF2QiCkifQaA6B2RSvMREO3mHxmyE6IjRVZb0/NNnVg3CrCHXgdGb/2852 iZfb5XW9h4a/deu9x9mcKdxpJ7ZCyEhDWr+rr7AWwuq6aW6hgsBiT5OU4mgbOxkePXk9LJuHjtgM x899/GOU2PFZlM4Z9O84mNHb4srtKDWGCvTUxMcUNyQY5QkoieEwBbt65E4IhGb7dtniEjbjaoZw 2YMAxcqILiVCIQ36xDhJDEPF2Dhd9Fwg0RNMfkb3rufAjleXD0Sl2XjF+Kd/fvcKQ4rRzyoiw4Qj tOOyuV1h4LREnAZ/UlkGpU0xg9retMjXfhbXNc1V4xmMAtqI3PoWEeq0uDeNSnQ2DLMw4GlCMwQ0 uCAMAJCAbrbyDGA+rMMRIRIqrKSxcOqD19FFF4tXzmij3RZ6PZECy1Fnc8qlBobt23IpOq181Z3F KOFdC3Ntwzx6M1N1dNKbzJjQVk+qIWiqqGvl7FanZCTrSuuluj4oPFZdMQGXva0q/NeNl8IFZfaZ U29gYi1NUY/EFodK9Mlus+BaB5OGD4ZZDb2mFKdRJyejb7oOoRpwIRQSpa7i0CBXbwCExLvyY02/ Ir2pYS6vHWkWhn6IjThHyfikXAanFffUUYcDk5K5bN3CGCM0WN6qC2qYiMf5AA+pSjt+yCtCqijD v6qQW2h2CDLvsP7lZbVFTqJHiLly/myIM/Q6DNoOjenTayPlPw/qtpmA+banUKSqGR0doEzZV0eR jHQN6JSo42majnsRSYyxxJilQT8sflKXp1kYkrsuLI5xrQ7ExnT603MEm7NpERcTDpUMOa4oETNv GCMH8wf5DjFe7DRjWZjTjKVGeTB15xhI9S5SLQR7hITr03AijQz3hKKpF5qSblcccBnv/tDVnMF+ IaIKJXlItLYmIAtcNxt/WSOzt6HLSm3VYz4GZF97FPm+rz3j7CaLNiPO4rZrm1t19wKHq90sk5lM UIMIYo0wREW172FG1OUfujXCTP1aloIdMTccWRhJhL4IyWEzMzHsObBHsNmIIUEjPQbqEV+NYfy0 /grGc9GIQfcU8Skzm7lhDDFZR8RZdGluK2q8HHTpQRFvPnbGHBJuBKTUNFYeynKfnQM1S3nyHYJT lpOHA8Yw7+Y9WwgzuT4f6+qOVfuRtmvKmBBr2UG4Hr3FP9XAzH+B9A98vcV9hpRR7UIe9ZoT5M/D EyPlDezqPzDVcsTXX+578C8ze0C5TUH3SPnVYvE/aptfDSj5Ar1Q7Q3prbJ5dy5w87RR2LPcqoWb S8DR/QQR9vDFuEFfRjbkgNztHFXifYDVMHSpBaxHny9v1Q244uWXxaIjkb9YIOTB1wsB4nXU+wq/ 0Bf9beZzQ4P7wJBiJVpafWFTRKlf3tFl1OJX2toLl4i0MfePvOe5N2pvduoRkHZlvrB2t00CvDtf LF4ssPeXqtDzBb8c/JVZYe6t2uGb3lb7NMVOf8WJ0kbVf91xqwOn4z788xdzDfiXuTdrrzvqbZaJ oxjzVyLeL7/84i/+TAzgfOGX3h87LCH0X829UZvd7G9US9DXf6xAyyCQoxLNAuAQqfuxT7d5yYP9 2MRFjz6DXQDw7WZF9zggdSXemBoht6vO69RgY+PBsd6YJP4/0poZpbRwrNeMOaAct6gF4+HsGBUB M8bkPn90niko24jmbo8P+SVfsSv+27GiM5gtOGg2yOMFD4gxwkLiJT0z+oc/z833ctxp1psMJ9jr j3KOQEXb4HUfFdHJvFmVW74mT3n5J3TaTvkf9r5NtZOho9+rTAg+oBNTN1Ouvhm8cGnBEaytKQjc JoeeWLGv16gnoE0Bvy+pGnuNzHvXmGDdRDNf4YG6qDirf7cjoh/pqmsLo7jVgeHqUGrnM++q5zQM cesMOQpSInK8qW2P7pONisCBSYn75RE8cNNijU4kivR6g/qms01ds6e6Ovl0bHqIOhXQBUvZLXs5 toUBf3NhtkQFKZVII3GxwXNgFLfPEbIAfxuz8BFDHm3e4eBfJ4EEow0D/+KKk96yMCe9RbCgwK1d vH90/1rYI/IOU0JjE10Kn6HQ3FM0QYvt0bnOKYHBvVs5mvtSYidLTtYeT6svzEXN96D+R+iLDBOm Mf65Cxd95ibd4Lt1O8jNfYuWdVB7ow4U3EhhQY3ngjQz2VsZn46ZlFa476p4ttlOznQuPrIjhyDk SIxu2hReuF0TbooL/yhBWy8xFkg1MKdWZ4abWB/Noztw6+tYQKrN+T3fVlWDpt+tM0tx3Gam5J+O LLQdQyx52AIuFDB007csm/tZRwgE+0W34lKXKUqaaCZ6dwafd3ayjYfHcPGNp28GpHSZRBWnzLCU tanGm57BENq2IJDRbo4lmNJmzPgnehpT52bvTVPrDvS2Nb16cRp9MTd5YrASF1moOgv/M1kGBqOD mlD3T2eho1d2zfHuuwqmy0SGkKdZVKfOggEaGrEn/T9KPqadozTgNB5tfKZoaLtoXBqyCLw7I7d6 hKGYq3/8NwiQCScKZW5kc3RyZWFtCmVuZG9iagozOCAwIG9iago2NjI1CmVuZG9iagozNiAwIG9i ago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDMgMCBSIC9SZXNvdXJjZXMgMzkgMCBSIC9Db250ZW50 cyAzNyAwIFIgL01lZGlhQm94ClswIDAgNTk1IDg0Ml0gPj4KZW5kb2JqCjM5IDAgb2JqCjw8IC9Q cm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczIgOSAwIFIgL0NzMSA3IDAg UiA+PiAvRm9udCA8PAovVFQxLjAgOCAwIFIgL1RUMi4wIDEwIDAgUiAvVFQzLjAgMTEgMCBSID4+ ID4+CmVuZG9iago0MSAwIG9iago8PCAvTGVuZ3RoIDQyIDAgUiAvRmlsdGVyIC9GbGF0ZURlY29k ZSA+PgpzdHJlYW0KeAG9XeuP20aS/86/ouEvsbEehu+HcVgg6yS3Odyes+u5zQHr3J1G4ni4K4kT UWNngPzx96tmd1dR5MgaXWsdBB7XiOru6nq/+Iv6s/pFxZWqokjlea2STO0a9ZPaqq/f9rFa9irS //VL+pz+8Wr4a7lRf7hWURhFUaqul0E5/LJUeVyGZZTH6qrCF19v1NfX13EY4enrW/U39TJOvk6+ jlOVvElS9eMrwF/+6ZX6WV3/m/rumvYTzKzjvh1f+cT3fn6F3eTq5eqVuorCTL1sXwX4AV9/S79J +W9lP+E+utOQRL1c2B/sM/srejgL8G30tfi2xv6wt58ZPjJa2Xx2ox8Wz1y9CvTeOv0l2NMn84m1 /Va3jv3WyH7U/RBqCPa0/9X+bn/GmQhD7kwGVeediTCkXpozBc85U2wPYM6k5JleBUwVhk6z+Cwy xc0RnQbXS+UoKU+zMInSQl1l2QyZ/kikgOv+2BBq8UM1/GX+1YG4iLTMP5Phl+WIkOcYxi1PhCwX BtUP/HFnKGK/v8eXasy+sT98Pflh7yjJ/bC2dN/TN4GoHW7FfZuLd/ftPuO+xvBE8PIjfQ0Yyy3u uMUywFJvCys5hnIr2Y/g758Dy+LmMoscl1mpMpVCJyGhE+v/IHSApbKuwyrOcrVReVm6fwZr/U98 x5o+pf++U7ckhcI8iusiqvCzllsEiCpABhHF/8RzeZ2lYR4XgZBnuAmsnA6fxt+ViqOkAlTLstTK spdKqW/bxabZN8DI9d8H8RUFtMzJ66oj69YpDp7WxbB8MCyf8PKLj82WGN8uPcjNk5c+duQ4q8Is SerRyXnp24ftct9228W63T+qm+ax265eBXYfdRKmGf7grvKwisoUVxeXoOS6qBmGa5OwNCoyXKV9 NqBnDcxc6xloFZeYRlmYZVXyFDIZjRegoDROwiSr8xE6mZDabd+uoFcMAjUFeaKhNK/DKC/BUETC Uxra35F8szfnkYLSugqjIh0fmSnIMo66WfSNut91+27ZrUOlvru9bUBbn5r1o9rftb3aNIttz8SV wLxIq2pEXFkEAyMrSFYYglurEcwQkn3WO3GVRRaWSfoklhnDFyCuskzCPAG7zUupXbNYb9RiuwI6 my2Ydf+5abaM0EEqniw1jgqsLAvjHGbdP5vY6irFwlU5QgET2223Xnef2y00mab04M+wUiGPCpiu jmSgXrI8LJJqJKNGMENGo2cJBl1EMuoXrXq+pGmOIVBrmrqYsqlSt7sOt+gUjtLCH4aBZd0Ex43K GAqyqsKkTmsSunEdFnVZBQ4GoWtg+Bzs9DqFzBWPWtDpxzmmReg4aVIYxcn3AcXZKfXDrYKNdbj/ oCzTMClKbL8AV1dpligLWktQEpZFEY+2D0YwMK0y/GniqgijOCHywnGmt+OE2QU1cgKCrVJirTmM 3u+aHsZAr9p936yBWCEx4yQNiyiHxHSYjWFa1BkOZEGgCwY5LNoncScOdr4y1jY4VNDEtkph1U+M GyXU0gWEZhqHWZTCqAM+3fKskSEumTSxPEjJi4TMMzKICrJCsOyUki6mjoUtyedljnzRQD9su1Xz 4rW6b3Z3i3tBQFBudR1HIKAiD8scLhNES1qHCYwLhoGEJCzJQV5gWPNsQM8a2PkkJOy5JMPu3QVO MTm6Pt8eAWw5MGNNKpexydSzXLeaGT+TwqUrHQuIi+jerI7DAjL9KcpawKjafoRgEHzl0dyDawb7 fhCRjp+YvhbAQ3ffrbuPj+quXdFO3n//3WvGRBqVkPopTDimsbQuQ9AU5L+FrdUIZujJPuudxsq8 COskJi9ollsvSmPCppyjsZvF8h9X++5K/631DiPTjyGS5lbVMWVDc992O/Xtux/eqvuH3X3XNz1C B1aJn7bwF02GypoMvDBsAjgHb7vtp+ZxsV02qkNE4frvgQ4ZejRhY1x5koCCceWVPT/TseZmPq9H BorhuiRpRP4SFp7ow2/fvYUntLxbbNt+o/70n++v1X+8u1brZvEPvvc4hnyuIzAMghpJnCYQ1EkS wxwsGET2ngVBq0PHQ0zbJ4MSYtXATrcBv2TSwhebCmiQklLtFuS0WVAsgbHK9mgKg7yuKxwDRm2W kodnQDC5JSiuYbZLSxYfM7AztI0hUKFt4iyCaxBTKAaHmdyOkKmHtkpwGk8cQ6EIxjAmmTXefWp2 626xUj9sV+3yAJenrf4ljszg2s5Ev66h2pxvpXry27ttr1ZNv9y1N43aNp9Z9X3z1x979dA3Ky1B YK2SFmDaPW2jx9BE3kaWWZ5l/IDMOouiXXPf7fb9a+0PkyRbNcv1Ykf6qH+4p9/p3S2b3X7RbrWc 877FwjLDaIu3zWL/ACveuzSFYTC5O5KmMeSpluNvF/eLm1ZH8r5t+yXh6tH3ofNk9tDvDc6722Er mwVFE1V/3yzb2xakAnPlfrHbs2zQoj7wYounEJJZnhFP8/aEqMemxub4IWuf6PAfY64sQsCqyMhq wx4m9zSKs7K+88MrMOSNVB4RouEDIP/mEQEH8PAB9k/3hI6dPC7jsCI/HyeHRzHx/5zJbFZHzCbW EXkvdy8MeEYD3z15Qj0o8a6FW9TuwSnfI/zCeIhBOvi/UEWBKCeiK1rR1mEcx2ngYKSPBhg+V4Yw kUlHiWcdzIuOyqDWswLR9icwyts/JGQPOirDSZMChotefEJXi/v7tdFNQOYP5BUhtPt58fjayd3B oDNJFHfTSJd+OXlzTCsgJBbWcU521dxNE4szYp7DWNgZcorg2Uk8I0fye0LPx+IZHvAv4hlYfoL/ JfQyUgy7ZhzWeE5K5SgzR3WYxcjBAclzh7fMzLz8HEwjrPoUpgsrwph3tV0pDLJnSo1jxxTRm7yY yqzB7Vf3XbvVGmtwThBUzvIEXmyRQ87m8CY3LsvFMM58AYZ4fh5TaNM+GwjYGbLC8MfInnX5PZxk apwzSxzKCg9KT/hYjEbWQUJWqA8vV8YkgT5aPWhDbWntlbYRQSpPBOVyZLwfEFTzK3leKAW4v6N0 FaySVXPbbrEnMhJNDnicylJ/+8v3byGN058/vPJuTbkUwWiXUFYkY6G52g2J23ZvhevoOn0xfUIF FOSTgenhYE4kHuwnXjf2F4xPEA3KMh2VwboT2v3USoslzqOwzqGgEVsKowTCCbHLogjzCqkPB4NW NrCgSKGVEVwkTc3POtgZ3HdMosAzD435N4fCsf3pEYcpudG5TifM4RC0vViTH4eYoXYoEb2j1AKK w355ALQn/0lcLvIjSI9kDqHBRqVphDIwpLwFkgXMITTmZx1MIvl5ulGIuCLJUECADJ8lzwCFaEJN 8PYvIOKKFA5WpOMFzBvMrNrvcuGc0Ld8KFySipeEFPsJ4ejRqX1JgiJBgqlCBCaOsPRUEoxtrP+3 SUcSp9BB5oMr1aqfT3gZzT+sTFWNTEzdrv2oWabvHnYITiKywHdqlTiSlxBcFZw9zswyjGJwQ7YW MCRNKsTCpQHAMMkdJ2rjqQGAyjekT5Au1qicCFEhuS/AHZzLZGQypY6ZQ8FPgD2161YPy0HfNr+2 JJc+OsXLqPZjBBTzgW9hl1AAyUYplsoZJI/KWiuPIliLA5DYbGF8++f0cmrrgwuuEZh7ofF4fG8v CLtUgbNSCMC6Ai5c+XNEwzH3C2VgYVXCmAWdub0y4xxEWDxybIaSkKqETtILT2QSaoo+N7t+iKTf NHz2pECtMGp5VBGhQiSHyw5dFldgSMQqHAyJKAvLUZ9Y55TrtI8GDPLCq7QqyhfJu5rFIUu8C/Aq BLuuIRnhkZl1KDw4yMd4YkOXf+HlQNsmOLhU3f1Qgqh0ZLm9jGpLkgKJBx0+oOjGxMglC805AExF zyTkYxwkTDXsYCKpdeoPMZVrBFSYEJxVlaOgsqZaTGSCUuAxhpa2MORQRrAMByWz11pk9DkDIzo+ 7VaPWbukuMu59IlW3EZIbqioVRf9QTgs9oxTlxbKK+hRZCSoCgEhryQqlAVh9wyCFk2xGqeFgrxy MC+cKagD55rczYW1KPtfjFRmlU3T9yCO/rWhCgRQPcp1UU47e/L+YXknjv9MfjhGRGmO7CX1qszT 0mGJnELhgwgTuDInSzHgixLVXaiOFUQkQI5g7JN+iGi2GCqHgRhVCQl6vlGhLC9WvJEh6V2VFLyd W3cBE2EoNmBSSqjcJIUDyXh03p0FQUlaJ1AwnnhywK3X6skSpfwTIa3FCxdK6BQfJdRdBYNSf+xE msNKmoCqWuq4pN6DuET9eIQ2BAeDrJEwxD8LIWv05wwMssZrTTdXk88e9yBq8Dxj7lTWg297iOeh +hERMR3cX+pI2f19s9jN8h+jNkHpQ55FUEwWBpEtYQaNzIFUbDSg+3TFdEzHasWUzghwTTnUY2Mr XCxpYK8wDyN4oagbpoLVCr6Ug60DhhUwD1GzOSINhp2hhswNiVAHbcVEG0qXqRdyg7d/aCA+L7oy G4cvUW4cI6lFwsOhkNXQu7doZLPYO82EGG7q6fxKiZztQHu8DC7q+yGDfvVX1CEgsw+rEOHjvmnU +6EwQaE4/cMrmErfrPd33cPHOzYtfCpG7nvAPqeyaMych/fhwcjKEMCMChTN4D5mEIX7GCOKsfCc 23k6J1PO1zfQdSxRBoj0vi4CQUBxsUKpwb6lgLqyFRd9s0dpl64cwR1aV5/36PGmNIbKmSvitq7L WDBg1RCxICoCLqF0D8WoTj4zzyDDXMH5zIM8K1ErgLAQV0M5EFdDESgt0LmF2lvzJBobHEzLm7Ni 8ULeiGooHGBK47z5C9C3qIZi7LEgcKU+SHkiarTm6AzSRaLg1CMhpRX8pAL6S9/nFB3IwyDMwkjx aAxLZp8hJZQ7DY0BFC778LINm1BHXKgnyLmtzFzI5qDeFYEGR1eIfUDXFvCiHAhWnQAZUrNPaiI1 MI+quX5KNffNDjKk//DqNaEY4oUyXw25kEPaYpSmsLobm0SMJ0dqgMy6KkR3XoLzGRiZdRaGgvYq Q5k3u5BQ9g6GA55p1gleShNo1RzNqiCeuWMy2VyAl9IEIoUKj/TiE6W67caVVzitl+ob6cLNnXlx GWZJYa4XeU0xb6B6IndXzf26e9ThBxdj+tzClhWR0QT1WgXiw0wu4BBbui5IiGFMLvZZ2IaShM70 ygUJkdlsau//+SREzp5uN5NIZXFM3ImiUCr1HKxAhCH82BlVZDUPrwYrsO/WDxQXpDYWlKS+Vnfd 5wa7gIDYTwyQ5V2L39HOvBeSi4Io3qmwycd2oE+VALWPXCxpIyw8oXLdDspCBS0UKDYpQZMJOlrQ n03xEGyzRqbcwSD+JCxF4RtAw5P6UwPEi22REzdVMRlHs3jjrV9AHooADOOOyatHsz9yOf3Deq/L dAei8UTO89WY47rDZxotx3x5kbPFvU/IRJsJlw1siwpQ7GBiNg09Lc51RG033BpUN9J8GfTtQXXb vkYDgeI2kIAgaQQZD5h8zsA0oZ4VFhFSl5OYs/h7mk49+NwJkk8F6peJSRzqmE4nNvCojngoUCMv i0plXtNNu8162BtZMtVMCSJk84u/NKYNTbcaulWfqwKP0bVwD7CLKV2PLfGzPKHZMEhcInufIF0o T8/yfjAuKAMsKBrBRRLU1E+OQiDdVmkLix1sHbiC4RxVlmhXp1QjlK15lmGn29vH8Kevzw074QPg +tCzTVkmm83WltJi3aMyiMrNUHZG+RrV3gqHAs/rpnTMvkCMDKYX2LYG/pBociCcxoEwRqFAsRbb 2wHMbws7g21HQb+D1mNR/1/NHfhiGlr4i3MLO6k7xFNXHTBLlrhLzye485wCfQ6FUNrIQmO8yQit AuZwaJ89xKsnJTZTjwfCwR+QCCxBTIzZs7DhwQMZzSLIC3LIbFeXBYlGLwIh8zNyxwTsDPKYhlJF aAMp96n4YPY9ND88iE4puxwmWayb4jvYtfO18ieNnzjG+6KnevbwBxzhT3jC4MMAFz3CBAtPTAHj 5XNDhs1pYlwcxn6EVOZh6YUMWNt1YWGU6JYwQ0TyUQPyQkOiEWMWjRelIel3OFQyDTnTYOiEm2/A PE0YHKMk0iI1qn5mwvSjkIw1aD0wjyjOx8oTGtIGLWPeo8MlRivwkVlxOnG+ahfof38QtUZ2OAKI FxZAhhQ01KOtX3Aw6EcHg5FRUumzGKyQMewM6jUKUtq1XPEyi0fG4aEEPNGxP0Y3oqacccnUCwOS ejQpmjlYkE4nWkI6cQ8ju+CghUeMzJpFgKyzOY1TvpTQQsx1qmm02mRkeyRYySkzK6O+e3Gzbvs7 VAWaaVHKTrQA8yKoomOuuoV2sX10zbVsoLiK14zmxiQIoEIog9hhHtfKwSCUJSxJYL2Iilf6nIER XT8H008np+q5oSuDgcKd6DBwlw0mkJkOSNPW87l7WBNC7CSmj/jE1iCDj25jzCqjeScxylRwdCpF jGFiOhiOzjDYZjGd3D4aZEDLAPJ4cFfTypJJn1uhLWy7H7ptbx6Z3uxu0INE81xRlIK2JZSJ5Kgc DhwMbUsGpj+XUMk7n0TCzpBNxwSF6CGqEY49zKEdSnt/poqY04CFJ2rmna4Ev/pj18MT0pjdP0qf z05ocBgkh4iC8GOsWpjEoJ3RIGGnE8gxZGptPVfdqNTf3t032x/6/qF5o35qvvrU6BLnh55KhjeI g7VIt6i+3T/ofAtaOu/QZEiJmMF52bQf76Tn4vxBjJkoYPETdzjPxcJAQBKGKhtdXWueDTJ8zsBO P/4xgY/jx+jknNwluS1bSLs9nefdv/+FOlfVqtt+tQd5tdt/qM+NLlSk5hhU/KMIFgbyhv61WKO1 Fa3rzY7GW8xJB5pPUSDtROmDFMkojIRC9eUAQ4aNYUhZFNDOzFRBhro/A/N4/vm6qcOhPcjJv//+ hz/NiQmkkgoY3DiRC8NhwtgAgwljg3UEi7NS+vhKwM4XE9KEsbPSdFHMRDbw7g8tGA9mKIfmaHFD U2zBYNLlJ2rEpfAbuVMH9rgu5BUe8mla7wu8jYkys5b4pBSEamaYWD2aVCw0aS9TRkPNGF+KR0uH 63MFDlgBdju6CfDrqkPeCLj/qaEUEYItaPHsHxDs1xGthUgAsimOvG2c5hSycBWNKEUeYCTBTH0k rHUK1VLQwj4bCJhHDp6rNlIktxi1rNRRQoh5NuRwsLFmYdIIAyxGfpjFj8ocyAuvsjGKSP2MIufN X4BZOQlCi0+YlRjUBF0g6HU59Wg7iFufnA8/xqMulTCPAqpsGBSKWd3zLAzbgypwwDzyggaPvlAQ /C8WN93D/oUWW8LM0QV1fafzCHYGEO1zSI7ZvlpNNobiUsyhLGpM/SZS0jCqKRGwgeJGjwLks04Y nTQzYgjZ46bZII4NDS74/1AJatMGd7K01RG4D+YsVAggBaBdHjuqmKa8aBjYiGHQ4hFKiyVrIVdF MHPS8wSw0IM8g3n+vCNi9j0jkUfb0OKTSBB6+podqpP2w0gK//l3Nw9x/uwXq6UHJVTUvAmb0h2b 2ekmuXE6n7kEjjHqzDFh01EK7ELEYSoMsmcYuIRhTD3m2QDVyJaiPGqVufo+NVj36IK8edgjErPF IMLxcEfDIluqvIB2Jct5L01ntjIc49Bkxxz94sJftiCwiHWXCRTBixdsEwiYx4PPFSYpbRB8JRqt xPaR1qrgyNNrCuCf4MUGKaW1CIRycAuqkLqh0gLB9SnDzteoszlJIkJQ4dQ7fmIYjbf6Ljdcl5af qFXyDmFk4R0CulKPTOGhWZVHT7m2VaQVXwxGsRLmKpPPaQbyl7w/0i4zoWpRSX6h9kLMaMQULBpS EJPSm7gqF8u4cPEFLTyxyBHFuIMRfNPvd5Sx77aag7+CS9v1fXsDn19bxpbtr4aZrizQIMuGao20 REsTDVmDQKPuJiTIHQjyzIEyVCHpjnfx5ADzqvZjVy3BIhluvhFXmwdEbeALUP/KINsm/j6VsENr LdcPK8w3FJKPSZJFAg39go1DIs22s6QWBgEgYRgrOXLy6XMG5k+mxa4sY3R6M5DXIIHsPTYMxGEg YhL47fDvzeUGKXqlNQy+jbtwvHAiR6p/JOEYdr6EE3aNJN65Gg/e/gV8Bi70QEDOcg47+ENjOaqR R5vw5im4wdO0+FRe6HIMt7J5k9bJPsoxMekm1YhTMxWtMPPqIyosZWLWTtlxVAI2QOdDST31DrYO GMZU4kx/ysUYavJCOSk2VaEZkeTtHP4c6qgkaWQRewgNcf2xwCFTjrCIacLUAq6nHkhq1SPv7TSl d8zj1JaBG2HGe4AsfEIJU7qHZdx5rsmskcJFBzGufaKJFEqKMOUYgpnP7zFCxOX3tPqEofpuI6Jx tjEgSKn2lXreKHpvXqXgYBCGEhbF8HQBs00F9DkDA0nrxMQzwgiGRYUw5GL6efwx2g5J+sSc2jE6 4lypQB+TU7cV2MPy3gxM13Ezf2awzEWPncWIVoBcIEUc0fCp5zmImec09j0mjDX7zo+q06PBkaVc dpsNquCpgWGECl+aSKrBE6rn/CXgRIAdOdWJvNi3myb8mY+MuWRgVQTAUwQ6MUaSErJusJuDgT/N sLcAsVq87Q4AfnAAPNcOe7KBFQb3VHVjoGxYwsp+r4sp9fDj735dUDeT+maHPoU9mlgxH5qpiC0z lDahjpTOZfvRUwMisWPa1gmUUdEge56BgD33cE+m2GMMz59cCtTK9+1HbB8zfNv1Gmb2Ts8pJPem 5wMvxEH1DC0XRuTD0hysDO8zgzFhu9VSC8PRJAzDwGXbdUCfM7AzjImp5OXmu/lDMxFeQPLyYCVa 3CgulkEHpdazndBMS34kUuIGPPE+kNsEUb9DGEiPqMcLHFatbs+ZG1b/TKvimGIiCUnDXyYe9Wxz LxTTyNg7UTMeE9Hc5Ev7MBzBeBkmTJM3aRMMZO9hxplGDvJhHd6DB4DSaMMkbjPckxqpXNGTn2tL Z9KU5BNfZqASWpGj4b2AEMpTg8sFR60C95vriBMoARodSotPxJRpGSYpLMYGIHavJ4ZsOsgvGvCG 6gdqMKNaqFWD9wSsxXwLFPIho4He7gRNeSnVO4kMv4OJDD+NmqngEaGD2zwaMMiLmMoxbaKoY/J5 5g5tEY1a2guIKe5NFNfNbACMG3mgx4boyYkbCgiCMeZT476J36WjeVMg/oO1YU2hoxjFILJeFuEx 5MNGQt6bfQu3d3hrZ5y6DbK3TT2N4tpiujg/mUiRMcLCE+m5arVUGsZbY1Q7Jb5sQgsxH4wnQPM4 NLNpDXQgKGYBSqmBFiD5JMF8pb3wJlDTATmPvdGVnSP3jymejKZJ6Te80eITvbyhuVhapveYQaIL Cr3L85lMNkhaa5dmNbz6hF60YWhadbDCdlPC1nleywfe9+jSryO2c+IAIli3Gon3A1GDP36P9z9B K47C8f58CxEeSt0OBd+5Wm4mIY/MJ0w6rD5hvsFkuKVpEluMJHKCMMHkAv2azIRqKeh90SLe7GDg NxtvJliaolQLMPNsIGB+lA7WGEYCI+RuzR+BSUbgJZQO3hxa1bD+oPEcIpnQvtnv8Xqih32j/rpY y3p8T/aUS5nykuC/Hxct5o1+eEnTKjGGiBFw2qrHZA4Zu5nL841WfWveZESvYqKVFXG+jhKLQTzD S5AQM7jca49iNMVMjGBgRSb6tEXV/Lpv8K4KvK/CP4pcxJdRlEHSHNDDcFPMX6fdzzFfQN+Pi1Xw 4ji/lnLmzVk0cF2/OOtCuQM38hl9ZlPxouU9U6XHYfMiwouFJ1b32OsfZZ/cG0Vj6gJNkSGlHIIZ wWFhMBtGMLyHW0/vx5QN/YZS+pyBnSHaDN/JgKsbIzKPR8bhoWjzkUPgyCfjkimq2S47/XbNoVFj s0Bp/7KHQT3alC9rURj3J1DUBZzsIsZ0XvhYEH+OsBgZVlvz2U9m5eAP109HuDLXGMprgZVdkIND G/OixSkB+RYRyjn7ljl4icyczF11S9S2bocZFsMLl05DzJd0EJLdE4MXQ/coAHQ4dW5canza8l8S sflM/EmL2GZ+/eEeYFQilX/9h28xHJBszP3jPb1dVP3rrnu4h6k5ynt52qib4zwiIOdkUlh00AV6 xDXtxuUUmJjJ6SO3z4dUcUOo0BM7jYsM70F0gwueg4Sng+A0VGwmOsfni835TgzGHSNO6p8cXhYd zy2r39hEWKaBGGJGPwZml3iFCCIn1HKRYPgr96c7EI/eIxD6HMiutk8GAkbK5zmoe1oAFXMxAVA6 xmusN+q/8NMX/rzTLp/+uBA6LshOb6LAnCzq5UiQDUHHKVkwBkZOg4BFNd4ABBhse5r0ENDnDMzj gZ1LK1wIpf7l6qQ/v3/qg79ngWv3j3NiiQrv/8HZaSpBgnkbDoZzMixGJR8GII/O7mAez+7cidHZ f3d19d/69L+b3PUbCDY7HB8y7Q2zlD1lQFWUGCFBBO2S1Q6GrJFNYKM0PM8LED6fkjr+LAyn9CB9 iLgQoJwYhjjYb1aH/zZzSgGaOyOVVWYphgCJMzqYOCNgUTYeFK8EzN8ZS1cLObrJ397rhlr1zW9X V8NlhldX0Jn480bhmod7/h3+QX/od3ShQ8G0vVAFszDCTHbNsnbUgYPR5ZkXUWLQAl5GN7yuAo9o lhUwf2RbOn9vdFg6j/6Dk9Kd/s+Hl3Sq/6XzvpHXTaeVv2REzDAtLHKMfMKLrwXTOphgWsDQlAVb nskZb7x2MDr9n/8PTdoAIgplbmRzdHJlYW0KZW5kb2JqCjQyIDAgb2JqCjgwNDEKZW5kb2JqCjQw IDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgMyAwIFIgL1Jlc291cmNlcyA0MyAwIFIgL0Nv bnRlbnRzIDQxIDAgUiAvTWVkaWFCb3gKWzAgMCA1OTUgODQyXSA+PgplbmRvYmoKNDMgMCBvYmoK PDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMiA5IDAgUiAvQ3Mx IDcgMCBSID4+IC9Gb250IDw8Ci9UVDEuMCA4IDAgUiAvVFQyLjAgMTAgMCBSIC9UVDMuMCAxMSAw IFIgPj4gPj4KZW5kb2JqCjQ2IDAgb2JqCjw8IC9MZW5ndGggNDcgMCBSIC9GaWx0ZXIgL0ZsYXRl RGVjb2RlID4+CnN0cmVhbQp4AcVd23LjRpJ9x1dU+GWktUXjfunwOqLdHoc9sR7b27L3YdrrQZOQ xB1eZILqtjb64/dkoaoyQRTZpAR62+GQlARYyKy816nC7+on9buKSlWGocqySsWp2jTqv9RKff6q jdS0VaH+r53SdfrXq+7HdKm+ulbhJAzDRF1Pg6L7sFBZVEyKMIvUVYkvvl6qz6+vo0mIu69v1D/U RRR/Hn8eJSp+ESfqx0vQL76/VL+q67+pv17T8wSecdy34yv3fO/7SzxNpi5ml+oqnKTqYn4Z4Bd8 /Q19kvBPZa9wl240JVYXtf3F3rO9opvTAN9GX4tva+wvW3tNd0lvZHPtUt8s7rm6DPSzrfWX4Jne mSsW9lvdOPZbQ3up+2WiKXim7R/2s+0TeCIJOZ6MqJ7GE0lIXRieglN4iiwDhicleboMWCuMnqbR k9QUM0d6GlxPldOkLEkncZjk6ipNPWr6I6kCpvu2IdHil6r7Yf5aQ7lItcyfcfdh0VNkn8G44UmR 5cDQ+s4+7oxGbLf3+FIt2Rf2l88Hv2ydJrlfFlbvW/omKLWTrZhvM/Fuvt017muMTQQXt/Q1MCw3 uLMWawBT/VgYyRmUG8legp+/BtbEzWTmGSazVEUinU5MTifS/8HpQEpFVU3KKM3UUmVF4f4MFvpP fMeCrtI/79SNkbn2V3jqMCyrvHNhEKX9k67Pi3KSJEq7Mdgk1AMTgAET4+QSVaooKlLrwmLrwi5U /9+nV1dvHO3N5dXVi6sPSr28bVZb9QF/7Hz64et5vWy2zebDZXD9P53Li/HlYRERc9mkDIsEvMYl 3GicCdqiT0vCPAXv9t6A7jU0ksPvNGnHsY8r97Gfw2a0B++xD5a7f58q9UGB+38qNVHqzaX+/4Xq Pv/vq6tP1YvBxx/Uq8VcC8cngLKcxFVS9QRgaVIAJJ0q6fHvSOOxX5Q+9nkKiUP1T5ri3377bXL1 FwV+xT/80fuQ5eJlPZwUZZj2WTe0Huswakx2n3dHG4/5yjv3H143m3fNRn0FJd/51+f9Uu2qd1AU ySTOC3AYVcmkSmNotyHBiJkUT4o8jwSDuMzRNIOw2GcrdxmSbQdITwbKDdXVU3syg3k2KTLEFMmh pUkWQYszsM/2qwqmgcVgFPstkWJ5WJRs/YDJXKzrmfpuNZtP6+18vVIv6QLvB3/xKW4Gm03hPuG0 csRUOGxVWBoYZBpsNqliwXRQZI42muKWiddqDdMReakvjP/a+fHl3g+8bMM2O22O83ISlUUOtg2N 2Ba0OEac47kG27DXjjYe25nXXsVct9t6Nas3M/W2bht1v1lv19P1Ahf4P/DxnMKAoyTWU42cuoB+ FZZGPDsazDXCh5Ln1NHG47n8GM/qr6vZ1XZ91axmPo32OamYJg6xlWy4mJQZ6pvC0siGHa2Y5GUm /TCuc7TxbLjyuikzr/EBdd7Rbv7zS9/UxuEkL2IdeZ3qWppUZ9Ciom/EjjTaxFbRRyf2o4rt5jaw OZIqomQSZYidcFVhNcmKJGIamGRaPMmzMhf6i+s6GhLP8dhM97D5zfz2AYV49EK9ni/vF/ObeTNT 9WZ6N9820y19NL1bz6dNq27WG7W2PnzufLhnhvMKip3EFJxi5IpZGlbK0cA806DECbJRYbw5tN7Q xmM+O+SnxfTKX2fNYg5uH93kcgKcV9DgqKI4FJUx/BQMx9GoSBC0KCqlc9LXGdpohluVQ8OF+0Si /Gq9etc81qspegm7SZLKC8xNBd+5VGU6yeIqyh0NutejhVUkawB9naHRNInezRH5UtC1dEQFBG2Z lKiRUQh1zFAvRyRL/PQYCQlZhFqrxKjt9PnpS5RiNmPwrsc2aXjiirCbpiYzQIlrBfgkZr2VDzie hGQAe9he36jtHbUF9NDBT0+qOf1FV4wkME2jqsc1S9yTk7EAIiQVVQalExqEJIOaHEXgaGTUHU1q S+9eoUFHZaFGcbyyRBEdh6i3PVXkNWR4s14s1u/nq1tlJ1TNmna6mb9t1Kp5r2yxrF7+8mOrHlp4 QTg8n3ND6pHlma6ebBaSWxp4ljQUzjJqB3SdoZ1uNV0HQfYN0jKZlEWRdpwPC0iesV2rOa5oPyTu tIoQxUuorpA6Ww2k2Bs9IFs9blTD5/5JTryhrEXihenlUcfRKH9bhkeJtO8j3p5bKSbRJA2TEh2p OEyHAcuF3k1zv95s288UcmwdlGfNdFFvSLXbh3v6TFOnzWZbz1fq6x9eOZWfsD4nCUqkEE0AqOgk S0rKVBK4oyTLY6Yt+jTYN2Uq9t6A7jW0sYJ1HHpaIRTMIoSzvze36+28Kx2J+1+aTYsysjftLgXL ExhqFOUBonSWTsocmbalgYkeLYxCmYXo6wztaMYOWQs5p0h3AXYCm0Laheis3bxzQW6qp+vVdoPC adlM7+rVvF2qeavqRbsm3zW/XcFJoS077O7lEZx7mVL/w3X3HA0+ynb88iidVKhiewkY045m/WMm iwJt6J2Uer/e/EunlKr5Y95uSYPre+Sgpjnw5mI+aSafadncz29vH9/W03/RRfdQ9un8ftG8uYQV +PgPi0mFFJz4R1M3TaHeuaWBf0lLCxgBxaquMxrQdYY2Hv/+RgEK43s0uFZCqzG/d1Q4b9eqnk7X lJG3d2iZ29xDPCYa9llBVZTrZ+WhoYkGUAZeKzR3mUPFJGIwhGs+2TmL1C3JInSYsKIHDfexyc8+ fhBKsmoSZgW5TIxtQj8HodV61gjZPdtDayvOba7N46Bs+OHV1Tddonj1C+omlEovXvy7+oKyCfVt U8+azQt1/dXXkfqS5TFKgKLyokt5es8jKxn+/Qt6ztfN7w8NfM7V3x+Wb6F+okY/6ok+auyVDV5H PNE/hORa9evIwoFWHCucf8OKMU3Wr+xOTsvzPyaW2F+BU27KXHM2ccyiyqGIk6OHEJYlmSVGHmTF n0zr+/rtfDHf6gI30AviaTVJ8hCpbZai9ZTDopaqiidJin9MW/RpSY5WzkLZewO619BG859oYPri h3Ccn7AMrYvEE6NJSE011Le6xMtiR6P61tESrPullYwCKmOadpIuyzthXoSTjFAJoWilyUB/dlCi 8MPv+sgRyltXWtPYg/LW4xB2c/cTwsMhjUzClCJxvE8ICH0sh+gpUclbMiRJhg4bFmC17AdqRB3q mVqvxNBlPoliVFVCf2JATZKyFLRFwDTWFbRzzb1MG0N/EnTUwjzJ9smOn358BUpDLBXnSCalANm1 61IZ6YrpCDbq/V2DpgWW7m3OcpofPaRCGVbuwgpmvMeORLME+J7xdCiHDUUhtYiEDXGzRGevzaoV TbYEmI+cutdCiZK8wror7N/RFgHTWGH4XqaNoURFCF8Op7RHeL0JG7nHVkTo5UeIQ1KArENU52Ch /iw9NkraYgAdBk5XKbTXmGkbep/vcanYDAuU0Xrggcdp75sp2uxTtVqvrpa0UIZ08VG9/PGXz/hp UFin6MhCf8h9Q0sozzdtt8DRqIo1rTiiJVgPRiSWt3akowPxIePTgtSd5kEN2z5M71Qtps/G4CBD 4EtiOK6lyoHNK5MULFnaQtIgtBhLBrJOiR0NDOiAcHKh4g0JcNIhPDzNT2kjIluzrjeH+Twlhzw/ VluOa2kdEmtc5RPjXT3CfXPRNo16jZKClstT3QV5udjerR9u7zhTjfJ8kpVAqTjRovAFkAG+EjA2 FregOdHaezFVjna6tzHZr0h5MtTRcRlpK/BJmWW5G7KeL9MM/Y+wjHW4dEJld3NXt1jVqle3iPyt br8s6nartvNlwzI9LWodyv4BrsIaNerGw/rGAjm2DAssLtYDKIvRzPP5vJ0q1Wp1VwCcptWHeI6K CosqaE+g9UNwyB1o17ReKTTebe5Qz7DStp0DK1Ar27dsmy05aOrNow9vk4kAjTq0dtJKo3/RLBVL jIQHBoX6O2bRkSgJFhlA691HtBFXV+Mk8rgRxV2t/Z09V4bNG3R051titJsL60LBKCAcVa5XU9F5 xRoHMW9oYNbRsKYMtJZs9QQZ08aw6TSuAKvCajVm1ceymyYql3opxPNtOk0KpMBYadVjG9Vmm26W 863uIFLTB63x1foBPY4ZRNqiBf4d98Cpbc5WfqypOQi619TcigQ/D5oucm4BTuw78vTNpWxNnVBW +kMaiSW3Ft97DOowcDhrqcvB/I/n5aTF+8Cc/fLuKfW0l3G01ZEfUWLJ7HMsX623aBBb50EXoSuS pUFKHfAM8kJWBVQR/s+Vo8FZSBqam9QasPfq6wyN0pJxNKiwXUV+dmgQvKJZ31DtevGgcwDqGLfN Z+pu/b7B5+Q0oGnkTplP6zvAJ/xEGlMjB70wrAlgDcLR4DscDe66oNVgkX6lTBs3/UoAn4jzmDKD xLPY46IC83NaXDqUbaVYgU0LzLYeexAga+BeIFU3chCnJbIz9Iac1CizQv4YQqiOBqk5GkuN7zU0 E3KeZHMys+Lsxis/9/Rn8MIZVKukFSMpP3Y3zu+aZwBk4Uncek1dVP9evlH9M+snmOVeUH6cIKXe TV1gljzKeIopVn99o7aA8mPDVPuw2Oqw0eUIdiFWpYRajqGmotXpaKLVSTQUPQRKsPcGgkY5wgmC Q9Dyw/nhcoY5Hy3iEibpelOv2uW8Jc/GkrQuC+UrXHOI3B2uGetZANEVgaNRHtfR9HWAHvQqRrrO 0E5Pd4zbEIYWAVCMJyF8BRgaagI//W668/yoEBURCmJA2PXYg7atXNW3y/4NNsXYnttRs3jIUZKF p541Naj/28duuZqyKoAu7tfz1RZhaKWpAM0sz5FeoFJHkx7ZrX6sQUHR7+XsTsdxSn1IHAmQp2GG 6OmXSq2+WdS36i1lm0BQLpB3rtAInaMt0iCmsECOmpdDhZV+AgfAZs9L84JMwDrgFi1tgJ66JUkU UJyMPrK6YCZJYzpfMp6fFpl66p5U5DU7XdrRUsGUYnDXd8O4A3N9ud0C7fWwbdQv9eKhUT/W803L MxNn+SSlRkwK+DhAbFRvJUkJXCQgQI5GflPQsG1L11vm3oCuM7TTHdCwh5KjAVxRpgGt80mS7X18 jYco4IexDVKPbaTJ+qbLLF3UmIdAqB9HuXNbS/NgUG5ugQGILiqn09T2kIkzBjVO9SL/bpuTCikn cbN3eAxQm6icMPDAte1vHqBl3KrX3/7w8398DVTQ+/qxpaYKgHDwA8AJrVi5XfcjxWpYRLk3KbdZ onA0Um5Hwy85YiF3ToKUPuxo4yUK/n0V63uqdeqFRmNSznCH8nED4MJ80yyJv3bbLOFqN2tsfLYx z6YQAbZ7IWkHNhG5ehih0EMfytGQq0talKL0klUP7jU0MPm0prNIIRJ0ZrHko1MIH6v89ONbcFJg vpA+kQV7UCL1W2gKoGdr7JjVIhw1WcfqBe3y2Mv42YIA41KZaQ4+N/VU99jMdlizY6ynMSjWqgiY MKkxkmY1xu42o+tG1BhRYYGBgTdgD3SO6g6QSew00j7fozE7XSS35Cui6Gnu+FCiI7rmXjls72ox kyeEnv3lXqo3QO26fSHxaLRcRZR7vlF7cMcBHHS+oiy7g8FiVWi7vqf012Io2evbEg+qjKIpQU4E h2i3XDkanJ+jRejaA+7TKw+ZNprXz/ybriT4Ey0tat5tmnqxeKSWkA4F6v18i2MLhh6ftkzFQP+j aLQQjNTSEMIkDVjBnsPHZR1JZ2xPwZ1If89oEy+T/Oxn8PfoWqZZSr0tjD3I2NarhdjM9CTY5956 P4uHeQuStnM5eQFuw8iDTP/7KyqFsICEzOFb0yZlq7BINUXAFoCy9f5L+HDILGIaNXwdDXE0LKhp Yu8NUoCZDG08q/AjBCFE7MKraSeegfQ3f0wbnSAhyWth9/cLAP1l9e8yoQS76bpdiA4kbElg0O6D J1JYIdUXeZCgjWIXjBLOfGye1S4YJYyxB3Yxa25qtNXUdlPfECyjflsjudRJ9OJ2vYHDWbqtQmLl aMRIx+AYr2zQSmDxjBeC0O8HHAgdTrgLJxbOlGzBBTSJ7DiWwIiiL6qsGi0V1k6wBRJdMkuCmUiS 0axE3km0MRdgsb92mCkp9Q3qg65XZY5C4Q2sdmvFDZYJu1oDUFile1kUTN/Nm/d65wH7DWtUKsH+ zizvrz07GkzIrj4TLUQOLMwqELTx/IYPXqHUJ/+J1pNbEvUBZBNsAMVqGHU6HMzX0jA7gobtodgj JBhRVFwYmvYPT8mMRNyMsM6SxkASQxkdYoOVURjAbtwcodWK7g1A0pT1YmyjR9x82KL2ZPsbJdHM HTaDh0G4tMgwndnxkOAYWckonQbGAuMRhhZzpjVa0Udnznlyu9aF4xcQD9PiT3JEL6RxlNWZlVvl aBSgu9VcTQuxdw762buXaCOtufEys1dw7uHPUJQhraWknPw0S4/1xuz5a2a2KTZWIy73oxpeUk7O fgVF4HTxgO1o8LNQH8ITSTAwNcR7OAja2MQ+9QRr2r/YhFbPwGhhTd0+SdovpvcBIRqgDd78UWNP VSOQlqfF8UMNRJyhhbZTSPk3HmmQle5mw0+pNLwJOCMIWRJsXdQ1a9Auw+ENttFD2GiLGExoC2eI AxoEQsDSYDsOIYCqEEezwcD4xo4whvcXiACv5Pab1/O9v4DWs/jYvOwCFwA8Pb3HaSjLWtRTR2ny Ie2hJn/uR/AIaD2tKL25uHnQJ3Mgc6W8H49yIHdtCVXmtoge9ZiH2jL6MR1qg+VE4avbfYwBV6qe zeYarkLHBtpyfURTc6gf7EH/Ey0N9V+ZYJkdU+VkwKbmGjWd62HGHZ4oAYAO6EUyNtuENiSyNUkC SEXDFi0SiS4ztKMTx4+qmx/eINtLBJbD/O1AEhPkwkDS9BNHS5OJYxxh8yk60FxYBgnTTncdwyUy kTjmvnPkeBJ2E8fjlqsOyTDixBFj7yssx47LOArLF+6+fqAjAHrsIhk5Nms8xCbOr4zN5g06hmsA iNnp8owW13AoJgaGfaMT43hma0N9Q4cd2AD/CfbGM/dYCsb+b0xKQtu5k0QfBWj3TzgawpndP4ED LSdVgmbSAufjuXsd7XRVNRIVNQ4fuUL8DOXIT7+rqs+PctgBAyAgzlOTsmTvvWzatsYBtOgsaVx8 71FGUiMRaL3sn0uNBBzBp0bYhP9ujv3ZzDKQpJMKkyV1x7XIWXcCQXN6Iu51tDF0J6UjC4wl/Lma I/ZxsPhYc1zMsw0VmzDpxiQQa8Ioj0o+DnkiLQA/KAnaMwfKZb1cYkUErV+azrGBLcLfF76jDnr7 yXZteIRwA9AyEPjahj1CcIVgr+DSi+cEHRQ128jpIM4h9QUkWxiyYY2X/6FzXcK9U6mF0YcGcS5f IjAizDWHJGsMzLI7RA3zhuN9gCtBLwP43QKwHnQKDW0RCBpSphDHaYgD2HAym6WNlvsVXoiLKZpt yoJC0XY9gxisYIsZ5a5uJ5+jiZ18RMPZq/LcKxw442hgQCcIx6cmw5yP9++Bi2EXi6U/vg1KxXMS ZG/IK+T2GBDdEMFStUDmvac/aYHK1EviVKbTLORjdVrhww8QmEbgmE48Uu6Qdxarchh5YJTWOIyO 0a4uV5badTXg6LFji871JTPBYnSF9M/RkK4xDbgawHrEkhxB8DvS6QF3qGN8NF/sFeM5lYybjSxH 1rF+XwtdJWgTHX52FhSG2PzvFcOOo33KKoC3p4UTRzCZEfXkWQbsaF1L8RHNBgZDzAXkDQdFo1bH dmOnPgLP6WgCz8n6Y28NmDSGSgk0p1eW51QpgeZkebJOAZH/Hh1CfbSYi9vOOkf0SjhhDvsUaGOu VwRQJ5bCUeliZ7n7MT3F/wumxzeqacTiMLeu1kK33IA2gZ9vNvcbvKsBR+8ScNMFC70MjbRStMwd qCfGcRI41E4fMWz3ejsaGi6SluTAM4s9H3SdoR2dUXws2iAhG8ZiLEOyrX7iySsAPsLBBRqaxLlS R0JLTJCwHSLrI3di5CGGdrp5DstzkduBlUH4Ou8SpDuDFlvmrRjZPJFWPMkszJoJvY1G9CGoiiod bIZHQQvXsztcxxd3VCr5ezeh2LN89jxGbOXHM3sU7FzZTEbaVeFlA1JYHIF2s5nermJ3wCCQFdQw 1nsJ0IFBlzBVjgZ7lDRsLNCNUnM4YUDXGdrp6t0zVt/8exAfmH/WsvFTZwF5LN3orH1mv39Pudy5 AHiTwCNni+PFI7GrCM801K5zpTcJsGXadUG5nCxYuZwQ9qc37pDxmM5bgxOlNQULU3Y0CgMGzoxN DdhQBkeLLNocUI7drY72ZBUTjkVAl73SPKd2ZQxdZomydu0kzbPmnjJmbJJSi/W0xous7BrVCUnH /hVpIP6NLvETwLru1zjbFE4TPZmXW7Vo6NARbNPqiWWkZiuXEHTg1J/Wso95gYxlwHrdpZnMr1sX A6IMDR0cyYOyzy4wOxovOgdES3B8PimxXRkTtNOVeJgG8Gq6V3L88Lse8vlNenFCHkuPNcju7Zv1 I/D3P7++xlr0FtsM3UrrUVp8qJbXOYI7NYufAVq8xOIzgbKhxd/p8+k3Zzk1R+yKKn3ovjNhlYTh OPaFAne7rETCzp7DwZFioKyQAejDJSzE1tGguEzD3qQK+GPQ7MEUOFfF0k5X5mEXQxzO6xUia8yu Nj+/XS0O58XYxgexJq3WdPbS7aLpdJeW8UTYo8Bre9Ys4qPUupf6DN+0h5Dvdc56Q6O2pd4WodNy jUMmJesLH8QRlR9Px3hnFwrwHXMuNNq048TQFn4HTGR3XiGcMiVvMRb8HQ0ta0lDGkPNOAe/o+sM 7XQ99jjlGJtzE7wCCfmST3b89Lt6/HyvHGPbI5b1tEf0qM78hmqg2Rq1EG1YoZfodOhxfeoQygLA 9uktWHOcD6lXq92zPv/R6JkqjSWll8uxbcFL16vH7tyjTbMAnn3WbZ+B4wL+jj6ygGjTjWj1zpoO w2dhqCPbXeVOjOo9qLXyDqXnhPN8/6OF43B4PCZmE6GLO/U7JyKN4mPQtvYlgFSr7gwMNBctEUzp 1CocEJ4DzAUo5eO9zApHQ1QIl8xPyL6AgO88AdFozVwB76N+/m42KhYu9fKt2GTh4IeUDeBdz70q x9FElUM0vD5Dv3LJHG4UCBr5onEm2Ic1Uqq3m4BFaRfRFE6EneDFUbQK6FpblibbXXT6B94o1TuP SdDGcKkiHFGusjspQhHGd6n8yiXKkwaW8vOqe7lFnrIIx4vDAk/tZZxcNo87XiAW8GBmmo1PHp+K 7cTYmEFnZ7K+uPeVOBrCrXmvCVTc6Yu419HG0BeBIPKKjUU2vr6gKToJ6RB6hDuPvhD0BDvgBNJk PG1BFMFrcoZOi0KsVBPjLJ8f02nqu6O+adxBSwpv0Nw+0FkIhH1jmWMvV0YHBqN8xsZEWuIRe3os DR7G7ekhWkTvjsIKqrzX0MbQGIZm+iXITz++xjBUR0iRcwC8Coi2iN7g0B57YA+tsrhTI10lgm5N 7zERio+FVB6qQyycSzwcewIKw1gDch1mfoDxQnKO/ByDY1OJd25gUQa//eZid/kJL57FucJS0dzW PqtoUKoezShVgh4d3RsI5RsrIiehByIKI6WyrndgDMdibNfAgxDUgH7Di4ThTw1pETAJxzP33n+O qyzp6Ic/VBdqD+MBMeFdXJSn4oxH/dbkV25K+P3JnKEzV3QCEdBhqNnwZmT9cjhDoXBhKYgMCV6b w7BstNM6GnzE0Vwd0nDNlR9/4moPmhvaHrSCO9ObVOBSN83soTvsGrsI1jc32Ps8Q48Wr43GsWP2 raPAObuGLXNO53DgH1h36y9oKXY0cGpf+gTsPo7mB/yKuQ8EbTzu3XtwhGlTYcaWzWYGZqnloU9P c108Zg2wF8DoC3qVGaFsyu6VkZoGNnq0sEKpyqxpyIyhEWs2Mp4UqESPn1dMcIiyCIs4D+n6Rl2I kLjr1I9OvPcea+1as2Jo9umUBeBlaewtj0r0P2aZkVsK5pHgVizKFRZKRd07OlGMddIK+WiW1b6T vPGyb4P5RNvbZspCn85UsXGOTMMOigOpw10mIjBsZHP6LIUIJ2vgeAVds9mtLY4GDWUaEhA6wxea bO4FHtLRpNaeJFChtXwMk1+MrDRP09pDWsTHMAlZsjL9b7NZowkQovBHSxuA6WbzjjZzOgc3njKR T8ayySCnhD5DiVkGRxlO5/z3Am8SBJuB3mAgHmW8ZIZXlr2jukSqU1X0WrpyoQcdq9+uH7Z0qDLW N7DHTkecFq9ZwFGOOFnZTYZD3+A0A5yaoN8BTfBcbJZNlKNRtGEa2hGAEQj0Da6ztNGiTeRbI6FN sAinzax7WSg2LFrm1RrhZjOUgJke7CF2wYdOMcDKlD5NDXu34ISVI1GcMSTYK4BdcquXQtWmaSan eJIiCyNmLCJemezRYlat8Y04RTMpxxn8MCDPWga/XFgWDvrMFrNHE5Lumquz9fSBUF0vWKd++j9Q gv89CmVuZHN0cmVhbQplbmRvYmoKNDcgMCBvYmoKNzg1MgplbmRvYmoKNDQgMCBvYmoKPDwgL1R5 cGUgL1BhZ2UgL1BhcmVudCA0NSAwIFIgL1Jlc291cmNlcyA0OCAwIFIgL0NvbnRlbnRzIDQ2IDAg UiAvTWVkaWFCb3gKWzAgMCA1OTUgODQyXSA+PgplbmRvYmoKNDggMCBvYmoKPDwgL1Byb2NTZXQg WyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMiA5IDAgUiAvQ3MxIDcgMCBSID4+IC9G b250IDw8Ci9UVDEuMCA4IDAgUiAvVFQyLjAgMTAgMCBSIC9UVDMuMCAxMSAwIFIgPj4gPj4KZW5k b2JqCjUwIDAgb2JqCjw8IC9MZW5ndGggNTEgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0 cmVhbQp4Ab2dW3PjxpWA3/kruvZpZsvC4A7Qld2UY+fiLSfj2HLyEKdSHAoaMUuRMkl5PPvr9zsN dJ8m2aIoGRq7bFFHANGn+9xv+Mn81fxksta0aWqqamry0mw683ezMm++3GZmvjWp/Xc7l+vsx4v+ x/zW/O7SpEmapoW5nE+a/o+NqbImadIqMxctX3x5a95cXmZJyt2X1+Yf5lWWv8nfZIXJP88L8+1r 4K/+/Nr801z+j/n9paxnEnmO/3a+8oHv/fCa1VTm1dVrc5EmpXm1eD3hA19/LX8p9KdxV/hLNxaS m1cz98Hds7uQm8sJ3yZfy7d17sPOXdNfsvfk4dpbe3Nwz8XriV3b2n4Ja/p5uGLpvtU/x31r6i71 HxILYU27X9zfds/ASXbI4zRs1fNwkh0yrwacJk/BKXMIDDiZEKfXE6WKgU7L7FlkyskJnU4u58ZT UpVPk6ZpCnNRlhEy/VZIgeN+38nW8kGWyg85BX4YiIsfgjM/rodr8v7XZo+eY3zjVyH0XJaTYza5 GQhjt7vjS+0Gf+4+vDn6sPMEtbZUD2V5itrKN0HbfouDYx/O3x+7v8YfpmeN9/I18Jd/uP+L44O5 XRZP8nzln3QtdN+z4NGZ1hVn2pqmCGVPLrIns/8ie9ilZjpN2qyszO2kahr9dWnkV75jKVfZnzfm WoRRUqXZtE5bPlvxJYC0BdJLKv1Vvr3MioRvnwRiDYHFk4v+an62/JJn1UArhRNpr4wxb7/57l9f /f4PX/zwzeW/vvjmj2/Nj6/SX6C48J/sx9evJ5f/HoScXd5jqzGPrYYF95SztxoW9PebbmV2N4ut uV7O3ht+brudeffxtXErCOS67oQAoTW3T2duTF7mSVq0nFaRc0D9igBxeoj8V6yjM+ufu81yPYMy Lv896eX8OFtQp8MWBA80sKPDs1cmoxBAkSWlwxMqOsRzvl5dLXaL9Sox5lK2frG6Xm9uZwKSE+hW 8/VVdwXYfLWY3Xa7bmO+2O02i3f3u878bba875RAiiJpijQtDRIqyevG3Jp8WiVVmU49aBmC8qSp 6wwucHdOmsbDhCN+Gme/G0dye/v97Wyx2UL1X/zt2+2Pr5EibvtzLkubDIatq6SpihpE2jJB+Ga1 h02W+7C8yhsw2bt3gJ2PyWOsXKQRUjXmy26zm3FEq+6DEWzM7eyjmS23a/OuM/dbzm+3NlfdfDnD UJoPF3/19usv9ex03VWaNMPhVXVS1iX74GDgF8LyHBmoOE/kugF2Ps6PCYwij3LLfHY3e7dYQrzd 1sxWV6b7ZdetttDtNnqUJSQJr09uTcZH/uMoB5iIYYVBgBlWnqLFdR52PlqPHmV1zI0lXHjAXcZS aeyc8jbJ2rqENrNsmtTTBo3gYCCksCap20p0jTvjSZN72PkIPXpObfScrFTZdnMrUa667RzZ0aHe j5lNtFk1RVn6xU8aBwsRyvKkrto6QMhwYg4mCD1PTwRqM09RTgUSICuK9vicAlHNo/Z09uTXi6w8 S5O2KPpnH+lKJPZus14ima/u1ovVzix25rabrYItPW8JjxIoRxFX1Lub2U4PkB2YPMFaOUlGdZJm iFF2fRoR2aKT9bkjKsksr3jwtH/ukY60OnCxem+lzLa7na12Cwy99bV56wwEbyO1aVJjb+UGbzKp S9EcSJ2kbDHpHAhGDEFYcKIC3Z0TuWyAjcecZRZlzq/R/vNe2UflzintOKmnSKAiFxyzKc5KURkP gl89CFkjrKTyh8s8zKKIne3Mt4etuZOEw9GVpTDqBM9dtXyZZIjUt19e/KGb7e433cXfEERrnIAj 6VO3SJ+0Epsly7KkbfNq4mEifXqYqVskTVqGai+EjSJ9srZJynyae6QkHKFIBTzwAtInw2LLxc6w O3okfq6669n9cmd2m9n19WJuZu9mu+62Qw79+Gq53mJIYXi8X28Wu5tba8Lf392tN7vuKlEddp58 evS8G0fS6kiUSdGfN86NHrLQ1BMk1CnBmKVZUgt/sztNRDFgfelzfxqFruGMI7rGW7p8KWFYC4G3 rUjD/tH71HfMTF74ldOkqNOqxKPlSCoEqjATJvQ0zRUmzORheVJVmYg/d++krjzsGcw0EE2gygN6 Bp1jv0uP65CZzvQ+TpFLYEfoXiq5spchoaJGn0SopzgkZ0PbYlr2p3iMNoTaC3cjDl4gUkZUq0Vd J23VDms40quXv/tK4gtOFk9yeKupmqmSCsozz5J8WitItIgDeUIJ7uxhOGejEE+JLsbGFovk0xOP hHfqut7jQ6Uddi8Pds8aYU8Qcqdop4QF64aw+gNYExfYfbwjPiIhRKdJR6SbqqyTvG32MVf99wNe 3vtVd1WXw9MnfyWogFwuMJoD0VMUeLIpVqyHSaDBw5R69N5xqafO0UeSanhgH3XzXkD01EWOQUPA IhTjSj5/3Kzv7zob2rLRvTFlT93W+NDEgR7AW7x1cWMIWWxfhoIajJhp3oqaVrmrFDQz+M3vcJwk 0Ei4cdEtr4SaZ6vV+n41J16yF11YEwl2ZF5mNbxBBN4T1a1BXeK5phLRHfTeMoR5QnP3RnTcng95 puKBhScunRWL+1bxuO+qm3fb7WzzcS/WR4CII/m5+6iojqmNJCBYFvY8sohnN1v5YOvLEETRlAQI plaQ+21Rgjh0qjEiv8fBFqdvvSG7OO8WP8sv4oEGBpDuVS7uXl2hqEoCnkUrUYwyx61pS/SZg2Hm hLC0QMah0IZ7J3LdALNu0SjBz6qIGD3G9I6QRAvNB2x1i9nPEs7FBFn0XmEsSjOpizZJczxWTLum TYosx7RzMEw7hTUETMt8z+0rPAz8nilxAtOOyCBmJp41XB7D8kXla0EMra1ySSDw8MG4Ufm66cTt 8c6Ij8gqyYzjBVXxdEoQ9+3Z2syu+kD/bLnH97N36/sdgk/Dp7rCEQVAKTq2aS3/+RUr/0F+M0kH Oyk7pjEBcZZtbZVwJNEjHO1DaevV8qPZ9h6rbgOmCBFxQgM1xgPeigQ84PAEcY4acDBsixCWZugD eHu4F76BVnvYiLwdTyQJTnsKDKd9gcGk++siwabm03SKooSdIegqK7KJh8HOA8xeV05Re2EUh3sH 2DOM7cFtCtg5z1psuNKeVCRVFZDHobk0RtA1J9dRECaHnf2uKjsvnhxe3TOwJYkfYGolVhMNrw5Z muCsnsiFp9zRaUE6usCdAkn/+IALSSEpjWRWQJ+dhNzD9yALrfFVHnvki9qU7/aumy8IKNlgZJDA cWFRQ9QFPsYVg1KrEq+sLiceBqUOMK4rk2lbSIAuuNfDzme+UxspB0ik48ilJS7zRWDKHJoVeNwz rIkZyRCMiRWON+GyxWq+vCcxggyEyryhqSyaUkghbjHecC05H4yG2sFgRwerKDaYIqWUQycKegaD DgcakG3JE4h8WtSPTjGgnEP2PNOePbXhWNe4hJkYkLrvyp4HdpkaN6NHHevCEbA+fYjGHURzbCzn CR75KfSzlJ3PKBQBfcLsh1l8a8Yp55KPeaY/4cvjDv2JrESL5rkEBWM7cLWGflfrnXPrsCbulos5 HlZQTxAs0Me5fnWEtMSmTEk77C0sEGlSZOSsiqdYXCyMQpjDbbCPiSRuoQB9zIjGS1C9UUce6wx1 coDbfY2POyc8seZ/G3WtIvKIC1TmuDIMKU9KphkqAkuHVCgqMVcYlk4Igy7Fi3H3SqWT0KrAzhe2 p7SH3fTasV1wtgZZKla2ClPs7T/gsHW/zG7vlt1ndg+8dffjq0PRS5mEIu8FbtUgcFOq9hC4DTJV IhkehnT1sJo/pji1ocRV2IjIxzPr7vSV8hQFgvjtFAuU4ASqr0dhgBEb3YMVLdyjKBjOOhlgz9Aa p6RYYH7Usaz6h5vF/EYZaaipHccCCeRXZDd/fHV9L/lBimSspYxaPk5w+bxWYAtO2auSfyaya8OO q0Z2MHbXa2ndXXfvwY4/0y9+WF7FUumhvHoBdR3KrUgZwexOtIM19YR4+9q6J9q5pyRGRjl3TihC lEIM+0VQvjCOUiDceayVw01+GaUQe+zgv0opn3f6Vco5MW2qkvgFkRtEhE9ue5jk6IaEt8CKGs0f iniFPUNEHBuWQcIbjD6xaRkkCHU71biztBqEwsZkzyBJF8UbLa7C/QXYFIs6SZFe8EkUdeL0H27W ENKWmkHiB945GZFXgxRbfA8wY3QTRmQj8E7ahuRziLxaF0Ohg3NFJcdUSl0WIU3PJmIgcMeUcKiH iYEQwAbW2btXYEOG8inSh3DwAyZpU0aYxpiv7jeYRrp5ah6QG2oRjfB+1STYea2pHGiJAaeggjLJ 0Dbgqh70DL4fTIPAoSRYnGeUXsoR2Oqd/VKD4NwPiX+EiA9JqqHYTLdP2V4C41iSkD/9MM6BeCLZ n7KFsgb5KmW2D6Au1rs+eMRYjFYXKtpK9beSGqJ9pPtlfjNbvadvyOFOTSx1IRR3eEpBcbCHhAgV BlXvwXpa2bv115LPw0xA8O7IMQ5VcEBDCPFRzMrAzmkq56EoEbmgluSMKPSwbjo+GBXYJD53a7yV 3+GhiZey7UJPmcIplbUjiYhItRRe6wI/Sfx04t7LbrYhSGyuNy9E8gHlxUqnXo7itRSm8bugJO+6 PGzsIqyspfvhl7sNDBEwgSsTl4bBNqOYPG8QI2mOALUQEZYhpEinUt3ky8vlqgF2vn94So6IjduQ boxQPhu62IDV7S29HNJKQ4Z7MA4PMtxBlEx1BFXIVN7YClZXmFM5GFh6GKEp0u37cUeFPUNPHNuH QSERuH5i+zBIHetGK49THTy7294v8WaI6fommUGQvpHtp94h2OEnKpFTfo4cPl2wxxvyacoDpQH3 kO58tGU75M9nKslcjZ+pUhoq2sImkV2fgoeJ7zH0MwiMKg6JsLh7JwHsfA56dBNjRQkSXvrpvttK aasIp8PokQvcq3hwzDMppYiWKmdxrqg8IJpUgcEAA0GFlbRAtXvxl3LqYSD4THcjMLJI0VN7gRcO rcTQ1OUHCpIA7dkK8pR4ClL0PHygFmWelw4EBM5FFPcDnePD0mdVXpzCO3AuFG/VOUENieYqbCGG cot3GTzhEIylE4kymjIkpgDmCcfdCyF62IjcEiu2MJgxa8yYvqRK1I3N6c/XG1ToHW2G2NLk+EkJ uAAF5s8lbOUlhm0r8S6m4yVTSgq9ItWOspUEVIm28zAUUQjLKwxU9Vcmct0AGxH9WAGDQcOuriSJ 11FNsf1A2N1Jjf0Qdd+X52SHvT6ghuD4oRbbhEjvCPyLhSH4D92UHib4OxhxaVqCJVDj9m5SKmxE /H1+XAkaU/KAkENCkObDvvHL4rtXmwBBvMMIjiEuvaA5JcyBlVU6GEg6O0tgeQ5V7CHuYSMiHkle g7ijZ9sfNHu/6ciF+Zoqp0KEOixNdMn75DPzbiZdmdhlQi/L9Xy2jG0A7ac0E4mb7jMupYMFWRh6 NKm33Mffg0ZEfxq1NO7WeBC0m66u3uAw495cL97fb2xwl67anscHjnA2gWd5yyIxzIlBNJSZ2aMf UjDkwHuYHH0AwxINYxQTuW6AjYf7NI2Yncf5J+MToauO8yV+N7uiR2y3QDD24vGQ9kNPz7GtKemj zVo8h5DlHQz0PctjFWE97GWgSoWNiH68B1cyvu9pQqQwci19xnGyl7/vn7g3pWJHj4qrkfeCOz1Z zGPJTOlg4B7CsKP2/A65boCNiLvP+O+Ju756w4UHmQGjp1fQwEcRFRi4UBqVRT1Io2tlQUVqjZ2m UssEsPPXf8oMEQdhStnAoZWO1Or7csOqGyXePgsGS8PWWjboSfejle2BS6OoU5Ep9ZCWcIeKfCl5 tTAhXAcTC5/EWYD8BNXlYOcj/5hhP40k+yzyxFuG0MdHzZx/lAKd5XJfdf1ft1nbMh3bKmnrdIKU uaIuLciUsAnqXjM5GKiHsIyyUT12MIdsLWhExGN5L6+rDEMeEEgyYmOPAqQAMkLSE7Gjs5ROntCf cbDQn0kh6pS6AcXO4Pw4GOiNEbglnIJuOPJ6yyRH3WioTR0bf0iFNKWKQR4MdHAwYpd+yAP5b0q3 01CvUN7pYecf0yPMyb4+wJy2ztzFDO2MClQrjVp92490VroWnKGTw1ofUuBhuyowKyKytWgoMKe7 JmRPDwvYU0IeFVXswTFOAtj56D/CnmUaicfBno+0KICq1rQ8Xmitp19T4QqzWfQHT6JwMEE/gKVM TdlDn+sG2Ijox4JZJhzawYHSkxFK4aCgiubbw+JtmFqcrCB8HGAP7eckxQOjgmK6HibYD35EUUHn BC/2sFfYeNhn8ciVq4CV/LVYx4F3pC5GTEgV0jkq2SRJTGD+Z9S1eBhCKoSl9O8GCNrrBhgIjiSk sriffNkj5Zjbm4wD80Zr58TAsuUxMa6mBA5Ht/eTsFEkHVk4GAfr0pFkXqiMtdOmHFFMAtiIBxt3 kINgj4QBhsS6NZIPEs323IMMnPweQ5xpaNMB7yEKXwwgQTsAlQ3BRmCDTz2RywbYiGjH/WKnYQPN JF7S05JAbuWm4FNZo5ngYnw8PKGpwsBQYRnVwEQg97D2sBGxjjvFzro6SCzZk31yyFyxl+Lustlz jAoHA1Mvw4CVJUWLIfYKGxH7uE8sLB6S+yDHwmZvT4z49vAvDMuUOOzkpMDFURhyS2HwL38NkOI6 DxOkNLfwlMLaIFic45XkRY3fgDkeRPepxbNj0dSmemawGIvgwaZFnckWPFyDxb1lt7eCsfK4edsm LYGDHu0jy9ImbgN5JdYXJ7xlIJqZ2c+6qvPStY/ZhfQExpy2L7Rw7uJrUrV0q9rZbLKaw9STuelm hJyGCMziihkdi11Q73reQh+z4PJ4ZEAJfj/pzc5dyRC5W+lHsqlmu5NvN4v3i9XFn9YkW0Tuq7B/ PplpLftB902FOGmlQySjot3RuJIZLuAqaL85b5sePU9fta8PwtAd8P6umy1veyIjdNgtl+HYReXp s7ISpw4s901OZR6LavT0JAUAJ+T06KQeKWxna3zi1FegjDJOhUC6HPn+mCA5ib5C4/PP/8v8xp7E nyz3fG4dLvPfoyPtq2L3gkosxP3zG1f+Q+VZ9rTE1CkSYGATdUcyk4AJQ8c+9OXitvt+R/W8Iuyd 4lxarKR7DPvaZWg9bDnZgzE2TUyPvXsH2L6eOoumB+4K9ZQf0CZoHItKXf6hABnBtveFLMEWKltD Sd9L3hgL7+Iv97fvumDc1BN5+ZRUKSrGoMj4a3uQxzswOskW8RJnR6/8/MeLkyxrOFLO33VX93a6 4MW33WaOlqN+TY9fKVBqlnNMQqiXGvy6zZpJ7mBYWQOMKk+G1uSEMEPqVdg41KvmRnRXdfkvQb1T JljISJtSd3OPer+zTTUXl4x42VvIWDUBmpSXFRxT7j/1qeMo34JEUiQC/mkpNxKwZHzugqb8j9Tp +l6IftSyUm0hE6QZiQjVQqwM1cpNPsCk2DKEFRnR55BquW6AjUO1ZDPqEtcTyontqB7bS1Atec9S stv24YMQOCDbU3JgRMmrtR3xfRiffmO10QH1fhLJGykx7wXFvpwIKJcQ3HRqo3GudDjH+BCYUK7C mPo1JbWwR7keNg7luomqJNgiAudlCddPNZCHxwjXiYGLYzkwItVqGWN8E8an2nhqw9Ptf2IviK/3 T3X2zhP3p8xbceqYw3FkJPDUS3xkPeknmtSnLDGxHPqBifLoI01zaFJjz7tiRqpoqdmxBR7KNwMo ZAdATNoOxyTaOwUGKz2DRYYtDAzqwC+I7p/u3KFwH6G7n3ye5E6tZvE7qML90Jz2NWJPZI9ThMN8 F6/cYvQjlOoabl9oaFnIoX4X1D38wOsR9BT80CglITcY0UEk9tmPShTIQEDuPk9AyN2BgMYKpoX2 XWwrJTakiIzIiKFijmwgQ2kJMjH/aPD15UilTkvljyubDPiykDKNrMHq8ny5B3LbOvSGMcTSb/Uo fKlj/OJyTTfyBfiyxoJkdusgVAfJpnz5H9eUdt6s6JD4D3oLdBtHZMsGUZnlvc35AC3pDjxFfTw4 34Ex0hETIewjGpFitX8o+tj5PcWzjFaWzKD8/ECweU4Z+v44Zd/Sm0u5fInaFWdheMeBh4mz4GGY V6RHYH13bz98tYeNQrfa2iqYHetjPbUXoNtAmOtpKt0q/9s08ujt58IvZazU3pivJTlv7hiUvXi3 pCZwLSMslrytQ4SizSfoxiidPSWZE+2Po5Fn8Plj62I/gqcytLdqsdszKR3n5UFCTW6qn4dBTQNs IrCcJgOoiakfeu8AE2o6jzFP2Vh2S/2YPVWK2HXRpNpEWsqpxpJgJVMVmWgr49QdjHYShcmsUt7G pJlC28I4wFj9r+/AkLhp2hB6gixiJQG6+S/AC4F1ysOPZHjPC34Fz0Q2SnQ6tCiOtujfW2bJLxjV YnYEnrdUvuw+dKGZMxLlRAb/QTnCc777b9gCrPNnHsKhdUky14btL/gZWNelX4sKJJHvdB76U7D3 jdSBo7MVMI+OvRNfmbv9zNysP3RUK39GpYl9E9deDdqgg1TLn3c0h7vCVvhdsUwdL5rou495ycbm ZUxFnRCCznNcoWLFUgb/24RduYo6pSW8mUZkJLU12dQWfWZVy6v5GKXgQIhDD6LsdcpLsJa8Paq/ cyL93wPs+fq2Z7uD9KYOdYiiZvtU9kqyP/BCkz6hrYNufb22FHbfXWFxKPYjHfwDdSMsxfPkwBfh IdiZTn1hmLLLiO3x2mpalpEVHjrzUvftOmEzam+YcWqLn6XUKpd5bQ62nFBWoTA0jq0/C+8dYM8g h+P8mI5FEzSOYhIBUx1KuxHyY4Efpnuo0m6Bzjl06X2Sl+Xw7yi9hxXzpiiGs2o3tgfoHyWhcZLL pa2ZOUou//mH7y+tES8vaZvZ17Tpk7PxMM7oi6kpCRNDI6zeGV5qaOc7a+XkhHG0Uj/H5dKnUPMB U09cEutwORhyTGGYkYxOB6S3WtAQhhpHNFTxmpJ/vL3rVl9vt/fd5+ZrEVhY0q5SeEGd2aw3IiR7 /ZkoDv5MmeG/77c7lV2+koysKV0JthiWGtii4Y1vDoQlqCBpWKDeTK3DCZVRDvYMVj2OvJXS0WI1 B1bqp/aUdC6zPPzIOqSZDdG/Mf1kcGqLe8nLVISfF+v7LZveqwxe72MDrLrRI1GCr1JR8YHhNjx0 Y77/09sfvvnKXC2289nmSurC1bfrYzuhYBkrwCUV0rwqislBZeUXqMYDhLgdCgDMyhYAQKsvNt7a vytD1nIk6OdsCbPApRrTvqWJoqtZWBzuGnIoh0ZyYB/Sasis/npKebSHESYIYaRurLs03Iudy2u2 etgoDMEYqKSfChTfXhWdh7prBEcTv4+Jj8RQ7NkeMQSV9Z6iziPxx7zaqjpmO0h8SVRNyGZlIsxG 42gXtF+dt5DHLHH6XY6yUyzkL2te9Np3FfDOZDcNaEQ17YdDl6zgiIBhJn1qNt6rBnWgrTz2KD5l 3VHRJL8lZjPoGg/TBfkRjhktXPRHUV1CJG14FYSHoTwUlhEh4T01SxPc62HCP+ed5qNkFauKMvZl sLp8pw2xBGj4aXiTAtES9xIvD9PhG6j9Uqbthr0hIYzlPzOAEHiFQcCCt4EenUxADi/B/ox+7d+a U8qrSPuqEdU9vsZ2qE6kWHMTeEZP5IpTHBkUYkd3Ab9MzxG+GMtoxmlxdRa6AarbaFSfy6wbmRB2 t9jYshVrdv2W1sm7zZrIZscg6MR2fv+dkObN+p5368i7iNU24F059CYw9cSTWKh1HCmGWkfJzt1r SXYgxfO55tSOSzSijtSXIQPxQ7cUUMs4uM5GBTrSRvwaWJxicB5qfWufdvL6bNotFX3HdYa3YGJG oLWlI2voPfMwhIaHEVWteDlMaIUS0HWwEdGPFCmBPue6G17gO3sv7YU7F7We7Xaz+f9uk6B4wGMn 7ZJlMZUhWZlMVJ7SUuZg4kEEsJTIZGhjy3UOdj52j4nEOlKQ0L8w8tCrl2GP0Hz/DnAkI2uVukH/ PgFpj7QwkvT+ha9Ixuygn5vrLGy0JL17Ty1TID61ZAxCmLqRKhklVCPerQ/oqiEe2Jt//X9IP7op CmVuZHN0cmVhbQplbmRvYmoKNTEgMCBvYmoKNzU3NgplbmRvYmoKNDkgMCBvYmoKPDwgL1R5cGUg L1BhZ2UgL1BhcmVudCA0NSAwIFIgL1Jlc291cmNlcyA1MiAwIFIgL0NvbnRlbnRzIDUwIDAgUiAv TWVkaWFCb3gKWzAgMCA1OTUgODQyXSA+PgplbmRvYmoKNTIgMCBvYmoKPDwgL1Byb2NTZXQgWyAv UERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMiA5IDAgUiAvQ3MxIDcgMCBSID4+IC9Gb250 IDw8Ci9UVDEuMCA4IDAgUiAvVFQyLjAgMTAgMCBSIC9UVDMuMCAxMSAwIFIgPj4gPj4KZW5kb2Jq CjU0IDAgb2JqCjw8IC9MZW5ndGggNTUgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVh bQp4Ab1dW3PbRpZ+56/o8stIVRaM+yUvW07i1MzWZpwomuQhngeYhCRsQEImQMveX7/faXT3aRAQ JdLNmVSNqGOA3X36O/fTrU/iV/FJBLnIfV8kSSHCWGwr8YfYiDc/dIFYdsKX/3VLek5+vBp+LNfi +xvhe77vR+JmuciGf8xEEmRe5ieBuMrxxTdr8ebmJvB8vH1zK/4UF0H4JnwTRCL8LozEL5egX/x8 Kf4tbv5bvLuh+SxmxjHfjq984nsfLzGbRFysLsWV78Xior5c4AO+/pb+JeKfQj9hHt1KSiguSv1B v9Nf0cvxAt9GX4tvq/SHXj8zPDIaWT27li9b71xdLuTcWvklmNNn9USjv9WMo7/V14+aD56kYE79 F/1v/QlrIg6ZNSlWnbYm4pC4UGtaHLOmQC9ArUnYa7pcMCoUTuPgJJhi5wini5ulMEhKwsLLsiwS V3E8A9NfCArY7ruKWIsPNFX+IQAu/EZrxo9b9Uw4/JqN8DwnN2YWhOc4XkzF5F4Bo+8f8KWSwd/p D28mH3oDqFaiHsgyiOrom4Btw2Jr29X+m203z5jNNKJxR18D+TKDm3/RcrCU08JIRq7MSLeE+0EE J3uaJtjTXGSRrXtC0j2B/A+6B1zKisLLgzgR60WSZfxrI+hXfEdDT8mf9+KWlJGX+EGR+jk+S/VF BD8HZdBU/CvewzdnXpEUC0utQWFh5Gh4Gj9zEcRpHiqsRFqlXQgh+vvqqyibRvz8r99uxH35uRKr +va22labXrz/4eq6emi3/dXN14dKvP39F/G5bHaVd7m4+V+l8+Rsn5uceGZyWRAqIPHkYi/2BE3h t+rTrtosq6t/7tYfK+ydHttS8MwSIgJ0mmEv5FBQJF4Y+QkYhbkoRoXMKCydx/0EROjvf3q4Z9cc 0zgL2BhrHCFu7kls9RIHg+IEBGnoAVJ5QUuUQ5N546Fv6nX1W1+uIbNy8MWvIi68KPWTWGRp4mVJ lIq1yGMP6idImdaMaWESZkD06F2iLRqh0H0MqhUTLSwHUejlISy3XIZCDS/D4h22xrUgBbHvpSFW b/OQITsDViMoR4L1EHrCHF5JDN3/BAtITj9c0P8v21Ulbr7/MfpwKepO9CTFLan8M+AricCbHN6T zRveGMIXdLQeOMwjKMU8WFjYivzIi5I0tLE1oils6Xflc4oGbC1OY7GFrSQtvLQInmQsT/8M2IIx 8OICwmPzj7H1r01X322qVRpLLi6kx3naiqVLMWcjsiSbCpQQ/+g7setK+BP1hgwGYLXpqy89QYl+ bT9X26YtV5K+bRuC2qrqltv6Y7Wid9hcHKnPDklBEuVenKdSEczM+7dq2dftRsReOIIdXPwwgRVO ci+M/QAqLYpiLw0ywE7RoKosGl6IihAqLczNu4Z2gkp7zlBnmMngVLHwwFDPYg+Qf7FtOMTLKPBi P8ql7GZTU6x42YGZgSg3K/yMLKYeicJDDLDt8Cwfftq2awm6291GbnDZ1P1X8dDW8FeAx8919fha PnB20BlG8T7tG1EEhRZqfEAvzQhxIWxYEUdAnKI1ixEtDOFWjhAHP3ignY44S9HBEYCiy8gvnIXb LNik3V58+maHLw1SKDrphxgWsp6DDeXRjxkMThkipVm1lmdzru/TfqW0JE4EK4ihpMJQLjafUa5k pHm5R2rHg4IEZRWH0FvYYbN8Bio09Bo+fvNVDQ5vLwgCL8/DRGRx5IVwswBUvOwhIQLVqGmIVZgW enCWI4pf+N2B5srbg6r20tiXDtcc/5h3Z7DIIdzeOA7U5k0gJCOmj0iqKJ/mRP9jFrZRCHKCCFBu 39Qo7zpY1rITpdi0m6vPbVP2dUP2ebmtyq7e3MEW72CkrWjpZbJ0CFM0m9yftU4fq/6xquAdPLZT d6DarKR+7qy48UioHzJeclqRtlqM8SGA/B0GYgUT8eNuCx61G7NdAkrY97MAvgCYnWYQUgDeRzCd xcXC0ABuRZPPkZ8AxWy/OpBO18uzAAgyuKJhRtjLIYpTh4DXYSHflT9gmWGMPgnNKUbtVFQuNjIq J5+v3Rh9IrOzL4mSn8VbPKu7txi93kIG+lZ8rMRuUyNHgE8vQaH0YFZt1bGH8DLZeBaE6ZRV8Nw2 bS82lZnrugWh3dRLZF2+WhJrOVQvm86zrIP2H3DD1hXTwf/+fAeJaLd/62hu1Xfivn0kRt7DtYMS IXf+tmkfu/8S4o+6vxc9QjfRUW4AIeR92bvmW+Fry7g/0cd216xog1/12/pzXTavBJTbspIO3j4C h4dlCqt0PsVwdmvBy67f7pb9DrUHcowfKzFMo2y6Vvy1IcZCWF4hbSa1kHisN6v28ZW4VX6s84lG T/GyqW/BN9pKFbbB03r/P9fev1mTuMFdAR93H3fIGg3JPK2Or4w+PkuGJPC9PKLQEJOZWs9xNu8I h/ZpH7Mo9KLZAAEdpCmZv0cavUMCbmXz5obWbJ5y2STmUsTPfoh8Dayedt8MzXLp0ihDyg8ZQ07q LSzaCXZP6VErHgnYW8VqphvGLLSM3TF5xEOstIwds5I1EcREc/O8oI2SwAuplAnUzjFhmtaLx2k9 nSKKQuaXE5FGOUKbkhG6SePpRA+Zhko7A9AwXYUs0WqgDppG1g/olRr5JJlCQsheu7bCiY9c89Rd osJFvbKsB7PIoVQGSYo4HaW+gKYx8drIObd8UARdBZ5PKJudwqUsCtRoII0hBC6IAqZBGm1aXKD2 14zfJZqzoCtAdiBCekKuYspMZt0ZpDEMkR2IElRiLBayNG6rZfUw5iEmcYwqOOTFhdiPFB7nEwtX hvOs64+SApFfNoYQr39ToVtAJ9Gxblcef5SHXpz6UD7zAmSJ8IcLBJ5wY+DB9vBqP34lyedJOdI4 MyUq2FMehqX2m6txnP1M/Fj7eazoZpJ6UYSksO/HIg2QIsiBmLVIc+T0cpRxDa1ZWLTYK/KIknrW u4Z2ghE9ZNEQESfA0ET/jBhoya4zEJk0Mg2vFAdjFxh6Oud2nBAfWn2QIZFFidYnmAA7+uES3qjC ErSwxYpv0SQLy6MJUVQIo3S8E8wK8gtX1W25a/qhpC5u2620oLa74Tg4SPyZfCswoZ1ELvBTNJ+g hlh7lfcan5Qxl2z7457yPJj/WWdqkn3Ms/2ZYo4UWj9sq46aFVRtihXVUAYYcdk1QwNfq4vRNMuH h6aukO6yNfUxyDoEb4IUZWdnfJy3Mr5rd9PK3Fa2cSDC70T3UC3r23pJLtiy2m6GmF5nKJxzKNZ6 gBUqNhIhfV/+BSChbNOKcimzlcqUCJ0vBL2nVCaqeIS3qtyCq1u0+S2r+nO1cj5Vk74ZTdVUNwce frjopBjo+iLvMVukF0WUh/aY095JgHr4/lajXmkNq/LxiyRJvIjKOXAhUcnMshjdSYoED9KQYi/P UDYFSWfyk8TQpCWSmexj6x+28jMNCjT9/7QDmcMQx7B+EBPDOxbP2EOP2zkcqCBEQbkgv3V2zau6 W+66rhoionr9AHAjZYoKOlIyJLK1lZp240MFaC/bhw5kj2SpW7ZDKwj90m/LW1II5Uc4dGvSpWVz 126R+lvbKfuXTeqQe02qKzTJvpGUvaVaxl21qbZlI+529aqkNB8ZRbCqkbOSoRM8TwoaxfW7H97/ /PO7f/747keoLmQskcB0rRBCk/QbTbWpwKDNV65zKOUKRab2kp0L5MG1WnBQOeWqUDI3t+sSu7l9 zfAOstyLgjAUSQg9EEZoQRShn3hpmqRMQzlD0RbI88B1ClNSDvyuoTl2U6MMiixB4gyowCSnUOWV WB6aM2e1QE0dYfcw+sRZ/altkAMn80P7eg/IbXdNZTEXU3Jl0rnvaJ4RpXPVEEazqsHYOmOCu3uZ gq++wKNZ1j0qFixlGtlosH9JqeeQZgBKtfbE1CYWg1qfyua1qLw7y6kKgJ/YR2MtNe6jeQXgDpFC K4DtgUCFOklYECHyi0AC23pL0U4HtmX1YkhRPmQPZtk7i2YJIQeqIQ4iiDXq5Anzj43ewL/RBFxh F0kDL87QGypHngqx9NyQ9IOlM+g6C4RS6C7E5JS1Yhaw4qZsZE2JIwtAEVoWMx822wAoQgdglqP5 xiBIU2wIjd77ZgjN1n+lqUzmlKKOW2FazqEVOYRHYnKiFQ0XZbWLwi9qIjEe+peHeqiy6xqTzLpS g5ZVeOLd/3a9IdlkSjwMeLg5Bm3KPKv4ECnYIarYoDfWwoJW5w5k0TbTZm6MRKoKwZw0FZrtKYQd Qi8d/7OQHqleD8UT5OAPvd8JJUb2LW1LfgMzTCt/3qgQ7fFJjOwgkoOQD+Sm0cSWI/UVIJAwNOS2 bFoITwL6Vr+7oOcU7QR9O7IedBzG0rwSBeZ8g83peWFxpfusxCEWptjKIBxBjfbVedMuN8MnmMDE bJLrQv1ACKDhSN/tqm6IPhhjlgZxxhTTukRzmjBFi6Waw5B9O2bsERD2DrpYWexZfrD6OisLcNjG C9FFRKZojgU4dnSGCBSNQojsEfXLUWfAgFCPB3apXaidlZLb9nJZCgftopUKBW9lb3WCocnJKwLk 0hE8wyFHOADdkgZow8JxHEODbmEaYvg0lw2y6t1FXBga6RY3hgVO6YSLQyPDtUyn0aEoZqjpCUOP HHzZMMc6zGkZTUOJjmmYfEbthVY/Wcy0E3TkIRNAuxPN1CRhKXkNljpwFmaxQ4HhJw7FYJwpzNqz xy/bwmdXbKogrJYRdA69KMMuyrNtxAL32hlnNdBhQQIZmXIIywWl25n1L1vvoPyebEPBmYipdccO 35xL9LkNZXboiZxA3ZsGlDjGibQMmQjICbqkqVhiSBATi4RAb3SmjB4jmquCNx/rolVMZH5eQI6x WYdgyi3iFgsZrahn2Dg9S7eUabKeX/608SQZN568Qw8oEneoBkOwgDWFamz2MahGEmG+gR+e51QR A9UILtD0qYryNEnuRXlEm6JMdGp3A34QHWQ1RQ81UcNORxMNZtAjkMbUuSQ5ZRhAtAvWG4SjsgcU JaoaJ7twSFp7BS+bzSFUkbqPTe+spXQEcCuuUTLbooSi4x93O5XNMiCwjUyAGRxxbunQKqlu4WfI 8mOxM8nuH6sOBSSZN776e9tZjasxYhecYw1FVKDZBhkAbv02JORAdec3PeUX6OtBD5x6c2HRTjDV Iy92L5zh3u/ZVdm8tAy25KmD6JXb4Wj0icF+i25hcNJAlfbS0W7CafKGU2jz6x5EeJBcjlZ7aqqS VQuVq6TqKxIOFPqgKbzrnXeY4ZTm1EZAH1FpRakd5o9DtAfI4uNiAAK7ae1myUYRfGWf94AXiqPK yOFESHT7eTBgHB5Jiu4xQyOQa1peeEmOszYwvupdBPSGBpDLuuARm61AbkXqVm/GLBeZb/vIfqEp OaQtbLkyDGRLe/5wnQ9u0w5OMUT94h1axHEdA00Gnffw27QFQ6sVc8chqmDz1TnaJ2AFQ7HVhkL8 ujAHGg2GEK+hDcrHYRVDQrimSYwgflPRXPlvSYFdLJAtlZIx5Svz7QyoSn30mhfo+7LFklG1F9ZQ w97xEjTrGaURAmcfceYTqxY/tUcf/3ouvkAL0SR7KDWfqL7gfAgKZEbrAsc4O1KKfSMsu4xU+6As r8FfdOyGoYo2BYGcJiPBpQSxF4KRJ/yRrpYtQdqFEFEGsUliioAypFD8FGfQDK2xaUg7QE4t9wPP DbRvkqFZXBGgkpki3LDPzMEzyJLlz2EGk9yhziEpF2CksCmfPjQz4bgNuSivZOeAKlqe6bgN+ms0 0ljiBz6939Z39Ua6nRLxKkzRzUs4ftvJKxWky4C8ZF9SDCA1/tDC5lwoTClif6oInVi/S3fuCA11 yOBKJM0fjAltL1bLogPv1UbQzCGK66ps1mhsLO/uttUdRawfLhnRLJg48xLnSKXS2RjcfQM1u4g0 DS6ToqGXN0Vbr7y6yXrX0E6ICw6x0/LMqWtiv4pjc9SSTVeJvFCfqcIRlbmwANLY4NY4HcKSmXME Iz6HTUNP131sXICg27VwpTOp4kEP6CBEfMSB7JVp87W8Osk4pdIU/4aqyCm3F43iSrrd0HK+uUcA 050o1zltytv56UUtHofQS8oAJ5on4w5sIk/3leTErN4WSp1eS/mlXM+ePnW+oeYgwL62fFZxk7q3 9KkjzpnbUEbzocTuqMNZ82WcNhx8rg69aENPtzQzMo537HmlJn06muYgoeibdQ0oOr4/6MHReJyD HLokpCZya10w8tTHvDZ1Ic3xavO57tB1Yo5/4+aG210j9UBX9zvV1PiIAjxOELtGcWYO73OeAPI2 FnU6m466MNqwZeKEr//TOgoNoirF0tG8nU9yvkWc5/GK7i3rXhG09ZSgLhHdcNBB6mO0Ktmm7Xym c83MQqzru3s+4t/fb9u+xzl6xrpljZ3ZRGONKf25LwKGd+ZChsGiHDP6viWxGy74nBxGn4qBsXnM Au3iOUjjWG2jvHbGt3SoKcHel9u7Ch4eo0D3uQoU5XA+HI2CaBlE5IXcQcA0lGNtWkQ1NdB0jyy9 q2gn+HfTlBhCarTFwCAHySwzmYdngFFCWRq69EcOPsERHayxxneXu0DQi0Vn1DU4u2jSRnxSZYig eSJuTCqu0FULZvBAOfIwFr9dOdFWxxCGV5LDpgvWeQWW43gOYHsOVzpAH2yI1m7i+9zyh8OcmgdQ GkfK7SGlYaVfee3M+uEcF5r+oeZxg7GOI0wNJsRplQgN2xSTqbMsmoQcCJNSdLAn8niLrt6EAJui nSCxh3xaK6E7y87Z3BfrI4fMRTWL7jCiXoM55kIpbqTtNnwNY3TMxLgeVzNR6sIUJVhkFA2tWYSZ oRkuWu8a2umctSIUWx3NwZNhYcmmM+eO25iYhSybpn9UFpVQAMdVBqP5HGNcD4EqxflVoJ7qPLOg 0tZVDe6sdpvNlSRUTWsJ+ODM3nBDkDzzTSdgBr1MJy9L8r6atYpiVS6YjjQ5ji9Q7Z26G0K8fXhA brD+ohWXdezGgcMR+AEuCJXlBYw/sRk/eBHjQJ/4XoS4pzgsighiZapphmZV2EKYhKzIY7gY+l1h 0SBW0uoekUqZuhhcOJzlH89+X6pcMM/c14zaomYeS9X3Hm6n17oew7sytNZNHLNrRo1t1+HgWy8P 5KEnUV5w6zw+zU0Wmw3dyMdgE+DyGgMMOxGTP99DRv7RdTtc+IX4mDpQ0IiCzuDNHS5PvcO17/KA It2ZWyJX1QvEpAir5Kl0FmNzewG8CPS4wuDAhQZwcYNPKgwN7jLTUhxFRfWZbz5Y4AZtTSOz8TJ3 7pBrQf5MblLxI1ZPQ3IZK8qQ7bGUfQJd2+Daexk31MSf1/Jwg15+3f/N6iAwXZ6hj+5NXNaD4qe+ tlqTsFKbhHtbqXFEv7mgxxTN4epNdn+0eortkXpAVwKSnvZVX3o2iGvo5BXuW1mLIvQiXCseGxr8 KosGPRWjVsUrwXOG9vKVHDJ9ch9nUrxDy+Z1tcJVawDo1S/Vdgk/GVdSMzLNiugyqTDIKbjD7aS4 9J46MDUNniLTgEI6I8srWuA1TaMVnagPAdWF/hMzMxfSJnTL937IDm8M1lOm7Q6tEjM6xs84JDTW FRWY0ERfUAaLVfMxMvp0e2ph2nFHKIU6Oo/lttpT54Y+DCjTqAo/zAtStPMToNTdTIZGgDI03B6U kiXXry7IDA0kBacTNs/yjwFrfTMT1jPdMt6vE5F7SDitm5mYmWzJ/5PQtY5azvKBCgTjv4CQjztW z3dVWmES9SOIT69KezA6TOfs9Tl8aYnISg0tXbDTrOWOkcOnG2oLk6YfTVJFFkOuGrer7pawhcsW dxWoq1ZlWy0O4MsjHY91p2+7lJduUrLIOtfhZKZorpnJL+43tJ8B7Kw5aAoTbf0E2GXWX93+Mpwb 5/LMh4um7XDsr/6rQs3ZbVyU+qYawQIJP9Pc46BzadhaGcfC9dP3wMgKBEzP39tHukdhuDWHBGiI +ZzP1JQkRjPdVvJKazoFebsbrlP9OL2N4rWob+X1gV21LpEnw19auqX7IOgSGQiM87maysRorriD jTnrOmRIfZP4GA0KGznS7tKQOC1p0chTkzJqsp8zmLrSpS9f/r9q20L5+kOGBOGF+22ZT1Tco75O eurDReBjdED6dzog0Am0egBKFMgg3MG/qfZ7kJBzpCvscCsSyEPywjWGkMmZMtU6u0DzWVeluYYJ QFbXsUBGce0C/oxJtQLucROXrNry/AJ3rmBMST4qpgTp3HyVHWqtc4shHJuYLjvAvYF+5Msb8PB3 oeCd4NpdQ0P60NAC+sNR8P/gbZt3meYsfkBrg1bXI9tG9rTeQL+spcIjWRoOfJm4gRrqggzK3oqE DM2KhEDzwSdKMet3FxbNiaPHh4JoPVMAjVTBKX0ihxw9zp1YzGRlNBTzkTJQk0AC8tf/B6JGEVkK ZW5kc3RyZWFtCmVuZG9iago1NSAwIG9iago2MzI0CmVuZG9iago1MyAwIG9iago8PCAvVHlwZSAv UGFnZSAvUGFyZW50IDQ1IDAgUiAvUmVzb3VyY2VzIDU2IDAgUiAvQ29udGVudHMgNTQgMCBSIC9N ZWRpYUJveApbMCAwIDU5NSA4NDJdID4+CmVuZG9iago1NiAwIG9iago8PCAvUHJvY1NldCBbIC9Q REYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3MyIDkgMCBSIC9DczEgNyAwIFIgPj4gL0ZvbnQg PDwKL1RUMS4wIDggMCBSIC9UVDIuMCAxMCAwIFIgL1RUMy4wIDExIDAgUiA+PiA+PgplbmRvYmoK NTggMCBvYmoKPDwgL0xlbmd0aCA1OSAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFt CngBzVxLc9tGEr7zV0z5ZFcsGO9H9rDlSM6ut2LLsRnnkMoBIkEJCUjQAChZW/rx+/VgXhBHFCmD W5arTKoFcrp7+t0984X9yr4wL2Wp67IoypgfsqZgv7MVe3XaemzWMpf/a2f0HH970r/MluynKXMd 13UDNp1Nkv6PCYu8xEncyGMnKb54umSvplPPcfHp6YL9wZ57/iv/lRcw/0c/YB9eAP783Qv2J5v+ h72ZEj4Tyzrq2/GVD3zvzQtgE7Hn8xfsxHVC9rx8McEbfP2C/hLoVyafUI82HOKz57l8Iz/TndCH wwm+jb4W31bIN518pn9ksLJ4dsk/bHzm5MWE41bzLwFO1+KJSn6rWkd+qysfVW8cDgFO3Vf5t+4J NBGHFE2CVU+jiTjEnguaJofQ5EkCBE3MpOnFREuFkNPQe5KYYudITifTGVOSFPmZkyRJwE7C0CKm H0gUsN2XBbEWbwhVvPj9C4Nw4TeiGS8L8Yz4YzKQZ5veKCxInsNwsq0mV0Iwum6NNTiDf5RvXm29 6ZRA1VzqIVlKolr6Jsi2YrGx7WL/1barZ9RmKtW4pK+BfqnF1V+kHsw4WlhJ6ZVaaUFy36vg1p7G EfY0ZUlg2h6fbI/H/8H2gEtJljmpF0ZsOYmSRP9aMfoV31HRU/z1ii3IGDmR62Wxm+I9N18EcFNA ekulf8Xn0jT1IQ3hxDBrMFhYOeifxmvKvNgLMyErgTRpzxljq3oOszD9q7dgfIHJ3muyHWvGvgMK 0qxfWoiJr5cuW7ZZzYuG5awtrgvY7qrO5yxfzdmsyNuiZV3N1k09K9oW0Fu2Km7YEr/kl0XrvJhI lL9wdj3GnV2Ycu7EUpINFBmbXhXsOq82BatpY5ZFvgJeV3mH/0i7JBK93d+bb7v2yo8jJww9zrdY qrdGqi0404AOYVCuFnWzzLuyXmmOeJHrZFEKwUtTx8+CjC3hHVMnDrNQwyoTBr+XBSSH4qOTJJUg IZKHiKJgtiGAYQwzkAQxCYON05qTR5D+MAYbEog/X3xLCZpiXTddubrsdUEJVq9se+/pLgmDnjth 5icPkQ9dKFekCF1+URX00hWkCZot+0n5LrniUp5IG6AFCjbgKm9BO8KnL5ui7bjikXDV+K9hkLd1 Xa4g8TXL1+vqlitj1+SLRTlj+QVQXRarbnSN9N1s22iw4+hc4DmhG6Qw2jGWFRKiWfTH+bpYsbdt uyl+ZL9jf67qTQUzVa/aklsw7F11WTdld7XERs4LPD4HT9hNfktsw29aO4PASQLXhSZC0ZMIOgHt zCInCrGygkE7TZgfQXgqJj87oecEjPRzP+nYJaEkHb5vtYH5itWwz9w6g+R5SdbGYexD0Vzl6xbW u+PaQyIDW1nigduuXBZE+X+Lpv6npt0HT93Egw+MoJKh6xHtZGn8yICBdg3DH4PMB+3ys5MkUrAR aQ+s0nZab1YdlGBWL0nI/8HacjUz/KVECgS5oCJOQJDnZU6cJSkQFTDYVQHjz/k+YgZNkAl7grF9 TOf9aNuJQOe1aTEs7uSAeGOXNJn6FEmh0mHHFJIyLxb5puqUdx3gc4iz2UW/BzkKfYgPhNvGBhJZ vbAH8kdigO/HThhEUb/wlh1TVtNYnHjmuzFLwsDxvcAnSYpjJ0rhmBWsmhgwhH0eElFIl/6sgj1d kgy37WcxogZyW1b2aewNGeIsnHy7RQrcEHFQKvZOsFDL0PnpycdivpmRMTqBKZpBPREZstefkZjL sOxAF75LlCIvctzUFzu65SIYXLhed0RJisLYgTmkyAl7sCVJF4iU56zmwcO6mJXwyRoNP/OcOAgM +VmyAJ4jTVJ/omVKwSBnSn6MzyrY/uZ2Fye5q4m3vSyMkvKiL1nZCTomvyrTj0QrgmnNUuhGGjpI gz3oi4RVQ5iXIfcwrSyeI9ikYk/Qje2QFirqpD4qSNiY2OI89DbcV4493fUuHnqh68Q+qOeLb4W0 Ltzz71eIWWDgCI9JX54aJVPyUymFWhmxdf9vffQhqjJkSy0e7lj66CcwzyHMMzivOKFDxVXebZq8 otgHgWA5o0Ce54uLpkZJTRomLwqdNEZ6l/ip46V4s5z4SFPgsCDREgbp1bDEiVM4FMrR1GcVbCjR KFg8Xi/YlugQdYqQa6fJUNQ0Uf18bli3J8ozFpzIuuv9AkXkJrBynuDqljyv6g6lgAK5bwe2aok+ 0L7vClmQlyJFoxzRtq3HS/fjCKG/i+CEL7zlV+5HCrCGATxCQLGzkhNY9dTDt6QIorXsGDAlJ8Zn e5iwht/urrncZBY7aFh11ieSqF1clyjmUJq7admXTc0z0IsCBqsp8tlVMXf+tCUNPoxe4vflDNdJ g9AHvQIGXYFNVDAvGeYMeKwHDTXlEItoxEVhCBVMPJ4v2mjWiv5EXdll+8MIlbUE7Q5IDAS2r79q W6xytb6u8VIzcpxNDjyr/adQehjTU7GgpFKdsnoHqusuJpC4Bar6re0vPNHbBSoUg5S1a+pK1zGQ y6G4WG86qukR2h46SOs+gmSirjE60yKrZjQygmWowOQQ/pZSIoHWvY1kyKmpSAXEX3K/rgpVI+0r Ssi9LA24uairqr6hhZH7z4oG9c8ctdqPb07P37178/7szRn5uguUq/h2zxF5TCmrUth5SAhGyqqM KmJgwVZWqrTAqapnnAaO56LIgHpDkjmZh/qLglUTA0ZVazhBMieiYhqjvi5gTzAeQogN4xGhaJCm AZfgxBK5aPTvG48RsqoogL1M0eKE+igWauNB5leXQo+muIjMLaJGpW0SNNJJWV8UpTbIF1XbiuYa te5rXht9yVD6ZsXXfLmuCvxSNm2npW4cnQhdq04QomwBD/YM/YmL4plqS5AqVEXe8MB7YIL6qplQ 7dHR9KzWRQvSgTq4y/AapR1qUtzfxmHNWBMqK5csRicgihHvIIVLUSOJ0fmSIGRwBsiN0TIzap70 mIA9QQ8HsR91Uw2NJFUM0cO7T8xDZbJD7Nm+vFTLa2WUDgAJPu/SKZN6oB8dkH6vM+jByoU+YirO gW0HcFFAy7jyoQR8ybUTbQB046SC5ksqkb5qKNGZowAxL3jXYsyMMwyt4n0BJGAp+oYY3M4n+Mcq p1qt9FOzbpNX1LDgbQvqsFQVm/He4o3MjhVTR7IYtu4W06agD8rIl4sYZLOqqMFJlCDDuS5rRMRy 4xEQUGuq7wcZLYSRUE2sbNWxkIpOjBBuv6V3CT0pW2RpsgyUTRusQ3JZPipxP7U0DBaW3ZLwQW/n LdJLNDS6EnJSU88HYoKdadhNgfYz9BCBJQqM97L7wmbmUC4MU5ROqbmDtDpMIxZLGIILDQudjIIB 09B5CkaGbj+W71JyznJ7cwf+c9axDRURlUbLlp4ux0G7TjdNg/Qb2lR2iFbbzZI+gk64Jl41Q2Jk 81kCA0vEixKkghHxBixMEIoBhqCTOkMTek7ARiTe3t0hpRtEPLT7vAMLP74oLzewfJQn3PCGf83m CHRlvRWftVKOPneELqsZZ7oCBipl7Blh/zOEowbhGjQi3ZaKMfSsL5xbKueQ7zmS9LYtqQ0tfPny opjDqqPwYpk1kPvGosx3MuTFRLns3ikYyDRhIVojQ9J9aAiHjUi7rSjLQAX1bLm9Rcny/JePpNAo N6hYV1OUQoUDalGiy4IMALyMBAhFOAFiEQrRWYBqjN5KE7Y/PY/aTJXr6/wsdBLDNkvMMWUEiXMx cIbCEMo8QYK+pILB0ChYDCl0Ucs0cdcw4E4dMRSWDh5GeswaoXIhLLEOd1BSMYg5MMbZxb0gc3wX 1TE4HqxrifJed11TXmwQwXzmsz4f8rJhiyq/ZM0G3lnr+TimOLYXA6CYh/78cCJ/fhgdSZUdanE7 FL3++TvymJybd6MjiXaOJWh/Ap53fKfpg6MjCQc3EpJ8u/v/xuZkYk8hbZyk7US0XfDW6/YDdwS6 e/fbp+n4nAzsnNT6+z7H3An9nGKskbGzYlGu4LqEXk9v1/1fBX7s/fkRkLRnK1pVpco++nrM7ban KXdwiT8X1MIqTj5jg1FgYdOfzjzGvjpfOV+NNtCYMbru9ScWzH6Dz77EPsahdtMe+bgMbeSQIoso 5sGmmzlRApctYehuYJ5Lw/wIhQc4b/OzAkaOekyfg6IhypWUV4Mii88hbipqjuFmMffioH1ILWLN U+1t/9XUm3Wfqxujv+OMG4eotqYYSd5JPOjvTQX7fAyja09uvzMtzKz2jLSQAlPzB1roG1oodk89 cUROppakGet+X5xM7dmtUjBxkGHvYd6d4aQeFsWyW6p9N0Vt51OHsrRYnVq2cuYTuSFOGGGKaInO pZO6FI8qWDWE+S7mO3RZgD9HsG8aYLGWSCgyTu0psubgEzOBfTmJKfU+ktMmivTgE80ko5538n6D PLTRYc+BtnpXQuIhK4+Rmj/EBeheYOieZon2gHv1kXeyQntA7MSWUJFMGesK/zUJMWHqpRnPUdPY 8TDlDjERMPg5BQtBIc6JDHyfholE75Cy9i5+BjSRFWHs7EGpgv3Q1BxDsLT31dzUgrUVT0BFR5Qn o035gFaBftNiq9rDfvnlLjniqmwbdf3uLLa9PKPFYkzlMiy2ZfDwDlk/n1rHGGlZG3V2bbZpdhDz 8TDbKHNh7gB1LtSrelhlwkInjlH41GZ7gsaShD0hxhzomaVtlZqjWvByfFTr2NplsFMtr7WLzLbk KE3mDlg6opqZZtsyiUeJS2iYban0KHfxn2MqoKVUhzW/r5ApU3M8gwLPsRUQy255t7uPvM9F6Tkt 3/cOtfJ5mL/wcdIRMVOMkfcAA/GhhCFmMmGeT4XYwUcBOk7ElKka5gMMPIZj06qH5a0RU8/LE85M 1dwcU+10x/gBDvCaQWSo3psVukXUIUYlhn7sqvfNnT7yfWhBgCsTHNwfbMp3pnr2AvDRVQ+3JNyv lkL1xCEKsbqZrQQZ0oXUG2QrCmZkK0GKGguSGVP1JOxIumevTmsOHln31NzW0O0NmNmbsTE1T584 yOz09+q183+he6SFilsjzJVx3bNX47GieUCHYwffnBoGYpdvVjZsv+B4EDDdG3YBkglOXtqq8d+V gUjQcLMhqTaMspWntOV2ZQ56ToKWt7oWURpupYBhF2PLLqLeyX9MMz/2LqpOgFZArPmd7aIqZQ+Q fN1iUKqdoePIm+q8FX1WonFBB01pvoBuPejqGWaW//j482mcBMGffOKXvTu5wLGosVmpKqUDLOWp XhqyzNklhi770RdMSDRFVVzn4kQ4hqpo8BcHXXAQj88P0AT/6EiqSukASTqWSyMLNzh5jfEuftDG RIcDcGK32oDjnNHU7B8bOU8VHwfITTFdovZVjXRhOo2PowORln369/lvv5xhzgYHxVsaouYnXIga QnZ0PFWJb4Anlyo2o7lVCCQfjOPzQIKpxdcSA1EYy1W0GBymuwJGR1MNrQzQzK/rcg79mP19kzd0 +H65hsxdlBWOm2NuB2fzW4wpnYNvzU3ZYiKYU9IUnBYIB64PqW5Hx1VVMQa44iAE7ztaWdbr8tn5 KSkSD4pNWbjKMd58jM1XKfIA037zoezHGb0gj+tbMr6ItkpeKnAqVAK3LCBJGFxlMo7P99U1RTop QPHGhsMbcdsFbh6SZ/X2w2GXa+VcUCGjxgEei4zElm1o62rDzekM84Zi9J0umoB60jkRcbgFd0vA 4nb1emyh9u1xHI6lYOm8gQ9q8uZW24NV0d3Uzd9gp5Ua69zYfkx9LJjDGXFbnAQfVXydXeWrS3CM uNsfkH52dv72lGYX61nJ5ewZmNvd0LEzEHCkIyvqsBYu/dhGlhzYZsW950pLHOTVSUJUPHxcSOfT US9jkFLCqLctBylxEhhXQCFRA0x/VsGeUHcU4mwMyeuD6ETJViK5o6A/QnqBvj0yUbpMymCjNmQG G3ERktLcA3Ovx1Q4UGHxQIXlsSNyP6QA6veXbIWoDhOzMOfs2WDQ9BmPlAAfW3cDFRgPcMTq5iVH z2iUlQ7V8qFmcX5r/ldOlyhovV4X0Bw6edCCktrovY2kvPZBGTCF7vqC5vZ4EfPA0pOuPsGLxo4j hnFORKfd7RoqVLFnMxw4XOHew5FD5EAF8gOm0nGkogEvi3VV39L9MDwQZUsc4itxKAnIIaTHnDSs jREK4pYKPCnRHx1XFc4PcBWG7iEbLWWWn+0jjpNBVNELx3V0RFVIP0CUh+z9QRISAGnHt52k4VaU GT9G6oFrmWw+hg9Hg53/rm+4fksO9scj55TM4bgmpJgOFIibOYig3BCXsc/m4vqObReDICMfbiXD cVgSTuCNi+wM6aVUqqpJk5Cl8Pl37iZHT5hCFeEPtn4KudPHTaE1l02+xM1oVbVpEXLwmxT4UaRZ seanZJWAylBybBkNVXg/QPQNzNEHuhONgrE5u+pF4JbNy8UCJpOueuAygQPuqzklKyqPB7d5ZjA6 oiq6HyDa28OXSCvJUnFke+ujOMdVW1gFzXvILBmBv2GJx8/vcMuCTaG4na/4XXL8Njz6XcoArg8d NxrH1THbEQymRjEyKisxPe8o4JbZHDRGbeToOoErjG1c+WRgJHfxIYw0j8ZopeCKNuLRVivltYER Fybc1bNiBWoWJGE8p0Vi0lAR6+stWyJ8eDlkopb9X/8Hd+lMwwplbmRzdHJlYW0KZW5kb2JqCjU5 IDAgb2JqCjQ5OTUKZW5kb2JqCjU3IDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgNDUgMCBS IC9SZXNvdXJjZXMgNjAgMCBSIC9Db250ZW50cyA1OCAwIFIgL01lZGlhQm94ClswIDAgNTk1IDg0 Ml0gPj4KZW5kb2JqCjYwIDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNw YWNlIDw8IC9DczIgOSAwIFIgL0NzMSA3IDAgUiA+PiAvRm9udCA8PAovVFQxLjAgOCAwIFIgL1RU Mi4wIDEwIDAgUiAvVFQzLjAgMTEgMCBSID4+ID4+CmVuZG9iago2MiAwIG9iago8PCAvTGVuZ3Ro IDYzIDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAHNWt9v2zYQftdfcY8JNjv6 /SNvXdoCHTC0Ww3sYdiDYsuJBllKLaXpsPR/33cUSckylSYds9YGbImmxePH4913x/tAv9IH8lJK XZeiKCM/pH1Bv1NNZxetR+uWXPFu19xPXC76r/WOflqRu3RdN6DV2kn6HxOKvGSZuJFHixQPXu3o bLXyli7+vdrSH3Ti+Wf+mReQf+4H9O4U7Se/nNKftPqZXq1YHscwjn46Hjnz3LtTSBPRyeaUFu4y pJPy1MEFHr/lX4Lhm1QP3XUvWnw6ydWF+k+34D+HDp7Gj8XTCnXRqT59l4ORZd+d+PPoP4tTR8jW iIdApo+yR6WeqsdRT3VVV32xFC2Qqfukfuu+Yk6MkJ6ThOrr5sQI0Ymck/OUOXlqAnJONJ7TqTNo hdTT0PsqNcXKsZ46qzVpTYr8bJkkSUCLMDSo6TtWBSz3VcHQ4oJFxVfQfxGUC3c8Z3xtZR+/v00O 9Nm0b7QUrM9h6Bxvk2upGF13g4cKgM/VxdnRRacVqhFaD83SGtXyk6DbGuLRssv118uu++jF1Fvj ih+D/aUH17+ofbAWYmEkva/0SFvW+34LHq1pHGFNU0qCse3x2fZ44g3bA5SSLFumXhjRzomSZLit iG/xjIp7ie9r2o7NFqR23TSLe0sGKNUt+mcxrFWUps7InMFQYcRAGruAUvKS2IuljvjKlJ2QeP3x 2+uLOAmCPwHd6i+YMIdVdRiERzWPSV8aM4ylXhyM+fLVO6KXZb4rumJPbz8W+6rJN/Sq3izeNWXd Ud7SptiWdbGhsqbuusR9s77dFXW3JHrDTcWpI2QV5t+KrLFnkhUIbZuqau7K+oq25dXtvmgpJ57C Lv+bMIFdWeddQd1dQ5tyuy32kJJevn1zYV3CxIgmJMzbtlmXeVc2dUuXBYuawwveNHsGOK83uMnX XYPrjrGjFthTV+6KpW0hE9copF7t90XbQkyiF4MGtLLtcNlHaml5qZPALCPWjF4MUAoZuW0ELxWf yrZjkLu7ooAiYtXV3KxDGc1p5PGWabEv3tYFNVuxvgW20g1vpZawd3jFG7nLrAsZG7GEUh7onxAB H/upPEozhe1xevpkxfYkmVGw12ILk09lVd223R5btwdo17QdXeZtuaZ1U4udLjYU3UHqAvtpXZW8 s8vWNoSpZ1xnSFEX6w42cFPucVHB2jSQoy32WEtlB7G867wtfuy3tdpI9ca6kL4RzvHWyAHTZdNd D5sDeidRYxskBWcnY3Oh08go2Q8Lfv0gPJz8kE3Syz3ac3zJs6YJ/K0IEg683D3RBRE+hxdu3qPJ +tqk3xiBzJ1BgN3kBAHRZBuBzJtDAGs+1QFusq0DWWBEAEt/MP1eFawrQGbmWXOj9yzPmv6DgZr0 n0f/R/lGkn7/s/25z7IiI/K25549MPcJn7A+d6Q8jGr//6x76gZzEUWv5sOncrrn9JNwsMyOwfBv quZv5vSWrUHqmjkJ4gYpSMDeEt4KzjOvKb9iv95dgxujoW46usn3Xbkub0AAQKW1+y1r65KmRtfP bKn4tL7Oa8TuoHSKvElOxWTvBUchiEVuq673/QLTkTu2LqqZTwGxtgOXmnP6PJWR41cJMgsRW+r5 rH8OknMHfnfe8Q8KSfQ8XADhvdEewBQZuMCLiXdAr2egB6n3FIJk8JdMo7S/dKxkBlIvMSr+vQis p4b7+L4nEcqW25JplkZNQTEYWO7yDDj5rhEngwAzTXrhHpnS+QLZTf3ZNNJ0leYEshvMp34wi5CI AMTHMQ/Rv91bRyicc4vfCqHZzNa9RmHxj/Afo+zHZ/2bfYSS7wyhYJZHQYk1aTgXWb0Rb6G7EtFu jWzWIWEQhMK2/w3MSSvJaMKjfAZnBWTugn2wjMM3DdIdTHHa2xtOD1qX0pyz0mGAYjLG9MWUwjAd 04k26xnfNDDTxJ4OcsJixF2IVgCx/wm0bFPJrNG+qXTSTeVYt83eOqxmnqjQVLyQwGQLTmlt6BLZ IiP1elRy7UteIPSMNAceEK9pvD3TZBuj0JyhgtF9AvWyTCnC0OicJFlg46Je89Bp/2SJ5oRmOghB pv7JwMZkk3WZzHTQIJMZOm61LpOZDhpkmmnSAlmiXpE5yzYzOponL9uplzQyZ90w7AGxUAd9KgUk jAR/WCcW0ZOycBN4WGzbNil6UmLumIPZR2g+V2eAw9BkHaHMaCEVrZnnXAvBFkbHC+K+qPPLCu7v WShY7BtlHfJK0Siv1JPFUUJmTGUUHZMswzaosZkrDsyGT5FwvrR5WMih/5hKWI7fYjNj5MPMWzBY QWP3xYfbcs+5OFELcHg+B5KIIzpREyAJmvUjujQ2U0VObInDdk7GDea+r/4SBWePyXM9RLa8wF+m PurTPJbhKM3+/vWrs/ev3/wix0bhRhouURaEIN2PUW0So5pkR54XLZPM9Yc2VJqM24I4ilF9cvBf bnMq+opKFFkVMqo/8bJo6Qdu1M/iuMxigA61Jihu8VDqkqLqxAqEQG/pBl5yACGaUJmDcr4TQHgw vPOEYR+qf/H9eBkG0eycESWIw9yOE7x9hrRVBTi2jmbSODvWGRj1ebI5tviyl23jlJiPu78pT0/M scPTcLIcOyTm2GGelI/X7pl4emKOHZh+H8d9M016t1mKZ5JHxw4AaBricJMWyBJPT1LjppsZfbxq /bV1FprOJ5E1F0cC8P/j6en3lkRO55PIBlJuaLKtQ+n3lkROZ4/Ze6WVhD06R2HfcLKriqdwPlg3 G+TMZNrxOeoj08ycxZWSxQcZ0vxYyLZBTWQfT4zklJvCthPMzKGETuiB4nbILYraTSHYpuG07SRt KlJ8PUvfoZjNupDmMEKvoTIYR1Izt+GQgVPjsjfT5B5cnoN9Uc1RxK68ukY5cdUCvQJhIQrorvOP XM13lGsWufwhzvmRi5Db6+bO+pl/Zo4luCABJ/ksIKeXhzN/RRS56o+2+X7HSnEGhPmHXV7nV4zt b0Ve7awrwMNpZ9t0FWVk/z2tPPankr9ZhgWRlLHs5p4uvAnDQJN/1AQLechDQEqe4dw/c80EUoIy wclA1sANTKl862iaOaWB50LkKX8z9FLUV+cpfv0XlkTgUQplbmRzdHJlYW0KZW5kb2JqCjYzIDAg b2JqCjIzMzIKZW5kb2JqCjYxIDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgNDUgMCBSIC9S ZXNvdXJjZXMgNjQgMCBSIC9Db250ZW50cyA2MiAwIFIgL01lZGlhQm94ClswIDAgNTk1IDg0Ml0g Pj4KZW5kb2JqCjY0IDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNl IDw8IC9DczIgOSAwIFIgL0NzMSA3IDAgUiA+PiAvRm9udCA8PAovVFQxLjAgOCAwIFIgL1RUMi4w IDEwIDAgUiAvVFQzLjAgMTEgMCBSID4+ID4+CmVuZG9iago2NiAwIG9iago8PCAvTGVuZ3RoIDY3 IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAHNXFlz20YSfuevmPLLSrUmjPvw m1e2q7y1jpyYm9RWkgeIBCXEIMAQkGVVvP99vx7MRXJIUfZkY/og2BwAPT19fN3T4O/se/Y7C3KW +z5LkoKFMdtU7CfWsmcXfcDmPfP5n35O4/jhdHybr9g/Zsz3fN+P2Gw+ycYvM5YEmZf5ScCmOS48 W7Fns1ng+Th7tmQ/s7MgfBY+CyIWPg8j9u4c9LO35+xXNvsnezUjfiaW+6ir45IHrnt3Dm4SdrY4 Z1Pfi9lZfT7BAS6/pG8i/c7kCDV0wykhOyvlgTxnmNLJ8QRXo8viapU8GOSYccjWncXYFT/ZOGd6 PuG8dfwi4OmjGNHIq6r7yKv6cqg68DgFPA2f5HfDF8yJJKTmJET1ZXMiCbEzMafJY+YUyAmIOTFz TucTrRVCT+Pgi9QUK0d6OpnNmdKkJCy8LMsiNo1ji5q+I1XAcl9XJFocEKt4i8c3BuXCJ5oz3pZi TDh+zLb02WY3igvS5zie7JvJjVCMYVjjolzAz+XBs72DQSlUx7UemqU0qqcrQbeViI1lF+uvll2N UYupTOOaLgP7UjdX30g7mHO2cCdlV+pOS9L70QT31jRNsKY5yyLT94TkewL+B74HUsqKwsuDOGGr SZJl+mPD6COu0dAo/n7DlqbbAte+nxfp6MkgSvkR4wM/SkKYt+HN4Kdww0j4uohhUOHn8HHck4XS k50xxv4+ndJfHJmvz+YHHFtGCdL5ZPabcHok24e4ZA9xWeRCkba4BAu7LJ1OcsxiEMAI9wV5Oj8Y ufP67JrF8KAUp/uvP17W5aoaqg17X/V93bX/3R8zdc5i/O1LMTkoxZ31w8fPUmZHpelcitm3L8X8 oBSlyKZ/vLx8c8Fe9H03r8thWwM/73/pWoohhdVv26LD6ACLr+vrW8Dd9Dl7wRbVuunuV1U7sLt6 uGFcqmW7YG3XTvmH/na97jZD3V6zeVNjYO/Y84SplU/BZcbqprnth005VD0rtxi+qTCNvltVrLwm xpjglUnv5JrTzKqX3cdq03Tlgs27dth0DSP5dQO469migyQH4ItHhbyHAnPkyxRjK+QhvuK1FZgf RXIsrii0Liyi8sVObAbpxUmk9xjlmsvIuqh2wRGCMR25fRQtgmsukwOyfPnq3R7O2cU9n9neKEFy zWV6SJa7gqPwZwoSxzRkX7xEcs1lbpWlhaXTSa5Z/PYxbXwY03I3tP3fUYgjh7o27fgwpt3Rvb9s oeNvH9PGhzGtXLi/Go3F3z6mTQ4CRgl0Hg3HRtDj2PMkFtSYeKHH2Lv6+vr+qpx/ICj4blO383rd oCzoFNkkqbXkMLup2B7M6rvmlpA/MOGybqsFe/HjO0BEYELkpMCDddk0967FY4eAaykbcAGGhm7N uiWrPtU9B87let3Uc56msBWYw8rhy/lN2V5XPUQ7u6ldo+qksAa5umerclGxdYe0/aqp2NU9KxcL WtI9+dIsmupj1XDBPmVAtOzyArXcR634Q+Wb1Ldihst//UC35Vha3Ph1VQ5IXKY/VvOh2/Bv63bo tJjn3WoF7N2zX84G9xJN7XD2poTOtazs+9vVmqvjcFMOXFjmsl9cvGbQx+4Oo0d5t9UdF6xredrx LJcUCVLmRlIRe9fJSZpak5M3kBGblz0Meckw9+Ze2a1iyRBY/5TVA4O6/vDq4vLt21ffvXz10rWk 7DgQGoUV4oonHctNd7dvHquKDLjuVz276zYfem74WHrXXNqhoCEqj932ZMCwzR0ToUQUVGFLPatp DSizd8xjZseCZIwlTPUePqdtUSzEckIPq3bB3SQ0wOYhoZBuPUxmx1jfdUMFMxW2uuf9dHTpUHhA Es9uyo8VW9afwHxfbZD0u+bTDrRoEcfKC0NxQcQLxI92se4gTU4kyS6oHrvigfAKZjYGIhg8hULX nNrxlgxtw/26es7ubir4mw33hPIbsFliq/X326of4KVrr/I4fzwMuWbSXkV8sqnKOY/Kbbeonvxy zhBLyIG3/R241UwtOFMM42X9S5zgWj9zOzScUXlr2W0qeEKyW0gVGKJhT0ZlmI46+MSoiI0hWnz/ hL198R/HIsXWtq3qOUoI/ho+0KiFLeoxHHZcBZ5IfjElCPv+z7Gh3AJfkdzVLXhBBXEho56CX0Bf L1p8KlcAsxSa+tv5DZkTxco/xczz+IAQuVWQIycTmZa34AAgVsDG5aZb4Ytx7XXInvzuYgstzyhk T9CyoOuJiRdBNhfluryqm3q4h5ja7radV1Qsdoz6sdNo22h8jxyDXPQx7L+pUJQWsRewVuJwiNGx 7hd2+LeWiRAjvd7iVTsOcuFbX4lKsWsW7dBPRQpKjZr6Q4XAS/GsXPxWzrGYbF2hVP0Uoa0dE4Fb bAYYzpuXsl2zaq9nKlZFJX80Q9Op8AI7JH1HgVuYKeF+yro25XJZz11zaq9plldwJ3zfpGyuuw32 TlZI+xjBsnulCoIjnuFhk2K93nQlvIuAla4ZtcNZxA5Khli/ruY1xDNmoVJZIfDp0E3xBmyuTF0f uubxAJg1XAt8n2nRMk0m10wmtA9yr6rhrqpap5yGvm+HtMSCVNIxcwckHPNSBDXtILEtJYoTZdN3 IkGAUTln017inJebTU0QEKYMy7DDbMZeC5e1lY65FqQdfRv5C1/XtrruKERTPWcOOHZVsRWwD0Xm +cBMQOuavwOo2yjZbJmONGax2JQLQMZLbT4Ujt7++/3MNZ92zP3d5YyNhSS2uEUsuubSbOolAmeN nVFhNirF7sd+DeDczm3+ApOxA244wbYnyI2V5UBWFQGQiEp2ViVSGfzj8EeLvv/l3C3aDv3AgmEJ 6wRY2B9EZvJW1OjejLARVvJKZlsXXdvXiwrb0ZiP26IdeLNDwxmcDiygnjONNnjoE7mrTKhUljWy TbKUvsqxMgb2PXuRPJGT3E+zpHtEDcDYqpeBSMZ414za67Vyp17VcCjXA9psbjkC4jGzUomqlOtO /HHNqr1ia1Q7eYfGcNOhhqYB+Ng2zDuVT2imO9ZZgJ4Wz4+CjEERi/0yvAYFbNmU1+yKLyOcH9VQ tCyCoPDSAglFGFHrYpixFQ5x5SBHo7WkNdu0CFZJrYzi3AmNE7THtzWKirPRzBij6TVM83Sc2X4K q6WJbkl0JAZom8zRCulCqnGUeX5aQB6GVCEONHmiM/xMSRVhg9iY8G5wo/38hEU9VmJPIt9Lc/Sl 89vvTx1FVoW1KU2BX7lDxw0PJB0Ki243eEI/tKd6oxvAza2BiqC9PYaM5UwRRbQSOsiKwao94+sH IH9UNHXA0urjzhiDLPDyMCVjBB972bEBnyhGMvbGKK9rOQR+DOVDt3cYxl6Wo98YxhhEXpxjGRQN xmjSwjwuyBjFuRMaJ2hkjG5ka09VH4IDHNwcDnd64iEKGX5GvgzPZYQZHvDAxLPCKzArTcPENS1F X3xADdXy3EkYKJq7iT+Q+C5ktbmtgN+RUaKDjOKO8hPYrzPzDA6S4YGNxELyD9VBrz8eb8HUi8BL owh6IEiYpUkKkzzYmjmGCZq7mdsT6Q41Hm1ABu+hF8YJGt9ZjFiQ+gnWzRe0RtEmcGteFsepwT3G Kdrjo4eIkEb0SEMP4YCil48gsmeKRizejR5fX53L8AhE4AcUuXBv4b519DDdwFNkIhX6sUekTYAW z2XIrdrHBZRjKCEKaBGK5JA0yJPr+wYTuvOpcfRYIIsSTIg/rGVIQpcryUYo6zGSHoOLIvKKGFBE aRBMIs29IM9SaJDSKknDOKVBgELyXEVzoVUxnuyICRX833Uq8eESgczGe+/pFPco2Ewq64bqqlqK 7nSIT9v+cImK//q+7nQIluSlQcJnbqmWieizE03HDVNlSVCbvMjxxE1QIKRGYQAPFWSxF/txMlE0 hE9B4+NCWA081Na5gnayfz1mlFygwJiWlvSHQirts1viJkzDCwNAZj07PGkkaObscsTIAM8iGXET p0na4y1lH72bHsdWP9Sasut/T8MqxwQbhXiGLiGw5IdKvtr/CuEKCGbI8XG2cszvGbkLOLAA+K0W CZ6M2VCSFtJJ+O2YTEgYEeKjRdnEPptZeRBpNYpix2AMwDQaebB56LZhC4zaC6QSQ26q63KzwK46 VSWww9/j34LKLIhiMu2XJWjKjPCIBE3juv5YaaM5SaLH1phL1F4n3VQr6lOQdRy98/f1us3vitzA so5aW3RGg0cZv+pZvSiAj4yAM7Eollrmz5frqn2DLiq0DvxUoUNohL/Yu2g/sPKKKtm7MZ76icSe BWXPqmsE1YYs8gH0A0DHNAk4+IfvysIk0zQ4LJMWJD6Bf3nuhM4VtJNd9INrbK+QLqp5U44VRYo9 w996aGB3VV6NG3V6MRQ6DuLQC5BCwTknsZenKc2VkzAFg0SoPzORPYYpmumbvx6pkjbFqOLs7iNj 911P4E9w0FqrxrvTg/faQV9uZRe+MzRq5AS47b5XJlXV09ZGdMpu/THfayAYPV2Ngns8lYlWRL4B WSIf4M9mQqdgUNS9pE1EI5Ew8wK8KM4XiHURgI0kQZUUKQVw8k0MMwlCRXNmILG9fWP0yR2aVrGb psWqzQF1w6QACFmxPPbwiDsSJqolEm3SbNP8AjmcBit8nKCZBvEo92oki0EUom6DH4eANSDf3vOt mvtdW/h6Ewxi1PpQtBjvvQfsZQzZYuER2dkxvcSMZe3YOm3eZ6duTGb4BWXWY+4VKamXRwUVCbQS aT+gGoAUD/xJ99NT02OTN0DigclvOQNnTihKCoBT+HdzztoZyH3pj2O/NEVUgLCOXXfAZApuqcQm KDIvx2MK2nJWLEJQiSNUz6Q1UYQ0acJyts61WNPX63Ya0++r4Icw7HOVezV6eU8FZRP5ey77v4CA WyFD3zNhM6C58+wGPLLdlbo4eUNiixYIpKQLdE7y/Xtq3qFV5e+0tYpOHt7wIXbR0ZjOH5GuFtr7 S5CDZYW65HEIxxkWiZfEfqFpVCNUtMBL0Fu3BZACRXPn/+37ihx3Y8+uFcUtWeh5yq4AC2sCTLxq gUYgdPF94uGP2pxVh9PlhZ68jhoocCcZcjtz8pJmTp4XwguqictzJ2NxnNPcTd6+Vym2Z7xftW5L NhhMFg4AMXulawuShsCnonyRekmS4mdE9BSYQTt5Cse8IAFAypQt9kIojKN3GYLwgdq3VFcmwSWZ ksm0a1PNK6RZBq5X086htZEf863FDMcF9rcUDVNUNGgodHirOJFr2uPjvYhARrw3immY/D4Q1Iv2 ZTHvmMSTIIH1hlSK1YLXMe+wIMHKI+L+sbCbYqO28EOx9vvTx76ECjCnemT1C1sB/XKRIWt+F8tm GFIM0b0tp8y7ZUel2kqf+UMl5BipWR59RXKc9g7f/w9/MJohCmVuZHN0cmVhbQplbmRvYmoKNjcg MCBvYmoKNDA0NwplbmRvYmoKNjUgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCA0NSAwIFIg L1Jlc291cmNlcyA2OCAwIFIgL0NvbnRlbnRzIDY2IDAgUiAvTWVkaWFCb3gKWzAgMCA1OTUgODQy XSA+PgplbmRvYmoKNjggMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3Bh Y2UgPDwgL0NzMiA5IDAgUiAvQ3MxIDcgMCBSID4+IC9Gb250IDw8Ci9UVDEuMCA4IDAgUiAvVFQy LjAgMTAgMCBSIC9UVDMuMCAxMSAwIFIgPj4gPj4KZW5kb2JqCjcwIDAgb2JqCjw8IC9MZW5ndGgg NzEgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4Ab1cW3PbRrJ+x6+Y2iepSoIx g3teTjm2s+utdeRY2qROxXmASEhCAhIyAFrWv9+vB3MDCVGUDKVSu5JbAKenp69f9/AL+4V9YTxj WRCwOM6ZiFhbst/Ymr1603G26Fgg/+sW9Jz89XT4sVixHy9Y4AdBELKLhZcOf0xZzFM/DWLOTjN8 8MWKvbq44H6Aty+u2O/siItX4hUPmfhBhOzjMehHH47ZH+zi3+zdBfHjTaxjPh0f+cDn3h2Dm5gd LY/ZaeBH7Kg69vALPv6K/hLan0w/YR5tJUWwo0L/ot/pT+nlyMOn0cfi00r9S6+fGR4ZrayeXcmX nXdOjz3JWyM/BDx9VU/U+lPNOvpTA/2o+cWXFPDUf9N/65+xJ5KQ2ZMS1fP2RBJiR2pP3lP2xPUG 1J6Yu6djz2qF0tOIP0tNcXKkp97FghlNikXup2kastMomlDTj6QKOO7rkkSLX4hV/IiHHwzKhX/R nvHjSj0jhn+mI32eshvDBelzFHm7ZnKjFKPvb/GhUsA/6F9e7fzSG4VqpNZDs4xGdfRJ0G0jYufY 1fmbYzfPmMM0pnFNHwP7Moubv2g7WEi2sJKxK7PSFen9YII7Z5rEONOMpaHrewT5Hi7/g++BlNI8 9zMexWzlxWlq/1kz+ic+o6an5M8bduW6LXAdBFmeDJ4MotT/xPOcB1nqC+E57gyOCiuGytmFLGMi iONA6YjQruyIMfjKRVl9LZesWHd3ZctWZdcV0Ji7m7K/wb/xf3hm1fQlK9fL26Za96zb3N42bd/R H4+9iz+V1yPhPsome4zNJFaqNGKz+Vq2dVMs2aJZ921Ts66pN33VrMH3klX4wRZFV7KqZ8um7E7A f9Gzq7LoN23ZsaKdn9EsmGJUyaZc+oxdQHbq3+yqGWT58Eaqjl1iC0vWrGcXaj4pVDrbW4inXC9K 1lzJsz57c/rTILXTX8tFD65f//qRBEwPv62KVdlDK5SyYFNzs5rwSbGW36qur9bXrLi9ratFQUcP Cf+kpLou7+p7tiyvqjWpsn1G6qg+hNl5FZNiffCoP7z+f1bUbVks79klRF+0vRa7w/LsXEaTEu1u y0V1ZUX5o9I92NFtcVnVVX/P/lo3d3W5hDug02/LL5uy67WLmJ3PeFKa1brqK5w3zt44oEWxZl1Z Qz8lY9Dhq7JtcfKLZrWCT+jb4gpbY8Vl0Zerct3Pzms6KdOivm7aqr9ZSa9UgL1isWjaJZiHemq9 6DaXHYkSnlR72/Lb4qZYX5edPzenabDLaeyHvoD1vB5c/gfl8t9bSb/Trv5Ns+6qZdlKg+tmZy7c ZQ4x6bebkhz6dtj5fFT5pY8//KMtKf6QSqybZfmPz8c6jMHTazWdnddoUj31CcJDklYu4R5x7OPo OTIb+NIdhZ6d12RSrjdFp12hUcaH45EORtrEZJiYndN0Uqr7gtHBbn92XvNJqT4sQR37STH+Pn+f BZMifdDfk2unrIr80T65kx7MLdJMTIp0K9Io6x6FAApN3ZDlbR/A7EyGkwK92qwXlIYUMlSSFBv8 X2ujlEmTKUXFn+DTxhFhdkbjSWlOxJ1xst9R2qzcEkIQQyl48acnoYwByJDYyfdm95HgfpSgWhVB NsHoe7DQsU/v3px9+PDu57fv3hITQ2UhUOdyjnomiWI/DjNUUEzk+DUKckPz6jEtCNMEFdXoXUWj 6urLQdXKY0VVhmptKHxH1UpPxQeZi7MFlO8pT70kzPxAAFtagXM/z3kQMUOrXVrqxyIScgvDu3jO 0LAFz8G1vvds8hCVaZgndDaTBZjdCVZFmcdRjGaoLw/WjH2S5EHuRxyilKsrgYamSr1wBYnlsfGD l91XbvJQ+HBAUiGnNj02EiuBmVQnm6zHJ7IDADXaEmY0Rw7UIBK5IKFPlLJDet2hGKXoQFm1FQBs 0c8yEUMhoQucJ1Bmnglf8Bz4haLBHke0gAcpIRzuu4o2oz3m0/a4XQ+gDNOZevkVjrkCuqNlLGDK ZKoswW95ngnaXQr4Kk/gbTQNO3FpUQ7HRt5Gmzl+U7RnYDlKax0EJwwiP4rAC05rqpi3h/MC9hly nG0E0crFd+xTlrXrdYN4WDKkmKtifa/zTKrJdD1ZERDj1BAz+q8k5T70C+j/tHgQ36yEnmhE+zxX Ggg/pE4ALbsTCe6aTb3UkmCrTd1Xt3XplHhhAgA3A3Jo1GrFojj3k4QLS6vHNKVW+l2P3v1uVZPo Mid02VE6gg0RoHb2hRLNSvNF9M2PgjDjo+VtPKAy5vMRwiuq7EHrIORSpg8FpH35p8QFGlY3i6Jm tw3wonsqyK2JH+bB98UOKRoD/1jeIBrk0lfV9WYomT8fI536V3MHL9OeMGQFdVkAQiGvqnJtuwfX UGbn1YBAI14//Pf8gkoTEmYHbI/M1yDCCvTbSsaBr+vkcEYDlvKcBlUQ/jXeaIvtnRKaya38fHaB RHZRb5b0zj3TpcHs4swmS4IdcFojksBQkWSv+waZNpzgCGrHHwboVQl6Zl452kZTQPU+WZKFrRuq CZYEEMKJ61JW5bUmWM5iSTzgk+K8LK+r9ZrKPmUrpKYL4KeSI6BWhP9/PiIMuIVMUV0RwTYDGieq z8ToNGC1btanneKn68EeYiBOG/8j5h1st5P+QDlP7xdq0Dwnmd72TJ7jtMMcrTLEBCZ4EGrfbY2e rGmw9LprBtZKtNd08vMFTa7vbuKgpqFg6KFtbheGZ4SeQ1KPeD6Irl/cwCn1dyUyMzry/g4tQcPh QYXbtoS2whoPDEI24lAjzMBhjUie6OX2pQvwcqh19KHYkjH2I4SJj23TNwv0tt59AxjTVQMIP/fO +TTkQnqhvaWEg0ZNNoVglcTYslyesNK/9tkdoG6G1ovG22dndRp4Mai+zeJRp7SSkxEoA5nStohD 2wmcPQ/gfALNgLabEqMbYhPCbAuH1qF/BocqZUfK/f71z68pOzGIrJUilw3cWWrdKMl8kUZIkCfZ RT8X3vSydhGLWPhxnDLk/fAneUqYC0rGVLi02nNokZ8mWUZVkHnVkJ5RBClDclwboB8/yhKk27SJ 3bR0ZLMjv+p9v/uPo8THZgGROBK0zmNXgDP6DWAtPo6A3Mfkxjedc3DzuHCCYwYXbt0UlNqo7W6f mGBGlcxS1CPd1lmDRiBhiVa7v/9IpDwmsAvwaez981FXluwcJQHlBqmxMkq2KjLE27ZZlEuaEkBs nps7uPup3AtYZ3cji0M4BSRaYENChr9/+ukNENLwD9PK/mfbbG7xZ2rCS+9LOc/sXJpCZnTWq5Ka klW3Qsaqk4V76VMB1BZ1DQD+RMqz/FasUNieDFzLlIec7uxsmhpmxKY66kGC4Azww7LA4MI9Q7q9 QbhqkZLBv0qgB425Nbutrq/vL4vFXxAslKKYX6DTreypIQaC2z80mFg0/Zm6vj9R1nN5qgoH6sES bXaRTpdcMO6z/3ySSkfgzk3xdSgRP5xeAklBrQ2mTVErRbqdOszO6HTBJcWD4Z7tI+2bW6oZ0Heb lPkJ7YH6x3OzGU7XWoPcUJgAnVBH2jGqVZ12h5NxHuYZH0s0Q5P9W3NBzwRHd6aHqT7JPjolnguq Xl5AHibNHvPAwYWN1k/Mc/ZtnDBZlJMUpUOMy233Zs4pfW3Zo+MNMQYkkgwYMFVTQcap42TwXkNz MOAwy/04C6jjpN/1HNrhCPdjhQsW34kodKo0z/FpmOV7eH+mpjE4dZjGfoDURu4vA5aJwtHQaH+G FiEbDGV2h6OU+HiYGhr2N0OKRfE8mi5Pfj+7Ldfvu25T/sCWFdJnipt3rLhuEd1l7KSKxKqU3WCC AxRInZwWBTRjoGGDum0RAnaNkec6ID5zaLTBJyZ0+04yFKmfxQII5wMbtjt5JkSwz0jCKPQjOnS5 ujISm8oa94DhHzlreU6QxtyuMjJVk10ZiduPaKKjTiIsh6ATxO3xsI8qpjS+Qi7ejT1LAIPzJ0iR aQ+OeB2gHkpuwe+Nbfx/PirYTUMwLwaMNW5htee7IRaRJ34SpXR8hjHrXzECZVed0bWGAlYTo+sr l91xrV3ZIqzIISiM47XAvhBkgR+6QcW6E3SyoyyNqKhMc192wUNNQwFpaYmfU5PduiIvDA1tPrca TZcRlAURnigBWzufi+ljYOWr4hroaG0L/f9jQCN/Rjr/A/sNCV1ZrpCCWrvRPomFmGfIh83n3E/C MDQk7N0lRWnIHY/k0ZuKRnu3OvUUUMytqG1ROykBq0gv4IbiOEJszQiTwOI7bghOoF5htA9p771s QW/WEowealB4BivZwxKmfQ5ZarVprI6s/JI8EjRZzr47UOkThb/PIfMo8BMhsxZqs25nLUMCbs5C 3S6aBReyUwAcK+9kFmhowIi7DY1RA/pHe22wcqoK4JeBxDOYCLU2KLXdmmrtTuwJmbZ/SN3KBInS CuEVozCJyKH8ila7NO7nMWAnWL4aGYD2G9p8lh9Pl+iXm94I3LT1WcgxsxOlNL2DUaQIF3CQLmka 9WkHmke0KEpG0zsO7Rm2q9RnZLt+FqRYQ3DsYVdpLPvbtjtDqpYIH6CUtF0rQGs2tqnpQkBvz96/ QZp6bgGZjkW4kEa2rOPkDLyRLccG0rBMIbvA5LNELJZVt9gM/aMbpJHbWBUxajiSA0czjRyFSYK8 L4tGHDqhG/CFXXfO2J2TqYWY4CDJ7OgK9foMIAbUZNkgwp2Y6yijTrr/+fgPa9cCVyXDDBsKA0R0 hHCyjACXJQE4Wxosw9IQvUMhCwn1rhcGhjajXU9gMAm074JahTQ+zpDeurPtWgOttcO6MYiAjazQ YMPwooDbMjT4JUuDXwpw99QOAMkwrmiH72lfjJBajdHHneDA2HvkwC3VtTg6QJqbhZOsm6RDpDgp XEHDAaE/B22gSUxNw2YsDSqKSRq7F0+kmvQMx6WiruO4OIZ1MpFQ/hpPwTrWArYd1wxTmxypZYL8 clhcSdP6CJrfb1d0i4hUxQXcnhjuH0s2kmmkyNQyVggzugEgI34CD4DNY/0dVdLjC2hdtw2pEa5S LYeKCmkuQdCjrAstpUwm5yib/SxBlo5snqO0zKhI0DTokUsLk5hAEv2uR88p2uF28qhwp+cJ9MiD hPwl3kWDz6vq+mYq1qOJ7odxKI0/9wXAAGxqIJHtGxKUmSp5ay94zNDGBvOUys8xGIwB+8M8FMfp 2WNDIogL6UdOyHimwUCe3o/qKvz23VEM/vlZmFPIsotbg4HODBrChmr4/F9n//3PWxsgZjQbO0BO nOzkqjTH9CJWgzTPT1J8r4ArARu0l2VXtQV6p68uyzVuIC6qorb7FxF6oBHu6WrdQd4Ln5zlEdyv USeHZFRHvwkTMbSxOj2z6HO6iZNytEJ8pjrtC2MJTzCtSO53SptIjKPl55r1BlyCr3TA3Xu57q7u IHLadWf0uAkA1DygKWtnv1Z3uuoa90f0dTGrNaY00iqCrApDuCn14TUJSZUlGQ3Rb25rzTwlMoa7 d2XHZP5s7gbTtDjhdouibWnk14Q0G14AmWHKZwTU2TwFqAD8DRWIIoauSKBL0+BkXVoYZlQg6nc9 gecUbRZLiZD4qBJrcudWZV7AUqIMlzJSwERQHdPKsY53VfyFGUeA4Ve4+ypvcKuRKatFM525ufho F0cpRRctAdBQSkC4gLpNPOCe1XokmbnuiYgE9XXEpfOQE2b0xSzWmAaMwqw8J0xiJ+A57iDtmMDQ zDcro22C8p+G4ATcTgiDpaQ7J8ifbptoGrIIRfMEcDhcqKArBM67hnZ4ZrTP9VIFkUw0xXCYCJ1o lyLvgyoRbk2tU6tH2r6YQNaTcUFFngZlLA2s67sd9FzIEfRc27S0WWzTQa6wqZ0jcdz5C9gmp6Go MKB62krUmoe0DNuNmgnTSEzrz66Es6MqxdSuT0y39qkL+Vzt/CZmFq1fV6tjnPWJgXNfGm8vZ3G7 b2vrxR11/U3MoWvgVt4sQ2MSODqqdYHsiy5YQGEJskJL1zM0KKyiyedEhvG4evyuos1nf6nYLbtw hufDNFC3QRtJDV3TuNLlZCGP23IpihFsyQAQioQduSQR4w6Fa4J4TNFmMUEhEJ/DmKwA+/qbTVCE EUwQ4IxcfKeQ/zvrkiBG+Sv7cZNi0BcSrJU+0U72WamTokzpFgBFAvfsV42AoGP18CUqjps3qZXR MBphCOHN6SaOVDog9C5Ja5h606PHHA2bJwFJp8eAMUSn7ymUGEQG/HVJA+M4eHn/w0LKJj/ELugi G4BB2A6aDzK5UiSKvIbEUbKhPW5NB28a2th0nlLSo38aBDv1dUZoKb7AC3o8tVG0WF5EcZyUButa UAFOnEAF+f1JdXEPsUqvZOZbzSC+TVS0CJGxA9dBYIbj1TTI0NKMDPW7UBhDO9zJ7osb0h+Y0QIb MOBkHcdqpi+B8p1dfq0adLgw447JEkw6UDtruEIkr5VIrFhKwjEVfLCcgeE5Agz6UvDGZhLa0LB3 PTFNNAGROzrlObQZ9z41EcBoylXeLaCbczQpc8LO31x8ZB8/vn9Lo/MXbz6yq7q4xgysVTad9nmU agmeySEhmoeCuhgSzMaQEh/XZt2CDI8ZmjQbOUPz1Malg4Q5kyvp1EYt8y+Q9IUxh3MjGJBj8Z2I M9zso1bSVUPDsaPJh5k8oZlSGGWA1doU1DjeW5gsTZ+MZDFXCeYkvqnp2TtWBl2y6/JnHfe0l3RS DSMEu65JBDX4cIMv2Sqd6RuTFxH+j+/2pIpMoJ2MURrPkMjfSxKKMMSxABCdk1E5tMPNdV/olq5q qt2P8XWyRSehtaaYCp/nqKxW+NJAn6dIbZF7DST6HkFNAs4P2MnxNnjM0CT73x24iH36EoDtWwIp fCpdarF6oLlHhAWDCdJscK8nLA3NmZzkyCeSJBqxb0jSkcjRl4MdiToFx5E4c6LDHragBMv8tiOZ oZgDJoiLHAQAkwBV3mwtWg2+4Lsy9ezYwd7jQRRfHhYy9aF7aNdCWGyGW1J6wgXBz/UmBuR5BdPW ZvZ+iS8LwhfEOQMeB7PIHmo0SBbNPPqIRXDpXKJkGIbH8lcVXaku+4Ubsw5j4zGrzE1zbMQGJPWJ 2qvyKgnc7AJs4LsybVpw2OqPpS+5AVm3V/8V3zWEbss9w+JVg0sj1cp1coct/+jmDUS0vfy5/NY6 fMnDerO6xMImFTxs4Uf3bb4LbGfhjfzC0XL5avhaErov8/BXeii7AR7xy/8AHjUDxAplbmRzdHJl YW0KZW5kb2JqCjcxIDAgb2JqCjU0MjYKZW5kb2JqCjY5IDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9Q YXJlbnQgNDUgMCBSIC9SZXNvdXJjZXMgNzIgMCBSIC9Db250ZW50cyA3MCAwIFIgL01lZGlhQm94 ClswIDAgNTk1IDg0Ml0gPj4KZW5kb2JqCjcyIDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4 dCBdIC9Db2xvclNwYWNlIDw8IC9DczIgOSAwIFIgL0NzMSA3IDAgUiA+PiAvRm9udCA8PAovVFQx LjAgOCAwIFIgL1RUMi4wIDEwIDAgUiAvVFQzLjAgMTEgMCBSID4+ID4+CmVuZG9iago3NCAwIG9i ago8PCAvTGVuZ3RoIDc1IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAG9nVtz 20aWx9/5Kbr2ZewqiyHuwLxseZOZ2tnKxRNrZmprMg80BcnM8KKQlB3tp9/faXT3aRKwRClQkkpE HxMCuvtc/+eCX8xfzS8mqU09m5miaEyam11r/mE25quv94lZ7M3M/rtfyPfsx4vux2Jt/uvSzKaz 2Swzl4tJ1f1lZYqkmlazIjEXNb/4cm2+urxMpjOuvrw2/zSvkvSr9KskM+kf08y8ew391Xevzb/M 5f+YP13K80wG7hN+O7/yC7/382uepjCvrl6bi9k0N6+Wryd84Ndfy99k+tP4b4Sv7iwlNa/m/oO/ 5nAhF+cTfpv8Wn5b6z8c/He6rxzd2X13bS+Orrl4PbHPtrW/hGf65L6x8r813Mf/1pn/avgwtRSe 6fCr/7vDM9YkOxTW5LbqeWuSHTKv3JomT1lT4hfg1mTiNb2eKFc4Ps2TZ7EpJyd8OrlcmMBJRdpM q6rKzEWeD7DpO2EFjvumla3lgzwqP8ruh4G5+JOsmR/X7jtp98fqiJ+H5CY8hfBznk/6YvLRMcbh cMsvtRv8R//hq96HQ2CoreV6OCtw1F5+E7wdtjg6dnf+4djDd8JhBtG4kV+DfIWbh7/xcrCwj8Wd glyFO10L33ci2DvTsuBMa1Nlse5JRfck9l90D7tUNc20TvLCrCdFVekfV0b+yO9Yybfsz4/mWpTR tJglTTmr+WzVlxBmNZROU+kfuS5J6jSdwiGRWkNhcees+zY/a5Oms6RyvJJ5lfaqmBbTdGrMj+18 cVhubsz326v29eTy506fRQpUbylEDtU/UPQE5oEnSKpkWqdl1T2IYxoem21Ct74yX283++VVu5sf lnx6bfwjdAp1vE3I/Sbovatpwha8/fs7s2D1/t6Tv/KoiF7FtlX1bMp/uVljbaZlmhSp0lbHtLRq 5ECPrhXaZGXkcH+xh/vYWT60k/Ysq6q/hcZ8336WdezNVXu93LRX5sO9OXxc7s3+tl0sr5cLu7tm jp1cLfcHvrDcmPctR7/dmFw2YbXS09cllMW0KrKS5aewcp7Xhak8jaXGtLRIq2j5E/meoznefgpP H+2DqMATnk5m/eM0Bo3m2ecFZClLpvksqxOOWG+vIvXDZtGaOa6Ik6gNPMWfFu3yU7s384354euL H779Ubd5RCHLsmJaFhkOijxan0OEx3VvRhStrMq5cSPSrXuiEmblysxXqy0c2F7p2tMZD1wWpakK JEzUAyxW5lMEplEaLBbT0hSVC81dO5FrHW1kFsubZFpW9ZeWZa5323W0oUfMNjlbZx0x+YniLrJ6 mtfl8Ykqswmf3W53VnULo70xy4Me8Hm65jG7kaRpz24gY/Pb29UyaEucX1Y/eYK5emjVdTmdJegR uClN+2x8+CiOjRfxEdk4SQtuTCgh93WLVi7+w9s77rw5ODX6xsift7vl/1mt+gbZjjhb7USeTdMk S4WzCS+yus5N5WlwsdLSaZUQV6g9mVR5oI1nO5JsQDOg+heL7R2Lwwn46dXbt29/em3ezXfzdXto d/s/WPP4tZhHOO4G27G7x9+6/Hli4x61FKKAmqaWxabJNG2QbE9irREpaeomshP2a0Ib1UwmZX+p lXV4xFK6hRwxsa4kxdBXacNKkhnBE8ptUnka/pqjGaElVXq0lEA6/9AeFUJ0a+doKz8ihJcfd21r NkeLseZ907ZXmPe7DS5VpG6DQyO6MxeDnlT1NBNuJ+61JNYWk3Bbk2hxE/maoz1f2UZWPGOzZgWe LszBFvfWqHJ+pF3HcYuztJrWRWpNedhg1a6H3fwap8nMP2C11ki++TDfs6vbjW7piNa7yGC5mu3+ wla8mNorygapTfLuxj0+O9V7uvhslk2zolTmWZsMf6+uaiWtjkmOd/yVp/x0nsl60HawCtR3n5NQ cUf6WjkrCH3Z1FNUtchFjd3NSqIyR0IvKamalhlhgWg0FyGUTaA9Qyyc9EdikeQ2zii7xfSOJDJ/ p2Ix+e1bmOQsPkX3xTupYrHYrtfbzere7O9uxfnAoQvG+LybP6btUmx/pwn0ruJyrG4wt4ePa/OZ /xPZiGMduz/KmSOKZcq513kh3gjP1ecrzH50HCN6I5F20g1R9f+IwVYzHcJ5gAJcEaxz2cBdSZPA 5xlKp5oRsgYaAhvTgBfEJ/HXTuR7jna+eXtUYIuBjTVRaJq4kJYIypq7//jhU7tbbedXAhwcdtuV +XM7P9wR2P6dcHa7+w9v3e+VJ1RYK3CPBlcrimdLT0OofTwrtJnoRRX0SUQbcfnVoL5abharuys8 MpUvXUNZT2dVLZ4Wn+qmBj4qHQ1dFdGqKSjTka9VloH2fGVlYclTnCmZETAJOiKi0vegrcjqYhLi hZEihlhfDmzmcrM8LOcrM9/vlzcbMeV70A5xAj/NV3c4tQsC8w/E7VfiNS03gkna+AIUKKh93fG0 zgD0gAD8jguHKC3srl7akZxz+zzlFFmHyFNgm/sqSbf41DqciT89pKCjkFTPWPX04m63E1dp6wV0 sd1csfvbzVRF8Twz8ajWqL3W0Ntbp1jsQgy/rNr5LgYVn3gAD+1GmtQ4A7kE6ClAQc9/xUjpafwC kuxxU3mGp8Oo4idnM5GsCbkpNQYsW28zpg1SsKu7raTE9LbeyJi7vaipYGmybFplMwBT0Cjce0Lq yKPypMijKtJpUSQSaPgrJ6XSnqGkHOtEMhNpCFbyO8tM5FHpNirTHnsx6ldp5KFbO47o4L66LdCn iD0sIOQloOUBL09ALuWtlxEd8aaHRCdm6vGMRVrgrOczca51H5Sp3x+B5T+2v9yxFVfmdrtaLu7N P3/889dFmpb/svhHlydJ8kq4PJ2UOZ5FBjyOY+Vjo0CDuWPaLKtKcazctUa+52gw/AhuvNUVuT9n XR/nrJh/8UXH6kfrWpvL+9v2YW8KbxHZtdmBopzmJSmW0tOwizFtJuhw7E3xPUcbRcjzCuSwIiDl ZIdWfsTHYyfZcvEAqkrCaG7eC2BcDuAKnHD/ud2Zdbvfz0nRYh8PcxwUgDcxFkGHjiTopdd1R4JO EsI5zBedw2wBvu0O3ycI/g7MY/2h3bknM7e79tNye7dHJ9wBg4z+pCGndfSkfRAmhIFHp/kUT/JB gw7m6tI7GdnZnlayoWe4syv4GAXrjwJN7tyzUMuDT00CtidlClaE1sTbJkEAuwmUl5OZIs0caILl dbRJmeTTps4kcRJdG2gifecx3EN7ZzVOM+D3G/jqSx74AQVz4oCfeBMa9MyqaVNh1AVebghD+Vh6 mqiViJZXuB+xquF7jvZ8VdMFPSeJyBxYOy+pxkDuhxb/YrhdXlJbUZGXHb7xkR0TjnVgPehOmTf4 Zn7n4jDY09i5EAbrzqXu2olcG+3meazzmD+fD+UspTjhcQscsQh7UhDvricJmYeMsIyFOhq872kF q2sAdZRDjJLGk4Y866uQmtATA3wHlHV/WvcQtH9YUFEj4JlANWTEMLR89CSWoyREOZsdQfVFHWjn L+jRMxpIqdiYiyqDdbv4ON8s92tzY5Pd3yy79JGR1GSkvHRtFQczy5OJKC8+NmVDSUxHE0UVaADU zYwcWnxaSovl+Wl+UxQfZDM0ZQ5wnaYIcz/ACipfEp1juw5kYKZpDgrnby5hlppB2c7NCdY5ejSd h/SL3tiebChfuJLahQG34WqLAt9sD0aO/8bGu52qeWKw8BDvRUpWHzTyaX8PJcuNe/7A/MNyJXJ8 2HI+vwAlHfDi5gd1jrzKpFAMdVSBignoWk8L/kJpEvgGWo4bScofZvfqtigCbTxRloCl594Yc7X9 vCG/287XndyafQvCfd2Kzxok2q3Vomg2K3y1Zd3ogA9DgGtBjEMRg00Le5gs0FhmTMtKEg8q5xP5 nqONuPQhIN+Y9lfLwcOIa0FKJiuoGF6T9J3WM3lOTwPYU1pGtZ/YV12EKZQWK6unuVyRskpmlGEl QL7UvYRcSSQNX1ZWT9OPwyAvJQuULYizx817MEL7K+UBR1v4RDXwmIdZ5IMeZgAcdfFjAsyKbHP/ ntx0CE5k4wIAX2QwS4ZhW5umlFI4OCjQVoE2EVqGLxdh90oah2mIxLEvkl8e3ELdt1MLNwbTUME1 477dzXtME0BiqaL5ijj0gbAPhXQQBtub5fVLhMxFSEYdGcL3ot4p7vv+ToJiVy9qQ3dJStk8wtEO uoD0N0O+kWOiTxbJupibGCcT/2Sk8oiCEh7bWsH/+6YvAAVUSQAVdvofpOzO1pNG/knSZNMmR08V 1FdlaWbhMeLWGW56IGEBAwljB8KGKPgrJ1hLTxvRCgzlTqSoBjvmTEEE3qvXiv4j9wOinWPFG5Av 6RupEykRiCkZucMjIyClXh3t+fI8rJFFx4hiQbKH0m6sR1lzTKUYCfXAXt5uD1IuR92n1Ap8+Nky ydas71aH5e2qJV6gfu5qb7bXZn44zBf/fuOekqxbKLDq9pbdThuw1XwGy3T7j3mNKW5nj64Tmsu5 jROhFiHjFAkghQk4SB/nkfaPeIXa1KYUcLSkk6jOsF1F0tF4MqVh0CkSP45HlfZ8fomcBq2qZBk9 RzbikBdQ/2iAOskoB4RDwx6qekW1kp1Fk22UT0f0GqLmg8GlnwQPI2YaOOra1mPrqpVzgnxI9ED2 WVBVUtRYk2/aDWJzsb2+eN/uPi2pKP/p1Tfb99RkdoKi4QUVo9Nyhl31XAWnwWRABvTDBRrKNdCU q/y1k0Jp42nXcijLZswnW58RJU9UVmZUu9YW6ojkoqMdywrBMgbiSLdyraOdv4LHHM0SxGEgQAql J87pM+v5vUfxwTmvt7u167P4sL2LI0FO3raT5DVthgURHkotyYBvKX8MNNRaTMPyxpHERL7naM9Q Cv20aEY5T1qymRjcrO/XPqAVnha8DNqtjOK6WYk/YG/u9lq1giYc1C6Mo8fJUfVcULAOn6L5ig/b nZSCbDctaN1faBPz5eYjqiXSRNNUigxZfkgYqXoQ3zba/xHtdlpRk46G6G7cC2YOW3Kd25t7W9Ee Fp4IBlGWOawKy+SpjeaJiipBWz0NOaXRzNEqbFpO7h8/LlyrtBHllITfgJz6SpT9gcqwzstQAGPT Hj5vd//mcK27F4mt6tagmXKCe2rBpf/LQzIm0FixR9SFRhlI3P81iWijCGwE+pchtxcxzRGnjo1T 5oS1aZVLZSg37wnsIDyo+/lE0XkIDkRXTSk2E39icBeWkTP2FJVBtEa37WlZm5XQoWTgy1fdlAO3 DX6D+NUtfZMH8GFbz2Z52mxvpY9yuwORxzJ9Xu6pld1aC0WhpB6HL7UxufTo0eEg7A0HUw2aKA32 VlpOi4pwt790Qrbfkc4X54fO1e50M2CHwCWX+8Vqu5caTwKGgPZ4I8wK7zZzV+Et5Rpz2qLApaHP P22XVPWRP+2nV8gVUf+aSkgawolAY+0+xBAamk2CUq8WJhFtvNVXw0kwfEOVbP8EJqf1LaltIS/V IznRaKq0FR872iTPqfCvSW7o05uI9gzF5HynKLwQFe9qL1hDXyHr479AfCHp8FlNSxF1p2ED1ZPw hv3oGcaCSbRrbHDd+IMvY8UTjb51zWoJKNO/bQ9WN0hFa7taLW8EvzKCroHWz3c37cHFE/vIH/cR NOwdmIt+zGmTkFAPNFELnqbM5a89Ya4R8ENRDNVw51pISoQ8VFc43ZK0sDXhVgnc7rafaDA3JDMu DtsLfgxpA9LDlEfYZj1bf1iZ3JNYcSDR7VrC+ipNkxxfztFG1AXFoCYULSfAStfOTc8np3tjs8ks 8kB8RbGth1KoFfHaYgIER+af2D9q+wo0Sbe6VjChUZZmm2zhpy5mURrrsxHyE1DGx1R+NZxVPhLX sX2ZqI+b2/d8GXG+r5c7yect13wUqfl9Gk6ilrjBfTnWJy8C9+qGxPpkc40AWUCPjKf3nHExVJA8 Xmty6YHMChviBhPqaYhNoCUYpowpJhHWS8jgaSOKUj0oSos5hhXXaE0zcydOe/MZ4bJJTyl86/kZ HwgcWr6w2W6YiOOjQi9jJieTz4AIGxxJMeKMOCnQRGlGtITOw1iFcGlHGnHZIamvB0mgO7/6eb6Q Kn1bmREpf12H9HnO6FUmbUViKucfkzsaQV5EQ+/Nqjjk4XuBdv5KHgNj6oE8J916sOE7DzPbdliS Id/ZcpP+2QjWMatxYNF/Iv0pJcCBBgMGWt1MCxK88eFkSjt/TY+pvTpkmo5O5xI9E4yaqPTtggan 5ebTdiUzJEiNbfbS3sCgFKhBSU7C4WXSuFTY/t4AJgUaHOcBJhnbUFCvHC3UeBqHLAsdMWaLoKbB hYt6DYtxk4fOLqx8iH1y6gLTspZgkRv3PFMB7CSk8DUNkVQT58zwr9kU3VCvugItUmd+82RD3bWT iDYi5wykW0SuSUR05cWawWIKjFNZCwY20Plkv7UHV6ax32rxVlRg93fR2r3lz6RbDBUmEZIAl6SY aOl1NNYZ02ZMRomYaSLfc7TnM1McY+g4jHpoB5R9TmOMEdBKBAqMmaJ96fTpgx8n+WGbEDbgEEEP PQWHoMTsCzhEPZA+4eRXVJPbBIr1UhQ5HcY038i3NqaljZZUNv8b+ymbAP5rEMZT7l0O3Wy6JDqJ SdA5UoE/vWqnN1M40zqz+BjbDQkhPJ07CuNtFlEIoz/lcBcMkMJqfv/T6yNuGita1CxcM9T0ggTr bc/jmIdUn4RNzXAaQ2+TBB/ytxcraL8Yt+0hy07rCC6lt/dgEqgSRcU1DRRUWJXASlmTBRrmKKKV 1LLbeWnRtYH2DE3TRzMSksyuyGlw//TxTzXNCMGuIgq6iSpH7//7h799+83RA4zFnFGidHDVJCn1 vmMmJGiMmkkTmOXWHtvctpgq0Vk4d8v9G/TVvYU29x8ZZRY9kAQODXGrMtLEm2GlqWmGFpgm0WsD 7ZiRniIbkcmKnI+jLaVzxA6+08c/ZaQzTRZO5sSPMz0Frik/J8FGx3+sBZST9ssVDgEosmCrc0l4 4Q+87WnprrZpZDvWDKfggh072pfR+Fur+Lh/zxMk8663RSsCc5ztgD7k60fyHFatHn9XR9W59TLN whlDfZIwSyrDkW2sfkzKkhClySaeRPjiSEZItIVIbHl0paOd74Q+alhCCkgXg5G//PqdWO73X1++ o2CByr6Ng6Qs8oiT7zrfuvQE0Yw4opEHomEMn0h32c5Cim9t8UzmaYix0hJ6OSjOhua8VvYl0I7F +CnzF2MxzoG3K1qUkaTfP+0G8MgwKime5OY9qMp7e45jqJ4aMWorpCqvJkHyhYWTIT8WmrFkVWre HaSvi1ZG2zLDNaAvLibj1APHhF7bQCNt5ftvI+4IUFREg2OeiXBGHBNNVfr9OYaRH7TTAJkMc8x3 b/+XaTr7Ld72leBeTL7YWKjrerX9LLHwS4QEoadRDVA/JMAA/fNPzIvY7v5ge0raP9KQYD7LkLN4 zpCo5pGUs8TnbnZlEx5R+cyst7GPcZ5L3hmDLyeTm6E+wZdPJg/dVsKr3bq9Ws53pEvfmH9v6P+Q KrSAQL0lbWTnpQSKRQ2lXM1cfvv+jUZl6o1LeyBemGAGMkMzowYu8zS0tNJwtujRQ3P7ayfZLNDO N1UPWV+8H2ZR+IKf6GSN+UaeX8zSX97RkWdzxZpbaY3zO49ismBhpD+ySZnFAZroC5wDTeFsFiu9 GoQyap1i2vN1zSBEkIWa7eE1k/lTvamB31lW8SF/IGO2FLaaBKzct+dZ+ewb3kCcRFDWSSlBLMRp CVsorOOGDQeasE5E89vqrp3Yv+y2ekTWGRpB2kFtQ4k3qz3d4EAPvFk+QrN9b1ulZNbQev7vIY+H /D0NkVSERXITaJHciAA1Myo2lKdYfKCNuPjhlKuvs+jqHK8YLr23aLSdj6j85WUFkBDvqclyafT0 8y48jTUc0eihPsomyPccTdblXZunhdmRXdbpH7gDwqknk3T08Z8ZkD0kJimlNrnUxCEmoTVY7eGe eh0QOR/TjuvJ6Tw5uXcvyKbWUcz+C6mHUGYarVtVsQiI6ZKLtmgnynBLSXRcROtzF4F9onbKQBNz 4topI/bxeY9JRItZ6vyA24SA+2QWgLU1zD8bKEd8Ub7SZHY2C7dXvpIsprh2//kv9xRw1lM8mS/C 0RmhgeMkvZvEgDBSN+j8qFHqaA+e4sA9KFO+yF4epr/zJzw9nuNIwzYxKVWhyHLYBeVpm6az8Txg cruLkqwJ45/5j0QCZUsuSS7Td2UQuiPZOtpA4tUJMqVWFGW4MtDOV/YPbaIwbkKSZ4Bx/yGpAibV 2NQR1XcuEXklgBwAPtEnRYg2rWRa2wlGNSKY0sft7cWH+wt+RFae7bHlJKl09bJWMXQ+gRRoGDWl lXQ2UUcQGzryMI52/tofcxCZpNDXiAZQ5o4KkDV2e2VTZR0AKR0afrZBlzgTH7IDt+0oQW8fJa4a Wr20A8uAczHzrquJ2SEdTcx8RONU4vwsgGbDwGZLG3H1Ay2tSLE9dFv6smh3MqTIuLTzG/PhDiiW nZHt6TbJorP2isEVUxnd4ASzYl8tnVLDa2msWGkUjzeUHcTnjXJztOdr68gB0ArqLBla95GSGrvq SCuo5eZO3FR1ApXJWKjdPVKmjSRdQB5qUXR/x9HhSShD0Afh9LUn13kGXamtVMVIAIg8vF+ul6v5 bhUlc8YMzAE0a4aYiGYKT6j6VaI1PaoxQ5nQlSL37WlE67or9CRNncz0p/iCSmgeVzicWNaWDQQa 3BzT8D+s6+6uBaShEaSjweFP82wHo0CrzYcS5Mj0LbHY7W5pQZ94IDaD4LwbP5fGJSmYjiJgA1p0 NMNTnXtJlQk6ycp9Tai81sDSWLnSSOp19eP+2kmaBNp42oygfEiXv6cs1I5biyNQWwwxHMctaCCh WCJ2PoP5knazvLBV464olJt2JFYcSCiunDKcWJlJd0xHe74y6878xPWMNIugEj1DLpBeYNvzFMdj DgOn3L/PMIz1lOzZIEtHHi637Z3vqbdFHqvzWCTaZpjJVVQQ66EmcBtkFtxXwlKfPfE08bZiGkpI yuePrnW0+CCfJryRVQLZpzgXwJbniXb1d0kT6oiB6OZqC6K2HsdBo4UPrHYofOhmEoIAnxSMYHts 6UoXW3xjYwuLY9N9/QKYNT20ntN0N7CMJ6U+vFZJJcvjE2fGVw+JmGbj5UH6kibVXnrjMdPxIaLS DVDDS3fRx/kt2bvt1fL6Xt57c2+7bQT54s2DPinju4upK6cPUKLSNc4r2C4YiNLEMka0dMYoZSTP dzXLtY52vn14aE/FMkrc0VOPgMHepXf5SSmsdwPYfXrETpzv3KBovoW3ZqyKCt6mK/71tj3QWKnS wMQbwNLIMMhhO9r5K30sqgE77GnKLjonjpPXwO1bkAEqrT7P76Uu0LWDAMaslzcfbXdIu771r5RC 6nWp9EPRgGJ7xtxrfXCWOpKsqnv5T8LIGWkZ1XXSCmpJv6m8NFKbUpNcO705tFjlxxdA83LAqJLh DrBUSOioohD/iYkGVyvxmKXSrfOW1Xt/oqp46LALMhD07dHRK4/SP/OX8pVLPFcAfyaPRFugqqL9 9Xa1jV5JNgmvlgjMAnxXSBc407QCDTOrNM9B0aW/nYMGXQxe9Qaqzkl+aROP0NEX4CfeNUmbFW5l vJvKUJJqJwYXQAuTrHx0njP3EPuIViQ/N2SK+/P+LBByOmL/u7+9vzR3t1cSVhx1Wo7I5PQ3ujKI 6GGV2UJ8HBtFmy84u4jnIcuhL12Qu/cMCNGyfQ9JGILJNr3dHPekgpftus5U6tesgl1uZCqOHmUY hZdIU12RSFBV8IqBtIIrAo0Xx8a0pJjZjIkbozeR7znaeKaEMoq+WpE0mG57Zxhh0fD6jKj7jKfH ONoZgN6686AdKTb4uaSLq7gxhisDLXa1R/CwLN+HPEzESnEQEwn6WAVhUTBDlrwndoq8yOyC1nYk iaF2xdzYkyOzNhqQHkIQSd33PKQXA9L1taXUCfjd0MPQUQ1/kcIULGksR/zx7rabV6mbklBlDb6a MwOY4g4idcQoAzbOcnr7Aw0zE9NgSykh89fa7zkabPe0wG7QvlhuG27pFNfZgez2RZIsEajZ4a/z 5Yo108fOKzdxtYFvYAUPMdsUbKRA2DeLsMtoYAZky5yygMAEGv6YR2WSFGuaABiojzaJaCMqkOEe T/taBVt50hs8KtML1gyTJFcurxuzMLM74yNXlNJdqv8smh48bE9jVTFt1pBc15Xy8uwGv6msx3JH daINtcV9Vo4sU6RVxpLfyBfm5k6A1X2I8nFAy8oyI1poLRYcXv6JChnROIdiQblxT3e5kK0b9iIs 5Eah+0SLsIFjIVUJnharCccuwkK+5tCzELQRhWUgoSgJGTsmT4IJtANvNSL5Yudc2BF7a3r9bzAX 8tpvVYU+YpuQ3aOekpxDVK8UaKg9X8OEzqC0mIKtIzEJNFGFz+OYKGqLqpQoHOr7Ffr4LyAmWYHM F7gY+LwhYaxiok3fqmtG8rBDM67ejUONK1mfuLMP+atSZ9MN18qygcHVNozQfR4RPQodTnLf3tny CrY7IAXKhTobZ2sJ9TnC5DemTVAQxmQ0KRnqst6TQINdfSZcaLQ4CJZydK2jnS+SD+2lWG5pgez5 RPJiC8GImKqBfxbBQ9KZq4iS78mUrCmD0lX3euk0vD8UnrSjUQMgFmhIogfJcNGKglcFRdI5iWiy 3CfykIsLI+nUrhFZdO8EX9iIhUL7aMdVXk6gV8aKXshb7X0dM4rRT6EP/SrP249BD66ScUeg/h07 9HeGM1dWHjElyWhQcFN5OUG0Keoh+85lX2OCd8R0cGJlXkoSmGjN8BaKRnKqBgNNRgR5mjKWXuto zjsaRwsyXaS/cW4MmyyEl20dQ5F4vh/pEbGVyav2qnvBQPfiLS8+E+nOzzM7CCnMnws0xMfPpIMG wnz0ngwT0cYxbpq3HlyrcshLGLdQzc7ET+8Iqfg47OiHb3+U3EmEYY90tiFPr7fEwv1pvvgYl4PZ lI0AJpSU2LyNjM9eUvVPJ9odo8swDrJJL/ASCT8IIGN2V58LXZ2FHtCIIpxLzXvF8B1EeKCqgBcb 3yyl59nJcmQi0DlEa42RYQ28EkUcOFIYDNuijDTQcFIjGoPK0Ofwvbt2wvc8TUzEX/8fkqSV8wpl bmRzdHJlYW0KZW5kb2JqCjc1IDAgb2JqCjgzODMKZW5kb2JqCjczIDAgb2JqCjw8IC9UeXBlIC9Q YWdlIC9QYXJlbnQgNDUgMCBSIC9SZXNvdXJjZXMgNzYgMCBSIC9Db250ZW50cyA3NCAwIFIgL01l ZGlhQm94ClswIDAgNTk1IDg0Ml0gPj4KZW5kb2JqCjc2IDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BE RiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczIgOSAwIFIgL0NzMSA3IDAgUiA+PiAvRm9udCA8 PAovVFQxLjAgOCAwIFIgL1RUMi4wIDEwIDAgUiAvVFQzLjAgMTEgMCBSID4+ID4+CmVuZG9iago3 OSAwIG9iago8PCAvTGVuZ3RoIDgwIDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0K eAHFnVtz3MaVgN/nV3T5ZaUqaYw7MKnkwWtvKt5KbMdmktqK8zAiQXHWc6FnhpK1v36/0+ju0yBA ckhhdnMpSYcAu/v0ud/wq/mr+dWkjWmSxJTlwmSF2bfmH2Zrvvz6kJrLg0nsfw+X8pz969vuj8uN +fcLk8yTJMnNxeWs7n5YmzKt53VSpuZtwy++2JgvLy7SecLbF9fmn+ZVmn2ZfZnmJvtdlpsfXgN/ 9ZfX5l/m4j/Nf1zIfmYj64Tfzq984Pd+fM1uSvPq6rV5m8wL82r1esZf+PXX8pNc/zT+ifDo3kIy 82rp/+LfOb6Vl4sZv01+Lb+t9X85+me6R3oru2c39uXonbevZ3ZvO/tL2NMH98Ta/9awjv+tiX80 /GVuIezp+Jv/2fEFZxIMhTM5VL3sTIIh88qdafacM6X+AO5MJj7T65lShaPTIn0RmXJzQqezi0sT KKnMFvO6rnPztihGyPQHIQWu+30rqOUvslX+qLs/DMTFv+TM/HHtnsnCM7rzUb4JuxB6LorZkE1u HGEcj7f8Uovg3/m/fDn4yzEQ1M5SPZQVKOogvwnaDiiOrt3df7j28Ey4zMAa7+XXwF9h8fATzweX dlusFPgqrHQtdN+xoGLG3WlVcqeNqfNY9mQie1L7X2QPWKoXi3mTFqXZzMq61n+ujfyT37GWp+yf N+aaF0VwWbHFrpOkWVSdJAOV/p88n2ZlWc2bchaJMwQVK+ZO2OWmMVleNJ5GMi/KXhljVluz21+1 e3Pcmcvd9nDc310ezRIZerjln+3cmIubdt9e7/btG7Pa3K7bTbs9Lo8rfmp++tP3f/vzN69nF//d Sb6M353UqRyunDcJpLkxGccuiqZU2LoPy5Oq4Oz+3Zm862CCh1/l0p48vnnq+IuFI9He8T8s16ur 5bE1x5slx97yv8NHsAEqjsvVdrWFZoaHa5p5tsgXs41Jq2peNovc1A4ml6gw9Ag/07PxmAfJ0VQz QVsnnzG62GxRzauilutdLJwI4HzoHzTVK1ja752VWCCFhJrnEBVYnXkdeZ+o8qSQe816i+eBtnYf 2v16t4SR/B5+fc4hrbi7v6TQcZkKHc9QybqWpWModGPJ0rSrIyRr2t9u16vL1XH9CRK3pNv9qyNp KHx5eeSCzXZ31Zq//O2nC6XjaWgO+exorrfVDYQlxKWYUTo4idYfY/VFjozJF5VgKotIAnFiSQIS 9zdjyWNmLZZnyprHmC2Fe7M8KbsNDHhu397u9kezOiBjbve7W4jkkyIiTUs4JskMWm2eVTXiI+VE iyKrZx4EgzkQT2XzuqpSYTp9M8BOlx6PYdQSXVCwPekRBGZ7FQSmCFKO1m6vhLb27a937eHIUVfQ oPyoo7ndVonNCz5TV5y+zCsRmlUzT5u6UhhCJIZlZVZHgmUm7zpYX7KcRFHuQiPJgjyZF+7og0v8 fMHyGMLLpJ5nTSqCpQx4Vw4C6VcrUT/GCu/V8ZM5rjbwOwLAwNM3IF1ozLO2Inoiri5HufrnVyyP TFlvfn5tVkc0yGZzt11dolwO5iMSCbHz/fZSNE2rO7+623cyS45wmHyrtbfLFH3Iyt3d8Y3dxlAE muXhcLfBQfBCW0XTZ0tvVVZl2FfEToKXnmjqTIpniqbHCKtIMEo6dckOVF062diRDfajO/ssy1L0 PDxYJvO6k0ZZ0aBwF4XC4MsYlmUYgqLw9VUBzdbmdGn0mHgVlqwSf60R+oz5yhxWm9V6uTfL43F5 +Qu23Yfd+gPkJ0JfVOLH1aE1y7vjzW6/+h9k1jer5aY9tnulO5VFeTmvFovGyiIM3xpXt/YwkUUR LF00i54s4jkHm0YWNSi1mht74OjhxsSgeomZ8yjRLNJ5hdnWLe6IRtlJpdHN8mCQ+u2VYnMagVOl owJHZIrl4verD+1WhV4PG88x9h7DQpZC93lBzCNnOwPW6WyosLKLf5zsuzxG8BmKrShY0648UEVi t4d1TQqnLsoGXysT/YlfEZvoHqYm+qzO6nnVlNb30ncD7HSefQx5lmfxDTsXucezBygG79ZLW89+ 7CuB6jDgNqYUS6gRn8rDcBhjWFpnEffZxzqQZb6ZSPDn3kRkCNQ47mmSikEJAQzwf15ToMbRStOO 7AIClfmW2ytztTpcLvdXZrleq/oIXDk5LxajvHjAIW6Rt+qDBO7sGyPO9/i7uJ1YLt949f/V33+Y fKuVvy1FGMrfbgzL6a6FLlaYUtZCURJUhX+S5fgY3WcJK+dQLqQDKw7IH7Wk66YvItRRNxFvGBek smwXkKBst9oub8X12K+4tGgDaK08a1BzmAlVIVY4EmSeZigeB0KL90AEc6zvEb/pYC9QfA6VEe/l onDL3ErdMQTq5u8rvtnnqx6k/bwowYO9Pcf4SkreuxY3e+WM2N21KKTerp4jfB6jJTaCU4BD9AAt 3bccZ399bgDtMSVUZQUhKdIEMS6UopzlaMwfxQX5bSlRsjd4gYd2TxRE8ZHnGJLJglCYJ7FZUdTz RR5R3dr0QI6cem+Okthnm+eWXWrR7RJc0cMhM/QE9+nsxOjcYzebp/MiyZtUcGuXl3SL0lkQ5cYK WZWSzxRUj11vigVfZGhbu4WhjhPP8qw4wNVnAwtxecdwsDRi4+3NFz9az/bi0237hfn51aFtzbb9 jejCcr98v1/e3vz8eq4I+nwRICQBvQ54H5L44363sdanbsmgxEbcynW73BMq/njTigui25vw/goi I4hpuT/dbkTB4lrq/U3oUUahChYeaDgbDjBfOIkwJyTwhdms3t8ckQyYLss4CEQoC8mQmgpnJ01K CX0VCVlHzqYwhIPCsjmOoHU23buzqgmwF+ifHodIoinSRHVV4ALnwqRjBw2Wl2L5NOp7TDBY6iOd O7AbHhBIGBDPtXNHzYdIINXZ0IYKAknP+kxSfuzQmNrzKi1FErD48OydqvHUPK2WS7nkJCvFz9aD Kxs5Y1Hiave8roS0crkgh1WX83JBpADTqWzITRYBJKZTBEoWhPEBxW862Aso1yE0olfih7AO0cMH 0Ni7u17IYALLKSMX1BSwcIzHnka7bBGJvT1MZSeRHyEOLHUQ4/Sz9KRDnQKCcDKeqQssVUggPrKS DpLvtj2ujrv9vx26IKlKxW17/ELyAd6Ca69wkr697iJWNrBAAOvyqIojE+OpKqtAWyIqKxQoQkph iMoY5ojLvzsTUo0I7jRp1ZOQIznWmpzgiLQi2D/w8E2FzkrIGsrm03lZSLYmwNi8g80qTkF+OA6w 8VyATcIt2KBJUuWSs+EIQ6Gj279v/03ALWUhmeLKSryAP+WWw217ubpeXZqbHXmUn18RZVtdkYEG RgTzXZQ8mlAKa6h6FB/37InpPNfI4RujpU7429j9J7NZfjLXy/WhJb/5rl2v2g8uix3sDcdZcnsu zef92UBoG5Mv6jkJwywmvggWCM07vjFBCvFNxDmlV7QqNCRT4ZLI7dUb015ftyTPPsh59+3V3aVX RJ1AQbBcLm+X5Hs/dUEWV7MQyQ1+tS1OqAhelxV6TooT0FgFpluAEduOYdQmSHAwBObkOQeb8PTV qNxYHeVQe5Jdl8u11blOHA6qFjyeXBSYPy5bMBWFov0BqC+Bt0riqXJ4bI2c8EKAyeEDLJuXZSrx Df/urCoDbMLDN6NXfy0OhiRS8XsQ/3fE9yy9r7tsGnUrtmRDfm51ii1XWb1brSUh+M7Wq4xdfcF9 5xSjxFfvYfHVA0tywg3x6RU24enH61I0TTyiOXI0R4arsMExmDeLhpKhysEwsyIYzJsVveBwlQeY nGFCkSnWOtVNQ+Xxf2ets/zAVf1+v3q/2r79kygP8U93lHr5aPuEp0/rdN5IivABJJxNY2RpMm9s hFBPryK0Uxh64jTLcRqRfBWRKJjbBjlF+5ek2wMMu9zBZgJL0kRKDXrvOtjLaSi21UvyLUUiob1R AtLtn8H6iNJLikC1Plw5GLn5w5I6Snw/VxZmAx3ff/32+z//KHT18+veLjGsJ3FFy4aqDirNOtQM bcteXApzfiovokqruVSUjd8I4bCPpFzQv+7QuKF5RhEiBWZKRZgWpO6amgqxiLJ6MEdFvXcF5rLl z+TPp6zzJpRjKYNgY9xjzQmRKMGYhtQ4WBwpxXKePDVBNjdvNd0B04UYsiquYjEn3S8MixImHZ8h 9FOxmCWhEmDiW0ewYkHhJS6Ee3cmzznYdIqrCTW/PWxq9DsqNHNH7VT6ttPpXcHlLSV6FChIYZQe 2tsbhkAIRUjUN0pBlCs4CDA0s8KK+aLJu8KLzsibVWmAvUBKOVqKpFShRQijR+/xfy+icKKJ/FhU qNAiBBZ3OlallLhDe827WH9komAYxhJXUEnmY/TYXYhTDz+hECop8yMkKo6hHlqJbbuLEv85lJLU C249UIxKFQ9bR1JKqcO9CrHFBDOBY2stolAsphtH5tyQuV5jngdTREme4rdFDd1h3BHCanLst8rB xLiLYUWdxIXT9jkHewHJD4NoeIsJ6U/BPwGlQWBDd38GvRzVsbL4wKy7FwfobWUqJRilr0fP/+5T HEubLggQpa/16Eo+we2RoNnhTuIjRy1aI2jv0tieakR40tCUN/hZAYbwdLCYanrvRpR0mo//mACz vIAqHBARZWsU3dt6NRy9Ljlyd2hHlAGBZQqBkX5oQDjalgkHGBowhhUFwazIdZPnHOwFnNEzLO4l RqJyZ1H1g/OdzbqIqWRk4bgWBV85LvtWw4Niz9UhiqyG+w94xYijiCMvCc8FGGI0hjm8+ndn93B9 Gu30UDwSWV2MlzxyMkLpYpI7GnIGVJSE9z+Bui53d2src7toWJC5YmUX5LZglByVk4JOD4KGFIR+ yJM4IMJjHeyzDNbYyKCji2IvcYVGT9yTc5MbGcQGkoqST7v4wMhwnvSPUuLsXGlrO3cukjLsRBc+ XvR4giPmSqz6tc33G5UmdC2iHPAibFrFtRFpFvT8c5BDRQctf2M9MItQCxet80CcxWrDCayZKCvK 8gOFfLxZnSehVakXNXrsSNAJmjvWfg6aKXN7CM2h2O8BNKfTOYsxeilkuK9Hlu8o2jeXd/s9tn4I i0s8ouuFsC6U9BAQMv1m95OvAJfClc3yt9XmbqMMikCrKWYqDFKd8CHBHQmGurBvgCH5YlhOnBGN 6t+dyXMONp1PuRip1sNa7iL/b6SLC2bC5nl3kLaaGBGdToso0Av3WVliD9EoJGYDqY6mpIorwDAb FIYHXePoqNnAcwHGIad0q/JyQdCtlnqK0UOT5VKhMSWZLWikJR7QrTskM3PdtlfvpHlg017ipawO VPnQkOtDpllKUWBDE2FAYWwheFTHFoKi0L/LlcRoPdE9ftJCwPu7zzXQjq0+UlR6sjAlEU7cWkm/ hmLqAFvPerC8InwTkwXvOtgLrMmhnxWVWC9CBVwkcnT7Z3C0ohJrFh/IdQzH1fYW2SOiZHVEzuyX 15KOXb6jelZagam8fk8/yfFmE3khpwngJzyGIgk1VRrr4E4vKOciB7wUB8hXonRyf0K1ntJVnWV0 62eyjSFpnc2wV48iOr9SA43Zd+ujSrqZOj454jyvJLNHyfyc/1fQtoMh6WJYzs9in4nHAE1lxmaE HpucLqkHcPcwQZ8oDB4jnCykEyL8Kf307UIqwUkrXq3ILVvNagMzEtgOEm9CkhK51wWEx0mK8umz YkazCaOYgaJ1+YkYOJSw6QXAwAMZ8saXh0ph5JH0ddc166x96n8Y6XJc7t/TrHbV00dT3g6pLlqB LMOHsj/lOwwrxc6EGjkmioAtXfZ2335Y7e48v5NpCeUJZSaRHgIdqGCffQmwKNZJDpjcZGZz2b60 wcM+i+MfMpwp5x4RmI/5JxOwvRrQsvzAe+2VEclFTq8wRNQSMxShN3b+c+XqtGozOrgS0G77fieV Ml2MLSoPD7WXMu6I8ntJLHU1mw6AfogAOdVyojJ8xaY8JDBHQafJiyeMOJLAQ8KhtBuX/pt2u6II BhH5E00VK/qov7JBQ88YlDOqbZcwAqDJU5nPEZSeg8kRYlgGZ/RsO55zsNP9msfUEeEU6os8Qeq9 IAZ9+636c86NoZKJwNZSnJ2lLflRdRQOWcgkkRJ/JfJrAoxDer9GYBSExomCWQR7gQHbu8R74VD1 a8YPTaLvLFKUcJnza0bXvWyX4ji6oQyHHX5ynGX1nokJCBSP2FWGBZh4xBHMI9V5RPeROg1D0Pw4 ND2NbXYM1OO05cGa6BAOHSG2D5k8K1MnpJr2guAMcYBfJNN601JWNUpPYLDIbMO3pDpTRAKeXgfj 6AFWM3RK+nHVIZoVCjudaXpkNAz5FukD6fp2c2tnO3wg74FMFb9EIh7S8W6jv3d7zrjf2HlFh5VM XAiYAgsELykFGju/zBLJsFkjh7bwsMihFViWUUHWO3+ATXj+8QT7cv1x+ekggZCx9GEhY0CoxecU dTUnj8j4IQ9DUkcw+jnS+BA85kEvkAlDpzZFP5BjEvGXhpR1JP5UDJzBqWUoFnF8Ki9k7RGf9pOt Ju5tYaqsobZyjZ+bVIWuO2XTa+jQj86s+D7c3drBOyhQV26y3x13l7v14U20Hbrhy5RMiCcZyMjn P2YBBuH7nIjSDHli/+rnk9GoYUl/nMuNjCP2nn1OtG6SEiwK86UTX3xZpSXFaxRsZSKNlzSK0qwA HQVz2gL6kC+uDTRGqYdFbBi9GqP0NMXylEkiMmIkXIaEXK9+kRJrNDXT3qhDRWXsUJ50THf0wogY 87Fdr7s8i58MF04eHGe1VHDIawpWhZjEaMFBN3THdDDRLBEsk0kDsWTlOQebULKOjZ8xXW11dHNc si0XLxgMQU5QLOQQFgywKFRYEPWoGkq0dP/08gbYJFJVQ4VFSnfV4AZ1+2eQqhoqlMUHYtWWAj07 BogZ8OCIOVEeGYmK7pi9EMK3Uv/dFWRKB6ztPId4vZvXDVWS+RDy1FV7vSRo5uMOqv1P46WnLJUs pP16WxyJkHZjl36U7gWZYPX2h3Z/ScBDSkulONmOZdDdTRjcKCiVK2qCfiA07FalmB1/F+ul6RJb mh6VlQcU+933F+jiLUZcZ8tJYaliIHOdrYYBcNQIM4UH6Qk7ZvR6KQzrLIZRvNzripV3HewFPOgu P0rSVxUVEUn1IC4f5sEJwhwVheZUyIppo+hUsns3eQiPOpMx/mOEYbsnOCUBOUwa4bLr3Xq9+yix BizU3+klTsRkITeop8WH7iaZ/OEPhtnCPkl12oJPaUjxBUYED2t+66emyOwLP2JSMCBN3TQYBBU4 IQOHjjTMIC96I/4NDUCKhXQ6Hs5Dd6esPuBhH7Ww9b1322jAWM/J9m2b4qsnDc4HvEzRlhBzAMHK HtQsmKxKVwDa1L05I+HsYdNZAwSxxlxsHZh2t2Uo7kEI/bC7Q14fIh0XjBxKvOkpa3oxJw/jCCHm JLAEezI2EiLY6cd6inzzEARVMmnmOVbbdyier2nIXa+WxNq/Y/ppNHhQDyQ9pjjh3FKaYsQsEKoM p+hgHCiGJUQeowPN5DkHO/1AT2lZMltj9/SPG4afUfTgR9kFKaAnka41LoCTUAaYU0JYoDA6GD5x D5akiLvIfpPnHOwFumPEKw6TRsjODbVhpILPYL9FKU1FpkrTUExCtaC1m1SWTCNRKeN+QKL6pFxY ccpaiygSwQ6GNGTn/4aVnzs26DE+jELzenZlRzv8TaaAdDQrwxx8dD2XXkNJf8N9ktnIEIQBBvcp rGCiOQB9EcBnZXUiS4ekEYWRTMfLilHMKdLuU+sElo4WuMriA8I53Eg1J04bBQg2iSsKeJBY1OIE 1cqnEfOT4ig0bioHYRvwHzzlSyx8EvXc7ScjkUgbpZQN3pvVaH1Omtqxfa33xPweW94w9WYJXQzc tW6znvO6nfzlq/9izNKKUXqYdnZ6lVh2vWueqrVNW92Z7uh3p7yhORFdfUKLpiBqX1kTnsUfMGgY d0/J3XJrSawbixssO2a6EpfIazKvC/o1bNSYABy9uAoSWyYC4X51tcPdmzN508FeoFpG3BJEAN8I EGYdRaji8QzMSqNbZyLYxQfMqqrl3hCvaXgRq/QB8o6qQ7vJhzETuiZrK/97PDg5+410sMB+wXdB euvtnIaSx9SOhE2K0BNwXzwF78UtidqZ0E/RyDs7GOpaX67lPpRz0ojJjtQfrIYmFDfkYLCrGJ1Q bkRVBmPLyhBSISeZUcBfZezNWsZRfAV0+9b+U4xupS9fT0sUlCINKXBG4fspHQGGfo9hTOsQne/f nclzDjaJJIlEM4ccXqJi9gySRMdORherNCz82/mbrv148joO3AMKgRl8kckGhqc/n7moXZ7R0VUl ds1R0oK+2t7FHVIk7jI+LhPTUNA8EQ31YI5eMvfu5DRUqTYaxeJZaSjSRsqlSkOxrDdXO7hVVPzH HmNOKBLlezYLakoeIqhz1UQ0EveU8S6WkAdGjngfeguFVIAyj8oSghNEYRBpREQ9mCMi/64lQBVE EzSdiCZjVs2QCY2vEeymwXCBAFxUXeKR8uUZ5O6PFBLSGW3LlLNGTtuJixAbyGqqmIR3NNFpAow4 gE90ZmTOm/4QLgeatP6pDJ01yvaosn9++/ab+ao9Xr+9osXjrQ/2vaXy4/AvHeKMrR4PQ/eHnGUV 5bhMTJND+iBcgGl4jX56mRjAYLUoABLB0C1TuuX2bsc7bHra+ww6RvoPupFjDDj2URiVD256kvXe vEcpsU1V2xNKB+L4TBqS8beylyGli8JTNp3QlNERiRESlOw8kdmZJ/vdWg/vqwLpI6EzVMJq/msX HiL0033/IqNhvSkzWznoigk9aFrGCdkBPQFUdNit7+ynYnpu3AN8Yhh9KWXrldQN5hQbUMwWYBJj iWF5TjIq5hPedbDYBnueDIxDLxFZ2NHf94YyK0mcgT+i+v0yzB2P+SP2nKQAS4hUojAyTF6+zMO/ lV5Oc2ieireUI80p3DD/6cxBoVM7VrOLoACNNymf90LVB6xNKcii2kPdZESG4hSEhacML0YVMSw8 UPA+JO48ErQixaTt8eNu/4sU1OsFqZaTxiaYGJbm00vMdIW7SbV2MMmyBhjaMOOHMIDTkLOMAe0O Jgww0aWP5bqo1GC8HQOZ9iupU+lyM4xbt0FrvuK34eMKl1Iz3x08oJ7v+biKDpruKHBksoUoRFJK EpkJMM4Uw/KU4p2Y0XlXYFPFWCX5Q3ZeErrl2GnD9sVLn7rlOybdkNhTRt9QNkscM2xhSq6J3ayx c4tJHhaelGvCIB9B+IBr3iHJJI8dyiul5cIPGgpEAuH4z1oGGEQSwzzhxO9+NuGMVsaVomQXdIo/ QELncjB0QM8oJo8UHOsN+gk9AV1aBxfzXqiDk+ccCn1KOAKJLTqNiIH1hkYXFdZXH/AHpTAnnhgY SRAqfhcU12748PS8ouRWWmo7GJIhgqVMKiF90ZMgARabCieKzKcCf3yqYkDTnZ7Uu4gkCSw9SZmk mE7OpGYHDqMqScTZDNkZ6LEXxrFyupcFkRrDNZ0r/KlqakKjO4q06G4jlS32S0gkP4fOHo5SViP5 +O5egqWtS6bTTebWgCw7GFC6RJMw7rXbW/egNCyV3FIBi1mMMWBnRcr0IIFB6xGMivOuqDx6N8Be TuuxWazNnaMI1e1HNI7mPFxOIC50VmShuFQa1ySHdM6/J6yEZWy/jtMrGTmNnJ5k81A9oBuAnBLz e5dW+L3khAUdXcTjtFWfMsL5IuCAtTsiDlkF61yN8fcd7Zu2/6Rvmp+Jv7uvlxa64Zi7z9SEVGoH KesOpDDdq10ymDCNdZFW0aDH0F8j/QN8bU8ms+Z4zInMHggwscEDTPo7+HA4msX15swkS+Bg09ng 9Vh21jB6fLU3hxvpzKX4VnLFNOWNVUal0hyUoB8RH65oaBZgiA9fSCQwin3jQiITwU4/0FOsU4+1 o0hVnwoPr+dnUsHB1x9Fz/uJ/Hzf28F0Sr+FcRk9PS/PORibn9J2ltBZHXKKEWVbXtRj3JeBE5gY kZ5nB47GVQTZICzTGaJBEYzJ675fJIM/fbkzTvofrXS038oyq/MUTfqPGI8jS2wQxRUq1+qJKXAU ZmbKwgM5sGR8DaGKsDQhd9cBkaLdoBqJRnubN4CkmqArlpQyLhn/KowfXrSgz/JJR10LS2mh1v// jdJCq0NMaXF8Rz6++q6lElAMTSlBRvnxWazLX1ooEbIDLupZulrOEJuqQ6pb99epxZCqtDauLf+X MIxEmOlijD8MotbtZ3/JLU8Kph3ahJPuLLo75HUgvik96yhvzLpDuo8mAg/szjehgtOFq7YMIlLb IOS/U+KiqR3bQ8yccAhRWA+CQxQk46wYr6SZ81mKAHewF5iiw3ob+phQtvKVSfoNvFkUYVlRfAYx XBN2K6VF1y4+EMOjHSZduUlcnz6NUdiELPl96k8T89FW6RFIEouH4JytEd/uPpouSty3Bbs2lN2W sJ51GBeJUsBEew3JxPt7HQoLdNSf2GjnqsbChm/My9dWOmP2CwKQUSx1om2GPOD9bYYs5xfiTm8P sq8dn9djzlU0kJ1pCBPKE+09YBzxwIUUmaq0nk6nRnPy1zZ3xAfWQxOKMhjdiesus3sAE8f2PYPE lVxSwqo0yDTWvuTDVL0Z4mJzWhgq1IfnBJYsYGcRGd27jFYKsElEhs4QlxMNMaloPIPIiGIeik4l LyFzmG5k+A5tdXe3ilklrGdUbz04ZJHx7iOy0yrPc9FV1MbI4gM1JY2ujBYQvt/wcSX4XM8u9lld ClFBhw2jufFpoFLbMx1gEJDC0FHyeQ4+2d29Ck0F0CQ0pV9mH0flWWkqKhBXVPZpKrCpzQyOJ+ek 6lieYxIX32U2yNb9J0X6RCI1ZIh1f52NlibHG2cr9pA1lTuQFjZCLP2C8kX6Qc+uVYlh5dkzJehj IZtoFgErD+TN9Xq3uyJKFX0SR6iTFuYS+5k+gppBj1HQL8DWGFMuECgwpvbIOJDeuw4mJH7a/T3l tUv1zQB1WgYUTTEIzjsjcJixaQdkhY8iBVj0oaRFxZeu+t/5MhGMM7zQeY8Cl/pdT7pYRyReuH/R n1On+VISmkVqS8MVjcoG4q0zXlamPDJ3LbZmJpT1UTvHKAIkfXtWJGR1Tt9wLmV4Y0hYE50THfi+ 3TI2h/mWWs4wuSgK+U69g04UrXfvWfqI9AvZh2dewWNspKmAZiTxObDjpkoNRW1nrDuQQjKXiJm+ UZpZmC8rZZSa9HsWuR29EFqeAgwp5NuggBE5tLPZ43c97AWK1uEx4uBY142hr3dlPQ6eIvWQU+Ob W2dTcajUQzxBskidd7WKPwcxjfBdhKSirskoLNtO+qP9JrnEXL6j8t18jTfCcFYscvFLlHX++r+z 28rjCmVuZHN0cmVhbQplbmRvYmoKODAgMCBvYmoKODU1MwplbmRvYmoKNzcgMCBvYmoKPDwgL1R5 cGUgL1BhZ2UgL1BhcmVudCA3OCAwIFIgL1Jlc291cmNlcyA4MSAwIFIgL0NvbnRlbnRzIDc5IDAg UiAvTWVkaWFCb3gKWzAgMCA1OTUgODQyXSA+PgplbmRvYmoKODEgMCBvYmoKPDwgL1Byb2NTZXQg WyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMiA5IDAgUiAvQ3MxIDcgMCBSID4+IC9G b250IDw8Ci9UVDEuMCA4IDAgUiAvVFQyLjAgMTAgMCBSIC9UVDMuMCAxMSAwIFIgPj4gPj4KZW5k b2JqCjgzIDAgb2JqCjw8IC9MZW5ndGggODQgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0 cmVhbQp4Ab2dW3Mbx5WA3/EruvwSqcqEMVcM/JLSykmttxLLsZi4tmI/gMCQRIwLDYCitb9+v9PT 3aeHM4JAeuhyJaKOZtjdp8/9Nr+af5hfTVKZajIxRTEzaW72tfnRbM1Xbw+JWRzMxP53WMhz9seL 5o/FxvzXpZmMJ5NJZi4Xo2nzj1NTJNPxdFIk5qLiF19uzFeXl8l4wtuX1+bf5lWSfpV+lWQm/TrN zPevgb/6+2vzs7n8H/OXS9nPqGed8Nv5lZ/4vQ+v2U1hXi1fm4vJODevVq9H/MCvv5Z/yfRP458I j+4tJDWv5v4H/87xQl7OR/w2+bX8ttr/cPTPNI+0VnbPbuzL0TsXr0d2bzv7S9jTB/fE2v/WsI7/ rRP/aPhhbCHs6fib/7fjM84kGApncqh63pkEQ+aVO9PoKWdK/AHcmUx8ptcjpQpHp3nyLDLl5oRO R5cLEyipSGfj6XSamYs87yHT74UUuO6bWlDLD7JV/qiaPwzExd/kzPxx7Z5Jm79OW/TcxzdhF0LP eT7qssmtI4zj8Y5fahH8tf/hq84Px0BQO0v1UFagqIP8Jmg7oDi6dnf/4drDM+EyA2vcyK+Bv8Li 4V88Hyzstlgp8FVY6VrovmHBzp2WBXdamWkWy55UZE9i/0P2gKXpbDaukrwwm1Exnepf10b+yu9Y y1P2z1tzLcJoXEySWTmp+NmKLwFMKiCNpNK/8l6SpbNkXJajSKwhsFg5a57mzwrpOCtLRyuZF2mv jDH/fndXb789HO7rr81ytTQPtdnuHsz8Zl/Xr0eX/2kkWyRKdXEBcr1+a9FezIm9sJNxlc3yZkuO fFLd0vF2LiIhWnlobKSzclzm00/gpB7fQErR8qMnXMKpg2fpdFwVafKpg8+jUzd6ZJC7z4pknDYK UklA8b1cHe72u7vd/rjabefH2qx386W53u82ZreNKCCZZeNZnkK+VTVOZ9nMbEyWJONkmuQKW8cw lOksE+J2r46mlQcJnf9q6fxzZH0Ko5asq6RLQ8Ycdvf7RW2Wu/oAPR/N3b7+UG+PZne8rffuXw/N Mff1ol59WG1vzKHef1gt6rExf93tlfhTsDWZJnL0yZj/5Rzd8lyWZQpbt2HpdCaM7d/l7EiyBjbg 4Wdl3+Hr3+abu3X9pZmbb1bzTX2sEXieov2ODApknJZTDpNMpuPZNJ+NPIg7cyCeSsfTskyis8Qw J7CGElTJdDYuQZPwyMzLKyVWe0PcnzvN6B9OQZ3NKKeoKc1ZKKssf/bgdbO6uT1iYv6nXhxB7KLe H+errbmrobPtcY6y3aFNPJaTbDZOM8xSh9IRJMPZZgnUo1iOQAHL0ZsBdj7FfEYLoFfQDdawjbBq ONav9/Xh6DiiYZ6DsaK4/m1R18tw3vVqszoeYJF3H+q9lRWL3fa43637+KUsxtMiKy2/FOMin4AP DxN+iWBpgWyJ+YXnHOwZNNa6Z7GdImVYFPl4UlXQWD82FvOtJzBs+gElcYEcnMyK9BMLX9UgfHcv VLa7NvODYR+7uyP4/r+5CGdzvUNy3S9uzeG4R1LfrOrDl+YBeRaJ6SwpxhP4J6B5Y4q8gKc4b4Bh eMQwh2b36kgeizA/iJguJmmvpFruHracpp5vkNJLkdWIaU5Zb5cgozZCfIdDIE/le5ViBeoonyRC Y7hvWVXBYB4GPSkM3ZPN0ojGeK6Bjdbm+TQWUVY2q8aTMivkgvvOq+LhBWy8fFKMK2vWyOIdU29f X+9FXglq0XXKrQPdb+7VcMu6fPe3H1qHHkpPwMLVZFpaVsKx6kg0DqrrJlhwA9lwVTmeJAgqLjgc WAWpUOz1an/A3FjPsSN0CyVhhCrLU0gOE8Jp3TQbl5NCyLWBQYZJDEtTfIu1ab3rYAMqhMLTip4D t+C/dw/CiV9aLsR4gmwwp0QuIZQeSX6zqRe38+3qsAn2lpKXMmqOuYGzIowaNKGHwagKQ+2Bh4hR R1NUs4Odf/KWDug6RAUmXZ/xtK83HNCeeyuKT6QuF3vg9NZ2xFo+YgKIQFY5PO47cIbcnc0qOXCe j6e5uIIexoFjWDJDPsfaj+ccbLgDJ5Pugatxji7/y3Z5cdzZP97Xi/v96vjRWJ8QB9xbNHqR6WRc TtMZJk2ST8fEyyBrB+MMLVgybQtcHmtA55/qcxZNkvXwvzGX8CJM+IvQLCKP412IUjn4413X8+M9 dG0281/4/9XRXM/3ZrMjhrhcXV+vFvfrY9+lImXLvLFoZuM8rwpDxNCCuD4c/QDC4Y+N5pE85mBy +Od51JGyKZAL1QzFlxagoEvJenMvoGyKEjt9hudnF+8om/n28FDvD+ZqfoCDhFN2mxpM36wW87WZ r292kNjt5s/G/PTqO9jpa/NjzdXUG8X48/Bjg2WPox/JZFKOC6ssejEF5SuyBrT3kkmGfVHipcoN dZQU9vb8ar063Jrj/h6dgc4KknVfi0fuLHCQdbOyvrl1y7e7LbFYz5YFa1T4DIEMN9Y9S6eQilKm eHEB5KjQv/mYMocxCJK81+CbL/+DZsQRt+YeoufN9iPBJiDw4NZK3Q0Wn7hTd/PjLTTzETiOOUax sCe8+VEPH2RSieWFbmnxZYBFjFnOpuMyw5WPZG0EO18qfU65JGUPS5rOBYOA76zduxEKsHSgpBid DombzBKRuFPiqbNyZspZAxOJG8OSpIpVp33OwWKxMxrolqe9t6xneAHZkyXjvPHTydd440Wtzts5 2hufFIvlcH9QWhlSoOTgPk1KYew+BDwKYQ4pUoig5SlejF25I1IwUFZ7E3jsrhYhTIQCGyYSrQlh u6pKC1NW2TiZFBICSlOihERcAkgYxINS7NRcTFH/5qisAmxAnoHCO5a8IXS34whmcVsvfjmIMulI SSsWm7PbIxP4ElW/4+EvlQCUnabEHWZYmGKJYtBPUqLvHsa5Y9hElFwsLHjOwYY7eDrp5aIFfvFR fLWuDVaWeJpEYjlCmY9nNqzkYbgREWw6JskQ25amLAMslghnxmNPmWPEN0QVCV9wpA51EjXTo8AU QwXWE3x8/HzRs32YJFiyPayOqw/1RaNoJdi1wswXNVT/dmwcYmvn32GLbI+r+Xr9UXY6slldyAFl SiTbI1joRiLZKZwTYNCIwgKC/bujR0gfRvrCoX0Ms94Ry8YjQ2+K9es17Xf18WG3xyCGm+bHHZLB Kp2lhIc3q21tVtfo31UkMpVjStI8Ja6qcIyLYpYeJhwTwSYlma6YY3jOwQbkmKyXY/SqnU0VXbWS nh6rQG0USePJIApzQpWlg4m0wzt1sHRcFERO9Vg8F2AxFz1Nr0bmvKbFipRtXG5GFB9ELrlu/wVU KpSMCwPLwkF2cal8UJUqeREk8N/f/C+RuDuEkiGuY+21w/3VQULHcJIz2w6RxB2IygtP5bojIhRX 98cWTp4S4jklxKLQEkq2K8RWh1iKvURoiWU7bD1fLOo78ReIMDUBCRT9sr5b7z6KHDv0xZpgxHGR VYWYjViLEwKTHiTUHYFwVEpAIdIkjznY+Tx7CqlWNocEdETW3v493N/ZHCSSy6esVM+7DIP5+z/f X5obBHkkw1D7fSo+Qz/K9SGwJDsumbrSw+BihSGqSfxEnD0q8agc7PzDf84fSPvTlPOr1ZpgixKy yqYMkZtgY6LhffCwdDDR8DFsQrYuOgEn5bYbWCybnqbhI9mkUU+O0eUI3f1j0fQ0adjrvMc2RcCh CgLJ7TohT+mGd4qfaOufotxELe7ew7eDB8OJgzSpINucYrOij3YO9VrykA+3K/JBjZ0/J3RlDZw6 wgTBasiI6EOgHTjCRx49TGgnhjnaab3bQ09Pu92InnJ0JxFEiR41OP0jdV2OPZJP0XJ+8bauW+5w HL7UyNV6JyGru916tfg4/un1zypshtFu1FA4Ya9EXRIWuBSrVUSieYsvu1qKzUbMOQrInrf+KdoW qZyF9Imuj3b9Fjdrz6IRTw1H2xFPs3xH15k2T9lQ6dkZ/lPnTVLUWiKJXz216qJlvUa16IlHVGzg 5ZOvLSeQTIEXpaUSCkOT+lqJgvjvDKdgTVGqe9WBhsowan2EHKGLuei6hq8ii0Sh4k+pZl8v7xeU mDohbMlloLRbmuVUU9hIau+xfUQgLP40VdereCxz9CfHdJkkECdFgr4QTrTP0+viorBWVnS9GxcR /lLXzjIS2hPqSYhlUJpFKWgUDAiw9SgEAwSW51iBVGnF7zrYIKZCzNp9yNPtv4CtQIKLOKktsFAU KoF6M3Il9SpCq0tCZUsiAxS+rc2bf1HR/QIGBEVAOJlTydOwqa71JKEqXXjAXHVUjaDYUHFH4Qi2 s81tEoHvsx1C7UQgJi35GwVYVPIXEVjr3d9NYJ9mUPDaEzJUfEZUhkA6W4ucMudjRg0pZKWykL7Y 76R2ReoKSS421WOU+FDkstqLH/fVVb2tyTMSbXLbpZztiYbrqW0SJqa8rxI7Jwvb1Ot/MSUb2Ves 27kdvNeH+V4t1FGaY+jm1AMXVTHOsVQlxuSish6Efaog4p0ZaU+xWcObDWwoLVtIEZUEyD+Bul7y 4u7OJq9TRkqBC1hVmVU/AX9KXofVjUgrx72DW6OV1zy6ItYggkLd8sVusxGhtZjv95SgtZAxFBKi aFgGCXdY3Ct8LzmHrQTVSm3CJx4hyjpOFevBE7IhKeUaUs9PieeUSn+TTmZE3iHnAINgHUzaAMZ5 QjwE4zF+18HODzucIiShICmM6yDPNHXPkkcOqaImSKzkFOIQhSQXKXYS29f7kgHG9gOMioDZhPIe jgmqpF56JFUCDnb+kU7JNHukvmKHdh/DJVFsHxWI6NPvi56NYpyREqchA9eYhBqRzwDjTAqjzGxa tvKpUj3qYG2D6SkGYOQLp2mJ1CtE1ojwC5dFKxlNZ688gVOJGqmyp7AZ+Bz5djd+Z6sUNrKrdXHl fDWYJIFo/U+lkAFVVQYPoDbEMWMbXa/m5fKpkZJUBCinz6EinHBbMWnzKHr8FBN6klC1FQhHQo2u /ifAYAaFBcLx744+SUxPaY2IiCmqCepFpIqsZxLTKXkT1QQpLpWYDtQ2ryO9PyD9WLHQX2+CxaWH Vm/tLPyePKwWoOaUgwW2pV5c2NYG6gljHOs19U5KNcTVCX6Rvy+onKuISItYJbqQFDPaTz1MQgoR LCtTSeD6d0fynIMNKFb7C1YktHhBeY6En/CXyPuE3iCj4Cs8CPjjkT4hivUubiFS+Uv9RFZMbALe R+JRVQ1MWMZF7AuaKCoxDWOdorABD99XxWHMw7wvMl9kGGgZJTibcCUmwOJr4rmMOKNu3j7WgNq6 Y1ByDDUxKsckDRyxwXCRPM0M5D0oXO7E+5GcsnloMb+mLwLixLxw9dAehjnfgjWYC5kPeez3IjOS nWky4Vol3s5ROgwdoe+x6HxaGLzXlY2C/YpHFZ0ELGjyoEDsUf31HE8qMszFhovygL/+bqoSuVqE Qg7dDx7BeyvNm3aUFfpx8XLWQTphZanZs5vpWgcvJeIj40iRoDwlfcs+XJRQrp2lVTaSCQKkyCBm XzvgIJByDMmoIUIw+Pfs5AEHc5JhqGhF5Elxii72VtvF+n75Qloyo957UtDHHNNRhELcSjIbVNw0 KdCm3oZKnnGWpOhIj0yaHsZQQTOgAfSKRI0gHpnxewIbKhyQJwgmnLVP0J+SwWPJMEAUOqcILy9p 9Y8xqJyIZLXdrfO9LYZoEDigZUWTxJgUndQb9lJPW6+IizJQEIRcfY591Dp2m3BE2qFb5tHBQwVW oJyM30MuH8+8oSWJfEcQRzmt9yLKOU+Cfs5hpeW7y3Ymsp4kutLEFKTr7467FEEvUMytn5W8vP2E lKGXWJq5kTOuiiOAECoeRLSBhuNWZUChMGs9PcVp7dVclrVtmcyjHG7bI/9mZwcL2H6a+72NO6/n 25t7qfOeX+3iUp5wypz20JTibE7pAycmwBABPsCCgShV9lKf6t/luQDjnM9MRUXGQeShUgjWvU69 pBeQARkXmpYIRJgwVCSpDLD21eGuXqyIJls1HHUjDUTCjJdoXBxdVpLER3MLxYoEqunnIJlwVddb Kb62OoX0Sm+J1u8mumySS5+NRUjYmUoHgqOtERIDun06TKEoesqZ9vdreolokbMdDer2+QkIJpca 0QK5Bk376HWAQb8xjNsWz8e/O5LnHOwZ3oOTUhFNR4F6zvIH03ROAXPKyAGh6YBIJa71/CPUZJud 73YkUciXKDYHoumeaiJoOjJmg3n3RIV6Km6QILWI8kq4r+irpWqiJN7bGDaszaiOcSW9p3btzoXP 7+7WH+FgYn22yFDSNOK/Qc7ooT9HioghBpT0YpTkMtQiTyuZbkC6ifYAhVlx7GEUCNP/KFEMfVdh VhUN4q2U/eMNuNdL1GlPP2DUzWnL7YV9idpQcUOjwRUV0yLQqJtW6lMdI33yBG6El33EIvcweFlh 6KKkVROdk5NvQOcf/XNmRtnXcc7Bm+EOrt69LxpOZQtTz8h2bQwFAhmFBDmBjQaGCd2CpRMqEmM9 y3MO9gyZ5BglkkkJAjCHlCBRzvMHe+FJUY7TlFSHXbyj8K5kMMy7qw+r3f2B5BdO75KYmJRBNx6U LT63FVtWeqlJ8OvvVnhiZZW2UEusLBWTXK4Q8G6xWx9opZTRRV+a928vvzfff//tN9Ixd/n2e3O9 nt8cfnotfw21tT6Jd1vPpcortBMOI1vLUMDS2qvdyOARCslxPzZOplzVt2++e/O4eG7gc04Trzf1 nNNxwuJUk2AHkeyPyGAQCTcN0WZdEjL4rn6QNQ/UF1zTy7E0hGS7hqGt86DlVEK5dFvS62372KUF /M06muAyDBVMQ0i5tdWAGhqBpbqSzSiShlS1KJhmllDBTrqyxHeNvYyyjVoqFA9qo4YEts+xRZ0q XOJucS9l/RGv+Lb6kXgDkwp9ImrH5ZsCTNSOh1UkoCuid+hc36afKQxxPUDgUgTTtCfyK2oHD/Db i2/Gq/p4fbFcbeoLf+YLznr42fwQtWHZAXq2K0t6nsUnbOriA78GrSueWFHaGFt0VAdrHR9kU2Qc aauRvOtgw+ndaX/XIscn/2MH2fhzOycfC2Oxx6iFA6Xzql6u5lJHgfxejVExTTM04trGNnoQIB2I RXsEQeZhMQKmOU1LZJhUXY8yhQ2HAGisY0va64eMrW/oeju6/RxhbgjyJ6YGBqxghF6tln29aJm0 L+aEpChGIzJMaVtqAoz4Tgyb0CjcOj/vOtgzzJWuCxWlPHux0JJrQ48xtEUkMzuMRtj8sQr805t7 OInYahMT+NLI3xkl0AyTsi2yQ6v9KkS62gJ/sdjdsxF8iZ9evXnzBtr+fr5v5tId/mRV5VvbBL9n phUzVT5asdfEMofRRFWI2ejGMFwhO9GbbtlWLdN5657y9EQ0VsHF03Vhjctbhmsy6ipe2qpmGTiD ar7ftmyyJ+rEU45CFJBnb122FdmrRJsMF9CNqmAVKaoOgyRosstSlhvPqEoY21BJwphZpzKpUHSf 7zn1IMRcDKLFw2ZY3JsjeczBhmF9NJIr0+vFpGLxBSKCBQ1eJUT9CRJ7zPqD83kYj9gi666AMW9O s74yfNBz5zHeKRoXxpsFZ7i1QzV4U2coo4xbNzVUAiOR4HU2kTgPe+kan8L8uvCAVd9R1lKRoIz2 4X4ttRzWvBKjA58Q/5VBA1KoHG3IJTRRp1QqZqTeNlqoG2CwnA9YZozYmZECFWtT3w2wNss9xR+O ggNRwLKF0z+kVC4KWOriSlxfvPND0d424zDNX5sBU+ZfOFm7/Rdey0TTawYi9dAHpLtBxzRRidal PlGPnFJuUafFLDSQKZWJDa/ENEz8Y2abJzpZJo6qKw2osKI28GZlaRPUEx5kOp6MSSNTV/+G1SLW DQOTZTLqG1sKFXU0W5PePKyoBdvsDtFYMV/ShddGBeSEBqdIsQVYpNkkqDibEHOM6owi2HBG/ayv ZcBa9evVLzVxYlfHr0a9q4rmmDLFVMZZSU7K4gVqYJp0FGUK3lxaUUc3w/uTc4Pdmeg0D5NzRzCG d7aCqPKcgw147p56b3tsY8PjcstzJlYdpDGTq/8wX0sUUILFSNJ5bGFDCLYO2c6XUw2sR6cGPGM0 vBydOTx8cYKjexhHV1hJwXE8wWUkzRANqC1Xzwow9Xgxak3M+o6v/PUipkzI9LN4x4tZbenPkplx JIFuts2og8ZqB/WMLJZALHF6aeSyMS2qcoIp8UR5d8qmmKVUDeRU+KPO+1DUlndPuAdUIZ93eFyX zTr0nPbErCwp6n28iLzrXbkzWWUlnwywc7Zsb/IVIsEOT2QIdrgAFW80AlQlWS9onWIa0kZyQgeD 1mNYRvC4Jd54zsGeT+0Nlh8NgrZYJp/xuHi3pVJegOS1gayUdMpjx90bxebeNo+JS/Y+zu77UMnS daWbf//w17d0DZU/I3Lex19tGMTAKKm96+RCQFFsS6MMbNiuy62oAfsv/lBDlyaUk/4gs+6u9Ja+ ss0TBcNJQygEmWUnXVJ6oZFXWhMZIUCtE5JCZMw30MOPjTbWsyeJTO6UYVlSSE37DjyZUMbLT8xj cDCpvI1hDCloxr9F7zrYM3iym/bLcBkYvES5Vz8WdfuP2XGAGDZDNijKJ6BqF++Qunhqat3/YAdz msuPd7Wa9Nbmoctz6GRPyYjrjniA9bpsJmanhLKO7OuRTvyEFFEpPZCUCGHwlhviwro9skrv9LwN nOJCkeQJX1Z5LEorKxHdQGMcs3iORtBS5y1/yjqwy/eEGLmqxgQM87FleNFBs7C2604RoXLpKR5y rwWhJVI0xHv5rQLCymSXZHm5TuDQgSx76MhGsZZdfBr7jYZSyYfcWKfKVWUojfqOKaqhqJzIuGqi /9RaVFOqwAKM6H8MS6kilui/69QayXMO9gyp1bWbS34fI5qop+nHcetih47+U7FBlbRITMWtch4Z NvmeB9cc18cOROmhWEzXg9I7n3Kwua/rmkHQSvBuX1Zc2ZA/KSKbpr4aOi5S4k91ZDnb5IsSzKpn nnIU7VK+O8tyPyWJtL5LNtCh+Y67rCQ+0OWE0GzE7Bz7xaMkzCf2ukpXdonOpjfscUAkGhQYHAWG wzP3HmMDo6RkSFQFdwUYRonCaBGb0TEaxUGkvM3BBmHvlA9dVRRCCYv1YfVF2Tt8oyzCq7KbbYhd UtO1OOJ3za+v+aHhIzuER+IRgxvaac+gKsjKKjjHVHRzUL+uM1Qp4Lyyn0siE75hnv6Kj1IxJ5L4 0NJOJp0fj0zoj+hgGB7AFerjfFExlCu3rm2ocH/og6NMu8sGVtvqugNG+8NEK1nXHVrZT7NqREmk SpuqL6nxlBCdbifMqkoo5ksYxSFt8a6HIIDgvQDi63mlVCZHL3qQMN55l3hKiIo9JXV4PY45FHfF dziIpocZvsy+DLZciK4lfGWwLJjdjCBhmsd0NsFO8DAOE8OSgjwNdgKIs2ML5DkHO/88n7MPmb7f uR8Ry+0+iR+lch2dyFcYH+bbqHreb47sSk5VU26HevLdmBk55gDjEOxbYXRPtro/5F0HiyXk03yo KCGTYm3lUtbLddlRJY+i80pjj922AYgklc/X5Qyc8Iu35/gFMeQ2Mexwnchn7L3Yl5pgJwU8pfSK x4dWhodybDeN1QV8XQPvCwe/NdJZPlYiETZPRzBIqKMKMJjBl5FFNJO6dxma0UtHZ15q15DWsQVC R102eVE60hoeR8RtOiK2fC8fMQmKY1hC4oNdFF9LzXH/0aPs9HlytSWHegKeaQiyK9k0ckixnAxX 96FpND5B19WM22auCBN9ZbavfM1uhYkA2ZISwpb4YkPf8/rjFyrg1VJk8Az9BrbX1leHyDAaCxNt 5SpGEuarlAnSP7YUFRbLwWfTrxa3yCH/YPrNSpJBBV+9g4IChtVU/Kbekj+52F1fvG++bkoN1je7 99RgNdaXovYZ9PVonIzobUZzOQToHqCvDzYLHtWznrfa56yELIzMaa0WkvE+KSmfkZFKW/kC3mpL uLqZZhOkJZ2kfAN3vbvBmt4uB8dJmE3S2iVxqT0BED4jxqeoxCBWDhzSI6XXhO4OoY8s1I5HvP9C EWodFirLdnji/X+/++ffvonoAb5tPkoC4zIukSmVWG6Eo+1HVAMMxnawER9xpnXMfmtA31XYMxjb EVts4IRPwvbjrnVhrQjP02yq3hCedu5HGFQCCq0c2+a7DhEuB6QebXztx0Dj/wU8UIoji589CK+l rR5Jk5w57BM+4tQQboeC7ESR5qNhoVGPGbFjqnMKEwhG6grcMEEPI7mhMCUYfVdh55v/nxVUfckh q3cxFVfWK7NOPeaa+Khdh0Yq9/OMqRGwhR+UEmCwRQSb5G4+ondoeM7DnsEWXXstjEops5B9iyRK oAahhRZXnKlhTyFTR6XI4p2IfyzcY7v3PHVzihwtHYZWB+VDLjH4GvjW8tkp+7EZm5HpfHEFPfTA J98ERYMPa9BZEXzCoCtyXy7OH8a5y7odr/3IBxbl++vM25WWFmPeUrKBg3sAF496HPwQeunTIIMh uUkGLfHNdT6EGmAS5fewhOkObsSBe3dUKWwQYtdAey9SX5TYpwx6SBgcIyIwYFZJz/UOhS0MoHQs lfen8parw2K9O/DRzBczVWSyFqltOS6SrhP+6TTSqJwcUO9EgQV20dE79iMk3727lKojmD2K0STi 7EhoTLpsEuhGfGvmjjTfpHYw0T4RjAIQ7A2J2+i7HvYM8j0lOXUedD922zGL4WaE6YxFWbeDT+zt r6R2zn7gBkc7fONS8wWBwEMuL6CYzvMgDQLaIwkBzKPT5wHlXQ8TFP/j/wHM8QbKCmVuZHN0cmVh bQplbmRvYmoKODQgMCBvYmoKODEzNwplbmRvYmoKODIgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1Bh cmVudCA3OCAwIFIgL1Jlc291cmNlcyA4NSAwIFIgL0NvbnRlbnRzIDgzIDAgUiAvTWVkaWFCb3gK WzAgMCA1OTUgODQyXSA+PgplbmRvYmoKODUgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0 IF0gL0NvbG9yU3BhY2UgPDwgL0NzMiA5IDAgUiAvQ3MxIDcgMCBSID4+IC9Gb250IDw8Ci9UVDEu MCA4IDAgUiAvVFQyLjAgMTAgMCBSIC9UVDMuMCAxMSAwIFIgPj4gPj4KZW5kb2JqCjg3IDAgb2Jq Cjw8IC9MZW5ndGggODggMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AcWdW3Pb RpaA3/kruvKydpXF4H6Zly1PnKlJKp5x1srmYSYPMAlZSEhC4cWK5tfvdxroC0SYomQoO6kp0UcA u/vcb330u/pR/a7CQhVBoNK0VFGitrX6WW3U19/sQrXYqUD/t1vIc/rjRfdjsVZ/vVTBPAiCWF0u Znn3y1ylYT7PgzRUFwVffLlWX19ehvOAty+v1L/UizD6Ovo6jFX0lyhW714Cf/H2pfpFXX6vvr2U /cxG1rHfzld+5ntvX7KbVL1YvlQXwTxRL5qXMz7w9Vfym9j9VOYJ++hWQyL1ojIfzDv7C3k5mfFt 8rV8W20+7M0z3SODlftn1/pl752LlzO9t1Z/CXv61D+xMt9q1zHfGphH7Ye5hrCn/R/md/snnEkw ZM/Uo+ppZxIMqRf9mWaPOVNoDtCfSflnejlzXNHzaRI+iU2hnPDp7HKhLCelUTnP8zxWF0kywqbv hBUg98daUMsH2So/yu6Hgrn4l5yZH1f9M1H3z3zAz2NyY3ch/Jwks2Mxue4ZY7+/4Us1gv9iPnx9 9GFvGarVXA9nWY7ayTfB2xbFHtl7+luy22csMa1ofJSvQb7s4vY3Rg4WelusZOXKrnQlfN+J4BFN sxSaFiqPfd0Tie4J9X/oHrCUl+W8CJNUrWdpnrt/rpT8k+9YyVP657W66nGu1Ra7DoKizDpNBirN P3k+TIIomyfFzFNnKCpWjHtlF6tCRVnCsx2NIqPKXij9v+pjvdnv1GGzb1Zqd1hcq32zrtVtrRbV 5uXs8tdOq0W8F+ShbDydFwFst1ZhWsCBiQNxBA8UB1nCqcybM3mzh8kJPcXsjiTA8ROq7oTeuaIC tZzA/Pp4PQt6x3upzOb5VpAWgsKC758EqVFRzIskzQe4jS1uD5vqsL9ut81/6qW6qbb7pt6pfauq T22zVM1+5zD7NDxohTBK6Rg1oY2WhwqlDjvRA8+IkCyag94CE5wlMRZVb8Eh5KrdqkW7vqn3zb75 VKtms69XqwbmW9SK34GbfbX9WO9Vtd9Xi992c4eh3zX5HhKBnkE+j5jMIMbtCgl401Trel9v1bKF RJt2z9YWq8OyVld1tT9sO7rdbNtPzRLT2WNwNiHV4iKaJ1mgMWf36BGv3iwv9u0FPzwKdj7GJKyc 5Nk8yLNIKJcZyrn1d/XisG32d//9S3/62Y8qSlE6WYI2yON5lOUogwjpThNOYUBIvgNF8zzLQtEG 7s0ONlupp2uDzxM7L8akwNJPtM/UKiEO50kQF6HgMTfq1vGaKARUbbOo9k27eaUl4KMgVsFc+3rR QbWYbK7gNR6tVvx6rtTldbNT6+pucpEoR0ViUYm2EGld9bvdqVv2rnbwYLP5qNpP9XbVVkt87Zt2 i/X4UO9vax7YtBs8RKNlppHbNDCkdLhEbqvlr9UCJLHmskZbGMnEzz/HnDxkMNP4mILFPIQY7yCW pg1k2aIi1FvZgDv1hJpBLHeameM7keT4l9e+Pp9QG3h6nKWPnIYVulm1V8pTSot2wK8eO6t1XW2w e9dgqdp47JuU8zgLUlyHKJhneVSKAiliHCTEx8LQFj4szCMUiHl1Jo91oC/VH+JWe35FGrOnggBQ I/8IA85iOJ4z+J+dx3ynTBVGdJ6V6I9x0mt3zS0c410VZRI7pK1VnGBPYiJhD5EG5mFt8OqTEdnL kYc+lB/xM4HOZ9DnNn9fB0+BvRQrJIzlY8/pDdG07aJdoXw/tatPYtu3cGillS9xhtFcj5Thk8qk KLGLcfo5dDQb5MPKMrbV8NKZiuwUL5VpOC/TOBtgw6mRm2p/LbJcbe5rdPH91aemvpW9ObQkZTIv orLQXNSLrZA7ivKB2A5gRmy7VzVTOm77nbDKhDOC9JO+/2etfVqI2zIjUeMOh45EMYmq9uhqYhGV h/E8TEuiMZUl87IMA8TFwFYzD4ZbmxaZF8fwnIU9QfMcC0wpei8uNZX0QSTj5B3E4f8ZBCYMwnkW puL8gcXeZ3ICg9tODugZxCKMUVwRqTe97rGShS3duqF2t892dk+JRAhpg6hTEPa8DtnaVHVeDab+ uw1uxpKApUVICVCQ0239+6HZ1mvxPADt6hWem+x0ppN/YYBRSkscY8NM6OMwxFCFPoP5MMtM5t3Z PQb7cpuijQliOxIX3l43hPw3db3dqYrU6X572O2JWfXZiDjuu3qvVHtTb6t9y/Nvf3p/6fweJ1tB OieSGJj0HuRbdECkQ3RMAP4ltzAj7WpgT5CsnuyeKfIt+djxHYfdl6wzle8pxY8HSWKGgAoOL40j 5SRLGKneWeWE4p+Gzll4LMXiLkNLLN2t0Ln+Y3FdbT5CZeO3L1aNKEr91K7e4t7vdNhRSxzgfueI PdFeI8OTDi/std+BjnieRfeQ4Y9C7WJlkaGM0wFgxTHGeQc9xQcifKREjlWc8jWcBKQ6M/XFBtEL Q1n2SOarDyuk3Ggu4rqh/HtpKx7a1otasjV9nAdPvNbxlmOEOJ7ncYD1zHDVw4CEGAoviOdxSkLB wlY+TBJFSYFFNe/OMjIgPUzk/jycn9LyGuepYS6PtEorLZ3mkWB2zPXh2JVWiPqpUXy441ull+U4 niUVIcmElPMkKVJlYZIK8WBBiTEAZtSePNfDJjx+fkx7ZKvZQ8S/HbbYsu263davBAU6qOgwg2lD 5QO8O1L9Y6fOClJHRSGnxrBGJLlVZmCc0MHyOWnucnDqzMImUfZJiSeTF5KRzcbO7mT6GZR9IvTV XEdm/H7uU1vXV97607kzaZLNoyIX33H00OLPuIUfI1joIUpOYxnmDHqPeBJumdAqsy9OxfjKbGTZ dfPxeq+uKzj2g+Sfmg22Q9yXD7CvsHiXHeKXOLJkdNvtbbWVFJbjZaOE4FtCkQzPEF42SUoLg5d9 GJUNKdiYd2fyXA+bhpddShZsH+lwz3A8By9L0kXqOvCUxbkz0M3uFZi9E+usdtf4jA6XYsMeUV85 pcGzkAwz2kTv4RgB1fOiIIvLeRngG4yjYEkEsMD/l9yBJEDVv1/U84+TVyxyqfjeq6Ogwi+/eScV k/ffXL7790sJcjde8lhilHW926HSdcpYNinuHEWWjS60iNJ3FHuMRkCYP6MR8tDwqGMTsTWE39t1 vWyqLeWvV+q3TXuLsfHi8UcyzCk3KwrJm8X4WZQjxoqdps7Tq6nJ/O18vN723NqQZY+UcE93u/TM 6CeVEYsQ9YbotoyiaUE60MFWPgybHPFLp9t4roN9UaHGC8oKqk1hJGZ6FHV296JLpi7ReKkWh0DH s691LRwHyTBLbz6kHHL5w/tXk8sNhfsRAX8ja4mIf/fufU1TwnOkXxJy3FEofkOO33JkznGC3bpT pl/ykLQPBUO97pFe7x1vnYWh5CXVWOeAexsKSOLAPvAmLBJyjPWMgG4eFwWBiIFhs31YEAY5fE2m z73bw4Y2+zERmMfXcYmMZTrRO0Ap7WA0jr3w8PlExsZczkzL2n2/LCFzUpB2HdDTMbZXe6y7ZI/4 /UvHz49UxKcsd1qk86iMxXSDhyMSS+zpUfJxHsMpA+A8hgH6yacL+k0kez+f5RntmE6agi4Rx0Fr lUQJbkiUORgVKB/Wc5B5dybc53HVRPZ1vJqNiX2NF4LFl5Ydh1QTWKLXU6ISuGKtaFdJYup5BoQ2 dyAy4AX1TheS8piFDYXjMR69Jxz0KVl9Y2vjXlzuNn9fOCYoCoUJh48oMsKRFpNOOPreDvGk/Lq7 29J5RDzFm+JI5qWx2G5pKCiJOXGU7rcCPIts+k6Srf17ZBhm3aeTzYiqbRGXElI4NLh199LfcEsv BJGZjpP7ZHpCSgmuVVmQz0sy6vBxiAkvE9wHC0Ol+7CE2qOo+f7dmTzXw57Ayb2i8zg5pqYW6VZj OcqxenNsc5+Tz8xrneKjOC3n5Nikturw6NgJX//qqlnYtK5OPODO/EM6FHRNb139Nrn3X3ymQaNv gNPtLmpZL5oddRR6RaodAXq7GSAKVju7vHMKQV5PINsa8WtcqZVW7Qkdm5huhIBWFSjj8OE4/M13 b79Vt+32N2mf+bhtDzcKlt/tD8s7yUZYF4+s9DwOI7xzCkm0F5YzySf2nVUGJorawFISTyVZVzje vOpAwvDTKK+CzOaRk4j2Un5BTAd2nehaE0ROFHmlSXOt+BTzKVEWthrCEimTOyM0k+d62CSi69kB zvMni25I/iiKdFuEQ6YTXRFV1XV96V5R32MjTb135uA8gp7y0DSTxsY1c3uAmtqZsGmNVXVXbydv rSpsW9Fg6Z+lw0xnortKZN+isXzFppCVGzox+xqVqq+uJOXxqV7dqev25uLD3QU/JkeRrQ8P9qkr pGqNSl2hWi+lt4mUGDUDGzR2FTMJ4LpKlta8No7B4k++U1vcHOxUI9Pplkf6+KfUbI5yonNAwsfC 1jadtpNEq+/kT5fvDgPy7CFd8nrhIxGWaj0K1mtOM92rDg05jQdBhjeY0isU5zSV4VXkuPlBks4s TPRpB+M5WldyCrkrmlfsuxY2nZItcTPGley/vrt4M2/q/dXFEk//oo7qCw52QQ35F9um7JjKKV96 c6hAS3kmJO1C1gXla2Cc0IfFghJf+fJcD5tE+cYxXQEpWaso45xHlPPY5Tn8JrzBhFpJt3iPZCcr C4oGFY1YfR/YK/XhgFDv1ZpeiK4jAh0kPYySH3J4fqRAnVLJGZ1VJDIkfh/FznMFzXmUzvMQhazX PeI+o9K0opNmANMT76XC6HgmTUfdzXIWYbMuBmfImOO2AaznLPPuTJ7zuG0aG1fa9gJPNWmnRXcz 6yrGh5o+Z+qdn6pmJaXxV0rXlJy6MMLEFrkBlNKx5NQFx+thvrqgdlDQKecJk0odDGGa9PIAzWhE V6IQR48rDr8nW+F0MZ0Xi7DyEesgPnW1a2puWen8pXQ2lqgjwaBFG84tOeog5NqIhaGDLMyhzb3b w74oHf3ZSgattMeqyW/UeA7l5O4NSCfv/YRwdUOC4mbbVHvY9DMxVfWh1RoLN0k6uXRyT+1aoiwv vzWRUNnautOfyNR7bs3InYFBCuWzyQ3VLrhUgp+n01dOo060RVsyHWzRles6v5bsWXf3TZpd6eTH 05RkDO1t19UNxbN22VzdCYwbGtzg0p2yE28115c6j0t8Ru+aUp7cFpFLSeLcHHfrGg99qpoWdUcj BQMEXlJQhwf5/66mplit1G11J01j/Z0tIpiuIM8Vrnp9YxoP2NaEltJlur1tevr9uSxlQhksyHB2 I1n3SN3Ryof5aHZcezXqLoqzOanjFGtIR3yKA4m6w4MMaMt2MNSdDyO1pC2H/67AenU3iYCQITPB n4c4bRi74AZXSG7yDK/YiFN/bBY5CJdzEywtZjHL5mlBmtPAMIEOlnNdOSG77nxMlTiY72M+LuXr 5eaiMqPzFCdKTuhI9KdUYGLqSnR90UjtLe7Ep/7jZtViE3E6HIdMKBaaL8duDyrXxyX98FsuPzgq htO5A66xOqcK5pDf119uDtubducuaok7YHqlEwSAO0CSIwqJEmJu/cAaPQwW8mFRRGMdMP9dgU0r H7ZKcF8+/gczIS20u+v2sJL+WQzHutksa4zHdXsratFr9LK+Y5JRE6Mv3A/ELIzTmECMO5W4434S TDmQFpEnhdKeiLgwLKdx79jXcbzxHJ6ODcNk8SNPZ11LX3KzWxNuvN5wJd24O9KPft1su5vUdB7p rq9m86u03k972zAPbE7fyS6a8djoStGmuxKw4fIjmV02/d1Vl6vyN0vq6nCz2+NfrKfeazieeO9u 9OhYVXs0A5JOlWh36cycbRyJexcv25WFa5/Sy3EqZObyyDyIJWSWHfSc7Iimz6+uCOu6i/c3NyQL xZPGSzF8pUsTdpPTpMq5vGG0n9sMHHTTcplWt0Et6YLqGKJvL5FOunWDA/FbvWGT2gY7XpnQSLgW BdnlsfBL9teh44k0O5U39JyoMTTZizeXZHxlI10xYRqnJxzPeHfjBqQaQzCyImTdd/MaqhWkWFOS /EjgpRtKBTvVbnfAs9UXgiQjpC8fO1pNtNPU0GbAQf1cggGBphJn25SF9THs69k+2zXRLy7W+3Gu wylJ9lwHVj9iy95tced2xj/K8fdIPeE48DENYxxrA8Os9rCZwEK5k+87Dg4mhvU8yp3ibfHAJJM2 nsG1to3k9KI9bFFP3p1x4yiwe+6PxZBAThRzKYJowMLkRAYWltLt6CeZZjjXBuZ702cerSeQ5ypE YUDRnoStHOuIKs+rKFyjgodTJw1m7kBjqsjTxpgujhg9uY3OPZZ8nDSc4qOYugM3xrRdG2Enbddc C+0skqt1TAlwbEKUyWioMISUHus4mGMT924P+6Kkmsc6SUROSxr0/j94J+H0lIdI9o/yjrkFJzn+ btyLrmHLXbypk2U0Iht15ngXX0DMmymcD/InjqEeafVPMVQkE6LilBSx7OdYPw0zJk8KMEbzqVEq 2jnQdLB4cEaly6+p1//7bocvrftdu+sbDgnobJoqwkglcuUanYBajBJCJMZZoe56GAmFHqafCyO5 Uzp4tQNNqObHap46f2KuC5Mb6w+2b19x4RLvTnJ3pjPfeQxO88vd14D+VTS/yZNLrkvDOI+DoR6C 3I8RZ5QuDWwSze9S+3loS8uOcs+r+mOySEUKImBXi2cnPvqyj9wkWNVLZtsR7IhfxqStj80GrPfX ah2CzzPsp9wTMeyRLVm6nUBwEmXtloSANLXipuDVH7gXUrEL7oVwF6mrm2317SNyuAzU0TfHddyx U+///s+ffngz+VZt1Wuw1U8ME1riyjrpmlDFuL76nGTMiIoRX9mu3A/IPLvh6xRxXGOprHzkpUiy uueNzou3m7Dtr3GJ9ipIuiB4Uunnsq4yMOyhg8kgDzoHUC6mczZ2oOmUS2RrQJ7EaeXi3Wjrkg0j fQ4SyNQbqWTqxhkS9o6/rK6RiWMM95HrIPZam4WhTs1VN4HRZy/XQcy7Mw82ia5x08dyTn5EQMc1 4mE9JYdwyjRKTbq76iaL93zrxEYqG/rOvAi3dAiM118chh8pUqcYm1u10rAhumcMLRKverh5ZDR2 CidcDpqXsfRKeDhxrLhtdr85IaI7VxKbiWaLnqUY6iCjEUvlsdQA1rOUeVc/18NgqSdWxz3vExEm iJKBKuO4c9t/BpYqmIhXyhw8H32OpboM1Oqu3wNxy0QGyt52d2uhNKxRIoVhjJIYK7lo081y6w0m qbGGpi35FZ11uCoy8oRaxcTp1Wi8emzzC30GyFHoPOyc5GcowUSCI+EGO6/VrlnT90FGUA+dxJ73 Y6Ek38vxt7cNTS8mXQgObegniR+HnAnlPkXTFnIbQ+/6WB/qRiSHnwkFP83IH8hoAh9fTvD1bFjt tPdDAWEuqYF8atqV9CaMXWLo/B+HJzsZIk6xQPToY4FkjnFZ4u9ZGCNxfVgQMlnXTZCYyXM97Hyr e0rValzbK6zuxNro0rmO5ieJjKd52HUG4E5dHWQ0qGOHMUtsUz7u/MaKMqONkQ8BWsKblmFh7qw8 R1/YwPz2gAlPbov9909+2+xNOZtmebd3KuEk3SRSsZdJ4x6Gw+TBqH8XeqKx966FPcF7eFDM/apv X3iEiE5aPH2PmZnEAXUTChgAbRxQp4NlyogO8YlOXCPPYEdT5XC9ggg7OXbCrZLtV582ietuXnh4 cBzVJ3HVbbPqgjSu0NMXTWh0WGkrRe87Y6X0ZFQ9qwjH1XZSmKnSsagFzXgxc6Z1E68BITM+KMlJ BYvz3k2olqcENGmVOB4vt8NwH+q7ltuV3f4HooMgMOpXZmMxJYXWaaRD5jAKTETHwWRwHzlA53jz nIU9XXQ8L8lNfss5yTG7uO17UqN59XH9GaO5IdfHLYv3Vs5JjS0E/Q2fpP6jksCZWqbppx90ojzS 9j6oQ2xh2jEvJJUkg8OItrqzSfSHm7eaxyMF+d2CimWX5cDlX7aLg4yeMx1f8JaZh8pIOfz2hLth xLH0SEYkcWYWhij0MP1ckjCdyc1S9WHnG5aHMJmM1IVLPIJvpA2lIf3KDDkn49ZEyKikMgqkLb/A +EWlXDMwMGJvH0bJQ9ryB+8KbFI5T2zhcMARl3DEVbtatbfiFNzULTyq40R9NnzF3eEDNd1uVDDa raIt86qulx+YoNvV5a1v7fbP6WigEtPKVB+aYmTAvIFxTh8Wl9HAM5Dnetj5NHzILUpG6nFIw7LZ LQ47uc/nZMIdIqeXWyZBrd19iaiHQRgae7r7FxFDborBTCg8TwOaSMWZ2yI5B/mzVZydMieLj6i4 arVWX/XKbU4X+ld9Y8vnBpPRZqQ9b7hNggDnVZ4XIz1Ialvkc3oYUlfwdDe2v93+l1QtBtum9+Ur STkZ36JedpkpL1UlAeXke7X1hMFeu5iVPcpQHrk31o8puqpWDOq8wy4zy5BZUTqGsqjvzzD5Hm3m fLhHWsRkdrrk5/x7bNt6eViIJtGb02gG3YvqplqYIfAk87B8tXf3YhrKUzc/Yk8o3+xlA3Ire0Fi XW9Ltzsok0ruYCOtUf2wBW++xEQbtRneAUqvtu1aZzSktWexP+jWDWhO0CYhDEl6vXlpjdccrHPz zYdGpuvDE4LTqYnPxOcxlA5yKz2fyj1BttAPJmOrZtyiVa1PzIiNOl6Sk+v+2ETu9ujZtWExcLqq dsI83CyTlBzLHmliiOScG/5MkOn8ibieRFiDEWRcME5A10KNfyDzmi0Mw0gjcQ8L57kkE8Qp6N6d RYRoPWw6w5jaRJaHPHptlfp2yw38t4u3h+3WZPn8EEBm0khqEOtoL0QbGNbRg2X8cZ1hLygDewzs /JM85KZlNjd2/yR/rxgttlOXu8V1e1VvGm9qnjP2gdw/oriM18mc46LAKcF562B4nQ4GEXA7PW+N 1gULO/84D5mxbDydAWF+WkGZa/VzU9sebJ8wIc4VJWaJzSwRDMwnjDTrMqx4EJt5sPNP8iBhxqIy zWLf82cVLr6vFjJBWF0y056MrdNgljaMWZ+Hpa6a28YhC4M2ppmI4dQk/khGOU965sHOP9GDtLHN tfdZ7QdcyXrFn9Lg7vlY4BzSS0CbmPiU9PhHKUphZmFITQ8j4OcGwODPTnmg8w/yEGly2+N5/yBv mXVXqW+2h/+ov3JpqF1xu3CMNPyNBhoSRWosFXqQT5gEwsSEdD5hHOz88zxEmNw6qCPngbnUGwKd MW0mLXbIuASdTmh62EBo6EHJQoI6dxJObmHnn+RByox1uGih+UfDJET1vlq13sUkJyt0k9B9oaPO flRSaECu4CvqjDH5g5jTwDju+cd4iCD8QYDef7hPkPeHHR7Xewzm9QGl7M0OsWehVYQhMczSgLv0 5JyknFkY7NXDRGrStJtk6t51sPNP8xBRihGTT3MhBZiF7eSQtMZYR6SUoLlbo3s8zeg2C5PD9OPc 5BYyU1F8tTzzYHKYH/8P/k9MiwplbmRzdHJlYW0KZW5kb2JqCjg4IDAgb2JqCjcwOTQKZW5kb2Jq Cjg2IDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgNzggMCBSIC9SZXNvdXJjZXMgODkgMCBS IC9Db250ZW50cyA4NyAwIFIgL01lZGlhQm94ClswIDAgNTk1IDg0Ml0gPj4KZW5kb2JqCjg5IDAg b2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczIgOSAwIFIg L0NzMSA3IDAgUiA+PiAvRm9udCA8PAovVFQxLjAgOCAwIFIgL1RUMi4wIDEwIDAgUiAvVFQzLjAg MTEgMCBSID4+ID4+CmVuZG9iago5MSAwIG9iago8PCAvTGVuZ3RoIDkyIDAgUiAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PgpzdHJlYW0KeAG1nFlz20a2x9/xKbpyX+waCcG+5E3ZZrI4cWzdTN2bpKYg EpI45iJzseOqfPj5nQZ6oQiLlAZ2FlN/AQROn33pfqt+UW9VXKkqilSe1yrJ1LpV/1RL9flXm1hN NirS/2wmcp3+eN79NVmoLy9VFEZRlKrLSVB2vyxVHpdhGeWxOq/44suF+vzyMg4j7r68Vr+pZ3Hy efJ5nKrkiyRVL5+DP3vxXP2hLr9X31zK+wQDz7Hfzld+5HvfP+dtcvVs+lydR2Gmns2eB3zg66/l N6n7W5kr7KVrjSTqWWM+mHu253JzFvBt8rV8W2s+bM013SV7T+6vXeibvXvOnwf63Vb6S3ind/0V c/Ot9jnmWyNzqf0QaoR32v5pfrd9Ak2yQpamfqmeRpOskHrW0xQ8hqbYENDTpHyangdOKno5zeIn iSmcEzkNLifKSlKe1GFZlqk6z7IBMX0pogC7b1pZWj4k3V/CBX5SCBd/Cc38db1/Tbknz0N6Y99C 5DnLgkM1ue0FY7u94xl6gb8wHz4/+LC1ArXSUo9kWYnayDch23aJPbb3/Ldst9dYZlrVuJGvQb/s w+1vjB5M9GvxJKtX9knXIvedCh7wtMjhaaXK1Lc9idieWP+D7WGVyroOqzjL1SLIy9L9OFfyI98x l6v037fqul9zbbZ46yiq6qKzZCyl+ZHr46ws4jCpA8+cYah4Ytobu1RVKimrKu9lJDGm7JlSKgxZ sMt/d4Yr4VdRGZdBWedhFSFZC5XlYYagJbxvj833sTQqMl7d3Kuv6zHICN7Kmh99e3Xk7es47yXM vX0ch0q9aq/bdbuctMjIfTJUWUUh/2WQwaciiXPI6LFgvo8l0LdHBtf1mHDjNDKOMaGG+52i7JEh hPy0Wi+a7exd65MUHJJU5GGZpwUkxUkZ5nEaq9JgCJCPJXlSeiQFcl2PnU7SUc6Uh5xBrn579e1X SRzXfyj15bqZLtv1mXodnqnPfmg/qPer9XSjrlfo330CgzKHZ0lRCoFVEiZxjeYYTDTEw5IErfNF j+t6TETPc/yPkEFPb1JWs8qTGPWph8h0r8+jkPIYFa3QulGUNk3zsMhTwgx5eC82qdXd1fa2Xau7 tl1vkJ5vWUsrLKfJ6lHG1lGvcu6hMLb9s1nczdsz1SzV6l27nq+aKRHX3Wq9Vdfr1UJweSu1vW22 qrm7m8/ajdquVMNVzXyhlqvtyK9K6GdkcO9Vb5vldN5O1dWH7mX0a802arPb3LWTrWf4TluxI9pd Rekhm1ixi6Vqtttm8oZFWcxubrciNoGOFJ8moToUuG/j4yILoyTPVCLvcWAs1W4jYYBRt08gr0nE 4qdx2b3Agbwirmq2ROfFyq2WTgRGXIM0YWlyVPAjazBbeksQa/c4jqrmeGCdfHgy4Cw8plBrwHfL 6WzSbFtHe1ynYZ1hpUvevCiTGquX5EWYFZmHYeF8LC4TjJ65NZBbO2g0o16xiIcShCi7P6/at7vZ ul20y636sX3Xzjefnakvv3pJPHKmIFiJ8T9TL5r15JZ3rcvQUe1ChTgN4xy/C9Ul61WTc5UGg2qH JZjCqvBsfVDGFhuR7mqQbnFmeZIUOLOfmvW2XZ6pyxBDN1X/CNXF/F272a75Ce/2991s2s5nS0we oq7+uZ5tZ8ubAdKLugrjNBE/nlQpcWEVK4tBusPKsBCtcm4uKFjNHhPS/xsFknzCc3h5ihhWcAEF qqKDUAWSnQkZyWbC/fsRkZMy+WSf2GfVJ2vsQw4uJsVP4lJbivrQWn538dOF+mq13MDNtbZXG/Ua l4HhwoiJfBtxT4pO3EU8zpxhL4sQQa5TeMqKxnUsfK5j2IZDtxg89bE4rlL4bO6Fz2h2h40n4nE8 KOLemr9oPqiEiN3zj1ZjC+QyjnIdnRF/V1WSBxbDKPWYKgjTiijbi8487HRyjvncOBsQ0y78LMo0 RWO/bf7drKerM/Ur4efF+s0bPn7Pxx9Xu5vbZfuh+0mU+e+h+v/Venk2pK5FFUbkUL6lKgzmWaqi ICYvy3pPXR12Ot0PCa9IbZwfSq3HQz5+9vWsWbRbgo4vG3z/y/Vqu5qs5p918iqLc6Z+nmxXV1yR RFjTQbIJawuCCqQXauOqLFRR9Bhk+xhpoJ9ABXJdj41IdnVINjKXEAJ/Z4KL/RTKhjxOhklp85R0 eBHExNgptlbx7h2GDPtYlEKxM736uh47nahjMkxeOmQDf/vu/Otw1m6vz6ezRXveJu35pp2cr9u3 fwyxCtOdx7FODNM6TFJqoYXBhCoPi+Jo36FwXY+dTtUxCU3SY4bmcjO5XV23y9nNGY70TP2wWt+u luJdRT+1KqKTkmlM1Q+hejmbz5sPg9oJb+u6SrQzpXabYKAKg8G9ysOymrKG42gg1/XYiLRnh2L6 Me28+PVlF0GJh9kRMHz4Qr2etMtmPVttNO1erIXbGeJ9TJGmImRcqJQoPM2LRBUGm/tYFtZV6lvl oIgtNiL9xTHeT9fN9fZ8ULrPqeT//owawZve9Qe/uOpSEZVhjWsVVuPD06rKlMVgq49lJaUfx2p9 nWCUfoTUp8VNXrSUEsNFBUlfUiVDBNvIRR41dnkgiyjHSZqgH36Qbt1PzSUB32xmGy/3fhr9g8mn eKRkqEKiJFxy6zBizpVnUqFE0PWTD+zn3Xp1s243m9+fe1GZrWUWEeXoHDdNYTALKW9iNy1GYdBg OSXbGmPilTx7qJeh04Lgo6bSllpc0rhvLl63d9t20bvqdCgyy2tsYEYjwPNqFvO8mmBZhtB6iuFh p9uAY16NZPyAKxB1z6sZORW3thnya0RTYR1TAKMemJWk93Ei9fIOgy4fy+LC99ZSZg977HS6jjGL utyR3PjF5MVuvSaw/KZLEr8M1VcUza7a+ZwU0YZlP5vqGYnGdr2aDxj2vEROI1pGXvZgMRhosoe8 QE6jVOoCJswJPGxE4h9TGJAc6b6d3+P3Oca0s/SYiSHyiySsamIVIZ8ALYtqhW/rMCHfw9KKQvEe +QneQWMjkl8c471nd/DnR5Q2yHPiz5J6DsJdVmEaJwi3wRBuh2HtysIPXLjOYhA4Tp+lSgeSYVFa Mt4siqQA8o/mTTNvuoDtBXXNmfzwo47eNm8ofEj0dv6Sn19vd2t+9aIP4L4fyi/gKNEK7XcvcLGY F7jkRK9VVvvePPCw8RicHc2OXdroNPmrdTudbc97PVYXUvSm0Ee1AA2QYpis3VDglqcIc1qIH7KB m8X26EeYafr48s2tHTQi9WTzDxdjLnY3u81WygP5oBNKJJ/CuUh3KqUCkGdBbjDkucdUniC7VEw8 gnzsdIqOOaEsP0ytYE9LJfZPdSFZ42azo1g3b69pX1Cxu94htq2SBsHsumfiZsg0xbSaatyNF4fm BoNNJg7NI3r0XQjhLLPDTqf0mFvKBjJjNPeSsvuV5P+b1Xyn61dCpRTjjSVWk879qOmKhaA7A4Bn Us18yCNl2NyEAqTQbcqzFoNuh2VhWVAw8UQWBTbYeHTTWx6S2bsV0e7VnFEX0/Iwy68ySQdzjOmC dJ68MSZLMBhh3R5GVd83Ovq6HhMSHhlC99LqpRDU/ytS84IoFkIO4yX3+vdTiBEMfhxRkJSeuH54 v4qugzZp19uG8L1rXvVdxr3+n21rTVa7OSMT/VI/sfE6mFkw3UDhTYf5g5zeb2uNmV+QP0eUNz/C mQk6JUtyoZY7HZevrp2KNbq/uFHvGU0gsqFhIJqHQn3wLIkQFiWVFT3EMaPgWyf0m404oj17mBHH /t5ArvPEcZxsJB+YtcCSPGgidZ2C2EeXGKW//8a4Bz95z2SmIoNmjEciQysFlPaQ2IkeKjGZWezX UFXWY6OmXflAleYilGGMiyn+XLNM0dm5xhGo5orOnW53NfObFWWa28XAyEmQyYwFPS1IjGnToNWp shge0GHYQup+zjxymYG0dWTc6L+em6lyPTkQMMC4l1le3kob3PdxatpuJuvZFS5gtZx/UIu2WXY9 rEZtZtLxV3NMqvYlU0+K+VqZGGIkiF5F1fU54FVnVA0mfsFgWU2HiVKdIzzIHDaiXxjOqS3z4PK3 na+30EZNGF64alUznTI2sNvQutOukrWZ3SzbQbozGh14ExFp6/sMJnT3bc0MLC4p1+zRbbHx6Cbm GvKH1v23f2KONtLIWrQTJiRmmwVLIWHCsn2P0zeyzY/DBFMejymaCsEZApsxg0Y5ocMgzmFZWBS4 Op/g1GJP8J59BOR5TwbTpGsuMw+DZFuP9EkKcPQ3spKgXD/8oADnzzrgGLt5j3EMdJGYkMc5awx0 c7XaEbxRepCmvB/edcbMM1dPi1sGHXRSVaRm1MhYhqGKD4VHx4ZYhwajdHC9WQ+3Hs7IXXmRn02j mbQIC3ymGOeqCBmWI/IzGMa5xwLBKCxJ8Lp3b4+drqzH0hMpHg8kXOv2hkotwcNUvcfRKGlHo6Sv 25b/dBd6ozImuaUxUg4ZYxkJSXNdJCfXyEuGBDODoY8WizHGKTVDX0cdNoqOpnSCs4LCDfIxVDlz wnE/wh1h5jIloErEWOmHH+jolr4ac2lfr173Qa5by0dqyEPZGaMBNMrpunxkBSQhc6swZgjLYDDl M5nmGBI0SQKpusoYz1SLmKM+oe6dkVE6qaFAQWRTlXhuT5Ic5qTG3BsQwhnpOl1jHlpIvYLDBUi0 5W5jQk62YLhkT8aEEnzUgqoxHpiB0cxAcwrEDoqJu50e6Ks66PSXP6ruAzM1F7p5fXEjNvvnviIs 0tA5DEtHSuDYTUrF9C4IMEtlIIyUD0U19WKPELlMsFFD53K4TjYQV16vJuRoElUqW/mm/HJ+tyIx ovq7addQ7YmeiSjFcOQFY1EEGvj5HBdjIcjzoIgYwKM4kMt6bBQTljHmgKsQEzZIt1PeT2DCvASY hx+YsEXz52yxY5eOyb3HCTFooR/UAwgx2utr/I/uqHU7Bh5pJh9UEPJhPLIsMln3gVe8bySJJEaJ I7xJMEe0iyMmjC8vt78/twtsx7NUWlIhyDM9cRExfMtIjcPmAWUlg9FOZOAEETWjXVxnsfHMSzk8 C2UiQclr1aa9a9ZkstRxTB7wnrkKyXqMLxjSRRlhwm6KLvZZemogMTVd4i5QlJHwOusTeNg4uuja 3pB7mOk4Pn0KXWQ2taDmi4japXYhuJSiNrurDS51LwDvhuMZ5eBfdU1WdcUsuMu+3HI/UpkedJWk m2WKs9OverhM+1G5rmOerE0PKnEpA8062nNL5LSJBEWGYyWpFkZ1Po4avWxpyYkwrJRljFaUKInD pBLmYb2cmXvvy9lIVnB4yE7vK5CxXmN0XbiRytAbm61QFFtHNphfW2Y6i7EDGj9OVZSHPUFVHuSK iEFpnIdjBxbd0eDpy1i2NY3pXqe4cP34A4cyb5v1cu8FEMRRxFDa5lS3taYO0S2hr3vwiFlpTGrF xIFUjVnwA72TqrF7LrWhKioY+k8lmIkzydfIprO0qBzENEoHBXJVFLPHED/i39ljT5cZr6LCOK2E yx9dOPfynrhoro3Rj8igNGE9/MVz9pVxnt18+4mqGG7zyqCiUN13pI8oLwkVsUT47ZPsFLTRaYF1 4N4rmCFVT3TMjhArOxicPawXFDvg6gnUeEGI7MO/H7xdhCnBx9ffXbz45vKbV/+6/Pnnf335v6// T03mDDk+1GVNUwZ4cLYoRiw6XWMxLSbFGYsVDDbqrbMmYwpojhvsdOoe9KkwqRoeapXyqSm8yaxE N3p+1d4272ar3VqmWwZ8Ba9KZaQIIK4owrxiu0DaY+i4h8UMoZHw+b6CkKvHfL0fQQlpylAjkzB8 kNbG14Px4gavmsdjDwRo326amlxgV0uaLf1OKov5wu9Wy9zLSvsr+MSWpWc5U7cHbHDhnADct5xj 1LkIJ9iVIY7WLZ+znHfrVuSQJHxNHn5D5n3TF7y8oZxxQiYK8Qd+nuxZ1J9B74Yt/aYf/8ho96H4 xmtk8/wD6VGfynqzgYsxFhIelt3S7az3ocGbed7LDpmmjDRnWDUxcgy3UfIoA4uJHegwJoQwaOxW wA5491rsdCP30FKKJ6rsdmNHC6HiZrVo38um3t2SXVF997CdwtpvkSu7L5jYSrreMkqC3aO42W34 VLer9y7VMVaaGT4ag0mkM0szzWgxDJ6PUVDcyy11pbHDTif+qIUf7hvO0RvdCzRdUyfIHi0Y9Ahn DiP7ilzAyQkdBiNNlU6IqiN6xJ5B9zDfoD/ONnjmyNsOTAn4UCXc6983RyP4kLik8Cx7+JElu5zO HL2m5DebtOpC74r2VGJEkyByjFwdEo4hMvuivDXQzfZHb99/SJY8m8R7HNhEE9P1W+e71vOkkRoC x7Z8AhvpedjBdVmupl5ONOZey5TgpsrZp6E5cpATYSmkArWfTzOZVMp8fsIEd8rBKahUQmpSpRm9 nB4jvPUwntFtu3O3GujpCjXY8WTInmfF4mwHV3K/tjJex9OrBDuJchaaCt5u2bxrGMhl7k2KfU6O 7P5xs3asJ5uPST8ZszEY6+lhZvG8Ww10urE95mnq4f6nsbF6hFbt7qZ8wPy6yHpzKwNnff4gpzu0 yhRlcPZDboYB+aogQUCOzCgK5ZcOQ458jKaWP5gayHU9djrlD5kGbZuG+1iHIYM+U0MIbNdr3CxT OUyV4ViZT9KrIky+1yui48lUte7+ckIUe3IJUHpIPI6FMNJyuInvhaRjCIYoPEFpepo9L5QRZGdS F0dVhgh2EnrfCz3O8Q3rKZSyQ1VqGTy89wTOC01aijHUwxkFRrYkuCE8dqIzTjhc2w0D7sEyqsFs 7acw8t6mKJ586Pzuuz6G8+LHJXEPybUXDju6nYESD+OotiEsZ5Zg1xkFdFET3b0ec1FTIFiaMrzh hb8edrpqHjVKA11aeNY1LEkl3s1kUIrRC6uajAPezJjv1C0UDoPw1dOeyuPCRLYsYWj3JqgSg4lP 66eqkgyDm6DHTkEDDxtHQakp9hNU9dDZF45fn0JB3QQVDz9QUOlHsZj9FOKy61jJYN5dy9ZYyTt0 u3nRvKG9jIXk6KHR1dduh9lTXwZB77RHekc3FKMsExwyRCKH/Og56d1asqDFas05SUwRTrxuxyNj 3If0zbeu9kWdvg0Fuo/U9odUJZMZEe3KBo7w2Nd1c05AkMg+Hmny4obNCScWQ8x9LOXoCxF9c8aA XNdjiP4IWQrvznCMCc29det13cm+U10SfrJOca15Ks5FjjsyGOMkDiN+rQl5nepyncWeoLo9Jzzf 6nocQsWhrXevf191R1g7NqZxwA8dC38JnY4Q03PU14rdxtbLneZPHxI4zS87GuAepv3p++bDRs64 mmJ76cLeyXlkzhqMqHTumKua47YOspl7tabHOdeHqHedAnnuAbvFKUklprM8ZzokxvDMGWJm8gav ZTbEyHBzP9vu1se2BBI2ZpUkawg4vpYWpWi4wcgPfCxhRx4Cbu4N5LoeO90ZP2TfNMOHmvyyq9wV lth28G6mg7iLl78y1t7lBqRD09mG2SORCfHWdgEYDR1wynIgkIwSS4LQ78yQTVwaQ4sdxsk++4P7 Af0yg41I+HDved1OVgu2IYgfJNGUpA8ChybfZMqz7DYimK14BoJpZieeQJyiuJ8FOOx0eh6SXc3I gfNH7U48dkjLcUuap3hLoeyVO2BsaP9dLHvJqOHDL1vStxj0mZ2zgmF59+bDPOx0+o4Jajy8a+aS zO16NZ+v3ussoz9DqiFY/MBU3Jl6fzubcFCuKfgYTxPEZKScQS1BoqPFYD59YEmEIfY8jdzbY9A3 QmuD0eHuWL16kEr3+vc9zQhZnDuDUx5+ECT2x2D2O49YUH+cl2aHU/URfYA+V6CWWbXhBbmfZjGQ OmLgVTAvkzN41j39wBOYIVJRqP1jBVISijRjHtgTroxzvhjc9zAGbXysFyRzrxZMJ1wnMvio8gy3 VfuJNNl1tXn44AjV0HPgtKvurE/aLIcWnjMSQw5iE9fGaS1UFTm83WISZ1qMXZE1I0xOoyDaYiNa jIHtZ9Jm8bdlDRl2Ke0XJYdWuWkRA1G3MQMkAsUlrXNHBq0ki51OxjHDLmdz3G/4Qwbn/HLa96Fd k71ezLrw8nxiNAo5jg0mM14eFiPle6/Pb3tM7NppEeUx0UuG90tBwWt1rl53kSQ7oQ5IIfCBD4mc 563omTOQzPHsFptbTF+Hv93r38t1PTYeJ2Tj/QAnIOUlpLzk5ErXgPW3ZXJSJ7PlnEHuCZSBPIEC imq6W75A9VhfLxyJI7ZmtpeTQcZPkPETG9T7+H6YK4zdckSKbsKZEwplFFdjOE5zQmE3nktnwSdH j+xqbESuDKTH0PK3c/1H/9V/7pBH/P9vA2augpdZqjdi2iMlLOYdKQFG2IAzcPQHHnY6/ccULB1O sf9Sr94utuov9fpz/gdXKeI89s9fQ/QjNGm0fxaa7AfQmE9/LOc+6bOdbNBVOWxE+oeyRAXN/yPk /qVeCv1P+zNEvwyWMxclgaPlv8U8+sEYkKSe4PHfw4T+X/4DtKpG3gplbmRzdHJlYW0KZW5kb2Jq CjkyIDAgb2JqCjY0MDMKZW5kb2JqCjkwIDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgNzgg MCBSIC9SZXNvdXJjZXMgOTMgMCBSIC9Db250ZW50cyA5MSAwIFIgL01lZGlhQm94ClswIDAgNTk1 IDg0Ml0gPj4KZW5kb2JqCjkzIDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xv clNwYWNlIDw8IC9DczIgOSAwIFIgL0NzMSA3IDAgUiA+PiAvRm9udCA8PAovVFQxLjAgOCAwIFIg L1RUMi4wIDEwIDAgUiAvVFQzLjAgMTEgMCBSID4+ID4+CmVuZG9iago5NSAwIG9iago8PCAvTGVu Z3RoIDk2IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAG9nVtz48aVgN/5K7ry sjMViybuoPdhK+sktd5KxrGtrTwkeeBQkMSYF5mkRp7U/Pj9TqO7T4OEJFKCQicSfQwIfbrP/YZf zA/mF5PUpp5MTFFMTZqbbWP+atbm6293iZnvzMT+s5vLdfbrRftrvjL/fWkm48lkkpnL+ahq/2Nl iqQaV5MiMRc1f/hyZb6+vEzGE+6+vDZ/M++S9Ov06yQz6TdpZv7yHvi7P783/zCX/2v+cCnrGfU8 J/x1/uQjf/fhPaspzLur9+ZiMs7Nu8X7EV/489fyXzL9bfwV4dKthaTm3cx/8ffsL+TmfMRfkz/L X2v8l72/pr2k82R37creHN1z8X5k17axf4Q1fXJXLP1fDc/xf3XiLw1fxhbCmva/+v+2fwFOskMB J7dVL8NJdsi8cziNzsEp8Qg4nEyM0/uRUoWj0zx5EZlyckKno8u5CZRUpNNxVVWZucjzHjL9i5AC x33TyNbyJW1/yYr5NwNx8Utw5td195qqQ899fBNWIfSc56NjNrl1hLHf3/EMu8Hf+C9fH33ZB4La WKqHsgJF7eQvQdthi6Njd+cfjj1cEw4zsMaN/Bn4Kzw8/BfPB3O7LJ4U+Co86VrovmXBozMtC860 NlUWy55UZE9i/0H2sEvVdDquk7wwq1FRVfqvSyP/yt9YylX29625dntuxRarnkzqadlKMrbS/yvX J0U+LcfJKJJmyCkemDlZl5napNOsSB2JpF6SvTPGfOH/9teH8L2FnPHzy/vR5T9byZfyxydVIsgV 43oCaa5MNsnGWVGmClt2YdmkzMHd3zuSex1M9uEXObTn0DfPoV9WjkI76P/2wn7sL/e9hZzx87d9 6Nf1mD2fdtD3sBj9Gk0zzTrYB9BwyNdpH/JfzI9/+EGO/S/y4/K2Mb///rtvzW6zvN8vNmuzWS8/ m9nV1bbZ7Zqd2XxqtsvN7KpDGb1nX0/GVT3Ju8g7WAd5mJrD7mIfYMOhP+09+y9wGB/LAV/MYn29 2a5mgvjYmD8JnhHovTmk8BFyd5yWFUimk2JclkVpPAhaVlA6rsoyiXDksgATHCcjYetT+fw5Qs+T 3rNe7JDvHofWOjn1iU9JliIXLoe30ykPPhIwy+Z6r4/Ni3GOykpHVVmMqyIr2bsSu6rOcoSDhy27 sLRIKzbP32uvczA2z27d2ZsXi8ZyPEl4gl3/MZPo4jkjpFCCDK7POK2n9m6aoQ2yadnZuywI5+Xi 5wb+22/MYnU3m+/N/naza8zddrPfzDfLnUqdyL59paTM8owjyt2Sjrdj9jZUlFX5uCym7hSOqOj6 fn+PSW8/X+RERtbKVh7zpAMrFuU4L3P0j4fBizHMkY6/15KiktMwuiZPH5E3LQby84t52Gx/RtB8 txYJuxCx8xUnfCiCrzYI3vVmb++U+/TUvbo0VYGuySdJR9x6WCxuC3RNNk0jUTSqFDaYuM3zXgkU LA2LvlMrZnbTrPeqWnbzZj3bLjY7tqbn048+mqUVxGppFA7WQR/NkmKlxZYG1znYcOgXJ5z+RQ9y z4N60Ydl0yRLO6fvYTH6OUonwV+N0VfYcOhXj5z+07bG7v7ubrPdY+h7JeXpe1RlqNfptAbDZIoX lBUY2g6ExRyBkmk9jfCzlzmY4PciRRvpilg69mGpax9eWWRFMk5teGOaV17RqrJ4aJZLWAYbbttg xzRfmd8vZqtm32xVYAxiR+e1p259OIS73lwhqP78fz9dmg/fX5rbzXqzNfyPtTzMtjhT/lTP01VP qc9U7K8cwkd119WR0lCZsm0sZeHuRot4gS7vWF7ih0ekkScZJqDVm2EtukHX283K3K9n96jw7eJf zRVbE7ZkNMi5FBMhihGBKn0s57JBpWwfFtgN9+v99n6359m7zf123uzwk/1+nLSCp85CHMyCo2hj ALqCepxBlR8264tvN6u75WKGrP8gpKJncdKzO1vf49ziXTpjRZ8N9n+9bVCvgRUslZpds77amRnu jfdnWgL5yiz2Zj5bi7ad7Xb3qwZ9PNsPvdKql39my6XjoYcFX+eyW5/Zut8BXV/Yf7WbJ3xmVoub W5a6We8X63tWubE4Db1Q7PTD42RLt80v981uvzMPi/0tiwNwdT+37uJibcQ9ZNU/ctFi26xEtae1 +duPf/y2mpT1PwZeYjnp3cvF+moxn+0hskDgw0mdZJKMy4RYSoon0CN1hGTYJj7y9NZQTWwg5lR3 y9F6JFwSIgI5flP7zCOr3JrEbfglSZJxXaeFKct6PKlqqzMTnK0p4iHAUJoONirLakzwSbRmdG+A nWMVjHwsvS/6VKZeOHTCL19MKlvlXXAREfPFHq/Hn6E1iWd3AreuufOFkGIfPys1eVMBFHGAykIi DylO9mRKDD/AMHxiGEGnTuRBrnMwayy85NBsjDY50A3FpBqnNd4xJNO3DWL1t+TiDvGsJzuxHJFL gU9dT/EH+p8XkUtKQDLPayGXdt9GUbTOwyCNYFdHe9S5N9q3k+T5c7qkzHpYy9FJIJdWbLdWj41c 9RFEgUIoEonDEScd1yWRxtLDoHmFpeOiSOIwzagsAuzFBBEdS2SvgN4RF0fhmeGtR8hvPMlJEkAS YWtVVQZNKDplu1nqRp4nOJ9S0zkRsVo8c7uEY/RD1FGl9nly8ymaymtiLVXVxV8lkXjZ+tgUZsiq NIMAAvGkFXGiCboswESaBFggFH8v1wUYxPPqMFWBwJ6IYH9k93T1wxNPgXit60xsvD7iOTaZDNaM ktBJAuEpyrEPLnqtEe/kONsJC2Rm1s1eYitmRsho3WDo7ggoSCCtNX+/wvS7egvLDlXaZzCtZqLT NvcSxhHD9y1skrzGPkhJfU9ZxLEnJBatPjcZLNwc2yUBeeUq59JjIYr/tVjfEL0K2Ku1kWGppOhp JHRNHiut8lHpYUhoBzOQ3rhICRTHlorCTrZUnhITltLqRywVMVS8pWLTIFF6IFJCmj4h5I6/d4+t rsyglkqGxk0SCYGrVeJhsaUCbJJgaUZhm1JhQyim2D7pSxTpob2BbInkWth4VUwfG5Elm4fGRxBG P1jj6OyIf2uYHXiOBRF4TERrmPUhjmPFR9F/kT6KLAC0H2Ul5P/h04Cs8kvEHSRExoQ2sFUcSYhh lpfjTMK8HiaGWQxzZNK518GG4w6C9K1XqOv2bBG4wzP+zXY2b67vl+Zjczv7tNhsxaGV4xRZgAMe 2/Xc3Mcl8AuRv05wExu6hcV2KbB8SrY55hKFnYz+c2qIAOqx5eLwVvTvmvniejEnmHA3+7hYEtyX IH5zs9kvWidm1cxvZ+vFbmXYlaW4qo+gD3fkNTZTbJZ7WIx+ko+noqFj9BU2HPqnJDaiU73AjWvu iLc063nD4f90f3ND8ADv7WpxfU2okviA+/SePo7TtIKBYvQ9LEYfWA5jddBX2HDon5LYwPa4gr6/ 6cmnH8S4kWWQaFsuUU4ojynww1EHaTFOJ1jpASan6mAFHtu0iLWBcaDR0giiLzLYIxmlgcyqD1sV hsPrgjxNyN3BxOmUZx/FEvezn9EGV5+IIZI0MptriQ2ozHgR4v1qoWazpXbDruOY34O3pJvxIs3Q +/CypFhmYiPJugkqa30sO5hSEFEmSay8KpVg4Jd6Os5ScIiIKMCUiMKtXSIaxGQntXi8d4ey0obL xFJ3UuPjktpEH5YO3FFMEfm4r2jBpEzHZU2BkYfB9B1YnpMfUjlor3OwmD+GibpTyQGdStRdj6hj MgzPJRlMMslqMSLap0txqlpMzoM3QcW8BYckZS42u7jTrOH4lDGc9BSH442EurA0m4gTrKjrxs/W n6OnoiYl6jkq4OY8s+5FigeR8NWDoBwFoUEzjCvxLly8tKgDzFLOS/ymSLKmST0uSSE+tmm69uGJ Jk0pi8iK7s4p0dw0e7Miayhu8VrE6oLM3Ywfu1vhTUTtrtl+WqDDlZoGkRE1B9STZKAoQoKis4/k aub2+XG65ojEv3JbN6hzEMWrdJVKbJpU0nMbjtKjeBUPP7K4IxPLeZ6x+eTCVxSVYlOIu4E6yCiw SRBWAYb5FGAlNsWE7B1S04e+CoUNZj4htY9FxaFC6FYghvIX71JoLKFTiRijzxnZClRyghIG7xjP ARZZjwJDNXaM5wg2HPqZp/WIig7Rfy6mYL1hG0RyNVAB24KaWZGKGJBZOZ6mtiTZwThYhREFr8qO p1RIFLyFxSryrGKoSNDlRGUmJRua4pP04KwMM7ygw0gAFeL49tlHNmRbprBu3iaeYDHOe4n8jTRi VH4pbuKhZ+65RnwsG11oiSbUUhYEJGqCbRANJeSUwdEHE2DLLiwrCTBqHeZIrnOw4VgkpPGfYJGj qMJ/oiyItdnEOQGjZo0Sm+NjPkj2v02uCfqh+kPNypxAfwHOkX9ZeFgsITLq9vNpx78sFDYc+qE2 4An0DyuTA95XzfVi3Uj6nVoLSb1/Y75FbT7Ywsle9DMEZFZ2atQp4mhhHfQRkBTrqlE9ksta0HDI h3qDJ5CnpgDvS8L3jRRQUsfxG42y/ua/XCzh8Fcv8njUOEj0Ymh2s/CwGPkUgYL51MFeYYOhj6J6 XjkOVzUoHW74EDHyLSRGHUg2mcY5UdsZJzAXbRjECJymPUpCFKOrGPxJvl8elcbqwatC8aw9KhJ8 YrIhYJhMQVW4PMCw8QNsQgfVYUBFYRzvq1N3WTElBV2JSurFVFc/vDrMyhLca3HUePaROqSwfNlW 6ez2W8KQNwQqVU6yHP45s2ylN6gRZRB7t+CttCPqcVJTEhpjr9LFlyBb7RFkRiws8DfRB1OlHPhF 3MkE+ymiJoUp5VAPZ+8dFQobTlj01Q8Il2SChqumkUotV4TVoxP6JSk36/l7ZjLUFtLPY33oUAkS YLHA4LoUYdmRlQobDv2QDNbD9HgH9F3q7VGlEA6886UP/VzCDiWJj0haBliEPhYCrT7UXEWKMoIN h35PrvUI/eFUBcW1NOtA8TH6HhajD4wK5Y6VJPc62HDo96Xq5NifLDBXKRvIOqdNjYRyLVFFXwfk YZyhwip0RE4NkZ6ryRUmiHlReVZUMXKZotogyXYFO54+cjrO6dQNMdGX6QjyWo+W50W1QfpsjQ1J v1Fju4+a1a5ZfiJXZcuZr5ebDfbXhrZYH68dxhoIzXq6Bqjb15268o2NWUk6YCd9QW0MmZTSjrXa UoPNGmVmi1HbtW7WUaJggFVmE3rG+gJXbWl157TOUKFPlSZU9PgkCdFD+2ylEHoYLYXYSEl4sJs/ MITuTjCKaXtrn3tkotp4hFT5m4+UmtsfYRFMZBiXqdTK5jRj8SWuwhsFWMxpxJWrRML30a0eFPPZ aaEJt599fPbILuraD/nsLM7uNYICn/VTjxTp3G2bT7YdCv+G4Gtbp9+S8JZKpsUnSZz7UKwxf2y7 CFqnfhiyDgneDvM1v87EUvRxViZceIF31kH0bkvogmRb6MMMos8TdlS+L6czcEW1fegRVUeVGKFO iewsxRtU4KEtfIYgwDRrMBJYOqGwR2CuGjuCnaMGHxXZtXBjSJEeGEG5GDStDRjIeaRKj2RhUuPU rQzpDbpxWWnuYfBdgOVT8mzooljpOdhrUs29NED7Gk42LppF6+g4LMnDEAGdAUcjhJxS/45SKxg9 1eeUwoZBCz6DFGCce4DpJirNKAxaeLV3GbJKj2ydrv5Qor2edUNWKd47FRxtm8q2+SfmgyyjZd3z JMdTBTlZCjEVtGM/gvrsTQgmNAHGSCsLhorU+XIhopypJsE+8q2KgVSI1ftkTYDBbwGmpOJuHeUK Ol8fus2M9GHIMz2yhW9JPfmUTpqKbrl4I5V65s12P6Og966hWc2XfOheDqPuQomCPjeyNVvN69Ww NTObX+ckD4xf3HKxWuylV/l730t2VEE/zEJDlr2zUEqvqa3DALZVppKnpUFfUqV3exb2r7bYTIyz 3f381miM5yuJjW8Ht4n7W0OvNg9rHt3MVq5Ke42Ro+2PA5oSaBC6g6kNgaJCF6aypu2SU5kwoI2c wpV1RoLAPvhIf4WCIdHM8ontC1q1MetRwiiNUhpZEQo0k+KI1gGGwu3AkrySKAP36b0OdrJ98ZSz ISI16ck7y9ItAhpjsq21Lgndzd0eTI8JglHQDyJR7RKEeZIV3SiDh8VRhgS7JKOTRe2SEb65h52M /lOKxaJ/SrKaysaLu80CMf/3d2KWY6NIc0Er+v/+PnSYsj+/s3MO2s3r34CEwia0eSfM4mGdDUgp ko+D8uDvQcOh35e4PTz9QNeE4j82tqjXDQuKjCZ/wiMpqEgmxKIlJJ9Rz4W1H2AQs8KoVZhUnSIu yhg8DBRfbTSFZnrIvA/Rt1R7IR1gn30UkpfMliiZ3S6EPJRbhrOdQs3/IzuA4tVNSKyMPjWY8JRg KWjsyMk4i3wJ7eIqoWeI6LuZZCLM1XZ2vYdv5BPLCwk8phTABsqRkHxCNz+SM8BgF4UFykndvVBi gA3HMP15/664HC4om5HAKpicFcVkPSiSFQKaMJgpFpYRbDjkH8vbP5nBUwLzMsJkMsyjToo4JOth ovB8mFZKWYt6EmdlbcmrgwlinlfOCtxEpnEIyUKqzLcKcYl/a0g2frZafiIjrhfbHQGjJR0WdpDD gEGgJJQh6CPhwv+hDQcN104pIlJ1Wm3eWwgvhojhOdAdw/aEtaoUMaFqTClsSBFGVLOmX80+XOnC xavafgdG5zEDhXGu3utNpQE1IeOe1fSFUsAsnOsL8AIM1o1hE5AU1nX3juQ6B4sp/DRHvmPwHHSo W4OH+QKByH3wLe5+Gj5+EEqZ2crwdKW5NkUZzvBlWr833hQF03nwkb0eioas9gkLeFnUKRIpoV8y xlfpNvYKfOQwq4i+M5BNBKKPOnqYCESFEbhDu1qYizrKVDUHO1nSP6W8hUrSvpkXYhcWVlG3P4JZ jDNKfobEzFxMxW5tEsNW2gARDqz9xFqeTbE1nJmMp5DBgrGe87BY0QGbUBYv3OLuHcm9DnYy+h0m OegWtOg/VqrSYtCiT2ESqRDpQRaTeH+7Fe/cMBZk2cyQ2SSjzD0DeeYzfuyQEnJV18hR9CHfFF+v g76DxehTYlKQou6gr7Dh0H+s7iBG//cffjIfwY0mr8/r2Yo+uLsGx8hTgZ1oqMm7tjztEfSlh15y XjH6HtZBnw1LmL0bnz7XOdhw6J9Sd0CnY7P+DyFuhqZe4Q9+pr5kfeNMWbtRPT96iZ86TUY+d+rz Mg+L0afmNfaWRrjHFjAc4v/eioOMAmIiIeIphnqTAIsRl6Lm2s5LVq5X2HDoP1NxQN3hF/NB4oIU Mt3fXYn/sm9+lTFSJPGYI0VQ8Hpxc+8m2LSeHaU51Gr2njtTvemA62DvQDHygPKKopyY6BU2HPIh Hw9DqV3wxZRCxq7WSJBXPekPw2R8y0vMdLQXPhe2SzYKMLSXg3FdQlcjFTaKSwwTXLw5f5qxc5z5 TSq0okyJRIf19TDr6g/tnLMciF5zI6FYpGTQcftsZ26onSPl6DaFjl2PSrAj2+yYV/ImMoZZ47bD jmyDt0LCVVeDg46s+gORLYhZfv3UzO+3i/1n891ux+gvNegHiWxn/SH4S1wcfJufJaYt5sR+c8Ev wgNuLdfNTGbC7mwZyE4mt13Ptm0Pk7QWL+b3y2jqwnnE85wRwGyYY5PRCO8rEQ3ob1B/bCcsc1y2 21D6/ZQVr2TG44pwzYIR9t7bCAX+KfnceopmJNvLwWYlLQoeRLI3AjEXVnRI506BvSbXG5u+lNUT 3SxFoPdtn+7cIfudxfD97OfHo8Q7qARPQ/rs43Kxu20nxDB6LMRt3egSmeOB+cboxpuFrSyyBVAy mG9oZujPoMyu/ombT5TZtq9IMHnNXHYJKEP5687WISeHiNPRPcRgMFv1k/VlUiQCoc8dbqJMhkZg IFkqZBL2Qokd5rczA8SWvN/tEI7RIqTbbYoNnFaUrfOqBWieqcjkZSiU8DBJpCiM2uh28p3e6kFD qJzQi2SROXaude2HNP96lROFSHQjleZXMhWJJvq7GZ7Kaibz9shfCIkjQxGgUSPtSVL+ObcxD8kk XQPWQ0gguLZ2SPuDHSS7YlKpY0fLetAb3aiBD8Sh2ElmmNzmamAezEPip7NUKS3Ei5nfNvOf32aI k9bAsIRjasEQ8B8hnGHqoKIKDsVb+S2OSEiwJsWUS6Vd0ubpSNfRQlPT0OxAWHQONEplBmFh01R0 XPs7A+wc6/TJKiiZ/9sTteqE3QOfaRUUveuSsBXDNFQ8BVhUBSWwTCRgZJh62Gs0Y7+eiiigLysV uCUg9LKIVO/DUxpm6kwSM31bGjUcm4W8GGNOPl/eCSKKYLbaMFxYLLX2E/k0zBsnbyeDAnTDkYbt 62ACLPJq/Oay4f7eUQQ7h27Cu72O55GC5CnpGue2kY8SM/zhdkERxcPmfkmGlxZDxKftHIkrfILn wzwOeIO8gSghKlhzErsBJkoowNA4KeykBDZKGerkYOerIWe8RqZXpAp6sVZqOlRDrze9cP7ESRWz j2c7TlW56qeZWHuqlfFWtLdF3rsNsbKvhhbvIVWly4BshZ5lRF1nMwYypqIK1zzOJHln+qBOjTj3 qSbcU55KQvdemhA7ZOsDziraP6Br3SeS8ky0ZN4S7yNidAz5CtxDqXD0POxgCL4OLEsg7iVv3Iju dbCT+fVZA4IXZD0n581w6dUUUUzTWCfyGGCxuEK3VVNqGmL2VdjJ6D91kPYE+7IUEn15MsFK2Vf7 UgUrppebHfH45Q1uzP52JSVgIs96I1ApDa4VfYOcvkprD4vRB4Y/2Yk7y70ONhj6VCv0edxfeBMe HxeDogil+ZXRazJeDF/cdfcpQ3vZPIIreO0U6UNomxQJ1QDMRfEwaFthUHTbjuDv5boAA7uXpaQi 2ZxRuUPxWME29+Koqx9eNkflszz7SDbTELreMbruU3NhJ6fachQ/1J3gJuEYSVxIdeEdHULMoqcX JJrJfZLf8Bzd0zh6FC7jxJcbnowOxmsRs8O7xR/c5Fex1Gf7DS6C9SN8iKSRGEmoPGNDz5DvTy00 KqLV9aqkba0EPckBQ0MMh3SpaB58JB+7DaCX3YpPn1TmTWV0t9nWnIx3Bk1kyoMHwekxiHfn2Giz T0fLZQ4mnP6KDe1JRxdhTHW0k/+2dLQ+Xa0EZQjnmUb7+xZkFRWVspxj+Ye84/NKuoplkcZeFH3d /MhKSEK8RJp788KW6wSp6WBiwSsMNZnzWjGB+TANL1JwsJP1xHNWQvHMOy6tssCqp3yb6aMfN/dR jDiI+ETaeMlIiHrA4mFGxJTiRAcDgRiWIsBj3S/XOdiLWSI6ErpTKWiWqpEJqB2TgB7+8OohJr+w rcoNs/m8uZPAKaVIqIDWeKf4Zbn5LLNHeLtMkLTDaIKQgtQ1cJxtuMjZOaKPQplx8JZdRX77cqIb 9Bnl8U4/6BpfIbwOygTCpHbOLKxZ2Uh2So/tjK3h5bMkg/t82SLuGPZOhYG+ZfSsTbfrA63yGQ3s X7CAI9r0wxU2uzkvtLEedPtOt0iOBI9BEmS8b1u8ZTyWMUyVjgJMZEYL4wv8SIACluvc62DDyZG+ DKEzNIO9+dd20KtBDhMPWd5fuSweFR1MocefJHsHQYpxQgpvJu82CyyhwoY3kiRTW/UdNDJz2loY ToUvG5P0ZTmlFiByNCLYEMKmiKyJvpyvEtHwwiaqC5Y0cOvpKaPTdy4t6K3H0gZ/pbDITfTXbR2O i5mkJtPmpcSQBR1R9wDJvkjM10TEKgaGtA87suMijiECS90rDpenEerCchyunHlvAQaNRLBAN9G9 ATYYx5Q9L3+12pYfgWN82JCDm0mO1lDibVsm9ASVMWgFpztMPPDwCgAZO2phiAT/WgCBUQTa8cAj 2BCMkcnLBgsbGwXNY1p4S8aIug11i5UxrpolCk2bqV7mkPZqlmwq3gADsphG3Id10K+K/nCeDdOM eX0VwTL78COOaOOG4u7jkMZi1b/pNVAKAQxKKZGUOVOCA/V0YJ563L2jIain3dEet4YykCNsYBDd w+Flq6RfnBGpT1cScjHYNuRKWyD2iTXnyDC/rYiN4g+s65itiOFE+/Ii2opkbNR2o7ugZlkkY8Ns sIROfohhioyloR8nmWSxh4keVljJux9FAkW3etBwEvaxfv9YwnqryyYmnKNDoLdv7r6Mz8M++UbE c5/8lUZjii+RvyEEmHhYFAIUWFIwkzk2TBR2MvpPBVgkAlqGOiE9NK9ZvIJRLlI1ggeV2AGXIc+X tCCi2BEIjZgxok2RoLkywM5XIj31Z5rcA5VjGaBrP5QAry8GSLT4RrdRJQD+m7yj9Sgbr0s6yU15 zjmXZoZDw44TDLU0IbvfhvOUJoez6oSQmOFxLGvsm3NfK2161Sipcd4Yzww6++Sjc++2zIZ4/cxW UC+Z56mD3C2fd5gVNstsdjWhARYz1fYOU+yEzELdeRg0HcMmvHsGOvf3juQ6BxuMWatQQ/E4s+Ih LT+Lg0Rq1duD+i5RPHTX9a90oExN1JxG0ja56ip8Eg8TdAOMxkBJaitbg26Anc/WTkhFaiWq8elF WnnokK0HSK5qGxTPPuKtnvJJm9DmZSwSq5fQgJvtJdntVUO4X/d6QJ5juAzxRIlh9e6Qre/RbXqR nu/lvJrmRyrhpeJXt0fpEbd9ZlnKq36mx/P2EdLVqPJATSuGH5Z00WC2BdgyhgVqiu5tYa4+5CTZ +Zz2Ix7ZJ7Q6ZS5kRXY9Cb52YniUEWvzEU6adOSJMhihYCbFd/J/UqxtYbHyB8ak725UQmHDyZNT qjWicDwmz/dR3MlasrNPm4WEaAhWMheTCv3202f7SNdswSvmY9snwCL0mZldFAdvkY1gw6Hfk79n 9d3TpwZYZn6A4cfPdtKFyFbmfkgruQQ9v//Tj6GcVd7drLwejl2aavPMzoYK77YMMGSoOGXyDkxg BOHsyzL8vaMINoRcjaKouIHHtK8CY3i5GqbVIjhCvYaaS53XjJzE3c9ZRlUobtCncL4hlG1LfV2l 79BDlMTbta9yAdm+XlrcwSHdMC0zU6RVJntRzIC5UGEiPa+UsFTSAennankYil1hSF1iaFKqp/cq 7GRmfPawQqeqrvuIGT/NlrRKiNBF5RKguYlm7XiWMWTHGMNNZSyYkWeVIFYAgYSCaEDH5IiMGC7z sCGYLZpMWPUVmrwls6U0IdTMxxMtHXZW2cAWKMtco6OifPon17w+r3mwGZUQWf/h/wERdp52CmVu ZHN0cmVhbQplbmRvYmoKOTYgMCBvYmoKODQ0OAplbmRvYmoKOTQgMCBvYmoKPDwgL1R5cGUgL1Bh Z2UgL1BhcmVudCA3OCAwIFIgL1Jlc291cmNlcyA5NyAwIFIgL0NvbnRlbnRzIDk1IDAgUiAvTWVk aWFCb3gKWzAgMCA1OTUgODQyXSA+PgplbmRvYmoKOTcgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERG IC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMiA5IDAgUiAvQ3MxIDcgMCBSID4+IC9Gb250IDw8 Ci9UVDEuMCA4IDAgUiAvVFQyLjAgMTAgMCBSIC9UVDMuMCAxMSAwIFIgPj4gPj4KZW5kb2JqCjk5 IDAgb2JqCjw8IC9MZW5ndGggMTAwIDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0K eAG9XVuT28axfuevmErVqZKqdmHcL3k5Jcv2OfKxHNvaJA9JHiASu8uYJNYEKUUp/fjz9WBmukGA FLkZWr7sqpfYme7pe/c0flM/q99UVKoyDFWWVSpO1bZRf1Ub9dXrLlLzToX6n25On9Pf3vZf5mv1 9Z0KgzAME3U3nxX9DwuVRUVQhFmkbkv84ru1+uruLgpCPH13r/6mXkTxV/FXUaLiP8aJ+ukl4C/e vlT/UHffq2/vaD+ziXXcb8evPPJ7P77EbjL1YvFS3YZBql4sX87wDX79Pf0k4a/KfsJ9dKshsXpR 22/sM7tbejid4bfRr8Vva+w3O/uZ/iODlc1n1/ph8czty5neW6t/Cfb0wXxiZX+rW8f+1tB+1H0T aAj2tPuX/dnuGTgRhRxOhlTPw4kopF4YnGaX4BRZBAxOSuL0csZcYfg0jZ7Fpjg54tPZ3Vw5Tsri KiiKIlG3aTrBpj8RK+C4HxoiLb6JB18UmAtAwhlf7oefKQb8PCU3bhfEz2k6G4vJo2GM3e4Ja2gC /9F+89Xom51jqFZzPTjLcVRHvwm87Ugsjt2cvzt29xl3mE40HujXQL7c4u4nVg7meltYycmVW+me +L4XwdGZ5hnOtFRFInVPTLon0v9A94BKRVUFZZRmaj3LioL/ulL0V/yOFX1Kf31U96SMgiyMqjws 8b1WXwQIS0B6TcV/xXNRHidhUMUzodagsLBy0n8aX0uVhGVUGV5JrEp7oZSat5tds9l1qr1Xu8d6 ByX61G53gVJvNqpeLJa7Zbt5Obv7Z6/ihE7lXRAQ52z3KDalTmwqicHaGZDUezN8FPPedi02RCxs 1+6VqxeCJGUcpHlYDejCa7dPu+W6Xqndtr6/X85Vu2UKxGEVZEUS4RyzoAwhhWsVF1VQRWHKsNUQ loR5imO2z87oWQMzR37JURuqigPO4jgoy+QoLZmIV+CuDPyXlzCb00y2bX7bL7fNGlxG25hpU+mR j/IoD9LKHOUkG4HN8Ydp8DxGEuTOqzTIoqgYYMzs85mXSnIwSVHGjjNma5XkUN8l6Q3LQashzHDG 4FnBLb9pBfEf6wMorV5388ZBpc+aVv2Xz6pbt+3ucfUJamLdqPf1/FchCHguLECEoiyDuEoqCEKU lbBMkAMLgmpzIDhXVUJSYB6cFaUFeRGCuISzlsIkgg8Ta5gEcnwqVxCCGBiXaaZZwlGWNW3XrJq5 5n+tR2fnneEp9allPa0Mw/NKOL+Pj8v5o3pqmm2najjFu+2+2zUwbVaTXih9p0xLHIVBmSRE89Qa GEFzKHFeFnI3u8CincI+TrFIUmqd44jA627ardTfMHK9IetAm2YDLhebSqogThBAFGUIsQxTSGic l0FUFrmDEddKGBS+NtvyWQMjVj7vdE+RVZ8ubMaXJNTgMfvZSZWCYxjEeQFpLKGl4ioCGga0kqA4 KPI8EvKIj/Ww2Up5EcgogVWKEWSBOfLfWyCjFFYpBvJ68ZHr0zUbKRDgS0+cGRURkAb9jyDdfmi2 q7ZeDOXiktVP8U2cwtdMKq0DJ9hn0cy3Td010AubhQIJOjh6x/58Zl0fpUmA/5iTYMXI5ajSRDCX ADnmsk/OLHOB4c4XkVMqQItIYRUgyz7QGRqx22MInoQL7K3BUgWseZGBDEA/TIIky2HYLQxGXMLi LC6EcM3ocwbmEf9qQqwI/1++/Zm+/Df97w5e9Dd/evNade1qT+686vZP5OSDCxQc3abb1WuEatY3 Y3RhuuM0jMjDTXLEGIhRCguDRmQY7HhSxQN0MwfzokvSpAjCvNKHPoU0K/QrGHc4FfDiIm1tIFu9 UmaT24dM3Y1qn5ptvWthdt/++d2det+wBJ1nEr7E71Vo+Z1XBxfX71ew8q068DKgVC5Sa6cUi1Cn 2MTYLvU+hzsFkwk7O1g7hXgENxkxbgb5YvxZ3pedWjf1Zjcw6hEEtQohnRmMem8NowyHmEMpWhjM 3AAWx/DJAZPPGtj5EnuKhsS8FfKUk0a9JG2kFZd1TgZGHQo4hj0dWHULk2YdflERIT3JbrYqDOwK Zh3YjCMuxwTEfb5TGZIPHSlZGNjprfe7x3a7/Df83mtkL+IqD/KUrPwkDQ79Xl/2PYmLoMxi0kRT nNQ12w+NqqHYzSGAhyLkOuIImrOw/AJ1HkcI2WDOLYjYxYIcB4kne5gvDkpDRMUnqHdVDkqjJMhz 8guZgsxA22beLEFDo9PhHr1Sm3bhX5Mnk5pc241Nu4Mqh4NWb5R1Fwck8cVNcYzUSZJpzYr4faSX eiJYT5V46TKDckqri4AZuYORFoGX3JGrskTkNq91EtKFr0h5IuFEmYckC/IKrE0OCs4wKhHGGRh4 dQCDBFSk3eWzBvYMB+WUmk+Rnke0qDlsiqpD3eAv8kBCM0gLeKfg7AmKIpm7bbpOmxnmpjgtocfg 1Fi6ES1hcLMUVt7CiJYSZug2eFbQ8jxf5xQJtaXMjlhKwsBYSmSIYf5FhhHy+rpdU67xj9rv3XdN n9mGf2Q9XTzMJoGd3ZhifrgH0re3MOnbQwMj20nhv312VjDsfE/hlHBo/POxVFjEHf7Afr9ZNFu1 WHbzfUcicyKi05Sj3zGJP+LlIqYsHscxSNFr2AB/1BKLoa+Pj/Ugj9iXE56FQdth7zGyg1GIMiR1 JPYWJrGPoHoyyLY8fYZ5xL86cvqnIzvwO4pmNs/HDAqDm6cUt0ZFGqQhilEodGsQVKIEoU41zAnh Ywam1aQ/dZWAbEhXaOMzhWxt7Q4q6xfanVOqJSH7kOmMZYWqwaHNe1o+PHyiRPdy86A6FIB2zcMn dd9uSXaE3EBVBFFMqW5HWhYbR9oByJDRPjmjJwVpz9OaX9AaURgdkZtKI9D/b15vt58IQetdWHfn xuSOu3m9QpJotdwgoEX6/+Ny9yixt4ylEJEHCEsGGREHE3KTV9CaCUy2kBsB8yY3URgfkRvCnK0G nOR1u0fQSGXPvspHrl6H1Mj88UYXHu+X226nnuqt/hA9PKE18woaMqooReLO2sEG+ENFRqWMy2b0 OQPziL8ryXOEbBEf4C+MpoIVMd5BswAZxgmjRQtumMS/hN4MUfaQ+FuYxB9BSB6mFF9b3pnlDPOI f/bl8x8rSJUXcHkqxM0ia25h8H5cJp1gYRXpYi4IrOtfAqZV5GU+stFVorrIaXNQdqyhhFo8jK89 lJU4vqbFR9Uliq+ZfD7zSy5tPo00xUS8cOTPDLkClsCXRcdkSpEoXTfzx3qz7NbaGFB4BgUqdhQj qgzhsjqugR+NtGGRUm+H5S5wv4QZTkK+hp81MMlJlx2r4KQ0g9QVSJMkhqgzdLQxcoKgh5zkoYTF 4Yg4UQ60OT9DmUsTdrOG9WQNC2sNeWFowyX1t3y336K/ZLtut80NRdr1A6KGPnGLbgVYRgA/8QGD QmA6LwlNVBvR+VIgiROFboPiWA6tstfehSwsAlTK437xkf9jk49wumKUA8MK7mCO0meIkj5VRosc Wi8GSxsYKXSGFWiNKSjMFs862PlK/pT/htAoQu/DaOMjI0dUZH6yVgcbR04yh6DCFw5T1BTQweNg cIYlDF07gziPPmdgUj7PFBbjugn55FohoTTKgVxXPiM0LeUoWg/oyWJCzWDM/b+hCc72d5HWv7zd i86NWqTu1qSEeB2c23r58LhTjzVE7n2D8vxygzwmGhbU+08K7SeIbikD1+GH8MMb0r8f661Wv9fI 7KbEzgUqe3q/40O5UlyCFqYA/pElEvUes0pAB1XTzUk/wVnddFS8o869DXpKEPGjeW97o0iRgZj0 R3pqtm0BMQ+UDpoA1yrNdBkzQ8+hga0kLA4yNDeREJtnZznsiIGdL8RfilSiaILjjYvqPFXoZIpA Vp/gk6Ox8zCwVRDQIEvKDKopss0YFgYMBrAwQUcHsAJZe78NzxqYlObLrK1uzz3st+TulGgSy2+W 9brZga8ZI58RrmuspNVHilLLkli4KAOE4vHMkQ2kRLRWZmjccDCQUsIM2SLzrP4ck1I7Z55spZaI qW4uaRSv4L0kEdIkusEoiib6uVA07+AwkOtS604rtjSkHj0hH+UwUDFsFbTCFA10w644ystWPmVl 2Stm7FkdoalMrGq811mewE2I4S+QLKK/NUa462Akiw4GlwAiQvLpPF+U9w0MsvhMBhKWNU5S1Izz o9zD278C70jxn+CdpcjQYXVfXmWMjos8DZH+n2aWgwjKI6/YUqiQFOaVp2272M8p2UR2yTWZRHke ZCX6QR2HwLnE/ZukLBFDWU6CtmaY4xD7LDjOwTzapYl+Qto7GVZnlzhn9G7/8IAOGngri+X9fbMl I/2x1e5JX4LQrTfmYdYSbIXQPQ1zO8ygWZjMoAAWIl4QFgz4O5hH/Kda9Q7xd61ElHAmFXg0bepy jUS8KfxBCZTwqLOBM2gWJvEHLK3grLMFn+UM84j/GT1lrD6wA+NNoG0kLdERIDNIBjbIIEVpUFGr PuOhcoYRHhdakJMZJHj5Iw9AuB2H2s+D8yMySFh8lEGajvudZ/c83Ce9sAShXJqCs6AQp6hwGGYj J8D8eaE/dsrZFYkQJggrSJt0Fjxla7I585S7YuJgq5mAMU/xsw72fJ6apCsZVdxkGbPVEZfMl4ET LhmWHzHWKxGueuSiFH2HYZ6gTDWNNOJTIU8eE5MoMIWoMPXrjsJQrk4w3+S4/4CbD7HKQ3QCZOB5 ynGgyJBVuGdmYNBFDpYh5qyQvF9BA5lHGfR8rhF+mPBgJ1mGN38NTcQ55SmGoYaAwfqXuO0nnWf0 AYdU7DrCMqg5iXV1ZuXi636nFI5wfifxpp6Jj1vc7Ns83IiN+PMIucZ6XGbIIzKLP7uxSDAat5TR kiNxkWlN0+hmBQJCgi7PAPcUWEi0ce5hM5YI2yLHkIu8jpm9dX6YLtAK1TUzsmUgj4nI5LxOUbNj S+U8ENSvgoruP1H8hfA1RizgYBR/CViKti/hgQBJeFc97BlyP85scmcZUgs2By8wG7Cd7x5Ryf+O rJxx/ObN22/JRdcl/odtu39iYl5oOE5JYYK2ipw0L2VXJkgAIWQqXOhunNI+UhIc9kx6Wej9Dm0N tUgk9jeAH9E/OnTV+85Qx0vw1AvEmrgY4EBw1AXIcRc/SCCYnosExo1pmBSYiRY3KylWYJi+LCQl 3HTc3hVeetaDpJOeoeBbJUBQOOkC9gwROemkx1Ntgrz5a5hGdzsKKRirLllEut1+QQ0ivIez63Gn tZzr6eO1cGhCr3W6vEoXz5ExQJH1dtfeUits18z3MFmfWFTP3tFpNnJddoMd/e3N7TfBstnd3y7g Jdw2cXOLHdxio/9Q902926OVkpJ/NpPbd02g2dD+8Mb7Rl1D3GCj+j4jfNBhpdKXJ4N2IrS3ZBRC xcjLHDZLoSKjLwYbNnm2HZ8MM6Tr6HBnPcYlkcVeuHHs26LRt6yQL4E1xCWQKitLhftaGkY+sIQl JXqIpV+MzxmYF1HHxSlYV+Tij5CRxewKoh7T5c8UV0f04qOwqf5QL1d0gQgVJF2HW9e/NqiQK9wT XF6p2SNDXBuWsY6pptjqWh3SWZqj9o0qkCQFs9SffvgFjjG1utUUI/2X7QwjD4wsoktS4FItutnQ Q+gYCkU1tDMWaGlzMDDUAGYYavCsYLLz1Nkpw6/dyImWRtq7xsC2v20bZGSpcCiUFBtIFAdhyykf h+gTqUkYy8zCICMMoztx+SAfl9EVqx72DLmZ8CIjNKcnuGOK85pqEeUTOZSbM0vyp8gpXVhHVda9 dGvy/WrZPfbX632r+8T1cfKSOMTlBrXwzW29+Gety8F9YZzaU102iya6bNuVetpvn1pkZ2Gafmlq 9IijufGx3a/EfajzeO6Uk0s8l7iWy8FW39MlmjXubzSLG/XYfmzQj0GdlbKt4EJ3++RxccUHGxqb qqvlaYR+ZUqwUvlQr5YYPvBJ3z+Au71atR9FAcjdQMSFC1woRs0V4ai5WDtzMLih9rJthjI3Ri1Q ByI/y7BnyN3YNeXLtnS4Y1oelzsP+WO+bDvJWSM+58a8ZjNv91uUZQV9z2PxU4ylWdwN2hqwuPX+ +t4xvar38TYRErppjFOAoE319g5tpb8cDlLVtj0I6454AL2QC7p0TLmkQbSIElVQFZgFktH0B8y6 IUNii30OBuaVsAS3lsj/6h+d0cd6ELHzeUf4RS3lullZNkeWcY7ZCNCXf9JNR/QXPReLXU3Rc8MK n00n0kgJZomQCGe4WUc3HDMLgwgzDGYS5gUo22dnKH5b2DNEeGw6RRcT2g1H+TCReriC6UzRAV7S HCDwrOtgZslZtyiVflKv/vJTB4OGa/Nb0/LlBo5h9pb56a4VToonTnA9l7wlcELzr2VHKVF0+ure DsR3V7NVnCBGlmgkW3poD3aEP6Rpe5USXSbaY47gC5cRFh1xhHBv3R1JGoiJGTtSgHuIFF8q0KNp mWIqe7eSniMYGPyZAkzzDkV2V+vgs5o+97tuuSC91KBXF/MYpsQUI4tw+VnfhrIzATILAxYOhklv mPMzqLhnDPMiptJ5+N07QHlgVoRAxLAhywRuzz8sN7gAddiICQ355l4kZ5jGfgQU99NGYSpkwaaA 6LpKs6GQFY4laWqEq9SDsF12v2qZ1Zd40A8JLWPuDiPHeQXHFxH91D4/LNsVqAadhrtjlLNS6IHZ 9a2afZ5ILZodom7hpkAJeyuTcnc5b1DYvGH1yf+EhgTXmmJ0ZkD5U8qjzxkxV+070rForVf3e0qj MfNcGAx8yeCnUx1zymXsrmsBReIM+xgRYSKxKS6YUAriKmRJ4HNh8CDZ5UnqON+aHfwLzc4pR1o4 9kwTZsy/v2iCh4AEenl42RJDiOBKorCd0sTADEkH0SzkYKJZiGAxshHkYZlnZwL2TKM0nqoapec0 i2lfWXsW9SekTNWi3ZCFQuXpAbNyD3uasVEIUIo7FrC7tunWwWCfHAweOq4X6esWIKPuaU4ZBiT/ 8z5KcVVlElXe/hXcSMmubrggaxKb6Pi4XGFisPWTPJkg1wTH68EEmUKFQlNbc79fUemM3A3cEqZs GrQaZnbAHL1vPmHioKPNM49hMivOk2sjxBcjL47ER2g2n9KLsnlKl2WgOyYmy32sd5g5uWhtyQi1 AAStuN8KLy6luYIxUhaIi9DRjLalimGQUAmL47IvTItnCWZqh8+zEcKTTCl1i8GjPRpj+rlDI3fb d2Ha3fFgCjJ79e6qUwdY3pdHgAsSaE2E1tRHN8Z54BF4ZJkMg25zuiw7zTLEqvTHRh5gGdcBKlgm we4RHZeSZQYwwzKDZwXLeFIIrpWRLRbtXWNgE+suH/QeqQPt9bXzdvX3l/D6Tv2ZaotNaVwgGrcG ls7CpKWD8BTRoJcDzGVAHu3c1My9Q/T9jeNA8xrexIACkbTzFiaxBywO0TwtMin0rIH5wx9x31hu CH8zjuMdszHdnHTmGFVGDCUatBukBib7DWBbMVQGraqMhxIwwuNCzTdO6opr5cBmnHQ4rvk8JHVF UzCTknUfpRF5/UskFt1zeD/CVIMIdMbI74YULtr5nuYD4X0B1vM6b71Tri3lJ8jdPAx2Kkj+a6rH LN/vaS6kWROa7sLj/FKwA6d+ij/vruUNUKYnLJE0AN4TFdwj40Z3H1uEOZjLt+g4vgHrJ/rmPFVL MbFX+712Zp2Dwe+VsAgj8FBfNY/O6GM96BmiMk6V8ZQ9wm5MWGadKzgJonmSScuict9SBYmiiaem fUIKXrvBxF/I03T79yhLbnZLJFDhl9aYSXrfNAuaZ6O9U6b6eTz/RbZzVVneIMmYG0ZFPTK6RmDF Dm8C8St2uStQDbbQKvXtFq9ueDt/u8ewG1q1z6P6QRyNfYYtDlf93xrXcjt1180f2/tms7QOMb0f yMfg/iifSNWB5kD4zytg/Kj+umwedUeMT4SL6VwXVv0ew1dvv6/nv+0JbWS6kET3fchUTzrUrT3O PyDwalbqbYt70Tri8oq0i7AOT/ltvV3W6vV2/2/1NSYEtSu8H8E70hOjhnuksTqIrL6BKvDO2aXr VT3E+cfltv6g3tWrVty08MPT5YTt7FF9t+8wm+Md/IPHPcTpwbcGw3XDkSCjFkA9E/oy39x/MZki okNmxpIRFv2R3luwo/mjYnk35OA8Wn9JZ6NFfIQxaP23X757HeO++D+U+npbL3Dt/ka9C27UH/6v wfwvXGi0zgsUGTsv//FYCDdHN+J9iQiLOltYriK98tkzWE55bMLKYmFzHrzwut7UKH4cXlq1Q99i FKjRkdQ3a0BOaPCog8GHt8NIY/TcFxUcJHJf+oFxMwHzF59Uzh4xDjjUz6ip6y/6fxRwryBDaHBD yC+Gy5IP0b8gAzz4Hc09g7ewWuEheo5FzsU1aGjvX2Ej4jMHE/EZwdA4KlOUMwHziP9ERZP2rjGw 4blLb5vhvmqN96Jo/6mGNq3VAs0jlMhD5cYOnb05gj8KnBhxMxgWSjeVNUzij3cTFQfhOd5JYWEe 8Z8qHh7iX9/TzIl+UjvxAjWPIaVZoxdQtnrbU57hIg2y7ZSCQDyN73ChzILA4xKEyemDXnn6mIFp h1xnQM+W2wmHnAsXGOP7ezvkfJGDZggfqm4aMQv2gfrUGrL3P1hDnuXzndLZ4vroJO7XagASmVJG m7ULMZCZDz2HKjGCJnSFzepaloGqQOYjRmOK4KIByHKReVLzn+AiL+YvDl1xmXEZaQqb19fpdKc2 nJakCeso4elhie/QAo9WKAyomdaUIU05xbhgqSktTGoKEqcUI1o5AwT8HcybpsDvnJCfQ01Bh+uu +Lu3hRC0D9+dSYY2N5Un2G+8BARhObQFBueiYIV3E1oYkJIwmMBBqos+RzBfSX4uQU+j67ZP/oTv JH+Ckaj9hWFafKQu3vS2xUYLSAV54mtX7h747UYw6csv/CI+9QO6cVfdH27U169/UlF6Q+oLZxRV NwrBBYLIqEKZkaXZ0x6n4ylyPfEGwxyu54+IbBpU0u4CXUz730C9Wn1AqzVFd/BF/2ePrAZNpb2S qnUvmcHdSeslCzVxNW+Uu/Vo4ZE36oy1PU3pk9muQkzgDjCJltJnGMiLV1OC+RwMmoZhqIDRO1wg lObZGQ2iMzCPmuackoltMiJfm9B0ytbYFli35l9Pq+V8ucMcYvtH4u8UEMwGKnuD3gC6Q6RhQtMS LKLmRKFpBcwj/ufUTHB/ar3fUJsStQTg/atEBDY0dBfTWpq7vteWaDCJP+oewGNQMYosTOKPQ6fX 4Ej0Hcgf9tGxiok+Q+2Yf1bokyKXlFu4F80T0EXX7cZdvgEHoGcCA1d36n7bro9hTxWUDJG1sLOR hUnsAcPdr0HBjD5nYB7xd3kUoUCm7Kx1wHt3XOs5HHo/h5o8K5rbRE0jmjLI8R45fbzkB118Q/R7 0AB7uriEyaPy8FMH84i9u1R6Avv9E14t7NLB7EngJkcOnwm42GmcM/S+9zAE0nZCJ8Fwe1X2Z6Jn 1MEImQvd8ImimRshAQfGGnOBEm//0JPwUTRzLfi0+Chp89d+hAMMJe/iPDt9KjGCUhbqztYGHfMl 3rz68RVVtrj7pVPwhCl6ZqfhQuqfCoK4IkObGweACMCYCJHHNJFrphRE4fOnJMl8uUVFkcouyBUi f3L8j9DaromL7tOhSYbcZkwbhC+K1hQHg+QyDFob0+0hufbZWQSTbmAeJdddiGY0Sef0aBm97a/S D5cTg9fxHnSpty1Mai7AwgoD/aTmYphH/F1C+AD/0y/eoHkSuDzagCHIS+zw+tmV2jSoeG5/tRwh zp+VHSqXeHXuYPxZZGED/MEc9KLdAf4O5hF/V9I7wB88atjgMzko98sHky4TiWFGC0o6K0IaGW3f AKoVN8GIhfHeMfyXG2WOfjBGS8KkDr9MoYqWL34nKl6DRjr895yCzlMZzeI02Je1KmWN/tBHYXHe R2EUCfm+84LJNVZp8tqWLfuvb9GbiuRI6bsvAuneSWNCQR/aCRMEfd/V/8Q85/ZG/SW4Ua+2v/6K b7/Htz9Qg+ymQWoFf7uKWeFZKbTNsVmhhs6r2BXuhRb0YYEjFWKVx1DW7P30QQhg26PRIRFi6p1W ptZwOJgwJvQzvNBLe062PVrA/CmT+FhZQvOcMSZ0IQB9DK55rh/E/9g+wZiirktz+PEOmg53PPCv 6cBdDPAH2v2b6KF0IvSNSWOC5G0PE8oUMDSNQUWw1pkJGOH/8/8DZp63fQplbmRzdHJlYW0KZW5k b2JqCjEwMCAwIG9iago3NjgxCmVuZG9iago5OCAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50 IDc4IDAgUiAvUmVzb3VyY2VzIDEwMSAwIFIgL0NvbnRlbnRzIDk5IDAgUiAvTWVkaWFCb3gKWzAg MCA1OTUgODQyXSA+PgplbmRvYmoKMTAxIDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBd IC9Db2xvclNwYWNlIDw8IC9DczIgOSAwIFIgL0NzMSA3IDAgUiA+PiAvRm9udCA8PAovVFQxLjAg OCAwIFIgL1RUMi4wIDEwIDAgUiAvVFQzLjAgMTEgMCBSID4+ID4+CmVuZG9iagoxMDMgMCBvYmoK PDwgL0xlbmd0aCAxMDQgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4Ab1cXXPb xpJ956+YystaVRKM7w/nYcs38ebm3vhGsVS7VRvnASYhEWuQoAnQsqr84+/pwcygRwQlWDVepSLJ RyCJM9Pd03O6B5/EH+KTCHKR+75IkkKEsdhX4n/EVrz8qQvEshO+/K9b0nXy14vhx3Ij/nYtfM/3 /UhcLxfZ8MdMJEHmZX4SiIscb3y9ES+vrwPPx6uvb8Sf4kUQvgxfBpEIX4WRuDwD/uLtmfhLXP9D vLmm+1lMfI55d7zlife9O8PdJOLF6kxc+F4sXtRnC/yCt7+hv0TjT6GvMJfuJRKKF6X+Rb+mv6AX xwu8G70t3q3Sv/T6muES65PVtRv5Yvaai7OFvLdWvgnu6bO6otHvaj5Hv6uvLzW/eBLBPfVf9N/6 Z3CiETKc1FA9jxONkHihOC2+hVOgCShOgnM6W4xWoew0Dp5lppg5stPF9VIYS0rCwsuyLBIXcTxh ppdkCpju24qGFr+Ew49o+CFgXACJM37c2Ndklj1P+Y25C7LnOF4cu8laGUbf7/AZcoBf6V9eHv3S G4NqpdXDsoxFdfROsG0zxGza1fybaTfXmMk0rnFLbwP/Mh9u/qL9YClvC59k/Mp80g3Z/eCCR3Oa JpjTXGQRjz0hxZ5A/ofYg1HKisLLgzgRm0WSZeM/G0H/xHs0dJX8uRY3asxl2MJd+35epEMkw1Dq f+L6IC3SxMuiBQtnCFT4xEgFu0jkIgrDPFU2EupQ9kII8RX/6x9fRd+KVdVX+029rcS6vRN3VdOc La7/bwhsIV7qZwHde+LlPixvI4IMM1ukxYiBBsciP41BTb92Qa9VGNFk0XnkReA0TTHQZOQiP/bi OA8HjsoOGcczoW8f74qRCzCOOd7fychGQeiFcZFYAxyZAf7FE//b7rfn6h4WFAO+gaX0+anJjPxA ER0/a5hI/f2Hn+tyQ1Mp/lZ2lbjct327bJsfzsW7//pJpFkUnYvfl337AVeEPliMs+zoFqPjWwzg xZ4Qv25v2v2m7OvPlXhX3VT7arus4ON6nubdwFMGH6UYObl2W2P0Z/TL5aUXRl7oR385n5csfWJe 6NPPxQ+XbVMv70W5XYnlutzf1ttbsWy3/b5tRLlfruu+WvaHfYX5olc4n5zieHK05Qw/r6/EMEYC k1Z4/rm4qnZ9tVH2EiHMmulCYNQB6UnHPWnScUjTtUCqNTVdhReGhZ4umfLN+cynTCSOdEy0PpON hJqun77Iqfr5i6i38KmbEvYqPsCxVqLdjpPzvFg2OSRRkXt+GlFgwV0eR7V+Tau6noIh33QS0eIo wwcXtGSMwzOG059///Un0bXNoa/brVjDgBsMxedqf4+1ZByJMEq9IsRaloW+l2ZhgZUiSuD+cZaO WGNjQRbSQqFeuqCXDhCtE/OCgloeJodUUkq04Y+UMN32KtjAISthAui26u/a/UdxV/drsSv3fU3c aer3oqtuNxVMYmWzN+tkEHlBguUB7P3Ii5I0FJnGwH7EQi9NsELzdRJBWWEO+acTtvSQf1ftMaHi ptxvOmymPh3qPcWnzaHp611DicGuE/163x5u12zKDWk/8dI4BecwRcqUYZOE3ZSEQI9DSIYCizIu U9jzU4Nh7ilRZklCnEdenmUxWXWqnZ6ZgJnsY59afJPlsc9M0sDLCz8wn0nBbfzMr+NHhcgMkcLA W8zQjaZhhs6CaJgWGE7+SjZ033TPkyMmvSXXS+h420feUt7CATos69/0xWOFNhxEHS+IQrIcw9Vg zFvSIvPSCGko8xaGOfSWYoa3XHwTb33xNH/EyqAIbP4Ks/gjMAZ5ZPM3mDv+SXAiWr578wcFjUv6 do2VyF4VbtrloeMJncn9U7hh4CcZGAZ56gUhPNJgtP0xGGKfH+eMIa4zGBguHK61ZOpJODnVerrw c3TX77CPCCA5hUGm7uQob92p9P1Hk8jTPq2sm+6Hc5kgCsrXZJJE+VqCfG0MzM+IBRP7xyTWtnAq V3pLiSttJqzkcNZ+56lELcl0ILI+XOXy4J2FOjl0tsfCcjwvl3/zuW0+IwO4LJcfq15c3XfIk8X7 F28ur96f/Sjeth/qpu7vxdtyi1hJ6YLruUmf3A6+2SJrucdNvX375v2ZTGavsMrTsv7L5bsrcXXY 7dp9L/7VripcdfXL1b9w2b5qSuQ2zm83eGpkH2bZlu+52ruHMRaeCEsclpxgIidAfmulBQsp7gZS sZidaj+WkEZx5MUJMiV5A0c5frVdXexaDIUKQixhCAqs2dgcpBGcPcDNI9dKUi9OYwhJCqPsgGN+ 4NOKyV+qoPkLxlN+ilV5WmQKQpCQWfZX0SK5bNqSmZVeH0SK34oCWg7Wh6DwsKhDENMY7p1jcQH9 iWcAuE5hROh56wNL36APYIyRZWB2jJbB8iDLJl3rSiGieB5Fw2efXA4eBP8sdO6p8VOeSvdJ6sA/ DlAMv0vsT7FjnNJxfr342aur/uZiVW+qiyqsLrpqeYHtyl/OR+FptaRbrtubalvfnou/e+fin+1+ jS3iFuOCf0kJUPziSRlwiCLPs87JbS2EEzg+fAF2am6U2SlpTKOtfmP4eszhY2zl4gwSivzgI7/f VFVP28Ra7yHl0icg/QFsoUnqL54Kxzn2iUUskgKBIEZZYyNi7IMzRIIRa2wsjhEJEQjUaxf0WoXN j2yPxWnKyjJfewIb2ocbZ7NcbLGM0pboODdetZBLtm0vytVqX3UdhcXRXk0gTPLEixFM2U5IQ2wj kOSxV0AL5mGQYQ7Zhzr5m8P+Ne0IxzBvVCrNjsofXhFkJIsg5/UgoodUAxkwKh8wLA6wXx/DvLxO YeD3zG0AC/MRVCY/QUUAczzFcnSd75D24zO9PIHyKT/8KMz90xOXddOU984LCHDbJ5LbsYDw+r8v xW/V56qBBLw87JFHvhJXy2pb7utWqvbfM6SNN8os7/8jpFFgG5ad8YON81JsG0KbCmLch00MoyqY j3ovSZ8xdMAkgvUqDF5ssLTwCj+S2qeJYSPm0IvniJ+D3vcwVh9FNh28J/hjvGSREGIn6V+02Tdy jsF4FMN1UQ7FefTyBV2nMIf854if7uScJEGhM4OmzflrjPOHIeRZaiWzyYg55J+fiOJKzvnPaTlH WUSH2seyOaxoz9jewPorE+JPrGExglsa5RZ/jXH+wKIUJQI+/yPmkP8pOQ/LgVrKv2LPKzfC9VaU DWpx2+4OUvgGKzX27jQEKH5sKtHV/QEFzHZLq/yv/fQaHkP9TtBbxOdfY5x/hL4ASno4/xFzxz8/ JedJJ1a7M6RrMj253VfV6pyaABD69+eY71KFPNQpO6gJhx7job94/DP+H8H/I3QGcP4as/jD1xFt Lfoacsh+WuGzSz/d4UPXlxBLykZQ0UfmcBiSZUn20LXiQyU2qP/cki4iPtxLN5ie/RDeHyIz5ew1 xtmH8P4QojenP2IO+RsBb1zQtNkb6+8gOsDeH/q3coqPVbUj98cQ9RU1i+yrZbtfTfOHoglthbMf EM4dSORD8B65y+Y7wiBfOOSe6HTnEe536xYFTdqtLCu0JqC+p4QKFROUq8MamuoGvtAObjOVvWNX HBbIWy32CuP8fTRwFZDDR/6LZMQc8s9ORP6BAn3/KuoNinskT8rABoF5WXcU4QTGBGTv1jXk3XIH LbrELxiG4cVT/H1s2fIH2xeNWfzRPQPjt/kbzCF/o+U+Mv99+bHaiosLFHWxZVYLgIn8stgLvEWv ylAKLk/yR0OQh824lfkYjPFH0MfWNrcyH4a5448q5JG8KOd8oEDfaeWTzgzfP/IEWuyHGICA+Brr wxpB4q5EzX/S9+McDbQJMhpm/wbj/HFdiFSHzz9dpzCH/I3i/Mj8w6Jh5o3M7Inup0PV9dIYQPb9 i31VLnuKfrS5hzheb1EnJ212au2Lc+p1CK3cx2B8BDJEgDiwcp94xByOwJSESbMuv/TarxuzIH3D /odZH4YBI9Nhvu/WlZz7wfbViyciQJwhAoTIabgFaMziD28PUflmEZBeqzCH/I2S+YgFUE9D3zc0 yTAGTPcBOeC92KHjBw1r1UopOoMnaFOYnn/0ZIbo/LD4a4zzTxEBApu+gRyyT2f4PyZ2KxMdamwS NcQ7vQQg6MEeVNMefjcrJIxk0voTaqAPrdwn1hhnDwyasZX70HUKc8jf9OU9OvvG63+Ek4stEmAp V55KeyhMnuCPYnxuF/JjdD9JjPOPUePIUe7g1j9iDvlPCcMPvf+p3Of6qNBP/j85/6ispVgALOvX mMU/RIcXalYWf4M54x/5c9Rbmd+bze6y3JWycFuTYFvdttgT0IaP9MBB8NJypoD+7AUoU4Gubl4b MVDTvXBxFHtpis0mpztiRPd5dQEmZ47te9Okv6ucCcEeSkYAOZM+/EjOfCdbyWSK2f3gukEh8o16 a/UIDGuU/L7alzf9xWTN6AKnh96/oB2fGiC0ETxvLiZrNGM3J7tNFooQR8eJcVmioZ6QFH2FmBDZ X0tHmcbPpZ095XD0JavLyrAjjCBilYghT6dIyMiwqYEuwIbOYDBijgUxarVk7MNrF3Sdwhz6sZGt RxJ075LB8IPyWJmyjAM6Oip1lEaQYam8jEMThR/iPhVG5eUBQ3kJcTlC9Wl0VI49w1FVHY05akB7 hMhHgy/EUe0rjNV4+w/rDt/WkDhpj2Ntmz78qBKALR7kn657f6YLD65arkFYdwic8tKHfebm9Mmn Wa1ETxTyIt+IoNYN/IljETGC1l9C/L38WDblUMh9W/Z9Tf/4TVZ1u484GENV3YtL/PsKHfr401sU ds1NOgwaCczRz5FFwULMTTML+W5VEBKf/Rz+Lz/4qAoCy9hBFoAQNqii50oagDyMPRIa/wZRTMYU My4hzD2JfbwnmjeHjug4jbyEdr8aQl2XQ36B2gk8UL1yQZcpzGFEOaUJy5Ci9kWUEGNXgH0/9YGr FGHIDcvtvdwQim7ooKJdAe2bHrDHtMmaSESNOzkSfrYvMhjLjFD78JIca+gYgRYMc8c/mKMJW+2d 2ARdHW4hhpMCiiq27IaHXNpXX/pXpIXLKtkp/mjixJxbumCkMYs/RgznBmz+BnPIf44qDMGDKeFq /jHNUhHHVoltjaAP66+pzDjK4NPU8sXnX2OcfxZ7qBdaylA0Yg75z1GFsd8rm+VBNgPSqYfDbiX1 b3kiArLIWocCtUEeRmCSfwrvR0eHxV9jnD8wP0bthNv/iDnkP0cZHviKG5lZbHFuC+rAYUdqEbm6 rZuey+ZKGoFp/vD/EJkSn3/00UiM80/g/5AQLf4j5pD/HGVYTrFNUwoFGyimRiToSCX4gJVzu6Qg eIJ/Av8PYksZjDRm8YevBzhPy+cf1ynMIf9ZyjBmWdkA1FFTFuB+XzYtSEuHIOXk5PzH8H8fyyCf f41x/thJWaoQslEJuGMOkeVpTXhQenfo9EDfB3bCcHBEeJh/9WWHE4pYAWQUPHQ05UYUnLR8nCvD VsJSBCONcea0W87lKWidty9QHdSYQ/5zNGFIf3W7qhH+oAPqsPf7b++QBMgyMdY/GoNWFotNrWCS P7ZixQP6CuLsAaGnjlfEFtGIOWQ/Rw9GIUTWuYzF6yOqKJDIzuQOFo8quepnk1Z/wu8xl+gXtNc9 jVn8A69IUDnhfo8GR4U55D9HD+bVYJbpqMLwZX17e/8BTf/yJKgijx+Tsx+gUy/GKQbu9xrj/IHF MU4Jcv4j5pD/LEV4j/6Hwc6p9m3an3QGtGw3uxatEJDFzmWhBFHgfJq/D++Hu1v8Ncb5+/D0CHUT zn/EHPKfowgj1cF5TxnbEPe31d14IMD4+tDPWondYY+xoOxvav7pnF4R+lbeYzDGX57nCwor72GY Q/5zFGGQhsd/ru4puh8FAbb8DXkfnruDleEEf/i/n1p5T0h9uoRZ/OHrPuombP7DwmDu+OMJFE+v fmhzQXRb1R3Os1EpnDIcyvgeiQun5h+dunmBfIb5f6gxzh9YVGDPz/mPmEP+Ri1FUoVnjeDJRseP A1kdZJfHusSDGmjRg0wpU0G7KwqTb31N2j+6eyM8AMXirzHOP0uhINvTbyCH7I3o9Qh7d52ASOTR CYechs++xjh7YFGKugmf/RFzyP9UJ6jqBLyCF080r9OpTukAO730UWDAY0bWrUyCyAwmZ5+6OaXs ahpBQwVZ7HFempqhLfYGc8j+VB9oEBMByQLbmgZNQGiFspuAtNjVISXEYJAqtC+RG8rM/wR76uWM Civ3CTXG+QOLIqjtnP+IOeQ/pSYq4oY/xbly0x6okx/dniid3NRLGeepNN407V0ni6P1BoVxlMYG 3WNy9qmXE/NtWb/GOP8Yvh/CTDj/EXPIf47md4Pqr0zuKLnXIh8ONmC6ZReIGhHk/nclWuDU1yR/ 6uXEUWeLv8Y4f2ARznVb/EfMHf94juZXqi4fbf/Y5lDjy8Ngr4k/yh/9HAVyGh790AcqMYt/gJJM bu35w8hgDvnP0fwcRn90c2Y5ng/G+WuM8weGnMBe/EbMIf9Tmt/j0d+k/8PpXDy2aYh68AS1SzgR /+hse4bnMnL+GuP8gxSPs7ObYcIRc8j/lOaHzzbxTx+5J8lj/tek/1NHp90KFCqIswcUJlDGefQb MYfs5yh+Dq0ffZ9hnNi5j8Ys/vB0bH1t/gZzyP+U4vf4KQi25JVoAf9C8VA9GAjr4/A1NfsB9XhG yGqY9RuM8ScM0c7a+TPMHX88AW9654M+LGP9rJpFZcYtNj4MMqeBzBH1wUsm+VM/Jx7sYfHXGOeP Z3/g0YJW9kPPA1GYQ/5zdD8pcm7/oxfLpir38lGIqG02mzEdRBY0PP1qaBWWBjDJn7o5/cTKfgKN cf7AQh/KOPN/uk5hDvnPUf60acu0dnjCz6D0rtAXh9OryhjkZkBWBx/hj36uAlkNt390eErM4h/g vD+UcYu/wRzyn6X8qSecIfhPFjshAdJBqFfizeeyGU4CkfOMfQBau8bzOdH0hWZ4i7/GOH9gMH8r +6HXKswh/znKH0LaO9veN+j+1bpfKX5+rU2AdoBkAeen+KOfEzysnX+gMc4fz6pI7SeFBgZyyH6O 7lcPx9uOPZ5MvxpmHPFfHf9ZNjV0cm969qmbEwUva/Y1xtkDCxJ0A3HrHzGH/Ofofg+mXsY5mmfE vEESO8hTQqMwJnOkSetH12dgHwEMFGSxh59HUMct9gZzxx4ViOm1bwhf9P2rcJf7oIDppUh+rNnX GOcPLAihjnP+I+aQ/ynVj+c+Y8AzUe4aYoDVBKIfXyD1IBJ9p62fegDxZfHXGOcfwvcDqOOc/4g5 5H9K98NjXkzuo6IcnYTC+iafcijXuabtSPm4pVLomh7wJEfE9AZNmj8aCVHNsrb+9BAbifEBAOYX UgrXC8eCrlOYwwE4JfyR6Wvpa1PhmbTbutvglItMAEgLumlJ86EogDJHV+vWaHj+a1oN6NVTqx8e 3uHnsZ39aMwagAD9TnjgDbeAwGAOB+CU9kcM9ADwVJeedypPfy4hhKHBoVqXDXoAUBmRYX84LTu8 eIo/Hk6NM/929qMxzh8YnrpqZz8j5pD/HO3vAX85xw8OvUgREDXBEuoXDoLTDmhq/qllL8nsU7AG Y/yLFO1OKSIlm3+GOeQ/R/sje5ePcOG5Lpk+/UF6PR2JxBk4WfDCUZGT809tfHFknwQxGOMPDLm/ /SQXhrnjj+78p1fAcgXRu6+74SkQmFzDW1kGLAI7JEoJ8RecjN7tIIFPzT9a+3w8oN0KgAbj/OHq aPS0VsB8xBzyn6P9lcNjfqnjjR5WZA6FqZGQbWAdunxQ/yaruNm3mxP2Ty17AY5C8RXQYIw/MJyD so+GMIz4//FvH96T2AplbmRzdHJlYW0KZW5kb2JqCjEwNCAwIG9iago1ODkxCmVuZG9iagoxMDIg MCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCA3OCAwIFIgL1Jlc291cmNlcyAxMDUgMCBSIC9D b250ZW50cyAxMDMgMCBSIC9NZWRpYUJveApbMCAwIDU5NSA4NDJdID4+CmVuZG9iagoxMDUgMCBv YmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMiA5IDAgUiAv Q3MxIDcgMCBSID4+IC9Gb250IDw8Ci9UVDEuMCA4IDAgUiAvVFQyLjAgMTAgMCBSIC9UVDMuMCAx MSAwIFIgPj4gPj4KZW5kb2JqCjEwNyAwIG9iago8PCAvTGVuZ3RoIDEwOCAwIFIgL0ZpbHRlciAv RmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBvV1rc9tGsv3OXzGVL2tVSTDeD3+5pdhOXW/FduLo3q2t 3dQWREISrklAAUDL3vKP39ODeZIADSnjayei1AIJnJnunu7TPeM/2K/sDxbkLPd9liQFC2PWVexv rGHPX/YBW/fM53/7NV3Hv70YX9Y79uMV8z3f9yN2tV5l4y8zlgSZl/lJwC5yfPDVjj2/ugo8H+++ umH/YM+C8Hn4PIhY+CKM2C9nkD97e8Z+Z1d/Za+v6HlWE/dRn46PnPnchzM8TcKebc7Yhe/F7Fl9 tsI3+Pgb+k2kX5m8Ql3acUnInpXyG/me4YLeHK/wafSx+LRKfjPIa8ZLrDuLa3f8zcZ7Ls5W/Nla /iF4pk/iiq38VHUf+am+vFR943EJnmn4LH83PAETjZDCJIbqaZhohNgzgWn1GEyBBCAwMRPT2Upr hdDTOHiSmmLmSE9XV2umNCkJCy/LsohdxPGEmv5CqoDpvq1oaPFNOL7E4wuDckFImPFyY1+TWfo8 ZTfqKUif43h1bCZ3QjGG4R734AP8Qn7z/OibQSlUy7UemqU0qqdPgm6rITamXcy/mnZ1jZpMZRq3 9DGwL3Vz9RtpB2v+WLiTsit1pxvS+9EEj+Y0TTCnOcsi0/eE5HsC/he+B6OUFYWXB3HCdqsky/SP W0Y/4jO2dBV/vWM3Ysy528JT+35epKMnw1DKH3F9kGU+BMnKcGdwVLhjJJxdxHIWRVkCJ8ddWShd 2TPG2Ff8L1++suGu6ivWtA3r9/f3bTfUzS179f7NS7be1lUz9N54uf3169nq6v9G1xfiw/0sIHSJ l/vQzR2L/MiLkjTUsq0ti/w0Bnj53hW9V8hoIP6gWfsmfvYt/GkudPQE/gsb2MKfJvHnuRcWUWHh lzITf461pogs+ErkEH0O1zE1+x9e/0pK8F/05c3A6r75y4DJrsqOfakGKEQJ4Q1e6x7r6h/7uqt2 UARcKAdnGr3vZbkf2+iFzEIPu8Z02/CVzCH+Ymb2YUHCCL6ycrPpqr6vNtDyq7sKYcRd2bPrqmpY ye679r7tyy0bWrYru48SPpvEn0VemGYWfCEy0Wehl6VpYKHXMnfo82Bm9jkI7gK+sh2gl7dVP855 v+8+1Z+qDWs/Vd22LTcQd+0wbMkjYFTaphrfPGX7aeLB3aQWfCkz8UMWJmFm4dcyh/jDmdm38Q93 7YbdtB0rGwUbI9C0m4pmXagHuynrrsFgsev9MD37CWw/9gMLv5SZ+BPYflSEFn4tc4g/XjD/3MSV lsO+m3bgPuC+7AbWkg+oWN9u90PdNrAQ7i1m8MPSD9U/ETILPyw9xMJp+n5cJ2QO8ScL5r/c9i2D iff19RbzTY6PEEv9l4qwbvfbDdtjmZzX/xjWH0ShNf9SZuKPYf8BcggTv5Y5xJ8tmP9+KIeK3ZYA 3QEsbNyc+HV5X17X23r4MuKWXye9X5R4aVHkFn4pM/FDFhR5YeHXMof48yXzv4GnG+p+XN921fqu bOp+R5b/sWkfxlUQFlA1G/KB3Ctg6Zjyf2HuBTliGjP2kTITf5h5aZ7Yq5+WucNfUOIwtfqPKkxf v8qIj/x/NcZ80tjhDzcEHw7hnDvC+/vtFyyJ/H2T+H0vzUI79gmFzMKPdDSz3R8uG0UO0QcLZp90 vV7vt4h7jIVOeD0KfKp+6Nm63dHc33Ttbh59EHlBgpjGnH0pM9EHoZcmeWppv5Y5xB8tmH1MuqvI 34f1x/biL0QmeoiQC9mxj5Y5RB8vmH13cX9awPaj0IKvZAb+tIDtR0iUDN9vyBziT2dmX0T+v5Ht Xx2ZvMj/Rm8gPT/FRuQdxJ8p35cWsPOgsGIfJbPww9CD3Fr76Dohc4g/m5n/oAAMEfseLvLk8Aho V5VrngPLGPC6YnVzEn8O6/cTK/RPpczEn8P6/diKfVItc4i/mJl/jkLg39Q3N1j1kdeVG3i4uh+6 ckD4zzbtrqyb6bR/cu1Ls8RLCsQ0hvdTMhM/rvOLwMr76Tohc4Y/BnHw7bXPof2nuednuRX7pFJm 4k8zD7SPFfukWuYQfzgz/2bmf0XpvQ558EM/1Nst2zebqmObul/vERfzsP9lu+MEQPBiev5TkDVp YsU+qZRZ+EFopiDDTP+H64TMIf5oZv5DX9v/G1h73Xykrz1RGyX74bcfkOO8//kDfgARwBkRBD3W n0n/l0QeSgdW7JNKmYk/CUHaBdb6l2qZQ/zJzPzb9o/5bm73dX9XUvbDA5yy+cKqroPPXyMDHjkR JL9rwQpNx76YUi+Jciv6UTITP67zo8yKfug6IXOIfwnvh4Qf1Afc3wPP7poKCRDifor1xyGAVtyw mpBzEgQsCbRkcv4j2H+IuMb0f1Jm4o9g/2FsBb+pljnEP8f8mfNPqb5BemCN29RrrAAggu/hAHqa feT7NC6ICFosC/Tuafyw/yCw459IyCz8sPXAt+MfXCdkDvHPMX8mfp7tV59A9D3UYIHA67xqX5L9 X73/73Oa+oeKlTzr6dsdZUcvZ/GDxUbqa+X+qZSZ+CGLC/Djpv/TMnf4gyXcX1dtkfyD/Ko/0/Re vX//rx//57e/nxNuUELXcApf+OzDMzbVg3AIk/MfJF6cx3b8I2Um/iD2ijyy4x8tc4h/CfcnF7Xw BXsHeJf/+wvles2n6guYTkmAQjB07Zbrzag8E7lv6mdekaH2Ytq/lJn4IYszMOTm/GuZQ/xLuL+6 QWi/4wZ/zrN9uRAiDmx6KgRBOeAMqs8IDSkDPoEfhb4EcY2FX8gM/AmKYQXCZAO+FjlEv4j5a/oH eDlJgJ+D5aSY53hFfFWXu2rApfRnSvsR+XpFjGqsgV7JLPSw/jiyoh+6Tsgc4l/C/PFFfibG51An v0ziz2H9kbX4JUJkos9h+xH4cXPytcwh+iW8n7vYH/G8VwSZFfsomYkf18VBasU+dJ2QucMfzvF+ h7l/3ZgpPny8KHnwAEg5wK4iTzAW/iZnP4Od+2hwMLVfykz8KWzfBz9uzr+WOcQ/x/yFARkwqfVX rPhIdFD3229R1YSLQ43zU7mlYJCCvf3tHbtHPIBVkZa+4aEdS3+T+NPQywvENCZ+KbPwh16Ugx+3 8CuZQ/zLmD9UOjYtQlqKAgXvA+wHJDCiIfPPJP4EdfsMhK6JX8pM/Ens5VlqxT6JljnE///L/SVx 5uUpYhoTv5SZ+CGLUvDj5vxrmUP8T+P+bsH8EPGHFIc7AmRGFfFBWPcV+zc5/zE6ZBI001n4hczE H6ERJi6s2CfRMof457i/MOSmz78cuDcOUXpDWL2M+gh5uWv38AuoCkyv/hHsP0qt2CeRMgs/bB3l cXP6cdkocoh+CfNnFDs2VNO//sIHwCY+97019zPoQ1h/iJjGnH0pM9GHsP4QDLkJX8vc4Y+WMH8o de5B8Y6J7hpeHzwAFT5FoIcFgSZe6YhwgZPaj67R3F77RomJHZIIFKeBnXebkmy1ZQ6xz7F+HIBY +cb1/MCxC4TzL9PYUbUvENGYcx8ImYnfR8fiYdivZQ7xz7F+Jn6HkZ+PSn5+EPhKmYU/9EIovzH/ qwTXCZlD/HOsn8n6vmnqoaaOpurz8ELXgDQPrItAD5zwGQdvIuuN0bEXonxlzr+SGfjh9NHxBHbc sH1D5hD/HOuHyoSK/MprkB6czOb1juq2xrIHB2g5v/6cIQocFz/EgM2k54+pZS9BRGPov5KZ+HFd iFDHwq9lDvEvYf3KLXLZZiz08IUeVO8GbW733Nt35c1NvYZ3uKJCmB6CKfuPc9h6HFqRj5KZ+DPY fwx23Jx/LXOIfwnrh8k8GgKeDaDKVzVo/1iD9Xi4AytIa8DP1ARHyjOl/9S1FyKiMedfyiz8sPUQ 7LiFX8nc4Y+XsH4w+6qhsg6R2Zvqpm5466Mgw8gjQI7/SvbOIy3oqr8g+ZvET117aHqw8EuZiT+F /Qc2fCVyiH4J59e07LZFw99DiZAHhA8RO6h9Vpjxen3HI9+x9rOtP1agP3HN3OxTzx5Ifwu9lJno IQt9cOPm7GuZQ/xLOL+7EvXdfk9GTq3djDq81tTfJSlwTnX3yPgp4OUtoLP4UbfP7Zp/jD4+LjPx xwX6ncCNm/i1zCH+JawfmLyuXvN+TzS8X8gQDyZPvnCODpvUfvTsoXZtRT+xlFn4QzQ3gRu38CuZ Q/xLWD930Q+ITC9AkcPSfykz8Uexh3ZnK++Ptcwh/jneT0Q/7ygEoGWNb21QbW6KBJGdvptqi1S4 o+XwpP5Tzx6Wewu/lJn4IQvizI5+tMwdfuTg0z0P2Bynoh+D839ECjCp/9S0F2F/ibn6SZmJP4D9 R2DHTf3XMof453g/8uCS93Oo/9S1F2IngYlfyiz8sHVQjxZ8KXKIfo71O2R9be0nooN6fVD9QIkT vQCbiiIgSzcmZ5+69vzcjn2kzETvw/p9sOMmfC1ziH+O9cMKrWafa8Kjv0zhj9DJd9DuKUUGehL5 BbhxA70hc4h+jvPjYEXm7073I/Ts+TlCOkP3lczEnxdekvtW7AMOXMoc4p/j/AztP2NH+9Ui9N4l KedvUInCzkqEaVIGZsaS+WhuNuaRXydkhMPYb7xk45rYuGds10P/KBgy8KgRKqlyA7Kxa00/Pm6F rXEBdgbmuG2/Xv35vXIBSFw4M6Cnm4tlBD1N2I+I3c/P/or9lXLwnnAz2r9qIMXGxDjB7rexOV3f xTbMn6kK01RfztkPqgL7EsRdPVy8FDX5SzRniI6VH87Zh59eMjT+pec6VXvCsx5voowxzkcjYj/r 5f523w8s9OEBHztS39jCGVNpYWKk/gG4mZ/mvzP2dv1233UYqNceL+P/6LGX5e7+utpuzcF7L1sa xPA5HybFPs1N6Qe9lbAXE0YQztk7xOG7a5TYkShFfARX4556F5tAY3TiHs0fVIe2dHxml1jq3vQ9 Ov3ZtroZeGZwsx/2aP/r76t1jUSJd0hgNzK3gNWvjzX1b+xRjdE3MhW3UaSqdSngd3WyLxi1SWg0 NuBEdOuj7cEUH+j7IlGLUj+JVxG16eANcPnI3YsiQBeLkm1tWRxj3++Wyffy64QMrnL1SFcpxs9w IEUEzj0qyFtNDp5+/ENXuXBb8SmbDPwAve5JaA2f1vjrssdJC9JZ+hzs4mk7pSrG+jAJWiU0xt0P FgoH6EPw+3lEi5TWHQ1ebhWQabWso2lX87S5R7Tho3PEXkYibLrwU5SeZrRAJXZ6QBxaUZylaPmG npsjoZdrxNVEL6OSNPZVgFSSG+nMcDJJvTgFN6AsCQEVGLQ8A1+iZAioTJmwpFC8l1umtq6Fc3xK 02h9zubINJTwVDg9QaCpTVPUP43GOewd5vSisV6a+OXBARE1weG4AiuglDIzoPRTNBGBcjYDai1z F1BmS8g0dwF1SI1xoW+RKUpm4CcZmHSLTDFkDvHPkWnfLiVpc0NnKz8XYhVSlxtWekwvqDBqF0qY kuEADC0L0CMERllPL65TMieLR4QcPUSZipR8CqR+/O+weEQgSPwEcTu/+VFctybHifIEzkCRwYab EBbnxRyFQDBJtfGZdjavsXIRAXrJmj0PxlockKIWMnfxR5jjWCVql8QYoBX6aIvq4UKGiOuRfvuU c4uSAjOAOIbf/Sjw4osGmECNPEAOn1N/S4h0MC9w2ssOh5YU2LOGiETJtitLhv39RHlY7xUystFH roLHyWIcBlg4MHozY6gf/1CJHSSLMdCHKfawmkOog4CS4mY0DKK7lvbNodpEnRZQ6i/6qZZp9akw jJsQasoTqdHJOJ5nSOhuH9o1urqpsc/T0cmyxzqlXvRYOD/syNguvYBMa4P0lQ8G1kZeaUVYIMvR 5fa27bARYSdTDX7I2SPIhMkoiT8QdhxOjBOv9FlJDuph/bqrr5EMtQ2qXzuQgT2lRHqIHqm6p8Yq SlNYFjhEDNkUe1ca+c+hGi8Mc05pEBFWIRUw+O2PBqivd/fYFLXF2RCMgvqNHgNHaqI4O2078MlK DaAvP42JqBJhfwLK1yhUw0OhZKU7tDBv9S0Kuc6fcYIMwjMqF62Lyap/BI+N1FWbulYYHKX15050 QrMRSi6IllF2kSamQ26+R0Xf95FrxklNQVkL2/nI2+LGRysWTseh3dFfxb1pvcpTcP5ZzEKQeojP qEgSUhdYDm1XMgQ5WhagRQq/pNPA1HtHmdMWMSxgR2sePTvDgTwyrtdjKAM4LHgo4cNWgUORolJm EqUkw5poB3Ba5mTtMxJhoDmajRNOw8HaZxCleii1/RqWKrcTXhu2sMxxnFJFcucF4scJd96hlalH OwO1r2AZYW8u3xG59VtV4X/e7dizGCdB0jb3jPNcA/X4jJzchl/u2n1gS/jRSkjuY6jue+dEaaHO utPzcemFtOzyXZ6S/yT1dkkvYkPbFMiJ1fWmxY5qvrYyRWmDhby4bxEmsX8+66uO4n/ae8sP3vvn mfMJUR1SeowwIZKvobHCvk/qhMWpQNq5y/4opSzI/NEbxh0flMjxU6K2MTmi6M3a8JPISG8pW9GO Si8yixjjUxYWgN5EWw+iEnqOY/eCthh938Ahv0fdlJGPvNTAr1e3chjK9UfjzthemRVgDOh5U7Sh Um6Ndnr0YhdahuVEyFZ0HY6N5EuM+V4hc+Ka0Q2Ivdyop82MnX78w3jOgWtGUg9qEu145gBqNR+3 eitN14/ixCknfix1Rd/y0otgUa/eXL59ffX6w7/kBltYd9kZhQV1juayJzkVUmN5SHD+5rQ/gtGg TkRdX1Q8QvYY/Y5YEh1hdbvHoajfI9Wn4w9j7PniT3VsS6BH9X0d2lKEDoM4Jg7VGA1tS+Q/JB1L yY2CHtC+tQJ7OQJqUArp1Fad60sZ4h2V65MMZ7lRc5f1XiF7ulFN5nI66ydYx8NpJkwIf+GbnFQe wNWAkcapFdOjuStRhIUK9WifHaiVUPZMqmHFsYiwTBx7IIcQwxrRCOPQr5WSgeYUMn6dGELrvcaw LrOVU46e24piELR2yDhYhsPgMLAwox9S1k/ljkh+fsB4dgTfUIIdI+MmYXwCpQPKrlUYjZyAeCNr v4iSGTRvECLRCeDcNQ+6MmSkVsvwf8tXBHM9YyMEjoOhHw4tshQRCNICTo2im3N21z7g/ITuXFgQ Mh8NFS1eSYEjjsmCAtonwgIpIlRa5BcghjVQfhnJRN7zyKVdIDaqhTGK8jiXD2ljMglXm//horRw kE8pGVqy0f0IqozufRS1UxBDfbZHS4TWnafBn3QfqPrihEYksDMDgaZvPRbwH/i72H+cGoMUIQgi FXHfI7eFlmzQcBgI2FNjG06EM1RwXgrOu5aqs0OLB8rPCehjJUOl2ZQJfZLvXdF1QubQcBTHd8Jx 0FYDHrYhqDecRYnThuFPaAN+U3G/yc/b4SZn4zesCbfJ4UGNhqsAhQwuMx1HEKC5CkyFtifgVzKH +OfaDTkKtdUMp0jAeaK7cI/mehwuWtIpI4xOGaHN1/yXcCZvBq3vGjLmNMmQ6sKB8COSMoaeg1EE dIbIx7GjFmBcJmRPWIAtl3ncuZQEiky1Zl5bznfwIhHYfhFX69vrOJN6Nx/o6Nrx5C5B6fK6609Y kqrP6AbaVjjFk3Zz6KF26FqoaQ59UugpofE5ZpjgWuQfPVBPczGmZ1c1+MlZkYQceHRZLGfUkJlk UbKCVuHgsSjD1jApIx1SshQHdYmTymSRHuyjlC03pFOOkXtE7B87KoGJ0ENFIF21bm+b+t+gdrgf oQCWiIOhvaDDqvoKgT1FXoqXHa1QT7WyKmq+jCN714aSGY4EMmQ09mkdhmw5fsucDjo4OP4pJvcQ v8hbUJG4rqgvn8o2GAvsYbo2ikoS5ArK6CMFoNhDVeCUzKjKoRCJnk/rPBpmyADyz/cq6Xoj/oGZ CcvQ5vA9/IaqsNDNj8IPrLzGfgCK5rTGOIovFd2svRV0c9s2+Gc5vkPCqXvbcBrfhGGR4egbO8w4 dVcY3fjIAb568/Y111rS3lvsq7zHKBj+CWdF4mgQ/Csg6ITAVPFGkIAOx0jTeKVkUF0ho+uwpwy+ EK13xnuljOzz1/8A7Ok5kQplbmRzdHJlYW0KZW5kb2JqCjEwOCAwIG9iago2MDM2CmVuZG9iagox MDYgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCA3OCAwIFIgL1Jlc291cmNlcyAxMDkgMCBS IC9Db250ZW50cyAxMDcgMCBSIC9NZWRpYUJveApbMCAwIDU5NSA4NDJdID4+CmVuZG9iagoxMDkg MCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMiA5IDAg UiAvQ3MxIDcgMCBSID4+IC9Gb250IDw8Ci9UVDEuMCA4IDAgUiAvVFQyLjAgMTAgMCBSIC9UVDMu MCAxMSAwIFIgPj4gPj4KZW5kb2JqCjExMiAwIG9iago8PCAvTGVuZ3RoIDExMyAwIFIgL0ZpbHRl ciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBxZ3pbxtJdsC/869oDBCsDdicvtk9XwLPlXiRzVxK FsFisaColsUMDw1J+QDmj8/vVVfVq2a3aErT3GgwlvzMVle9evdVv0U/Rb9FSRVVcRwVRR2lebRr or9Gm+jLb/ZJtNhHsflvv5DPmR9ft98W6+jrqyiexnGcRVeLyaz9x1lUJLPpLC6S6HXFL75aR19e XSXTmKevbqO/RS+S9Mv0yySL0q/SLPrxJfAXf3kZ/T26+nP03ZWsZzLwHv/b+ZWP/N4PL1lNEb24 eRm9jqd59GL5csIP/Ppb+ZdMv0fuE/6jOwNJoxdz94N75vBaHs4n/Db5tfy2xv1wcJ9pP9J5s/3s 2jwcPPP65cSsbWt+CWt6bz+xcr/Vv8f91th91P8wNRDWdPjo/u3wjD0JhvyeLKqetyfBUPTC7mny lD0lbgN2T1G4p5cTpQpLp3nyLDLl5IROJ1eLyFNSkdbT2WyWRa/zfIBMfxRS4LjfNYJafkjbb0X7 LYK4AMqe+Xbb/cysQ89DfONXIfSc55M+m9xZwjgc7nmHQfBX7ocvez8cPEFtDdVDWZ6i9vKboG2P 4uDY7fn7Y/ef8YfpWeOd/Br4y7/c/4vjg4VZFm/yfOXfdCt037Jg70zLgjOtolkWyp5UZE9i/kP2 gKVZXU+rJC+i9aSYzfSvq0j+yu9YyafM97vo1uLciC1WHcdVXbaSDFS6v/L5pMqzYpqVk0CcIah4 Y2aFXRZVUVakaWxpJHWi7EUURb/zv/v2+8vo6n8RYZOfopQPxbNEVllMqxgaW0dVPoXiklJhqy4s i8ucTXSeFdhkFcmGAjmsOxDg8IaidkPBNpIsnVYpwtrsxlJcsBu7fCQwvxUcJWCs4udRcJjk8bRM 2X2Iysyjcn/fLJa3y0X07XK+bg7NLtpsb5qXE4PQdkVPWYndvGH649PMknSa5nXxGBqWe3jZvbfV RKNgIMuzaV7kXQwo+jdNc9PAN/bNk6Rm9Vmh1LKO0oTfUHEmnqqglhBmKSh8dEwCylhSWqbpY5jz i78EAWV1NY1LEDJMQB+Wq9Vyg4hy+HseuwxSTF6k03KGZfQI4xy2l6GYvMqm1Wxm39sTP4vVdt9E h7tG/vx03+yj7W30/mH1sJtfL1fLw7LZT1vppHyUlkjhGXaXJ6F1lKf5NK/TjmDqwJxgss9O5FkL E8H0m5EWnxOwp1jSCNis6IukIwEbfbNdr5vN4avol2Zzw3FH82g9Xy0Xy+3DPvrhP36OPiwPdwAF HcGmvTSuqmlaZzXSWBHhYPCSR06FBVtngTCezDxoFFkcHu3Qxj0dX4KV8jqBnquZ0DMM1ZoeKouv m+hhM38/X67m16sGEnqjqBzprIvYnrW+FUp1SmB+WG430cP9DT9wxn/7+ftvylmW/T3a320fVjfR YjXfLW8/CelHd/PNjWH8S6iKHJMjN8TpF6wCW7it/dLDep66CHQ0pozwojmaom9xOBMDjZjFM4Rx hjKo4in/55N1lCXJNJkluYdBwR1YCusKLHzWws7n5M+aSthgLU0FyDrm5C92zXy1/gKGXWHezN83 0WK72S9vGoTX6lO03uKFLtf388WBY55v4Gn5+l0pUc2kWQYiZvB0FmfTrCjTCKPegGSnHpROZ2WZ dHh65mHn7/6zcqxytH1i91c//PCPr//rl/+BuX5sdvvtZr5afXoVvY1utps/yY6Xm1+jD+BEdr64 Wzbg55Hdl8V0VmRlZ/sOFu4fWFpAWGpgTmYKG3H/9RlynA3uiTP89rDcNSLQjdzePhyiBvmN8Xfd COPfbe9fX396zbdou3ts/wUiPY+Tzv4dLNx/gUjP6rSzf4WNt/8sOeP8263LHpu0ifbN4mG3PHyC Gv7aRPe77bXhAbEIo9uHncHIo9RfwP3H5O9gnf1ju6V4WeH58zkLG3H/6RnnP4fgP+2XOKbO0FZ2 xkzGqE050CSpp2U9qyYzB8PFs7BolsO8CZaMbiiEyYaeaAJ+Tq5leV8gcyy6h8BtmjzBbTolUbJk msdZlaCqeX1PaX779s1fvrv67ud/OIES3e62a6MYm90Opplv9h/gp+UGc7DVpo84WOMo9qxwh99R 7Pfb5ebQwdNTnLlT5zIjLpLExq3k3X21g44O3ksI4hlu7anz4d3TMinEJRra+/tl84EzgI05lmAh hjRH8Srx53ETiTSYBfQRIDaSvjiBLkeizBT+c5TpT11VnpNposQx0I1JF7B7ktVTbM86mqXVNKkI fGCSpwnWeTnxIOFsA+JTs2lZccAIAH3Sw57P7IHplceEasr8UUwqFgM+N9ic/HHmyXHjy1JiA0Nk tN0t3y0RmUZlNvvD4/zs5el5SzrFWmL3ZjMn8j7Lz5OzyfkUP4X8PHPyTqlKbO7Hz+FMT/TUpkN+ Hti78DNa+vtWKb9Sa/SJquYUCtKkmpYEi1r0931i4Wj/pcj4w65HBo9VRWpUjd+6oj5wPZKKCFpS 43qkBPVmaY3rAQ9Pk5RYhYMJq4awZCa2V+fRFnS+6XHq4Ay1VgMa4NjxWMzvfXgk2jTvtkYx4m/O 91jcqxXH+8vDu3dwGdaX/xp0PODZpMChCj0PBwtNLwKOZVGVgaUywXJxsPP3f4pqZP95PMAxR/tX glGLC8FXEpcMQ9QtiMizRq0BEX0PHaiILJ+DjSKCgwg1e+krM138BURwEKFWRKrYW24Wq4e9BCaQ Qffb/X5JcKSzoKdo1lOknMXE4/JKbIpBLMxvbrDmxGc0snBikqZPZP9TpBREWhURKgjeN7vr+bvm q+jNxoTcthv89V2zmh+aQMGnJIGzqkIeeOrK0pJcSFJPHAgesaCQkjpPWop7PnUNBnQNsySDwqJz os5avIA1nyd9S3m5ud3u1m30Cy/w/dKEON/89497F/kiNHez3C8e9nuEk9iVjhDxmFUZnaf7T5GA QVDmpIkyAfJw1yxMEJZkRUTgW4KFLIa0ofPkznv7KQYwbydbdxyYfHN/L2Hfj9HXCOnvPs6xLCE5 H/g778Wf3Xbd3/bX04Q3/oU3w/vfohowxoQDX/8sQaxoR+QCbIhTz7/tzcGEn/r37f4w9jKLuE8/ rbY6Ws3YB4OB2jsYXuzdSiJZ2w/ggCjtksiO7vsyJhLLGTCRwoTMsaoYwUokfTitsloSM0Po2N63 4hm5uG9WzeIySMiwwvIyrttFDCBB7USlgSeqCculoZc0K6fxjBhruHVVDoGVmBYl68OfIkg9jdMi wUr0GRYHE5vIZV3KbEaGPDchOn3Ww863kz4nW4qByDok3MnlR4fd/FYS0tfN4UPTbJSOvd1UZoQT EmIPWL/5bErFU8peLQxTN4TFSdwJvcrnLOwZus3KsOBYUkKZZR6LA8nu+sSgFHAJdiCOnOeJoUSP WlUaNyow4Ycd9oMicxyZXZROCOhbOdAtdSlOKz1R+pwiITlXm4nmxX0rdR64qPDbWMZD4BrrfpXz ds39dmfyZaZywm+8kFRIRYCIxP20rjErIVfyP/Usrz0MQ78Dy2tKViisCZ+1sGeQa1+KJDMiuySe hFyHUNg5N2eFjRVrSUjl5impAPNyyytKOFaNv4pIumyi5a1EU0lGzeX/d2i0vRMJJsxqtVyLbip/ nkhnp6yRomZRtYktDh24MTMeR9QIaq6kYMgGV/WUFFHgRV9/HiOfYiux+oqqb/XByK3UwAS7Qqe1 GCdTRsGDySPhlZFIkbDIsdEVYTvz1NtAep+3zlPHYtbpk1yKDta5mO9Z1AdDL7KecKmb7YF/l6zm sVQaJ3KWUcZWFpmEjYhJ9DXAkVQazVktajTfTKJGEgo5zvuS5V14odTJYCa1hJuoRiuNMEKXheaB g4XmAbB8FkuJnHt2Is9a2PnmwecOtzwng4fzpcSvJkFMPqJAromMpVi4qGes0cJExrawqKCwoC5C iyAAjSNhy1yMLjFR2U/vXAIVdWwQjBDNpgaBSkNy8ublPQnr6jwsX4tL2Szfh9GD87j0c9KkTB1B drhUONML+aXJS7UxlBFld5JX6JhUFByr6HOjJPaVfo6PYATZHSi5ITRs18tDX1xKRMG4j0aaWhzh 3yNfxzbZMFZ7dIEEPZbirYMt68L5d3mk6O3Nqw7yxjKxsoJ0k3RBcGp+fWpiRc3tLd4cpIpnpwtI jNI/O/1ximqDSkMW0OPa69V28au+OM3z6SxPqklRYYBnUgORwvbYVXXkQCJAPSif1hmlEsDsk3zM w4zYeVZ+MPBDgtKyQQzq4i9A875cS3GnjL9qDkYRzTd2DRhr54mZz+oLn/7Ut0HKxlh0AQBvjj9R xpwiliQt8CENsQ6lvoWVFN0jZn6TQLX4rSuXOMe5m/JW1UeFW53MJGviPWSpehOYuCHOazaVcAkp 0VBtSnVcCxtFSQZeczmEQkXfMbWOoCRT9Zp5eU8YWptXl3A2sU5cW9Zx5btYrmTRrVjpEOs3Jli3 pwhvvTYB/T2R1mi9/Hh42LWFxT3bWoRyCBxbQ8x8Nquz0sGQK0b+91S7NG1M+BX5cbyjaB6oDIoI DxKp3ssfowcgZgPRfOO3kCairLGrrcYyvYNcNe/vKQsfgmUhQkV/JE8USPiE4u80i6UOX3et3B8E AJOE0sQ6TqMCnq6kVBWWd+VbHgZ7uzIvgWUlRpPAgmct7HwL/5TUFCaYZX3dCpY6AUDLeGEzD+k4 6ktxWYJMqYcFqdKCEpUqJzyMogUzphHIwS7QzMNu+gamyo1j0XWm1juFwyBVqqhULqX6noofKlqj D6acVdxelQ5P1ICntC/VQkQ9xc0YxMGHu+XiLtSB4xlqgaWoGFAu+GDq1MmNIYUogCIwN6fIta1n Rlb9J6ElKeskfbWH7o784mxa5xTqesqivEDsu6TMFEbq1MOU2hIiRvLsxFEbFHg+15zCtOGa3Gkp 3egx10hGmOQPYY5d8+6BOn2TA5G9I46p9G7rEfevov3WlnQf7z/gGNrVslJ8aV/FXUgLm8CC8gqB ZRRAK7OxfQcacfflAJcdyYxeM4qrbZ9LAndHYfcOBEhazLoSr6TqZLCqvcC4y6Q7I9y9g4W7p3mn SmneCbevsBH3j3l2HN3pnT4F3YtfOfIt9L1b3twQQL3+xEFvKIOEMiSCt22r/dt6fnP4w/unfoCy 13D3LSTcu9QYxHWnJEWazwVm5ezZRpPvZR8ymtBin9/7fvluIy2MyumIP2lXET+aOnfRx9sNPsiD NCvdkiWVbPJQYVGRUJddY/p2dm9h4f5jGpi7YaRJobDxzr7yyeYTnG9Zu23B6nRlSRvalQRFh3Rq TBl31fqukDflrEg+BxOaDmAphB7QufmcwMbSqVqEObjhi6rUnErXnC4ndBkv75norTfQdjthw85V nY5D4fQF9zwQmBN7WQzY10H9uI0KyZl+TcPGdrMwPYjuo4Kk0aNpIXL8QgNS7LTsXsDeCcIyIKp3 OBY7jY9KjZwHIleM2yYhdj2mYPdHjv54Rk5RSv8F7WTmxT0Ho/m4aEylg2gwf+xeV9NiTeaxNo1Z 0miSz8rIw5BiCiOKVVbSmeKenWA8O9iIUmyoVORYg4c5Y2+K5NL8WWB/rSMsTtqomCThYSsPiwRG /LBj+Acw2coTrd9TVrjYZGRQeucC3w6KqtGipNqTwut7YsMmvUxjn4kiiN23f7jeS3kUlo8TIGIS Gq/cChmqyVSqPRFNp0zXICSpy/2nsE/AtwPHhD2kx5RKq3dSJZCVsEoqvnIKA+EE1JCVhaEPPYwM OrFfsYTds1GuMEjNhHKf3uwRuPpQ8jSuKokwDmJOl38BmUvaalrVRKtDIlcfc8+YCH3/b6az54+2 oFemFGHCuCJ9j1GCUrPibBhKNMnh0rFobDtD4CKAWx3gOzTs0sZVBDkFUnFJ3T0o8RUvASWb5ndF ygUOJWhbb5Els50UWRuGxriCm/Psks/Kt+GCgDDuKNWVLtF/Kyfj04m+MnREaZLR8hAXzODgDIY6 fcM0+wUOIBgiwut7lsj+YbHAZLt9cJ72K5NRa0WyStfzzuaUUDX792UGSgGwS8sYi+1926D/g+ld em1qYD1xPPFATlFJmpHeykq7oL4yfD9fPQSJEDtb7Oxs3SkkpIyOqEj3Cy14XCg/4t2R9fgX6PHm gawhnQMuNQKWWpOpHXiWlDSDSIkWv4vJaeSLEf5WIXhYR9DzuVS6HgmUhs9a2Pkm0ynECkbrodKB Y5OpDbPdzYNSbLWcsPKSChed0G9Ki1uMcZQ7GKv3MCpqsQFD926SK+wZlpM9uECdpbjVlSmQYVt9 f15F1wX4NmjqUpwq2/iuXduvu4aJyR+iVS5lFKkqGURGKMaS8TwK6pWp1yFYN0xad8t30v3PDJuN zIGQITZEj6i08ZI8pa6ilNC6JyJiJHSi5hnjeTwMT8LDlIjcs+MQVttYIgPlAhIzPOOrTlQUwO8X Ja+gTbz2r1fyGlKXYn5TnHU3YJrzT4rxJ4rqU/IycONZZZ8DL+bIhmTn0aOnQ0ZQQnGtHAsDcp7Y oKYSBzAMyOUOpm5rJLBkRkICo9w+C7F52Ply+RQWDY0NVaccy2U7LUeyEO+3TFa5kcrEjW8ZwqB9 S1DeNpNBBtCC0UvKbKDIJK9kRB6KRkqHnYseeVi4f3QxM1bCmQyTXGEj7t8nzPUUZe2yAfvt924w fh+tH7ATaZPyRohTUhMyJggV5iGhpGb03sUMGfQwlFQIoz4hnKFhPmdhbO+P+1zBdLp6aJO6/Ato qcC45eV967KNBrper9EKaOrKCQMVWRwj/YVtDQ2mRYQH9ilaLSlbg47bBpug2/CJQuqU2RMYdayr b08iNvUMRqyqCXHv8aHU7RNnrZRaNwCCdcyqKZSTRrn0FWNsQMqu/2biYUgl11cjsIReb6Hu4NEW 9Axry2I0UIWE+1yj0CAedfHHhDxCbU3gpw4RlxSGfJKicclTrbZzeimvaV81k4hkkOqoPiz1v31H DfL2cTATBJPU0BzaGlLVEmt/S/LQp9XJMVFOrjp6FH+ujIeLWExBqOJkRFbTjhZ5d5/VxB7gy74b cfNES7TvAmiDebBbZbKgeMX3vWfUqbdN/nh7uXE0LYSKjwAS17kkHTvPCQwWe6be69uWZXxG4Qpd BnbCwSd/ahOn6yKZ4RlXYFscMnaWkHrzMHHIHKyqp2SiwrwyJQctbKx8mzpFsrG+PeiXLw5Ipwto hBoWcuYcJ1ouC7Cq+sdyp1/CMzV76yUczRNOK8ah5wydNq/u7/tS80TVtgi2rNS/3JBl1DFNE2/3 ePqAZlzXhodBMx6mNKPPjkwzOI623+T/gWaykgkGlEw/QjNzmvOpEN9JlsMmbGV2ocrpJ8rOU14A g4SnaUVK7TEa6lb/jufCS2G5maEa8o0SUSfxL9zTJoP9FEpPN7gSRPhrZkGE8kdhSkvu2YmTP1ak Pg+bgYlSMp9mltBR9AgOPfNfQv6UpDjpHiZ4GDCjyp/thugP9TMHSkoYC+19sudtelAMVYwOY3iP lYB9MdS1dMejoAqPsM5kEHawc6UgSuaaj0uZsfAuzCujehk6JA1NqsEktxon8pscbGVysC1MKcg9 e0xBI9lN59TF2cDebo5Rs5O8p2tDYJSrKmda+qnQlk75hBmWZvSzBYmlHoBixi4B6jxpYV3rfYzE WBmbYRySGNNjUsPsMgPjNaRlX99NNR3bycZE/hMjsNtpNGtsaWPgmwKFtiIRtXq4220PhxUjN4l2 KFONRAe+Qk7ZOLTzad6RothXDDPtSBY46+x0xCnPVVu+aIscMqfDqRgjeq6hGedRoISyoAf0EIRd 1MQssTVxRMUUJSVQk1BDJFiYkHsLmwgsZgqmsIA3TxXWpfezZpH3vVVtxhjGXefAOqboCN5qKuOK iWCLQPQIVBqSHHPn/WMRjA6aGt40kljfOyLBaKtysF8lGCsqTaAjeL8bJudJhBBHBpZIL3mywTPp wBzZhM9a2ChkwxgBma5gVNkQy+nyjz2YEchGywECNCrZ+NhGOxkiup4vfqXG5sN8dyON8wFHnif+ TokeYdy4Hgxz2HIg6r3Fnbd/k/ZXL4sF7oIhbZUF1jPxEAa9322Xi8u0DoT281B1b6ek8Ilxh1OY 0gHvAcKU9tcmCq9xiIkf1Q6Caegm+IzhLCF1GZ7oYcTgPQwHqaDuDmmpz1qYddzPO+9T3oecd3JO UbDpcGjme6kFGDZ5uFujSPJMTB6mPPM/zGRhIvBDWJxwQ1Bo9PA5Cwu5eQTWMvsbqjT10aiLGz3J QKHpw/7BtNWY6fg0I3PxBR4CzRQMJzRFSfc7GVpiRpAJxltjJ5hMZnoyvS8xEh34skqVPZg97Qh3 dJfp/RAev13uyMDcr+aLhr4H2JvZ7wgpI4zaSD/2mww9V8NsRG9HywBJULl8gzKezLJTaT0mw2Oj VxXNb3CMH52m722tIwq626AzQU7at2mGFa+UHD0ejoxGdi6wwuBud9kDzS/TWsqxYA19toWNFaoL vP5B7CnqjhXdCKE6HYQToFCJrWsfjVIKyEhvUWa9UkAzVJ0BQK0qDTUaZYFtOv1mt2VM4bHBNtKM Fw1+scC+x261KEpUz2NEUiZkyX1ECQFjix9xyZSUe609nVS61N4w2y3DYmL0VIemLSgkaUDUibSj CtonJ/KkhYm0H0l4DdVRHieSN4yA2+64kIOAjGsqtsUp2uHDkDOVW+qX8xPVB1I54GcuZA4Gv7o5 DBntHzXTYgL1xoY9LFRvz9n5QCqBPt5+xiUknAswcuDT6+uVkX8Qo5BSDP7YmVYXURNBDtgYR0b3 rZrmw/yT4ntMPcG82nYMfMka+zx2KT0RWPOKG2UuJo9REnUgIRb0WlD3OOXiLiJ4MgcJfSFk5lWA g4VqIeaBjOpyYPZZLEwPG4+vqLXro+6YrzqxYgo02qI37IHWSfEyTLNXqcxNSmkpZ580utH2m1AS b2HsKYRRHB8WopjPCWwslajzN0m4D+zWL/8S0WMJeLZX8cnLLSMrJ5kEt89uK5+MIzRpyrOHq2/E 4tMcuihD59GJ4X9gWhsXOjIA7XNZbq4JfVry/XNeCncDDa1V5IwWl6wfVoclw4Rt1mYvtXFLrOj7 RmK1cgtaJFuSh94x/WfD5pj7O/pSfb1PF61YysEkC4ZbyCA51iBTh9uyLcX1tpWeryLjeLkQQGhS j0QC/nKGzlrbrNfeVQjhJJ33ulMes1jO2XAJxVsznNHTOcdHPYfUjOIPcUQ0FrX17+1Jr+cyp1xK HucUwVFa207qG/sYs+EyClFq+Gh4OPDB/sE5byZbvzB1rosdU+U7UoPhoWdHhk8xQhBw09WpbjGd +friZLxUT0bpXClmDUc4UOEhp+GnA5rLKkOTUQbHlxRd0jlIKzwjhwPl5mGBcktJiVZpYYS+fXYS wMZTbtlQscKxcnurmXRN06Qyq4EgNlvxjYQeFjQSCgz/rlNpGMCeYQ72Q94JtWBpSoEKZzNUVqIE cWwJjhBg0RlS8vKehLZyRJxywkY3yF+Ja+iKRpIq1Hkez5g3CRuE++ujMeqSXxLzFAaWKZ+tXDFq QDRFswoU15jGqL95lhthnNINGFf0QFjSeh5eEBWnZkSVhBWHXAOUt7mgkQJMPYkR0wIkw8nwEuGE IAeGbYgdoe+lunDGVVAZvEWrMEUZwlJM/cBHzRUGS1kYNiR9QkzlwfTtPGth47CUn/o4jENd/iVY KuBnjz7VzmoL2Bi7KkUTc/NFj08k31OqW28SGcaHGFSKkxFJKXCmhkjpGg7m0tgGl2OBfFnu17A9 Xxp39+6R0pLG3Q0tGZoL4u4BfTnXyjwb0Nd53HkKoYY3hhJNx9pnK3VI2Dncy9K8l4kkfGtW0uXg LmaDCuw1VjjZ7W2M7N9b3z6CIdexpHL5Nft3l6l6mOQY7AWr3O1OwQJKHo2MhJK+gUkAG1H7DqVr jvdv74F2m6Wi5J7atiWNHiZi44kucC1lcAqjP0PP0oJCxxIQt2h2Rs6I1ymwCziWuHl9N9ov/sKO JS/vqUebv0Mvu+yCksx55H3KThXy5hq+njkAaxpVe6yUxU/zDSys6bgoxN7MMvoSfWZIxatZYnv/ i5WvTuCqV4ID0jk7k8cfwZgK6jpzv7TASqADSN+bjGjdk5zLSaTKqflslb73mpCVpKjmcqda+xUI mERKtkiIJDLqg1CnMF4pd0FS0+hhcF4IS9kp8sU+OpGPWdB44oWa4D7LHYuX125DT/oe7N6JSC7E E6OHCoJAvHpYIF7lLj1EaidAHMBG3P9QYkH2//N3P8m3f5U/fmka8/ekUsLSLckYiph7C0jp2nod aoktLKjhEVgac9Ghagy6UTxsFIssqE2iO7Rv1eryL2CRBSXmvLwn1bRY2CePWr/nMuNCjXAdumyD yB0hJsWEkRDjBB6kOb2dIMIFg32+EpKCQsIbF50453I7YjntRXOBWUY3LwZdkUNQNDDVbaOTCxR4 mChsGzyQUfRlzRAVKkPtsxCZh0FkIwhgg9qhaRDCK0Tb5Zv5498eljdzydV3VIFyDpOVS6ahResJ WVaCHvwonrKBwTkhDFnQKYaQz1lYl3OeUgEaFEfrXAVaIwPOYYDC1W30IqCXY845M+Z3ygvVy4WD l6uyFb/Bx/pcZLZ1xok146Kvlr/KjPYLNc/rXCxZXV9bXErfyk0SVS3pngArqm/bKwN96plSgoyr ZKkMmCkRoWUoqzSzuALC6sAsEXWeFdhY5m1Z4jHEctfxMPZUED2TsE45UCWsz01HUjGoVK2EpSLZ lCt5b+iJPvEpG3fGMKeMweOPbV/IWVEworVWMWY5M0WmunMlnpvmIFcbtNebbvjmvgKjhbFUNEeT ffOks44KSd7XtMR4GNdGhTBLTu7ZyZGcGslpGMrUWqnrhS+zzblCAmf4y/n1Ri7aXMkscMW1E8OT hPEqLNPc4uJ6vz0MMawwxg9zdXlovxCEaUFGCJuusVFC+KJimAvaFzb/vJQ9r+/5g/MNdxzeNwsZ fIpIPh6UFSTwJfsigSaJ6ULjUoZqKuE9j41DCczN7RlakLK9Qf1A4NYn+7yD1hbIcnHT8nBnW7ik d+Bnc6Pa1ad7UoXhDJKRFjqcmPzZDQt6/WOzW1A9R5guMjOMxs+qFf6ab5WA4Or75TuG/kdVtFxx 4zEzi7jYt80zzuVGgObGuOGCoT0LnO+WWyw4Fxx3I/jH9rkpQBs619YSELLbR78kr6Jf0ra08JfM JQ58brRrJ3xhzIUvpmOvEx09tM43mwHX/0xD6ZQ+Y0Jf1V7HWfLmvn9DwE8F3IgBVrzRWPJYdET6 DasykSHgr0yi07TjMAKaFgaTct2HMVb6/2JTFEa1I7UcDFXD7vXC1cFCgQuMAXhizHeetTARuecx 5ymUiqSlvq2Py2N9cs342/mKwnb2Rza52a2bm6WU6Hz7xhQ9KGk5zRLRKctlaWaqd8pN8SjiSmGo EQ8rp1yMSHpKVcuEhKGDdQ38s1perEkSGPhBCQnb7SsWpZsL2GFBZkBxrVJI2JoAY+O0M7bsiCZY TkwplesvzUH3dy5ZNd19Ml7ArKAki+ZvKdzXXSvbyKQe9GKwaQLvcgVkokQShIk8MQVhooBI9FlL OGMZ8IH7888nnKB/QlGohGOzxV7om+IjuY5Aqi7u57S3e3tjRIIKOloHMYIUNl9/lKgC7q0JcJjO 10FKCiMmeDwZ9rmjFhot8pm0cNN67GASHPEwFTO5e1RBI4rYoZqDYxHbKhLY0ZoVtqugucEo+vaN tdiaj8heUlgtjvkzcFm85JVm4Dwzgwh9ysrDAgYCRkiyvSQN3jNprAB2/v5P+YBGxQzl84/3byuP pTSml6wTa9UTlOax6BdmmAYzyIinO3XiYYGKYQYFflr3DkoH+0OSYrDXPFQ2Qxu/1LxBMFCaUIMo 0+PrKwaygx3SsVcPeOwFstfDQtIJMdo+O3EYhcNGJB2f3lfdIWTfMoANNbaV6aiUgTSM55TeD539 2+lvWGTcqmGKbj3reFiwf2DMJEVGBUZLABvFaAl1zxAWPEOI0u706Y5gGYa6x5fIqO4xF4v5Moqf /g+3TjArCmVuZHN0cmVhbQplbmRvYmoKMTEzIDAgb2JqCjkwNDQKZW5kb2JqCjExMCAwIG9iago8 PCAvVHlwZSAvUGFnZSAvUGFyZW50IDExMSAwIFIgL1Jlc291cmNlcyAxMTQgMCBSIC9Db250ZW50 cyAxMTIgMCBSIC9NZWRpYUJveApbMCAwIDU5NSA4NDJdID4+CmVuZG9iagoxMTQgMCBvYmoKPDwg L1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMiA5IDAgUiAvQ3MxIDcg MCBSID4+IC9Gb250IDw8Ci9UVDEuMCA4IDAgUiAvVFQyLjAgMTAgMCBSIC9UVDMuMCAxMSAwIFIg Pj4gPj4KZW5kb2JqCjExNiAwIG9iago8PCAvTGVuZ3RoIDExNyAwIFIgL0ZpbHRlciAvRmxhdGVE ZWNvZGUgPj4Kc3RyZWFtCngBxV1tcxvJcf6OXzGlqsRUlYjb912okrjOJ6esVHwnS6zkQ5hyQcCS hA0CFACKp5R+fJ6enenuxS6WIDnwxbEJNbHcme6efptner6Yv5gvJq5MFUUmzycmycymNv9tVuaH n7axmW1NZP+zndH37Mfz5sfs1vzhwkTjKIpSczEblc0vS5PH5biM8ticV/jDF7fmh4uLeBzh6Ysr 8z/mLE5+SH6IU5O8TVLz4TXoZ39+bf7XXPyH+eMFjWfU8x7+6/iTB/7uw2uMJjdn89fmPBpn5mzx eoQP+PNX9JtUfhr/Df7qxlISczb1H/wzu3N6OBvhr9GfxV+r/Yed/07zldab3Xdv7cPqmfPXIzu2 tf0jGNNX942l/6v8Hv9XI/9V/jC2FIxp96v/3e4ZcyIO8Zwcq543J+KQOXNzGj1lTrGfgJuT0XN6 PRKtcHqaxc9SU0iO9HR0MTOsSXkyGZdlmZrzLOtR0w+kChD3dU2sxYek+VE0PwyUC0SaM35ctb9T tvS5b93wKEifs2zUXSY3TjF2uzu8wzL4rf/wQ+fDjhVqbbUemsUataW/BN1mFiuxO/mz2Pk7LExe Gtf0Z7C++OX8G78OZnZYeBOvK37TFel9swQ7Mi1yyLQyZaptT0K2J7b/ge0Bl8rJZFzFWW5uR3lZ yj+Xhv6Jv7Gkb9mfN+aKjNE4j+JJEVX4bM0XEaIKlMZSyT/xXDyJS6zuaqTMGgwW3pw238bPyqRF UZVOV1Jv0s6MMdt6u12sV+bybDGux2azvt/Vc/P5m3lXb3eL1XSHX55/rKfL28vXY2P+cL8z69Ws NlN+crF9Pbr4m7OAduyPDdU8MtQySpxatYaKAU0/Lxfbm3r+xkyXS9j7L/cgbs1iZXY30x0P6fZ+ uzPXa7PD/9/UZju9xf/Um6/1Zhx8rGnvWI35abmoVztw2Jgfr/0n8ym2FPzPp4Q/pa+NY+BI+SyR MhGxjrwOKKE/ysmsdJxMtNDtm7/79xv9iYfi1v5T9U9pXZLhpWkVQ/nKzCufjANewqtNnE7GSQon Xhb5uMzTYnRr4iwd478F02iZaFqSJyXR9LOO5paRXT6jLy/WySTDAk4nWTORgwwNykdr9vfXcRan 46IoDjD04x//IixNknycRGk58iw1tyZJi/EkgaFh2rJNc+zzz9rvCUuDK2fhl44ohddJmcgJzCHs ZRZHseVjkXSs4vfLs/jytfnYWBdYxncf324aCyjWI+BC1ep1mCXf4ah5vVjL/oKlmSbQrxwOBkuT OSBS+L16VVmN0zhJTJlX4ySLYlqaVTJO4gk8m6NZD8Y0BNHpJCGaPMu0wEszTcpxlSfWxhzmncHS VFN6FvceW5A9bLy4WWytk1ps6ltyAfjnar0z9a93y8VssVt+M9P5fAMP3Lhc+CpRMFmEnsm3Jkuy cYYVrBmvaMxk/+yozJmmGY+MSNzJkd6FIlBl3K3qIHxpwj9RnWMWMAIq78uOfPlePKMXcOk9nMQK 38/d//3bd5H6ExfsUDgV58U4SRDQY/UMsKDtDzhGanLEoxfvkIvXy5j5ILJIJjJ9tRajcZkUJfxB XBXjOCkzqJOjUSTa0KA6CL0TRLetdcy0Z6jTEEvTNB8XeZo+ylI3oxFlVS9VI6vDk8NO6ERGAxyO wHaaKszk/gJ698v7n8x2vbynyBsR98VNjbpGYzluFqvrJtitTet7YjYKFCyqNIO9RqyUxGlCfr+o kCCUMBueBr8vtGRcxihoLI1/dlQicnO0Z8i5pbF7ZiNDLpQ5vnem7m1Ha+F4YitIPcViquLJOAW/ rFg6QZ7NLx7W98u5udvUX8maU2pxvZ4ut2Z9hX/s2fqrzRo1lIu/jWxpKEuqcRZFLbEU0Pk8ghlR YlE0FoF/9oRiIYlU0WFrrpn/DxOIsm4YW0cin2taDdPZzQLimGOl/IxMdTr/23RGwrHL42Gxu0FC a+oEpS8OnlxUMirJ5kwQxtyaFD42KhIkIJ62bNMQ7UxalhDfczSskJCRcYHhTSIYBiuRzqw9941y bcdZwiHza+WPIG/fGPm3ifxFpeFQob5PrlMMWYc4wypJIAbMnUej/HqTSG/rZT1D1v8JJTgv1MiK IIhTTSqY0AyVNTuIPgEIN07kIdIJqWOat/ggfn1bz+43i903M7P26DOqMSt4iO19bchZqBpHgop2 WlXw8LA/cO0Z6TqMe5aiXM406LrQynFR5VST8s+OSsTYjhbYG1i1S387s6PiWW1skDXvLwRdrOCs BklUUUJbdUbkaRRJNRkR+If6XNlOiJj0DI4OLWSVD1UDjGXrESyOQhLWYZpYD1moT4x+h+YqcRRe 3jFdrWqIRDaooMT5BLVYqP+4amy+py01LUE8WhUqKjKIiDwtsM2PI0RFMQozMDkDfAyQxSqNjyeo EKWRe2mHf7oGEKMqN6HgxXGKagCIlopJiRqAcE/RmFOxPMs0rfMhynMRXEQaU0B9Yu711gCSqhpX We5e3+Hje0r7V7/bmdmynm7MzfqBaucuvjdNRLlY7erNVdt0xwX4VWFWzGBtuoXpYrpFPf2zo7bK 2rrHE7YUhlx1kaGyQMGrZXpn1n7pt0J5ZwVgc55oBVoD2asFVHE8zlNbyuqTfoq9Rx8kSKnEsw8l lTQZp1Fbjz1Ns08926vHR6ajg/aMeInEfN/3eF7uhx1NZhGQlXGRjaMkt5FP0fWBn+6vr7HdglrV w3ozR/D91vyIeta8NjPEHzfTr7W5rRFwz5EQ4d9QdNrbs8wnkUfwgvkE+hwh7M4KikSwcNMchTNP QiCiSdgziyno1k8SbbQ02oQcyfohJcoLsmbxoZl7CbS02RPDB+JV15vxy9p1TES9QWJe5Uqrrh+/ 26x3iLgNpbRmjV205Xo6b/5F4qei5sps7+/u1htsGV7b3AvbsT739c7XFAhrUZEg0XP5gWmqJAG/ Mi7IoKuShKK9VPaHShLVAN8V21XeE4r9Wv2Y/yrvuTxLDm1IsHELWN8ssd8VJxHtjwzwxOt9uBBy 0rU5ovf+k5hzJQi703ekHRgywToBhalqLLESRLuw3BjgJzJ+yAwlaYaQrLBp0QAzWmZI+PFETzDE B52AMh8kAUVNsimw3Nazm+lqsb0197SHQfUWV5gUa2BNhBQofVoJa4D0CegFWIMMoUuJFS60ZZsW xxUVKP2zI3rW0QJbA+L9JB4ywF4RtTsWmkz0ieIY0guVnGJsnTzrYQEwBG0scRzZSIIKlNM77DVN CbFhi5T1tq8SVlTIiiKEsKoSxjRVCUNVZlxEqN+qPQFFgyhOVAnrm7XnOeeyFhF4zJ7AkOZb+aM4 f0wQ5keAKtApCtIKPzFJuqbRxVp6i4AEjq3G6ebvDR6G/o2FuS96isY8aqIoUYSeoPwP0afVOE8g XaZB9JoWUYQE0etniRY+HivwCiScThgdhfeM14ZQ7OCXozaGHlUC7KEcowQS5wRc8CoSn2TdBe/D 7NvpN7O4vZsiNiNRXy/Xn6dLidCaFW9DdMcdHYcDETZG4kPl7wSlgDyLJoZpsLVCK8cAqtnyt4/E i6KhhZd8niMHqVBshxnumTlLXsR9gjCgwD57SuhgO4huGAAUlw+DCYu2qXf3m9XW/PKfH8UQBAwL 7DLIuxbAM6PfE8lvhVdeRQNUXbRP6hnbdDW3Oll/nS7vLYrQWSGz20yvrhYzcG1+P6NNTrZVSkl9 jbUoYNALpKQwT6jLA7KCIMHTYJ40LSqAsdSeCd8jWnglLQGuKmMbp0165u45fwLPhDLyMUbJj+Af 4JnKrnna1D4TtNUBG55saygEcJpYI1u4rPdXqILZ395MgfJ1FZqRuJYcUXceU20dCSMKtfgIfEBD g9yFlozzPLZlAnZLeUMLL/ciLoC/sbapZ9qe6Sf1SozilWjcv1ebAWLpKetDk6prjrxXAurWVwym 19PFCljceb1akGe6sjDcBeGHd7vp7O/bN2qg7FwyeKO0oho9KnPjpEgRkngaZK9pQDhSjd6XiEb0 PUcLnBjABRL2isq8mPzBVaiF7wUDO8Dx4XHByVAyAG9QAklwMCg60Z4kl4jo5Z3pq0jT7bwfTElu sfx/FIZIdQihJqqPlA8iCEWJEIBbiL6hIR4RGmIPxMYQu392VKRMCyz2DE4kKwFDtkzvzJtFzDaM iux+XzxYfShFqlyBNVryqixxeZaiPvTjavtQb4BX/cXhVd/88qe3n+I3MLlvP17867s/Xb5ujdJE ozDFQxpW3LUHnjdil1qv90wKX7uh0ThJKSb9iy/e2MLVCWs3g8zQ9kHYcZxVeCRlKSOglw5HB/I2 RIGhNFNZBT4IIZ7pkNkHcAEVic2KisVkOazJWOwA7MCBHL9h4Be3KZJkDJhOg2TDWZwS2SrTqGys aNkEx6LEMNjvES18LJChZlKVAE9C+Xum7pVfy7uX1hKLXQsBgvMK2yhAJmBvt3dwgKoJ8BhBGfbK DUAeMpQM+IS8yhBzCe/zGJawwFE0puEAk6Mxn8H71rNOHs8wyo8qe8+REs9gsTj9n8T7+IToyNqx 88tqF13SIOyGdm1gH26kwJZ4VmH4CjfCNMQyHjdSxNl4UiH40TmN0ALzVJAjNJGDdoRzmlBl/xIY jN8wlumB7fcjRwqEnRPsxUNqjBxhmkKOEC0DC1tWSGiQWsgaqSBHBvnYv30VzPOW2D1NUCGCtWF+ Ks+7rbFHiCjkjT1duDXvPnIRALnCp+SfP6WyIsPWTcqoBxcvZkIs3hMNgbNOyhAoT9hzJkChacSv IeEBbmQCNA023ieTGEpTOBppj6flwEyjzKAVSkhtK/DikxUTODUk4TbcHeAcvNpLWdeLpYmVJvVw 8f1qsaM8clf/umu2OAA8+PSWMPJu28njarx7U2dTY7uAyad5Huv80tNUfilM9o+OhNTm+1EV51ZS t7cJLdklaeyA9fW6KxKgmi4lHWGQAGUW47zXBKXP3qWTKsxtWgEwn6RthmLrHvqTCJPBUEdT3ONH X8TQoRChxBmdCQ6pNfMYYKjT43Du7Dc8UFISbnw/A7BVNirH2jOMZo7DaDMcPWv2jZr9wVlToIUx frhZzG7MVMwxWytsEo0nBIsm8Aa2qXGq3TCNonBFyzJglyUKh+ABOW5ogddNNomBwUU9BuraM3e1 WvzH00SEvdZMoGk0uE6Q05RJGwnAQSIox16OPxg4rwEJvF2s6GTglPbWbZ3cb95CWxmQxkKAG7FI bfCBaRCCpjkhtJ4lWvj0iKpUMJudSQ+LQX7bdS8B0iIVrPeNze6Vu7WwxKGSJfBs2+0UfTRm083m m89WG7lh/fwMWJSYDz5hl1eI71OqY/H2hCfBGPodC6RX40ka2cq13+3wtPDikB2LQalwdB9qLx0A 1K5F8lIWGZ+gZiZnRGkMTg9VUHp5lg3UzChcPWnRLC0zgMkBecEy4eFJ5eTpghiKLuxiHDgO0CsI F1G8OKTUguCTFUoQ7bpc00fkiUnAUCAgh3WRvB0bWXG5PmBkpY0P80Ekbg8YohjmD3uaB2zuC6Dq ar2hUz6y7czb+m6bh20I8ZuA2WR+YIjiIkWfGUcj++NpgLxOqGIo1YUR4RAdLbCfLtN0nMfUC+QR KYgqfjkqqB4SvVX7nqMh3v78A0MBwfKUcc8JD0Res/Xt7f1qAfcDGPX9cre4W9ZWxlsCGKD/DlDV UAGCczUuym6bOuH7rU+AqcfVBAc5IfysGKfo12CYBuFrGmJwW1pyz0L4QMI3tMDCL3I66Eq4cpp8 J0D14tClUlaDAF7fqkEPnt2/V6sBv/epOdWQHgqaB6CBrglCARYnQhBdQOB+fUPktIeOIONT08No sQLu2kO5dMslv/WJTlQ5auMACFBa64D1TIPshZahcA2roLZNCXXjaIFlL9Dm3rl7GWjZC03SkOOM QcsH7p8TIe1jcLXYXf82kbwKRp6SVQ9pgPaBjDJXPtA1i9rdAGm/WyIZ4NZWjQegfTxhxhO94xBX 0HQJmIrS2uV+5pyo0iMIY5JKxybQ/Pe6prgDBvao908wljjl3VR+3NIQ/niYsMlxSKki+ABBjAsk itgcYhpBjBUtpePfyGPdidkRfc/RAi8Ja496UNVeE7U96qPJRE8UnfRAz2nHaLldwyHtzF+dcOZ/ NW/PEUNTT7j32MdbrP5uHoDsQATz6sMrt56oOsWhSYaduhywOlgoRBplhe4igB02NFgopsElYfPJ Yk35WUc7QWoUwe+hkAvz0DNxL4CnB+RD9oBUIHkyyvwkgleRCUbUydcpIH3DDfYg3vmaDjO6xWhe UXXplbkD7mCL9oH290ryHJfglF0F+ZLkPaI49zRIXtNSgC3gmvSjIIWXu2CMSRSdiYvg5ZP4iOP8 0aMqcCTQnN57QjRXmfTAy1nCrnHiK2Ne/WyFvVjNlvd07AuVkdWO0HyXZ++teVCSRz3dnvbLAZVE kZjAXAn1fsmA62IazK3QEIEkOBsmUQm+19DCyz5HWRNxMrm9vrmLxPs+BdeCAaS5vEtFJaHAGyoq gRXoK5HkMO+9ffA8YtNuPDxh62FoRUgfvJLgXft1bCcKjkfC7nuo7Fx4IVGiPVmDxj90+tW2+kHG dlsjIbdpe40uNOZ6M13dL6e2Mceqruc1esnysmU3hvACWTDMIOfhDQVGUFNSnKugpaCfI1r4paAy 876JywIQVQxk/LCleUDGanPxxGrP6G0VjHuc2Mm7x6Eoe5gF/RnRaU4aqWAcQ+q4Qug6esxw/I1o YF7fAc8N67/8dn5ul8ACZYqpuUNFfEVbtE5ZsEZ9QG2xQskE3Ut1MA78kKXpYBzNMMpmv1uedbTw 6m8jsQEw96PBOFtCH4wHqFhoY9QzNshji+LgK+qB7E9TgDZt6kSvqE7U+Z0IRGwKAt+y2tuo8DSy R+68RQ5aQv2YtD1ytPACUTsVSc/cT2iPBlDd/Vpw8ni8B2R/s97uXrVXIMHqVV1wrGG+HEZn1O0F R2wBNsHW7diCTTwNglW0DEdxcSpMheBIxTxNp8IBFD0HvLAiiBvisJ7JirDlU2g3lPag2f3bROz0 VoYMPwe53CrC7IE/5NR5KaNRDmmv7Rna+fuOJidpe0aD6PgAsIQjL2wOemN3JG7ShX0KLqVMnMxZ 4q0+3GRWoeVMXqS6A7Gnkbr6rsRES1DR1PZK0QKrsMJNHuBbo00Wdf6ULvlDoTItGGqQcSh+2hNV qIRBMG54eUdFenGTJqvg4tHCEm6fcZNME9zkKINVAviIanCMOVE0LbWnKV0vNEPhJof46HT+Jbm3 0nnpuEXC6/BPYQS5axZzSnXcYhp03nXh0tyTZ4WjgbmHxvKu49agFgbgXq/wpONWLx+PRwm6kNYf QKSM0nfdYiYjVfPNQZmG4IhpwmR51tHCB0fSHLR35t5vtXIH8RbPM9q9IqioQzCYcMAOpcpHZajw or/wiLmH+B+19UmKlh5MQ/zPNOGoe9S07UBI/LSdwMDxDYkA9kxqqJ0htTdIzYf3DTqArvVqu/i8 WFK/TwR6n9dosUJnZhYrQAJuG+Ce2jueq6DU1+AyGF6cBrHQPX+qn2lUg3On/4mWJCjQwbC4Z2FY mPYMIzIU9chJf5QgujPv1WVPDH6gMu05u8EvU+WIkEvItwHH9UFdT06ATXutDSru9dWCgM9AAEIB VvWD7BJPPwMuQDthInVxnrhLJUENliqvGQL4DPfGZJ4GqQsNv4xbeM0MYM6GFFjmGY5mo2UqIQH6 Ju053rJfnthaiqcA6GDvnA6WusF13PN0eb1Gce/mlirebgPSxG9RH7UNp+eL7eze3qW0db3wpnOF DgQkByB+/HEWAeCaEfqh5UBrMA2xj9C8DNSjlhTerVgrOHgMxwtBnIkqzAWzhdz+GQduvUVQedDl WXGoHs36EHJvHMhZtJSkTQIMp6MPjiVPjuthE0f+/sH9C36sIAbw/7IGnCAQsjxTEC3TDKwEei/Y Yv45fuqElEejBOErpPKzVSu1DjrI0WLcPIPkwZ5jBLTlkAhCpKa9UY6qi+L1HedsNwKm5vewB+jy Sk0wUSalhmjXtEuAk00//PzDh+a6NHhsdN5iLeXCZoZbNuKqaYLGFsLTEBQxDS35bDM+GG6PUMiE FthMWzUcgNOLGvZ/kok+0V/uK6W+cUZXDHrQ9Nr+Ih6qSQBTe9B4eW9vuCOPSs7THh4CgsoXUUZc EM0Q1KL3lW1NCkdZlQCmMA0xv6bFdKUZ4iS/QUPfI1p444w+SIBOItmHGeqZt7fM4QEK2ZMvhDiJ 3FE8cNfIlRhRxwbgpFez2igonqO3EIHmvHtO3ppO11rja0uU7nmUAc5AjJG/WfCcByMwDaIXGmDb BUwkRC/PNrQTiB6vaNqg9U5dRC+fWK0DFEnIDOA6ho7d82/Ti5/e+5IySa/9VckRxtER/UXn2J9P 6HHF1oG8SfymT3FwkgbtZlEgpF1ZD5JkGmSvaXGGVtGSHtlniRZe9go42Td3LwOVmzwzEBiqMyqM jCiCCgR4FN8/JXSAycNXAdIbq2soAgZlVid74PN+JFon+2iyPrxrCrCNoVxT1jO2Q6k6AP2Hkzy1 oNjH0K0RaW7xcx4sQN0WLA2KyjSqCqbINcQ/jVBZ9bTAwYICEGDyB43FCfzTAJa8Xw1O7p96oP1+ SRjO1QGV8pkkbdVusYW7q68Xte2LtmMFlWZo1B63SJC+w0D5xmdMg9w1LUa+on0THgUpvHniVmgl cvqOZfYrTyfyPLFQnqkHSu/fq8WvFpJNcIIkJtoz9Rwt2OLaKdwUhnQAgFkLGZrugI+YzZrG+f5i YrVr6+NRCkq4bodO+XGE23sUdi7zNKrbOTwdZQloO6HrdjZzIFp4ySvsXNYzdS8CLXqhBVeCHuy4 f9texTb8JljWg5jHgkbigQM7aG2J7kb28DUd67VVOlutBVDmdrrC1Z9sBRxTIHou3tGZ+eaaGj5Y 7UkQvD9rTaRogrNeas/M08ILXp217pu5Z/tpIxKtfSx7FZFcnpWoEUkrNJycSN7o05yqdBw6LBmA j4tBkhVwgnhNFW7Qecn5YsUdPmsplZvT8EMVbjCQAf8g7PgS5LxffiSqnt57ynwF4+jMmto102Vt dIYPToFO9K/vqKZPqavtgUZH/Zc49M8XBIlpYK+QAueQ42Yg7RWYprwC0SIU23W64mnhjYNal31T Z+MgC0F9Cq4Eg7h6eRtSgPBeAdfSdyR/eeavokTnO8R780XjHha7y9dvTD2+HsNlXE/trTquB8fu 253dPmiUVBwD+rXjKGXrDpXU08g1uKte6Xx5ji6qyjWMFC1wDuCvdS0x+YEMYFgLToNt5WtdaWwd wWDxuaN2TUzWnL97gwa2C9rsWfwf1qlrAuEjNKCf+EZW5jxt5uAgUwpAL9NoM4dpLA3/LNVWvIQg jdCb2jkD+gVU5dkvK0+WwmmdEUbTdUYe1uaagzXoVURMsr8JCD2XzAM767wH59zlj3BqL5gMteWl ipsYUWfpYC9hDn9wTSHj3R0FlM5bSPP0fyLFxdaDPaGwAvKaOcYFypQaoScoXCF/9IVMpqniJh0G zQESVQnkSNEC2wxVW+qbuheGziNYXQPUbKiQlA8AjE8uepVCYhwd0XN6gNNV9TUAl74XDV1oTFpQ r0y9m40B9zWfQdrez26U7H0OmVIz9DijmhHjPJhG0YLDfhAtilNbM3LPQvZMCyx7hf3om3uf7IUm szwuZBzaVLJaMIA8PtGyFyBl3oM6Z9HjiB0O0zqBb2frO3uVC0WKqrgqoQH1Po9wiwdEHcWAylJH Rk+DqIUGx9OKCwAFIcJLhby3i5wWaNyPlka00HpmKQJ95JPI25dsj6wgOcGrjW3crwhgC/os2iF1 ogG/MwQXn4KtE9xLKByE8fQbgIqrnjZCvdUyUT34bK4OleRJY4sBzDrbSA0MCBXlqhODGIPjn8ov L8+qVvatG5HrNLzJyA26kn9sTis0UW6Y9VwwtlZG5lXsO2fACrfxxNBiSDqq2xCG0THqfhjaqZ0m 7FVbEsIPCQVbWG3exE4T7DeipTXAxrhgLaILyB0FJeWGMiIKGuK3Ticq2jNsyBA/0yxFj1SkO1D6 YX6S3r8koVdWIsMUkUi5l3ashMJpJ2hrFAG/wXyC6U2p8STd5cys8yTNu9aTjp+BeWctxQCycs+3 hbIR4tuKHmBtF5z9oa9/Ky6439jjhWzORuLncGgIjchtCuwvhUg9DX5OaDDh1GJNV0eThha+AKIu iuibd//K9xiUZ56n6d00l8ur0OSnG1emKbMU2UCES5wnORSTWSoZgqfpDMGxDyz1z0LPmc1Q4JB5 rMoQfluWqnb6fSy1AF1ksVTGW6631CrFbfCZaUPFN6bo6SW/UPEb98tXQigS9O+ny7+ZBh0WGjPc PwsBMu0ZVqQVIe8dTrNWpAeg7BVa50l9tJdGb706rr1bD3IbaLz5GgKhbjXbu3q2uMI9eeD+lnZe 5tPdevONsmbel5GbDwQMllKn/QydkSjuc81qmAb117QsA1xVNtsNfY9o4a1MiXO3TbMaXMDe8Uye /+H32gvG40oM4d8m9kQVkUJ5Ex1xMghX4rrvnc5Z7+ydN4Z+IOIkhMU7F4W2xhlqfHZ5DEBT+5eH DOWJKc1QrKRqSeh01Yk9PSYOkHUAp1bcsomO7/8ONgu9fF4BOkegqj9fvDd30406VcC1JNp0niTI P1QtiWnKU9jNaeojLmCEkaIFNlLaU/RM3WuqDrtZBIFqScUANlMrAb83pM9XtSSMoyN6ILPIN802 979KAZEbrB3ASyrD7YtJCfXxjnDvIYSPbvr2ZjamQfhCgzeKcPQEwvfFpASduh0tsPBV7/y+yfcJ X2gyyzDJJ7rmHzTLewF3qBqyBNx4eUf2Dw3k5K15T81qDu0zvrG/87AFYQoH3QnaVVcT1AeR4Xj4 AdNo38m1fycaYMqt+pKiBRa9giT0zV3E/MgnmfAT7XErctrvOBmjgUYakYfo0woLDcHtl7Z+jy1h hCQQD5rz14uv2HX66K9HPf9Qb+iEEbpt2dsScYYcSBFu4c5CUO3fmUZRI8CtFWyCEkLrWRJW+DjF TroHsuvloC1iH61rJQOYaRU1ou1XZ5lSrGDbLM9uFvVX2myhAx7tldEAeuiox3zNY5SgMcElkSnd jKCKhUyjoNGdKkhKlEabK5U9uNORwotCnR/om7XnfviYsRxAg/bL/yTLUIVFGFFH6m77l1qu0vVE JHbs1iNAYvEK0h97Y+gnitoOlXmays+IaTCCvhpENMi61cdQ0Z5hBIfiPlWuGmK5x2XBeKg4/SlO aN/Y6SNjjACQIago/YRKxihQeV3ztn9fXN9j96R6a/68sGHPu3oL8VoM3vmf0EanSQ4U8SO12TYf oQV64zlQXMBYwf1xMm+6H1zrPYU8OG4wQ9pClrlikFRrMLEL/2eAJ62QOaPFF+UFHiBhWxGv1qbD xx//6wPWjG8DJov4uMHua5U+82UHy7CN1mCJW9PWWBrx2TvG6LKbL/cQbasZ0nHjeZR5vE/fGk/i mGebYsKPLJfrhy3KQTPcV3W3RtN2W3IAvAu372DgTVdNc7VZ36I0sUUH1XoTnHO8vd0aKXFuN/28 RL/WJihEejAD8KzxdM34m3FucTmbXSVwiw9AJ9k0Ivgoefu1M0ovRDHFYUQ44a2E1itTMORTvHeO xZ7t9Eth2lyxiwZ4tgk/fAW23We4JOaN3YOnFsmh2TPhInprrCREacQqF0NA8X3jePwapyARU/IR BHfj0Hq1/BZ8mFyO6gyzwTvaOBe3EdsRfbSDvADEjbj9at+ivFLl0eMk/pgRmXCJpjW8rLVo7T2F PQxrykiIzJFK0RKY7ho1Cc5DLiG0Bkmi9iJEYvC5SRS+Tpf31AXE8XN+D0TheqWSBQOzTCtcVXGC 8LKKOMXtDPMzzrGstrhjDJcV2FCKuOlWC4aONtEuk6EyBLLN5e25s9euj2FgllYRx/mdsVrTi+WO QrCzcp+sAaBlIwYn4N5wgoaKEd2gltKwOok6VajVe+29O/EE/SBeEqJpZyqY7F62IKlBY+9GdC2/ SrGSDOw4HXrEiWJDxVcqOnJpKwR6j+8oK2P3w0vBWTqSH2lZE7SENhxVxKebOgO9QHZo6qsrOHTo O/L3OZz7Nc5yWTeJQVkwqQft4WTy1WJmb/QJruR8DKczxn3Linsk9hnGe5CBJNtz7gAGLHeWth1b YoMGDeZb2tYbxYXmWNwfUxZ77oBiNYqBGgfQ0kIdmjSwg7/8P6IiDdAKZW5kc3RyZWFtCmVuZG9i agoxMTcgMCBvYmoKOTIwMgplbmRvYmoKMTE1IDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQg MTExIDAgUiAvUmVzb3VyY2VzIDExOCAwIFIgL0NvbnRlbnRzIDExNiAwIFIgL01lZGlhQm94Clsw IDAgNTk1IDg0Ml0gPj4KZW5kb2JqCjExOCAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQg XSAvQ29sb3JTcGFjZSA8PCAvQ3MyIDkgMCBSIC9DczEgNyAwIFIgPj4gL0ZvbnQgPDwKL1RUMS4w IDggMCBSIC9UVDIuMCAxMCAwIFIgL1RUMy4wIDExIDAgUiA+PiA+PgplbmRvYmoKMTIwIDAgb2Jq Cjw8IC9MZW5ndGggMTIxIDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAHFXE13 20ay3eNX9PEm0hkLRqPx6VUcOTPJvMmLYmneLMazgEjIQkwCNEDG9jn+8XOr0V8gIIpUYD/nxKJL ILur+1bVrepqfmC/sQ+MZywLAhbHOQsj1pbsX6xmLy47zhYdC+R/3YKeky8v+h+LNfvhhgV+EASC 3Sy8tP9lymKe+mkQc3aR4YNv1uzFzQ33A7z75o79m53x8EX4ggsWvgwFuzqH/OyXc/YfdvN39uMN zcebGMd8Oj7ygc/9eI7ZxOxsec4uAj9iZ9W5hxf4+Dv6jbA/mX7CPNpKScjOCv1Cv2d7QW+OPHwa fSw+rdQvtvqZ/pHByOrZtXyz856Lc0/OrZEfgjn9oZ5Y6U814+hPDfSj5oUvJZjT9pP+3fYJOtEK GZ3UUj1NJ1ohdqZ08k7RiWsFlE7M1encs6hQOI34k2CKnSOcejcLZpAUh7mfpqlgF1E0AdMrggK2 +11JS4sXYf8j7X8wgAtC0hk/7kbP2JlP2o2ZBeE5iryxmdwrYGy3G4whF/ilfvFi9GJrANVI1ANZ BlEdfRKwbZbY2Xa1/2bbzTNmM41pvKOPgX2Zwc1vtB0s5LQwkrErM9Id4b43Qbsyak+TGHuasVS4 vick38Plf/A9WKU0z/2MRzFbe3Ga2n+uGP2T56EfhmnCVvSs8697dkeOyY8DnidBhtfSlZEgyCDp vZb9p3x3HkR+nnuOi4PzwixE/zR+ZkxkPMkVboR2b2eMsdRn7Oct2+7aumPNDq/uiy27DlnVsWLV Naz5o2xXTbEsl8/Zpmzvi03HlruSbRv8fiUfP/duflfeUM79samyx6aaaYgNporZsm1b3N1VC1Zh ok3zXs6O3TUtu+ZQBNNuy16VombdbrEou+5ut2JF3X0s29nniVXvTWE0z0VTb4uqrup3GNusIWa3 adotzbSqF1jDe6xyL2NNvfrMis1mVZUddJt7riF/cE2vw+eYScneyMndfN4gZugNdeKpRR0JYeMa k0eCMAywSoKnwCImo7AYWixiKey43KNBjgb/IUSFIvJDkZAN2EWw426arqtuV+XbcwYY2T9fnMmI 2BdhJliaxH4ai4StWQh/zDkXnpGtjEw+F8ZhSvbtvlfJyMo/HGUpjxk1ZjFeSMa+9GrIH1/Ysm02 L9ry93KxBdg+7Mpu2/kWXyHWIkixL2mc+WEUcGjHU7jwHB7DyKCJlYEyiTyEdvq9XhobmfJhT9g+ x2MJ+LQoykLatFBbmd00BynAydzuUnC45yiP+8FHXvPZa6xgVRfbqqkvfmq67TNnNY/b10N4lUCN tc4Dz5LBc9zAUot3Zb1lXUme4kF3zW4/S7P+o1jBXVe13fGZ5pg+6FHelMvdQi7PVdkuMFdMGLH6 aziVMPEjEcutSiecCpbL9SuKrM/jVzLkCRHYGCBqlsJC9PWvP1+y26IrV1Vdsq5Z7WhB7CJwWFuK KadwEEmeZ+RToshPI555RgYLUzL5HM+znHyK81YleoLRKd/iGF0Uh36SIqmSGo0di538vtF5fx5S UQKXk8K3ustp0S9RPJjAKQ7mkB+NQNUiaXRTAHLRA34XIC6dih5nhWMR+EmGbNNV0mLGiTkINyCQ GR/gI4OTDWN4ao0Z4EPJJGYUGAbvdQBy3CYdWiu5TMBgz3rsxBFvhjGnYCvEVTDEd01bbe/XYEFL Jk2iu292qyWrmz4YVUjg73Yt+AeC7xfro3RkYWmY+TxLItiHAIMQcRJa2cqVpbS08SAqhUZ2fMx9 zDcjNCnWd0D/blMuKhBVGSQc1+eoBSSkCG0ItpHw8X8CtXoZmbgr46kba+VjvWho9chZNCV7mKEp 7RxMItL5mcjJ6qGa3Vr4SpRAzv58qMWQni6+7GcmQLOfRAFZvR3cWv2mbW6LWxDjZXV3V7YU9RDw aoprFirHwfrRbeWTIZeYVB9B79pmjTTjO83YnV2l5T7BLxyysDACqpCt0YLwKUOj+G/84LzxLPOz CN5FjjyCuEqhTBDnCYJFRrSRA74x2BKQnCU+RzC0MiBZybwUrCqJM5n02vca2RDLp7BjB8uCHGMs xEOrZxaONmxAG2eIYAI2G8WRxPIEmHrStqyQT2+Jt5Ug42uVI6q0djC9uRBFPlugWjHhswncyOPt sE8LcLJctW/Z2PYAWOgHH6HpzY+/CdQY6iW5yBI1H80NE5CqTETw8QG2EosJVPEcDClFUaUXeQCV K0KZhcNlDt6pZLOAyklcJ9fRTv4rgCrkAbyzBLTQccf6x2vBio7dIh+hnyiKLIr6ObvdbfvXq8Vu RctLTnM7mOYTaMzkLsdxhP0CI5AYG22zhDmhzA4OiD0B2Y6NJ2HkCyrjT8Pa4VACbCsN4Jk0cEAh UAxIKHhqeIFBuCKFm8E7HSwdF2oO+XdpjdGUY99jUH1dolpV28821Bn6kORgRSKU5iG4H4UIoUYG +7AyxFcquji5OmxJy55gHxMEwuZgItJB1OFGdu/37WOGKohT3cHgyslZAzEuVk3CoyruCTxpEvRy D5OxNRLQ8WdRbIoFto0Vi7YnwVQmbUtkgWUL7w9D7cB/wZDrd2C93Y4qmhW4jd1nMpETCMUhbhMH qR9mnCopwszZ2Z19/3/KuIeAHosMaVUizRTsfT/6FMslayTrNzkC6s9gds3GLoNObgBtMGOeU2lK 5ALlPB5bGUzYlXGOSp2TGNF7lezpcO9xQCcyjieSOEg16Jw17XFwCPencPVJDBKD0o431UZncQ+S vFyhULTCuYoOrSeC6tDm8gj7EXJJdaYWoLkbeH5PHpWe6PknHI2t5Aqjs112x/ObqmuCNJoHILWg ESIHcHBqbGTkJ3uZl2S0nigDkExVex0ZAec4v3Fo1SRekGjt2wLgMsyep2tHqvjXZ9GqnsQWu5bS IqRIk9lzksZ+nOPo2smejczJnkkW5CjLu3HCyo7X/5ArIv2jQIPVbtxI/2V5h6IZ0RZ4yv1CgkMW dTj0kiTzgzSTRTQiiUmMcKhlUMnKUh8HcFRE0+/Fc0YGNeW5w+mu1/EKIgXFiHNivpPKDgxykIPM ADHUlXxU0oiPYfCJcFis1hctzvnKpT5Lk7DCOq9LpHjW957oLQ7tewIry4Pwwe2nXMiuyolu4pDB JWmGgXFS4a6GxR1gVuxWoM66SuW7NiRQZQ0SHLAYIK0ZqjR+yOPIylauzABJvxfANLIZbSjU3MPq MrKhnx3C72Ad3CfB/NcshyYxUhtMUclWRgb1EHQSHF8P7MTISJUT8aG2ybETHmMGIVoksDmoOY+c okUEhhrYyQy5Ok+Qt4RYCDm4ylts+GxL2ImdwHGuvzcBRHY0b4yyYRpIjA2yZwrI1nBOgMaEQaj2 Ti00T47MA5S3OboW5ATGGdp+gXsu/udQBKu4xStO0NA9sKuXYMDLqlvscAor6R9bF+9xXCUT2jVY TLFt2mFwy0As6TwXhR4fnVs5wBym8DAc1UsjA3CtLPTjmFONQL3VS3DSoUQzmmV8hFmCblfrzapc I2jD8x75Z6owDvP0QbKp7mYK40bmhnY8FwjZbKL9gEfPKdmM+idHhPaLIzUePjapPxIMmLDMCfTB QKJlrv4CLhhlVceXeYmVzai/aVuxMIcaXxiKXfTjiiiaMXG9FyxBlQLopFQ+izDTHC+1DKWugSzg gZvKy+eUbB6fLEI/Q1AgZ5F9c59skwoMPvLJthHpK1XebRljUnd58m72b9bKe4qUNkI9VK76yEUX t7IKRJXaRbNe72pZMzUzwXFw5GcJcmyNGnKIWEsqowLpCl1wiErmombw3jmRhINxP0vhdP8/kOQc ZE8hSUb375w84mlcZjLcOuWWSRRpFGvCi4LUiYT3ENOOs9gPc/CMaST1rWZUMN5+LMuanJOFkeDc 5ylSQAMZBBZ8HsgDSKKFkZa5MBq814HRccTpEIWXSUOuidOeY8WpBjlW+Ve321BvHXXcva6KdbkF saibJbLIZYO/3PNmeRKD7LIh/U3vonXIeIWGjHAQWLXMDSyQRTlaci1J9hIrmy+wxKZ3b09/0nxP f1l3GZQIwDL+gf5NHLagT3ItD6RZ+WmBChGahSf159j0LKKaiSUWWubqz9F3mgmqmUBr2UPmJVY2 o/5THWBKca2/xbGeC0tQ+cxxOjkIrEo2CKyQRSnIo9VDvlfJ5g6siPDfOtmxgRWDjwIrunpVj5Zd xBk9YsgzHDdExCkmVR8mIDP2fdq+Bqu1NSByCLZ41leclocZuXaW5LN1f4YDMhElvqD+SSODsbgy BajBe0kGMM5oLKY/3+oKL/GXC/lH/lCve8kJf/9lylkGaNuKUVFznYWWOc4iRpdVjjqstTHPimbU fqITT3rJg3/doMekZLjdofNv7UM8CqiRkC2xqKyFaKZiWoRKsRXBEwrsvNUOjxmZVO9PV/wpEqJE Dd/h4Y6S3dxXm02Jc/RP7BLo/fFTQdmlw220Krh4gJ0KUG9BKRzdtUGCyKVldKRuZAlV68BGXWWs 7Pi9eiyswymMHOGlT3384m9XV+w6KRCzEMbvCrTKG96kegaol3IcuuMYtfsUx7vQEWdCeYQGBCOD jlZG7BSHU1ZHj46ylex4HQ+RMblhU0dujP375ofXL9m/ZCfcglST2v7yy48XP11fOyyfSiIf0T+H k0M8VOAcsdk0q+bd1JFwDC8vYuRuYP+6UdDIoKeRoRqbRTiGcHW3shl1nzijgRku7psK9zLY2zNc 0LinvgXScGx7LKZkVKAJnVpA0HiPErJnZNhMJZPPCbTPWX0cEanztGDmlipz0GoRUA0tmTruspP/ CqVKp/0Eg4+i9xoN6Hb84wj3Y5XKxBxS2ZKocqCr6n051Y+HS0N0DafEVhKauTXOE1f/kEU5RyuY 4ihRpgscdilOTKsOeasI50doQaUjHbs01gMTfunq1Os3r57T+P1xZxhy5GIJi0M6TxRUpwtxJMXh Y6wMmLUy+J8QLR2EY/3WXqQIwtNW0sGxaXWeXD27dPsonuFgysmL7RJadF2HcPs3+mqDBc8peMYp wQOVdzQBjexG4Rmg/Vi0S3R1XoemtRN9+4v3lB/SydQCN7LQd1rJrlObW/b9kLPf/ED7/UNTfbVc VnSHAIf6n/sbW31LIS6DIDZQm1fB6vKjvlBG5kjzl9UO1uBOo2Y3My2qeHBRn8kxn0lj6C8Gngjd Q8bIYU+4HglbxCWkEYGQjeYOkiXtOvky5SEn5BwdYQKjzapqdPnIBk+4RHW3DzSmx5ICTQ/1Hlhm rjOcahHjSM0phLUuhXU0ITXbLdgh5tVfAzODPzFGTlqcE7AwmfEOSUJjRp61kGpTPrsM1k8/k5ZS LZ71F6i6t+f+f8w8bEqHm19+iCY5ctj4dgCRoRhtZHDOSsbAofw0QdMBuIhOBx3Z8UTqENrllk6U 4i998piSKF9dXlqijCYqMEW6sAuZ7K6dZspRhlvWEc7kiSmnfkbE0ciIKWsZTtFwJ8ntmPAiKzte yUMmRUritvQ4oE8x5b99evHmkzTzdfH5tmTXue9uo853vAiXNXFWL+mj7ks3MmhoZdhG9JM59DHC 6XAvkvrNkrpl8t7+MHW79AU28RfkbmiYcm8VvqHzZ9b3aViEatVYFKOlLcs5XR5JEj/OcmyekhEa jQz2AIAOUrnIylxufJr3cTgFKA76tIka9RrSF2jA5L7J7RHnlqgd3Lo9d0XpnubLa87glBvcx6N4 +dxGxBPD0yEsOx3RmNMY0mPXe1w4fsxJZED6qIeid/wWQQ6xm6sD3GlExBRG4VA6+/FGhLQRBWpw lC30m2GKL3ozToPkZChy2qHs5GxA2CMLc2YMYPARVVhgFhMbs78gFon6XjmLcBEIXXnyrnnOUUHF JQAjg69yZTyFAZL/UnfS6Tklm9FBP1haa0vZUGZhZh0VeilxUYjqMSmSedlOheu6UoakxpGhZy6B V3GdMPXl9zLXUc2QizgtMdnUnc89E52tZxxf1DH2B3/+bsQ08oE/dY8Mw448Q1+AQkaBoyBZMWS4 l/mRDs8oZdh1KLg5CYMQuPAf4GNwzwDXDmKqMQFfVE6MrQyBx8jofo5AxEMFWL3XA4nQsifsp3K5 TuBxbulPLqyFo+P15upuEliIIMY3tIjMLq+NPNLr1fhWGpVyPbGrdHJn5ZjmfpnjzHpnv+9avk5F hNuKWD5xTXGLLxFhv/7jDVLSGl+vo0sipmQX0V1AHAwRjgxZ0TKXwEDGQ6qrD94K0axnJrm5WjVY zp6FGV2mWCaj0hAPQNChCY49wDdTz8gwbSXDc/BmQTqkmVb2BItQhMCxCCczhUYjm3eQsG8RM4Ra tA6gfJUQEbTLaS3i1f9dUcj/XCLsw8dU7VKGfdDft2f9l+HgLts9isHgBMZsZvD10lomLgaplFjf QMRlFJU29ZUVVfQxrQM6dTaZc1+0nrmkkpvTArtwaqL7Zv3yWvhvz+1KadI015KZCrC1iFc7lDnb 7juGsNHii5X6U6a+2Hkchz3Em7FRKPBPBsi/N+h5Yv/TtPeg7jUAU6IQ1rSu+seN/wiHxqnXJIf+ oUU6jdYru9of5kgJ80BWR4YpIbb7qmnfvy9WRf2+2O7QteUMe9TVtUe1NN8EZvcWw/5Urrqqfl8x 9tef//cCLcxZYGnpcev76P6atr7ByH+tamgr48QpXyP2mJ586lumcESKS9erl+x3ApVfN92mWH// jmQ+bfG8Fo0bNZOIvt7iPI+9burmj8L5TpjjVvlRvScSDuzvr22xWDlf7TXTYFMEmoEJ4uIyuwS1 vC3R5/0GBjT70mY62xyA6TXK40X3nN2A2Hb4fjscv8xuQeEEo8YK/7Ou6F7N9ZaK8cpq50oecIdr EkkKzV277MH0/a5TrzqJZ81A54kLOb4sZMwrGPsBbllv9uyKm6A42OevA2dcGpjS7xvAOZw60GTs W8BZmJtigxX+qnAW5uhkMKaC821Zfw/XvG136yGKf/svVltLyQplbmRzdHJlYW0KZW5kb2JqCjEy MSAwIG9iago1MjMwCmVuZG9iagoxMTkgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAxMTEg MCBSIC9SZXNvdXJjZXMgMTIyIDAgUiAvQ29udGVudHMgMTIwIDAgUiAvTWVkaWFCb3gKWzAgMCA1 OTUgODQyXSA+PgplbmRvYmoKMTIyIDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9D b2xvclNwYWNlIDw8IC9DczIgOSAwIFIgL0NzMSA3IDAgUiA+PiAvRm9udCA8PAovVFQxLjAgOCAw IFIgL1RUMi4wIDEwIDAgUiAvVFQzLjAgMTEgMCBSID4+ID4+CmVuZG9iagozIDAgb2JqCjw8IC9U eXBlIC9QYWdlcyAvUGFyZW50IDEyMyAwIFIgL0NvdW50IDggL0tpZHMgWyAyIDAgUiAxNiAwIFIg MjAgMCBSIDI0IDAgUgoyOCAwIFIgMzIgMCBSIDM2IDAgUiA0MCAwIFIgXSA+PgplbmRvYmoKNDUg MCBvYmoKPDwgL1R5cGUgL1BhZ2VzIC9QYXJlbnQgMTIzIDAgUiAvQ291bnQgOCAvS2lkcyBbIDQ0 IDAgUiA0OSAwIFIgNTMgMCBSIDU3IDAgUgo2MSAwIFIgNjUgMCBSIDY5IDAgUiA3MyAwIFIgXSA+ PgplbmRvYmoKNzggMCBvYmoKPDwgL1R5cGUgL1BhZ2VzIC9QYXJlbnQgMTIzIDAgUiAvQ291bnQg OCAvS2lkcyBbIDc3IDAgUiA4MiAwIFIgODYgMCBSIDkwIDAgUgo5NCAwIFIgOTggMCBSIDEwMiAw IFIgMTA2IDAgUiBdID4+CmVuZG9iagoxMTEgMCBvYmoKPDwgL1R5cGUgL1BhZ2VzIC9QYXJlbnQg MTIzIDAgUiAvQ291bnQgMyAvS2lkcyBbIDExMCAwIFIgMTE1IDAgUiAxMTkgMCBSIF0KPj4KZW5k b2JqCjEyMyAwIG9iago8PCAvVHlwZSAvUGFnZXMgL01lZGlhQm94IFswIDAgNTk1IDg0Ml0gL0Nv dW50IDI3IC9LaWRzIFsgMyAwIFIgNDUgMCBSIDc4IDAgUgoxMTEgMCBSIF0gPj4KZW5kb2JqCjEy NCAwIG9iago8PCAvVHlwZSAvQ2F0YWxvZyAvUGFnZXMgMTIzIDAgUiA+PgplbmRvYmoKMTAgMCBv YmoKPDwgL1R5cGUgL0ZvbnQgL1N1YnR5cGUgL1RydWVUeXBlIC9CYXNlRm9udCAvSkFNSlRPK0Nv dXJpZXIgL0ZvbnREZXNjcmlwdG9yCjEyNSAwIFIgL0VuY29kaW5nIC9NYWNSb21hbkVuY29kaW5n IC9GaXJzdENoYXIgMzIgL0xhc3RDaGFyIDEyNSAvV2lkdGhzIFsKNjAwIDAgNjAwIDYwMCAwIDYw MCAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMAo2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYw MCA2MDAgNjAwIDYwMCA2MDAKNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwCjYwMCA2MDAgMCA2MDAgNjAwIDYw MCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAKNjAw IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAg NjAwIDYwMCBdID4+CmVuZG9iagoxMjUgMCBvYmoKPDwgL1R5cGUgL0ZvbnREZXNjcmlwdG9yIC9G b250TmFtZSAvSkFNSlRPK0NvdXJpZXIgL0ZsYWdzIDMyIC9Gb250QkJveCBbLTY1NSAtNDA5IDc2 NCAxMDg5XQovSXRhbGljQW5nbGUgMCAvQXNjZW50IDc1NCAvRGVzY2VudCAtMjQ2IC9DYXBIZWln aHQgNTk1IC9TdGVtViAwIC9YSGVpZ2h0CjQ2MiAvTWF4V2lkdGggODIzIC9Gb250RmlsZTIgMTI2 IDAgUiA+PgplbmRvYmoKMTI2IDAgb2JqCjw8IC9MZW5ndGggMTI3IDAgUiAvTGVuZ3RoMSAyOTc2 NCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAHUvXecFdXdP37OzNze+717e6+7t2wv wF1YijRREWmrIMWCWAFFYsBCFBFLREVsRBGFGEWaWTSWuGhMJOojakw0YrKxJJt9eAxRg8vwfZ9z 7yKQPN/X6/fH748v62fmlJm5cz7n089njkuuXLqAGMgqIpIpM+devpDwf4tjhKhC8xbPvbxSN9+E 84F5y5aEKnXdt4QIdy68/ILFlbrxFpzXXXDJ8ur9VjMhM30XLpg7v9JPBnFuuhANlTptwDl24eIl 11TqJjch9JJLLptX7bdMR/vPF8+9pvr75CPUQ5fOXbygcv1iidUvv+yqJZX6JTmcf3f5lQuq11Pc r32IULTOoncRDbmWKIhAzKRMLBjZF9qfYLyU9+OaL/1/l88zdfyTWtT8cY+t+tchVnjjWedHR14d fF4ZUD+HqpJfzzpwj1It42LlvUdePfJLZeB4D+tl/2Z1HhNW0U5iIyItEz2Ow4mM4zB+bCPDUW4l z+PYwluaebmJdKOlkdyLYwNvr+ftJTIfLQXeUsuPORrDWUEzvJYmi9CfIo04Jnk5wX8zznvZlSKN 8qeGaJBEcF+It7GySAP8Wj/1kbPQ4+fXsbJIvWQijjW87OF3uKkLZwU/itRJXuE1O++z8d+3krG4 x0LN5Aius/AeVhapiZf1/KjjRy3VED+uYkeRqsk/iBY1NeZJpCryX3iSAucu1JT8egU/StXrJF4T +VHgGKWkDtcSNgJyDO1GzDo7s2uOggrY/UbUWFkETeJq8h3vP0L+Ra5D/xFeY2WRfEusOH5Dvibr 0fMN7/mGvEwktPyTzEUb6xFxXIW2f5LDeJ6C94jkn53HQGsS2viYeJ/IyyI5RBy467/58wbI34kO dw3wGiuLpJ98Rlxo6+dtfyN/5Vf8jddYWSRfkgCOX5AtOH5OWnH8jPyFqHEPu1PkZZH0kWcYPnFm GPgzP/6JURj5lJcPol8kn/DyH/nxD/z4e2JH+4fkdxwjH/I2VhbJB7znfd7yHtlFOvH093jtAD++ W5kz8i6fATZ/InmH97zNj2+RGrT8lj9lPy+/ydt/Q37N5pr8htdYWSRvkF/hOgXO7O1ZWSSvk9d4 GzuKZB+jdNLLOIS8Sn7Je14lcVY7xmbpl9Xxsx6RU6pIXiS/ILfhqS/yp77IZ/MX5AUyA22sR8SR zeYLeGoCbaxHxJHNJWsRyd7quPeSEmo9HC8/5097jh/38HHtxvxX8LObt+4+9jaewFpEspPs4O+w k/fs5O+wgzzL34H1iOhn7/As2c7fgfWIqLF32F4dE+sReVmko0kKVN/FjuRpPqc/409+ih9/yo/b QB0ieZKXn+DHLfy4mTzG+JQfRfIo41PyEzIBx03kESYPcGb4ZWWRPMzveYg8yCmDHUWykdyPVgU/ imQDv+Ie3rMeErMNPev58+5mUob8mPffRe7kNM2OIrmD8S65nawjaVx9O+dKVhaBCzb3a/nxVn5c Q27B1Qqyhv8CK4vkZt7zI07ZqzlN3ERuRJuCH0VyA++/Hu8iAq+QeGQl+SEZg/6VZBtqrCyS5fz+ a/hzr+Z3LCNL+fsv4zVWFskVvHwpPy4mlxATnrKY1KOHlUX8Onvji4mM+RfJReRCyDIFzozTWFkk F5BmHBeSmZw3FzLpRhbwX51PpvKr5/NZmEfOB8YUZB5/IiuLkDlzoKsVONeixsoiORfvzfiEHUUy q/rcWfwu9hsiqIe90/Tq06dzzJ5DglwensP7pvHfP7t6xdm8jb2LiFln955Jmvh8nclrZ/AnTOHl yZzaJ/H7J/LjBNKCO8bz3tOY3iLjeHkslwljuMwazVtGcSk2svrskeQaXNvJn13GvDLJVeb3j6jW RvAnsB6RDOPHDv6cdn5s48dWfmwBjt24v4Vjsrn6C6xN5GWRNPBn1fOrS/xY5McCvyNPcriyjrdw fYs6w0OWHzP8mjRRoSVVpfEUH3uS80qCXdV5LyQR00Mx/Cqbnxin1Sh/QoQfw/zINTGfDRH4kPi1 AU4VfmBRJL5qm49f7QW+U3ial9dYWSSe6i94eBv7NRFagL2vkx+5doYlYuUagh1FWEFmYFrBjyIo 1whNr8CZ8T8ri6CtCvca+DP0mH/GUewoAvcaPFvBjyKex9pU1etVHAfsXhFXVMaj4BKAlUX8sasp pxvCNSyl7tXraPb/4X/k/61393MTFbJ6L6TFr8h+lLYQreAVxpEVoONdqD9IniL7BC29l7xHR9Cf k7vpGvoKnU/X8Kv34wF2MQ/q0dNXJLXQjzueRtsayOL99M/Sh+QPoN115A/iRrJcHIGe5eRpOlMc CTvvCsnO65txzXuESK1iO7mXaukL9EP6B7qWbKGvU/y6OJ18heetER8U9+At10ge8pVYLwr4pXvx G0/yZ+C5aN8gCvRR+jEdIHuIiy6kT1M9eVLYgN+8mh6BDL+XrKG15C5yFx0BmXm+tAlt10Mesr9D +JUNZB39Dca9DvCKOBHXP43R7qdevMd+soteQeaLano97EWZHhGNoos9C7rwZvzdTTYIN9Ix9C7B D0uKYWAdjkT6Wnq08odKEHgbwG+uI2FpgP0pjGSp4MWb4Bq0rlPaldPo60It/Tl9HZieL7iEdXQx bBpCPHQ+u0vU4rq7hMniSrJOfEfwwCJZhzFcT1dIjwqbhYWo6TGSO+gGYSbuuldoh8xeobRLWuCP /6F1HRupME6xXzFM4ceY7xUfpHeID5IXqZJ4cF5BHhbvVa4Gzq6m24C96xj+yRXA2nxpE970Mvxd AViBZ02HjjsEjXaZqIYG2s/eFm/tAqa0DFN4xhXAVJisUFwBW+sq4R1yFT/eDWwth979BG+DfyuP 4Z02QEMXyiqlQsJEklzIvF2InzZ/e/mM6aFfzQjX5k6phsyq0HYyZbtheejnx45NmS55FTO2K3zb xbh6uxSPfvq/dX5am5swZXro53TU6K7qY0fP6ULjWdPxC/iPNePnRnfV4s2k/WQhAGc6HWclYL+0 X1Cj/iBgI+rvAM5HeTHOqNNHcf4cgOuohDOr7wHsADwFQDt5qwpvVK7n93ahjf3WSMARwMfS/mMy zlMBkwH4Dd43G2d2Lau/CGC/Ow7QCtADwoDxAPa+7NwOuAPA7hsGMAIEwDTARADejY+FjQftxwbQ xn73ZgD7nTkA9iz2bi8AVgPmA7YAvgRcCNhbfVdWngkYCWDvzN6NjZvdz94xjev6cT4TwN73dfym F/hEO7xM5lHDbcM/PbTIaziHQFWsRYCuwCQAFOhRQddooH10uM4APWWCBLJAh9igWRzQSC5oQg80 ixda0w9tGsRzwrD4otC+cVjMSejLNMlAj+dgQdWRPCmQIuz4etgDjbAMmmExtOK32kg76YCNMZyM gA3SSUaSUdDIo2EnjoU1cxpk2wToyElkMjmdTCFngNfOgu10NplGzgFnzIC8Yv8i+LuWttADglIY J6wX28RbxV+LX0tOaZz0lIIo7lRGlL2qDtWTaqP6YY1ZM0azSXNY26S9Vfut7nZ9SL/ZkDHca8wZ 95pmmg6Zh5u3WS62vGldZhNsU2x77dMcSsevnOOcv3aNcf3J/XPPSM8va6SacTV31myp+b13oc/t 2+Af7+8LXB5sCH4WOjf0u/C2iBD5NvpU9EhsV/zSeH/iq+SPUoHUtvQlmZuymexnuUtzN9UagfGF 8r3SQsVmYF5FXGWNRJRUrRAkkn/zozeLxHzgzQNvFmyWsCUetoQXSmTwKtE7+Bf5XpXx26+uVKbZ yAU6XVwsLlXMxOxEyfByMhRwOYx6hai2kudq1Dtj0ZC3xmFVBpwWo0YtEqVekJxCIGY+0P9Rv6vV YnW14ocGO/pKrtYCjSSSYmNDUzstOf1UNNJo+N9aRL3HKQVdzrlOV1ByeuSbPS4x6HTNcTkDqIqL PQl6hd7jdnv08h0Jz8k19r5EeWy79Ibiaoz5LLK2PCPUmEtL0cA4aeoZBqOqKRP4eZ5EaXSYSzhz jPHnIxxkgmqqrkkyCsOa284684zJ48aOKY8Y3tRYymUz6UQoGHC7nJQYDVqItNAoh8lrHSW2eUXr VPOBvgN9Fmtrq8XVimOxm5h7Swc6OvpL7NjbXUKBdbMrgIUCrW+OUgw5kgAGmm2Vc324GShAQ33Y NpzWl5wOu1Il1p9Y5m1Zqqp0RsMMbUPPoB98MPMD+UO1xxpOS8L6T4PhSIBqZ8pfB8NRP61/FB2h lCD8+IPNKq8lmBXF9e8EIpHAkZnfBiLhoPzJo6oaaygtind9INgHB3/jdER8kl5JH/T7fMHBgM8X pvtYm1oryfPpPocz6lHqlfL8kNcXGgz6fH65/fgtwL2CQNqJsnQIXO0CZzaD1y4rl6WwLiuEs52R fNztNb3kfaXzZcdL7ZqX4q/kXxZfatzb/mJXNpLSh90BJdHnrPrhSn1OG1CXhmv1+pS6pQuI7geq +/rNA+YBjnCGbmLuP9x/mDV+/dmAFShutbS2dheo3VlfampsSEQjSvGEsuI4dk+YA6CdYxf4FE8o C/XdEybOnj1xQveXsyeywsTZwjSVSekJuqxH56gNSjcKux5f9cPHN69cueVLFDZv/uGqx6m+6+yz u0afNVW4a9TUs1jhsCgGPJagSv6nKIbcloBa/svSDRuWLr3/fnH80o0bWYHxGBXU4mJhH+exWJlz l0SeU++0fs9SVvBThZP6/iMfCTMZ17hd57ncjGuqbOL2eNycTfAb9EH5MrEo7YM0DZctosb0undn QE9sdyqp0uII4PndfSXGqn2toFVQoVJw2J2uAAVFAj/JhNDYYG3mWBSLoyxdrYWi5xybOTixtOji c2a0nZ8w26QNjrXpR+Rvb7/xn9eO3OlwejrH3U+n9Gyl9XeeN8fD3mHj8XeoL0c0ovd1086AR+MR PTaPK61Ji2lb2qV+hL+RTU/wUh2H+7sZZ1XeCnzTZMXcJusoY5mS0+W0OuyCinME3dhlHdVWLNVM s5vDE/BWM2YM706Y7fLD9jXpTVSzbtU3Pxi502n3dI7dID/ds1V+887zZ9dw/JN36IPiEdhFY8iy 8uTRwzs72hsb6mpziXgw4Hc5zSajWkWJQ4rUtEidO8eO7OwgAcVo1l2rGMYulYppfp1iNLtSsukc NvvooiNtHzYW1Nv3UV8fExIVcchOlal8s9RbqgiPAo1zzAYpx7dKUcG7qUKreVoZYZ7ycY+g8eqZ 3+NSfC9ShU1UrTJKap3KI4pmk/zFCyqVQTdSb1Qojcr1d6tMKsmsLRvwki/IfzVbVBT8rFbrEaj1 Wr2TfRZx5hWCZLJP1JtEtV4c8XulSaUwafIalV777bc6nVqd17AW5e9HiAaN4FBMtJsE4Soa1Fv0 +K+Cy/NhZVws3QyNXS6HTRq9Kujx/cZF3tT/xqx6I+Sy2E3AkFNNXHan2xTCFPdBOzAZyZn68AnV Ag1X2DNs4TTYaBmSlZYKtwrb6aJIbS4q35OKBGrl+6K1hRC9KBOOpIRXcqFQSl4Ty6Hl6lQoUEeX xXK5GGhwsfyiWEsnwr6oLde4rRadZNQSj1Hc72EViHmiVnkcnuMM9yYT4IzphlOmt5iAHpoWTEMH baaH1DXBP5iskiT/XeU2iir1GLNZoK6ITa9RmFVHe01WQaxRWfU6jQKW0EZYivVCHhZPuIw2SZRU 75C3zSa1ikg60Ww+0Mup4zBjdFskMYxirMCDHzwZ3Wd3ueziMFdNwEYXe5wX25xO28VW5gRS+uix r8QsnQbZay9rxAOad/VKL9FjGGDqw/2F+AkCjj66+JwZlyyePv2SzZPnnz9lyvnn470+P3aHJCk2 wAILlM2iwb6QLIR9otUQyay0V94KjHigt6A4roCAkqrKoqudSa8vo1QIl3sS3kBGofCWYmm/2qFX dDbEUz61XcN08/5jn0gEPhPTD5eUZyl79KTH+qL+PXe7rl3VQBsUE3QTVF20SzHLMssw1bbIssgw 3/aA7gHVerpesVW3VbWFblH06HpUe+gexWv0NcUHlg8Mv7P9zvW55XPDF7YvXDGNyiGqTD43hoyR 44X7BqEiYHlAmlnrS5AeghgRLGZWtpgFYeFVq1ZdtWTVqiUvfPzxCy/88Y/SSvnQt/+S/5ta/vUt NX83h86jjbSBzpMflPfj7wFO4xRWrHhEoYZF2lmOhc1AkkI0vBi09Lq1IbfVYSYeTVAKKR1mf0hp 8lFfxHygu/fAYC8zBCo2QZHk+0uDmOrC9/qoIgMcliFNz7V8OxZgrjYYFMFkJETTOofO5tw0o5BK Hd2WShVmbJGKghD1u2OaKaIYDXz3mj8Vw7+UX3wHNIEoMBH/DHzXk9XleTElfEVDz0o7tfvT8V7/ iyTgWaG/VrFC/aPIGukR9QOKjdJG773BhzybTZut25TbVNvU2xTbpJ95Ho/3qHfHn1c9r3ze+4L0 gsKXz9UXEjD2Ygp1JK4KiVpVLhR3iQ0gj5cP9PazYWKgzCbK9w/2ml/r5nq7tcD5dwRtaiYVDa2C mqkaM1VSokoTDQ+RlYPJPaptrH/Z72+mM6+dO+KqqNIQr4sFjLbyL+Zt+UR+6py6FfQNKRkOJ6BE A+5sbedOn6+Bjrln0eqGnNo2Kjc8BsvqtPcf7JWfP6NuWRZCXTSJk4JRxjNkz7FPxG+BnyK5r7yE +B3RnkKCJnL+HoepR698L/eioyTV2mvPjJ1pnGWeF5tnvMh8eexy4wr7isAK83qEIdYX18d+XLde cZfx8brNxc10k/Fxw6bYduNOsqu4g+6q2x57SR12EE9IlbeqLhepOCd9eVpImz0hj+DRBErmw73d vd0HukGsMF+4Ddl/uJdZOhWcFSoKoYIj0EXFtklCHTc2NDdBHVfweLwf0kkUll7/7b4Nf88GLe/N vvqeC2Z6c1PPDDkmz1k2a+qzTl/84C0PvjVP2B7aeu0znywdE0guvOWSGSssClHR2a4VJf2F48+7 5sKYd9jyX9x6EZaCBaxgEHFAoUephdxfnncr3UsFGvL7ahx2VdydM5mzki4eJr15XVHT635RTDla HNOEhcIy4UfCemGLsFvQZFMtpXxEyoUEu140Kf2+kEZ0iEpCGmljLqUMaonflKKpYCG00kRNrWAW aIVuqAXza6VuRkxVG5qzD6eqgQEY2XLHa5yfwETd1KKhVX5pBJVBagI9XD65nFyrgquq1h7Tqlnq qHKZsFdeTU2FSDS5RK71+PwKkW4xWk1KkyQtNFrqoaPsPkFUq7z+qdEy+I7uF7YcnSnXB9Ox8JOh wOhUDh7Vmx6jQKlZ8DqPqqMBp8akTsdqngwmYrGKTnwKck+QBuCvXl0+PZiOkIA4wnu69zyv6HX3 mEAWH1h7pmDomnRv5H3Ne9lFrktsi9QrXD+wrffcadns2WTRRALpKHGoEiZYR8R/mX6lXtDPCdBA lokW0E832I45G0MyD/Tzdbfc281Rx7UXH7B0nFSOm8mshSnUIWVLV4+8vP6ZL2X5jSf/nPHp3pv1 oycevmbmz6wBT7qeHikUSnVyu2h0u/6x66VvZ3XWpCf9ZOUPHp+Za6Nfhf3JZDxdkfPiIJfzMTK3 PDrkjegdmg9NGOEHYo8j0uN90fFeXIrao1OdU4VF6kXSfGG+c4V6hbREWOK8qeYm+03mLVGzUhWI WElIr7KG3b64+XDfYJ+5b2BogBhexe4/yeZPDsmOKJPyhI+JSRmB3nHDwjkrVs6fu9LZdNPkhz9+ /4l9f6fn0uDc4csm5x/eR1eveODHy67d8OMNY8YMPL3nr7SVKuhU+pAvWRaoJiAf4/LirWMDYj/m MYJRlQOuoFOqieix8GXW99a8L+6NXqRbTdbqN+o36h4jW/U7yfP6Hp3W5awRbYaIV69TwA8PqA0B 9RwbtUXZxPVWVQJUfkVX9WISLcxULMRBpULF0aPhIZU7gpF01RpQCUvVRptlrN0linSNLImxaCRM qRZ6QLjH79Xq7G6j2ag2aaVsvjYS02qlmb6AB1ORDIOlyVuQfXJVF+fJXeWrYm7TMxqq+b3Yk3H0 BF7MvFfQ+hXBGr8jeK36Wmmpdqlwk/Mm4w3aG4S19rXmteq10gP+B7Lrg+vTD7jXxx7IP+BZH10f 3xzdHP9p/qeerb4toT2hPdE98R5fj6enLhFz662qcFSpSupV3miSqGp9BWjp3sOQdocHqtKPa+vD 3b/lPkhV2sGTs53gydmGjH9miQ25J3AH6FWrL71s9S2XLLpFe+PCC2688YILbgjPPf+PP9v2pzkL Flzy5927/3QJnX7xTasuvvD6lXRg3g9Xzp9z3XXy8sLd5z/w+q/uXLS+kH5k0eNv/9cTCx9hPCuQ N6q6wY2I0+LyGUQj2k3OyIdYnxU/8PVonD2m9zQvxnVqnaRzeV1Tw7O8s7Tz/fPDi7yLtEv8S8Ir vCu0DEm3Gh9QP2Dc6tqmdXpCRKUPB1XWiJLTc//hwT427/Bk4cZyJQnr4HuLgNsohCtNSLMmq427 tXDLwLvi+KYbQMbvbek9JP9E/n33sKtPr3t4n+LGhXOv+eG8uauE2aO7/v6zPX+T98mD8lb5Al+i LAoaP4JzH/2AEfr9d2OMFZsRkWhmj4XKZs0B0XTA8a74D7dV6dUTN4zzfuYT8vcrMEN0yF2uGuDc LP/emhyyKoX9VbNSTg7ZlwLs7lfEJH6L4bOzHB+yvOPGt8TIAd8/xP1oclQMcKXHEVMFvZ64+cDg gX4m4ysOP0y5z6rWOGyl/2CNs8DKCW9Jv9S4/W8ZLLDMZbXNqNaIIyGDxCze89JLZ0y/5HDYqteI MNE/NxuxdKW06iStTtwzef6800+fx2ziLrJOmiadC5+5XM6p7W674LfbdFqKcJqKuj5WfRTIImoo nGa62Ha8p0aKm5g7XXK1ctcVHixTUJrjmjxJh9Q3108VjyIpfJxLRIPGSHDwL5Jy9ky1JHq9CWMw msgJy+WnHemaQExroldRMVMqpSSg06CL+L1ptgIjkIV0tbRQvBCRVC9Jl93GNx2fqN4kf/Q5HRXX VW2V4h6dj89nxffsH+wv2IYkPpcyJ9e2iNcHwuHA4MpgOBw8oSx4ktFYAootQU9PoBSPx+KMXygi q+ukqcdxpXVrBb+jiisXVX3s+igQI+cRYYxpge54jyleIzEvH7GNk3E1xOMuCh8fhgZ8ruOWonjF 0XhdIhowxX2iV1LPnK6VgLMGdyCaqBOW08nAlT+iM8h3C1KqVERcTF4nuGKBmrSD4+oI/KS/SH8B zRfJhHK6mDVl9Io6fzgW8jvrxD0a50F/bKdmdwnNtlQyk2RuVDIRKpk/6vsIZhoPQYEn+gZhpsn7 wa8s+MTk9QmEByJkDHuSkcsduYr/WAmpNNLLFpw1deEFZ5258NJ4rbdx3w0Xj1lmEEX1iHDydw88 8c62X2VglawZOfWsUaOmnk1/0TTcZfTMunb2VXGn0jWzkDq/eeIvN67YOn5KOJ2IsDkQyMfH7hX3 K6ZjZMPJ0vK4+pJf7CC+pnyiI02J51Op6U95gzba8Wk+rf3Ulh4haaQau8auyLrb3W2ZCe7xmVnu mRldwkxCJZI1+1ozOVXGmR5hPjyIoff2l6CtKkbqR/3m1wZ6zb3mgfeqwbchL5mPueJgHRcXlarT YRkS18khfQaBYrPUIaCprEq18OypP1z32E9qr7HYam5Z8OFff9f70I+dplLIEnWnxyfm3bhro9Kl VJtNsxedNtJSEje7166Xfyv/VX5VfiXhdxZH0VX0AtpNf/iXQflCX8AQrnfU2MwPLL/nZ4LcSSdS ekn3hDNZoEI4JmMx4gPEfASsHKwvlyYIswQhJfZoSU/wz9q+fNgvmnpTzoKoM5oQoQsEQ2F9rqbW DM1dF69V5XJFFtk53N2HuYczBxIuVcQkFqE6PZCtXXguVsdxDgICABP+EJVHCSshOIYAYQC7rqBS mPv7+839KnZS988g3TQMf56zJtP4rqqrzULm0HbtNBk+HhKuttAN9P4P7vjxsGJ2DvU3J830ZktT KtEgH5qYzXd2z5WlaXNHFrKnyf8qZzIdNoEI1nAyHfQnB/MBnIPpRHBgIJhgpWSA0ZOIlRAiXQUc qRH9LyE2dnpa87nqM6+5J9LnIb1WKS3F7Wk7RMCM9EWKi9IXicvF5Yrl6R9lbxWNvojHJgVrSjlr OmHWUlXUqiQGQyLoTEiGnFNDTDX5evMgaOpAPyckHgkDfTFmglLMD5Rk9h8Yq2KpZmnjUME2hANL 1ZqtCLKKNcB9xrv++MLGu3u+eOf2NT9Y8u0bcjkazZ0VDk/KxSL03QN/7Bp1yUUzzyxec+m68y69 7NwVM8+dcd53A9xrXh1MR+OPP3T6skTytktm3VvwIWwJ2Tb52J+lM6VXMFPXlKerc+paYZZlkWWF Za3lXu8DlscKW7w7C8879sa+rf02Z1ji2+UTiE2jFz37gin9l7Ze8Yu6nandRSbKEq6EY4l7iX1t enPtrlqN2akkxYjGacgWiixk0dtfcZshXpi1+xrzm60Ia3dfMaQrnI1M6cIDZFxTCWowP7CimXmc kMDuRVV8VBuLxANSKD3SrpJsd8599v0Pd7Rd0+Y91x7M5stTt537jfwiHfPNyDXS9V5nrOX8rbp8 +FyfacJ58tHf/14+Gg4bR6UDgeZUcwMYykwNdH6IyZjzjw1KS0ETeqy8zSi3aVz6noDYm3GQ3kCf wav2Sll1VmpXt0s/jWxNPq9+XtKaAm6H5LSGidIQq/daG0IGYnKWatnkl/pKh/u/n/P+/hIkrNyx rxAPYEhDAtRS5QPEQioT3i6WCGKCfLgJenVoRODrv3x2NF90PFwbj2c7rOaO2ngy+/DH/6Kps8+Y 8MFW+3nrRPGjvw98KIhsopMBcXUoFY/KL8n/vbpv2uSxEtdfyGDAuIaR28pTUnX5bDgWdJg19a1N bSoSGwh+nh0geXooT/P9fk2P52/mvqKqt+mvZJjV5zBrEdNUS3WhYrLkKzpIkh5K0mQhYGp1NBok dX64ebAXQx3EstAV5oES/uOuLGQmRAd8WZlB9xV9MltQYh4AZt3CI0WF+uqIjw+dBUV5MJB5uVi3 q0TC/5eWvflYPDupXJ5QG0/Uim2RKOP0o/1U6Y9Fvb5YzCsfEeyM82PhIfqPR9PJ/oZUbtId8jON TZna8XsnZAqjo/LoRyfl0q2DsQRwNRtyYTZw1YK40oTGfFMplcj63JbsQOLz0gBpooeaaFN/zNIT +pu7z0h6VSqSjHuiPrfVqJbMOoTPGpPFumjRJ5E6eqiO1jXHTT6Hztxq/qi31MuxBM3CscTFAZcK FVydjKohJEFEMDNqSDYKJ8qFSuz4P6NKODeZScQisi0SS+bDI0ZMzMYi4tJINBrJBI5+StU+GAXe SMwnf7suHIvG49F4SOQiIp2UZcgUhqOa00qJjFxKlE7zy6OBm65jn0p3S69i5fne8oXjC7MKs5yL nIsK1xVWOO8oPFJ4JP9Y6Hnn3oZdTTtDpnAplczGrG4LsbSYaM8INVX/d0uvO/tlqTf2RWCne3e7 s8HZlGhINC2pX9K82a8yacx6tVAbzisUyaIiTUx6c6PBW2jnsmOwj9vKjKq4M8kkyIDcDWLjFAUs QpYUuuONJ0nNLLUwTwoaOVSVHC4uTioUdbKgETd/G/DXxOn2Gk84Y9BbW39/uXxY3kNHHelaM14b 9eWDkUyDS62I3zpj5/v9va3LnxoIhRO+cDjuk//m9jq0kQKdRqFC6cJgsMbVsuCWYrJs054+TT76 0Z/lw9A6FLmSBOsHbC1meXlcpGf0Z/WxkGjpybr7RjWaRNLboaqv7WiSGgqjhmXjUipq0ritklkf qgELSqScaumKmloLDQ1+qSVMTA0OfYO5NBYLSKU32Sq0ua8k41RhPxaMrQDT4AMudLHDAFM5jJ6q /vf3YkeoNFMsmVfZ8nhL9Y6KwsYdYXr1qPZCZuwfTpRI70zJNk2opZ90tRZrp79eG4tnmtzmjlxm 4ltn5BpOK8rhdaF4Ovi9gAqmUyF5M50dgVZGa3hwxZB+ppsYrl4ErozAVYQ0l4Mhc4+LcZvSqHZZ JJMuVKMkkl9sDZvsulZTFPZrCVg4Pl6En/tLhXiVcf5dygwNyCLeOymbnXT0J/lYIjfpT3+aUJdI 1ArnQbDUTvjTOn+KvRnizWCLeDQWSwcHWVIR3m0xdObdeLc8OaNcr7NNzUytm5+ZX7cks6ROlU/E fVavMhfMfY5geY+qz7G7YNZaDJhCYjJYwvGitwAX6nDvYC8nXbbci9AABOdrbCkGplHV5Akff0vu ikIpVs1sLKCBgNn6JVMjgix/NSEXTdYKtflYNDf++l/+7txtU6NOf8wdUUuSUum8YfatP5CsQ2M4 ev1ffpOttcWLfxsTtVm1vpg23Ow9fdYDz2Bc44BzNq5x5LnyGN3Y7Nh0fbwxW+oKd0WmhqdGNKn6 8NhxErGUIkGQbcbd14Q5GaaKlOqbhneOVdURn9QybgTUQ11beJwJUi9/GtMO0HwHervNX3cwkmTU WKpQI6tWTMpOmIpNZCyOLHWlnp0BLCkGwEqAEnrG8Va0qczSoKpf0W9WGfsHlcZ+s6J/RqFIuv9v 0hJEjwWHE+xOxgYUvqttCNNsLZitRCZVdCOj8HZ5G9yUfKhcnpiJRui09gwj8Z/oncVcJEGTkVi+ wyhfd86jP7UOR/+ckN+kWZgc8cOxl4LWU6HvRWooBVq/iN6H54fj0WRYvtX6gvxSIBmNGz3GX5y2 dKn2Qk5XyOqRLgP+U2RKOaPWKYlNjDt6fH1i0tariwcTEZ/TZpDsZvREEqSobPOYEyZ72vxRfy9s DTNzYSpcX1Uor8HMZKLRgsALd+H8lKmM8P+FI8LiJ4EMXODI4Jp8LJadeN1145m9QV8Fi9ROfFKw 07sn5NAgPxdN/gfmoLCdiPQKxtBJNpYvU3SasFjq6MyTeGejvzGOdbDOhnKXH+tgnV3lBeQZ/zPx R8lL/pfiO5AYFY8F/J1UFR4WbtL1DJP6GhJe0dBba48FSCdV+OPuss9vVHfo230mywhDppyIG9s6 mtoNw4YnTMURjcGRiKP2l/oO9/WZPzN/NsDOMDoqPkxFApZes1aYDFko1RhLdmj6hzQs1VWWrZK6 quV5vKOa2MJudAkXfmAs1m0OhdPNZp+rE9a3/HlbpjQ263jNlMtlcsY3rBUK+gK6tNPpNzdnIqHN dUUD7ReujIWi4YR/8Ep/Clo3BZNt9tFXMniUMGJwM6Mcjtjb/YlwNIQoOyXhY4ekNcBpO2z0lkS4 MbwwfFG7lGprCLeHFD51KWLtyfj6zKS3Wd0Wag87RxmSI8PJfEO9YmR7st7Q4LNoOjuQqdTR18vi zDLHSytYsRe2GWNHhqUCWPElzmlILAOfhVhaGlw2c/8MxlhD6KrEbY/rjfoCT3ly0eOG7HG1URFb lE6rH99Ulz3tCOgp3W7zTG2vb03Zz62Le+i3ybFNxcyo/y7EotlWvbdYdHmP9lf1BJO7MGTDgiM7 uFF0RrnySIUGLX6nrk68B/wikPGwR26EPcJifMPKOX2vaO3V7BR3u2O2mCtryRraDQ22Ble7hQUr b9LeJOhNBtLlMCgLbBH18ImLqGYSjVRsBEL5Uir3263SjfLbf/+b/BatG/g7LRz985OvvPLk1pde Ec6UB+Sf0DmQJ3baLW86qqf0T3+i9Fjfn3g4He+Gb/u4HakGN59bHkZ7CJbf3PDA+5yaXlMikojN Us0SF6kWiStUK0R10OM0Sy6bSaMWEiElPqkwRPVJYoqO9tlcYHCY2LAdWYCmquSGvMj3u7ECzBaA WHDCdpKpOGRWMxebizoLffH5hx586EGIL4g2VwRm3/VjpsMupG/9Y/DIP5+RrHJhydKrlgyuCMeY +IpGKhbhC889t1d+i+FbPsLxzfKf7ixfamohOX082Os8FPncYyv1KnO9Nv1u5c6WWH2sOVubLTbU NzS317YXW9Vj7KMcY/xjAtPsZzmm+acFFjgW+hcGljqW+ZcFbtLdRlcHNtL10XsDmxU/VW0lexp6 aMSELzsa8wafpqvRkBILLVhPZOuH4N9KXPlNtpTYO/C1zMQejL840niYd8hmMZqBDOemHjBTke6Q eZhSLvkQv6pOMXMy6RtPv0Nb+j6jzfJ//dPjNSzquHZk7oF48ByTJ3btyJZ3Gids1Tpr59T1bN7X +/jm3l6hREf/garpBfIG+Ru5X35auMjtysez/uCokeMKNd5ZubVU/OMnVJIHP/lERihGAN8SaQf4 V03K5InyOWziZ3ewqV9Yt6xOVdtBUx11IzRZ0MgI8whhRA3pCfflXZreJnNToT7ldVnCksde15FV CyNa8+oUNWsjIyQDqVcYUoYWhBtSAbsn38lULTwMGMbACBYWgakKuTBO50p3oARyQSOWIDizt4LN 86QDxzqWZ6oymvsRqmHsDrd4iKjEKv6qdsmJDkgllQexCdf3KhRWtVgHLUtvfuu2dbeuea+rrZBp k7dHYqm6cFsbLJUo3XL/fQ2jJq37YU3a9ka4BZrzimJeKb7cPmnEaskrX7Jg/oKFg1ce16C3+5KR iD9au/7sqx4PmVI++c1gIhofp5RodEZDxR6749i7Uj3yv0aRV8t3ptvGtq/x/Kj97vb7PevNDxYf hl/yeOSno7a09oza3b7XsytiyaQitXGi1Irtbk+b1Bms/bJB96UVsYzOht74F8Gdnbu7nCMmlmaX FpjnB+Y3zm9dZFvkWhJY0rikdYVrhW2pebV5re2mjpsCNzXaFxVXFNcWRRPxtbk97ZGisjmVdih9 qrRjzPDmMSpfF5gXsdWKbuaJUsjlqzox/UOymM1UxRpkTgyPIOYreWCuITuvgVsm1dwwTtrBSv5a 1Y1hUcZqjhWInI5UxJKZtGhAyKBGr4ved9H1P5l33vq3Xjz6i+ZrJwm+SC4iGVOxRr/RGP7B6cvv u2LJpqe3H3ln3O3R2mix+QtrITUt6xwz8drzTp9jtPs33XX/2/6g31lTfEcbTY7POEpN18ydON1s dz1x+5O/YQHait98BWi8iLzIET4vKcLm9TqsGiVR+txiwddj6KsN9CaStflMKOGPGq0W0eswaDVY K/cWHeOiY/0waMb5TZmx+RJLi4Q904e1s6q8G0IPiynAiym9NpRdpjKqbBxfjYWmRpZbCmHnwppa Y0X7iGFLVXENaXHBEj4kBGujUUErxBLigkSM6oREIhUQtPKnG7nPfPQt7jNvlD8VjRPS8VjQTMfH 4ejJe6whGoumJ1CJicghp7lCg8OwDr4O4y+R68qTuhxdnqmOqZ75jvmeJfYljis9mhpLriQRV28+ 44Wr1xNR9eV312eysWQ0mo34gjXM/WU+QrClJplsyOpbzKas1KAmnYgkHtfbQ2hgZ2brsYgacx9Y iBbKgfkPQ0bK92p4iIL+za/jKGrcg4gS3J79zE3LOtzR6ybecWPj5MbMyI8LsXiuzfjh7/f9TUKu bTzKXLajH122IDOs66mXheZgmvtHoaM7//GPf/yW0YDx2GHpReAA35mV81PNNJU0pxBqshgxYLeq L7Y7HdLlHQL0miUUNqfUPslxmhk5RLrTpDTm/EA3N9e6jw8Jzn1FVHWaiRlSiuDJliHThLeYeCva eYwZ1goPLx/PQK4qPg3iiZVM5GoDT5OI5JF9VMpA/eXb07nCpVgTn7A6X5tpowgmZRr08oZgzNc6 Mi1ICCYzQy0eHdwgXhjlpj0c1jMnxC9GogfGLUC+78O428jacumlCB1bc06NEInQVGvWLWp7SpY+ KeEPNeWNgqcmk6XqNhLRaIEJ43hH0/h8Oxv60MjzHa9xT50J6E470WB8GuiNGqJFycO/G2Dxdfar GdKGUhZ/GTZ6sxoBdnhElQB7N2R41ch1eU8dPvKsmRsEC7daEE/Fz/ynNK5Ard+jefX8h+qy6RY6 yhlJJPS3ixbbWJdb8+HLKqdngh1psfpkMuSiXc3pbO06IGJayGL1Ht0iekPRRCDpj4QH3UG71SNs PzrZY7ZFxM8i4UAikIiG+AimAW9XA2+d5KvyOcrwaZ1jwjM6p4XXWG423W+5z7TNssXUY3nO9PNO Y6qzGDZLkZDFAFLyKPvKpbwY6W1NFbSFphHOETn41mbQVKRQLJU79cPizpw/rm2Ki8NGIm+r9wCi 8O9zpQiz6XgwhLELw3KOFIFH5mJaoJ8t8DW6OG0V8I5D1FYiJbSWeT+7ml3D1jwi/D5GmxVKZPcU UIuwPgXoka95sEOlrOYFqFjaXVnsP25We4c80yF5NbSqOhQPoCcr4mb6SjYejQzGk6WcTfvnfq2j 0JSJDUai6bz8Cp2dg46TDzfEcuX0MTJYO7qAxZKvI6lMHT1TsgrwQhHxiyTkl2gnEsyS8WgiIk+R s2IkFE4yj4TOlR8JJFOhZBhkTN8CtU3EXOE7LnyDcn05qwhfGRZSYcT3g6K5J+3qMyA2EzaX6uyJ yXWTxLH1vsn2SfUm7VhTI5flcDgOf8aEFiwR7nK4ELjjyLdyBNYDXWbu6QPRSOljk2Hii0hm1sPJ m2FQXXVGTrFzq/TdPiTzhgj+eAO1iCMR6emU452Z/Pi75J2WDjixtX9pTxc7w199lwbmTqt5eGI2 22GWn+KBH8g6P50otDKu5+77ZLojlMoEuAzskX/J6XcPFpL6gZM8ubRcGJcf65qZn+a6Nq9oqqMp hH5Mfa4ef9JdjMWQHVHU67WSpxjK26Si1ubKIgj0MtaHzC+/zxZCzEgsxAHq7bUB+bWBinkGvmJm GY5O/LkqWGCrZ90saxomPWZwGOPyqoWvouHmhkZu7xaUjuo3KLAYmim9TktpPBkPG3AUOto7bNaj O+hbesXYeEQw0ljy6G3ZJrdHGC5Z3za49LFwsjZJ7bFIbdZZ9A1u+SsVr0rX4rOUd+LBUsrdFhc7 2fiRd78OefePwvtqK4f0TpOO/I/qK+f/mPrcJrXOaWbqzIblGVDP6TpkXLA0fDAdyAASfhAanmmw guIE+/L7XK0sFcY96Y9F/PI/gplMkBr8kZj/yW9DXn804VPc5UuEEb0++R2GlyPsHVQEb/AV3uT7 t5Ae4a9gs0ks7wNZC8w0Pv4WeAn2HicKSR4lqcbhhNVPBqLhANWHMpmQfNiPhYYnkZXp8yP6e+Qy XyLq9wWBC0HcIP5GcSGyFHJlr9Oh56kUJmSIU89OJCtU6pIViQqVJOjB7t4SBNAQl0MaaypxBz5h 3MATtrGPFUI2jUEhfyn/VanX2EJKJXVpwi5nTDFF3qS2aR0BSUmd6JQCDo1VS+fo9QY2N8cGZL/0 iXw3VjotZSXFx2mChJ8G4pHmTB3hRumT70zy3cuWMU0iS5CUiqVgNWRY8LQKhUlHdRgWQZYVvg9Q mKTj2dtI7WJZH6dk6lMxevRro0EQwhoXloUk+rEU36uwm1Uasd1kFgT5S2jJm499Lt0s7kKMqJHc WD7nWsVaBTJzHfeofqrYrEJuVWqbY7f2+eBei6HG72k0FDVEn/GkxYMHndQ5qDliDn3rP5j4xvxu 5rti1tJm3WsVi9m6xhJ0Ql3QQ5LpKcpU1NbEDO7DiAMxH4ivF+T7+war6wUsFjZkayPWyhYaq8vz ja6KGcnjZK5Tc0+rictca4pdzRfUb9xx2bSVH6rPfGXhPc/946O2ZcMvXTL55aA/8fFT23cVxyKZ 8iFfTEn3Wi0XTu+avnrcW+Mnb1n98NMms+qqS6fm4+1n7nxGbg8gghYJAS9d+KrxRmQw67AK+2Hn 2fBjDPjCy4Cvm53Y88KA72id2I+DfetewMpkHPgzocy+qPdhrg/iq8I4JehRomzCHjAO7G2Sw54y Uewb48NXgOzLdopdFxQASh6HjnscufC7cd6NsxrfHKZxrR/3iAj6+PDVYQxWB3s+288hhW8XMRP4 LtGKrwfTeLMQviWM4YvCItYe+pAtAtOzilXGV3yFe6BPxirXUAfjr+740KInPBWREThx2BF1SSR5 cKLKbUNGKmJsDuHBddt33rr22Wd/1vLkxW9Qvfz31y56sGRzPpdM1HU5bF1YYdoQ8K7dcfvaXTtv u22XcP2Y8fL//GqfPDB+whSvmwXRJBJC0rjdgVHPAe3VgvZyZEV59mrfHab7o4+YHjDeb92ce960 N7orp8WnJZSIFul03Xm6y3TzfUt8K3WP6J7RbfZtD2gDriMxneWglPkm9m5tl7XLOdU61bk1sTW1 N7E3pTbaSTGsmmpPJaextV8WpqguVPUiAwCpqtyPYdH9k5Y0+UJ3lf5YUg2XhEhjRQo5X+a+O4El iETCm/QV1sx48NXn7x61vMkW6owHk/J7T34of0JDv5t4vzhHCgcLE/bG48HiGWf9/Mf3/CIe13sa k8HTH6fOt9+mLvaxI+JRGP9G0FgMNPRB5zTQmAkzaQKNKbC/iBp0ZgKdKfC1vRq0ZsLRh/m3QC3X gfJE/nVrCvSlgk1E0FOHsgG0pgKtuUFrftAaQVZZHpBEdkUekMSTdQANnqoDMEuWZR1k8RYBhPbZ L1jxZPZ0B67L4teSaD8HPWeDzlP4inYaozJ8DTfYi69GQEfHeRpMzSJAVdLjFAZTaRgXovigiyHQ dSI1VVk4etJndHc7LB27LvrFMWr+zQWb2xvPqU8n9we8tcVcIjS4fceaW3c8u3bd047AmRPOooZf vUVtp42lK5EeDZL67v5wDH72K7duf27d2l2wBIDjhcDxTOwE4AM3/aJzMlkIfC4DbOHgJFsxvq24 bg/qbF8Oxq1hHB3AXg9ZBf6lgDvwrIP8eVAr6PsGV70LjHXhzqmALdC3W8G3WzE7W3HHbtT3or4X 9b2oa/mXxW48wQ/s+oD1ADCpAa6no4Vx8zQSG6JS4A3/8XhEP1RSN0cp6DQA/oxVNHMl84JjFByL JZN4mMtNalfvfGApvrgIwKyc/95F4Hga+fJd6sxfaDq6QFhr2rpi9R766J0PXZfw+QuuYgNVffgx tR4je1oSN1591214QbztC7Ar2xVBxA3u6KzH7LOdSLyQd2GUDqLEvibqwVub0EaJkwpoOwbKI6A3 JdrMKOPzIuBAizqBfMqjxvKOXHhaEucAeD6JliRwpEWWEtLdevF9CvwCEE81vsDjClhQRpgM7AqM sIDiKVYmRBW4t73KwhXzC+rD//2nXOLGdDadPHolO27bnK7NpB7+7WeXL6qLWdcUrzifnp/O5hLy ljtiWEyM4SDMQ5phrGv3Y6XGYMp93qWtUAfJow8xvAhktXyFtFp8GHzTTP7eORf8moENHgLPZpCj EMJOPiHsVpAhP8D5KcBjKL+A817Q3k6UWQ5LFotqeSzA8L3TSAT4aaIELQzDB0EHjM7Y3jAH0Wel TNJ/A3NTQu5DF3DdBSqdivNUnG8F5WyDntiGWdmL816cNXh6AcZ6Hr+lwW8FgOF6/NodqD8DEABT gf8kaDhOWmB49B/uZmFsJIFzvQyvqA8W8AAwPjQTcPe76XGV3JBgBtAJehnR3AqDc28eDM4npOrU C+Nv3LLlxhueeIIWfJGWX6+58qL6qPdy//ofDFs/5/l/Du6ddPcEr/++VKo02iqqH71+5WOPrVy5 +WjtbUtz4yflCsG86ZbHl48d+a+XXj7a2jbOYY9GUyGMfj7zeyA3W8kbneNAa0lQnB5yjPnfMVAU Gx/oGHhVo3QEvd+gdAz4iPCdZBidloBvH+pRthiGshv35dDKMNcKnLG9bpqAQ4YzBZ4WhH6NYpbd kIQ2XHUOn88k+s5CfRauPRNXzSBt0L8Qgwj5VtJrQLbfRxJBxLCzubs7wHRxNRaM5kLzSXKR25r/ /mlWJSF7SGpWvND6AVsXROQGb+C0Oybd97N8KZdKyV/nw+nW6MULLngg2pEJ5+Wvk8l817qK6nXa 5Pauzhe2yO1Iwolxp2rT0hW3LpTnsGwdpqIZrW8Bjqco5oDWk+TazgyOUeCL7aenoQriA26joMoa 4Oc7jN+OUgjcHQMm8ZUv5sQMGmb2SwhYORflMlpguqI3ietCuC4FnseKezf/FolhBlBFEEsWOMzc r5OywG2VRZNq1LB+KCmCe1qCNlkenop3lpM9cJ/j0fzgt6lUJkOLr6az+Iom7g1KL1zSkp8+LZ0Y NISRNwBmjwjXY0El6rSx8X4pLxU38vFmyLJOttdDgvNoEDPOR32cQ4MYO8NBAuNnHJoFJ/owtiTG psTIEqCnypj1KEX5iAPIbz2AfDvzgapuPB5trvAZs4FPGuu/M9n3n6MyM2xtqnNYMlbuTFFTINL6 61uuuBiMdaX/xz+Ql88tplJCkg14UWvdjOnJ5Hd7V94Efqpj/HTzFuEtJB2yQVPswkKkDeCjDvJ1 5xhQcg47VeSQCVOL7Oos5EQONJ3FPm0dgHZwRAqznMII2U5RBrTmYDlkMVYFWikoRSIG4MZOUjiG gB07eK4dT9OBRhrQy+6owR21aEUiIu5ktk8LSmrwD7NCktCXejKMuQulvgPQB4xDwDBI3UMKOWMY 9nFshVBYnMhJcpS9M56Jczv+OkiWtQA6eA+2ZMGZR+lYsALZrsxnR0CugHgPW3r/t2Q/ZuZaKt88 V5x4pIMbqYmevPQMB357uKYnmcpPKqSnldLJl7wBiuT1XIaaEqm5Nl36/NJddMW0bBzJW/+TSyWT 8gd0pfxhqlAxgpnF4rQdrf/KGHEFsEtCh1YQFI25ldjuAIGgQNib1CPIQCHVicR23fGSGZ1BYBJN 0K3HjnNehdfU6FGhi/GhhD8CTmOcOwW8RgGshbm5vd2Vr0KBRi6JGKOd4mafwmRCdNvcYjpJx2N4 bViuyx+FlABjOaR1lSEwo6vCTvgNyvOcP4e9dTqt6bwYO/i1kHvwTnfzPcwINKYdI1FyWjsd2s6I tx4GbVrPeYbtsnYEEdscxlgP+imj/A10XoZJHlz5HXymKO4ZDfrE/MIeHQnoIAsASwFK7LqSxHhH 47px+K1a6MIG0IYfdzGJMwwWC9vFzAjcKFn0DFfNw3E2rg1hbzwv2plWPw+9zajNxv3n4ImMC1gb 87amsEQh7A6B1C6IePNAX0VoVcQXlGglj5KtJuU7WFiTLY2w1EKGcCbdQM9QpycJckaBw6ilmr5/ snQ/vqjPQpCVTLnKcUg5cPIVP6wfPv4c67B0JLoyG+xqr53gjXdkIgXI/Xi+y24dU59K3R92COlz 28fMcmYuHXv91ebhmVh0eSoh1K6bt+pyeQ77kjc10k+3TJ5wTmPD0Q+ZLkBY3S9cH0pFo654LjNs +IiOJ1+ouMgFrPJV5MdK+G/t5K3O8ZAIRsgBNWY4C9uC7dTG1gaOgKO5JsZ8WjCbOcwF28WU6eB6 zCvTETFg3we70YN76/msGfActutqO6ISbMfVFliJhqomrni6s3H1ObiezVAWfRVNbIcmbsF8sUXI GYTlV/xHZcwmYgj+gz4+QRsjfOmv5kKfEG/gJo7l5EmsJGHUfwVtnMnn53yvjvMdH5djmTZo44UP QhvHxuxpSqehjRlm42GnrWtIGSfDgQzCvMeVcSbAJgCjngkf5ipxB6jTRUaXG8hBk/Kg4xvTu+4u VZdugmICnYpNZWYpZtFtlm22x12PG/Za9tp2u3YbzGJKP1+Tsk5z89heRelAjMKOriY7w++nzOOv uLdEWLhx32v337+vV3hC/ujLL+SPaOyLL2j8qlfvu2/fvvs2/JLOfF8+RM3vv09NMtvpWCAjYRPf CJs4BZz/sfMc2L0xQBK2rx+2bwyQhO3rB/ewHZTi4CofRmEGrTAKUKHtIFrzoJMgIvwE+7BJ+NhJ RPREhZZvMP8T4NdOgAyYhfMsnB+HH7IFdLMb5z04q6GPSnimBc9UQ9KZgCcmC5nMy+FXIygxa49p lwjkhR39zMs+gzSyPE1m/XJbl5FENVZi7kcIhbtdlaxgRizg2hOioszpOMFiq9AIXDFEChLJk7A7 /1AiEc/LY1Pp+tE22+j6dAoBkq7Hz3uDGo+R1y/e0UGb1u7Yeeut2585RpB0GYrBxpWMjOnsjrlj xsiH9u+TJ4wRnll7y7Pb19y6neF8MnB+B/dDGshHiE1tw9h/itE/Bkwwj/N5lHeirITk9WAO8B0+ MC7CMmHWGtsB9CDqMWDbD+46CM77BvpTBP5VxA/8N0LmagHMt9UCBPyCFU+2chmYgV3EolGYI8xA A2aliOf6UWM6ncXAmI3HIgYZ4DkOjDM5YIOHC3wz2ckQDoRWGPB/wTjrxMLpCR9iUgtzOmLVKMKJ TsbJErN+cPtaxKfW3vaMcNXwHYv2yceo6dfnbh7jDdyXShRH2ViMKiWPycdTCfr6LU8/u+aWZ3cM Pk3vGDNB3vdbahozZq7DjsyI0HdfYQ5iIcQD8f7IL4UevgyyLktu7MyDmlKgOB+XdNC1jG4xUhaL YTTLaHiIvtcDE5sBuwBsh0xGp4xK7ZgfU5VOK7RpB3Xq0JZjdnEvkMTXkytfp/TD/OExvYrgKsRP 0tL/gRR5fjpPr1EJEp3ILOKjVyZT6ezTXXMLyVSf13feb6+ecWlz2LU4O/lnFyHffMgkZtahw77t 6iXjWuOtwy67BmPfcexLyYWxl+msznuQDlqCjWjB/JYwpxbsx9dObgCl3QCs3ACcrMVcrwGt3ARZ /iNc8xD67+Y2gBdnH3kA/fejfz3670X/vaDO+0ErP8N1j+G6x/Ccx3DdVs7rBmCvAPqrA1W3g6pr AF6AD/SYQRSiFpgtAvcRQBg9OVAncnugBXR4thXvx7SHm8sDHeanBXsIxrETYQpUHadlXH8Qd7gx a8PR9y65HHMD2YGeTtikDfgFA6QMi13o8Fw1non9zPhzHZjNBdjfOAzPOkyQpodrwuCdPFoJdFwn s2KRZMs+lIfRyoQvW20Z7O3v74YlW5E2Q4oIxN4Mmq4vnZBcUrVMIXUqGVMnpcizEGUl14dJHO6P 7wjH026zIbN53sWrLriu+c333/nFpE2Sbjg23wpFA7mgvfGaM869atmrb798YFfrbRdHSxbk7OzI JVoilqbOaWPGdtx+800/ziZLpaWN+fqotZg9qzyiSVLcvO7mRx0el4vZ6xQxywHpfGkvMLKpsw2e uIEsAdwEWA/YDFBAFriAqQDACHmQh4zP4V5mdR1BTxBtPWhJ8KgaWIdidx5gvoiWEOQ50xXMxhVR tuBufM2BPxPaKQDfwXXDHWCfsld0OM9M6O6Aw1CJElXlCpPX1WCRhUuREwJn7GsmGFxDwaNqDje2 iLu6WJvJyIvOvmCWHPAli+3nPzR66SNJu2VbJtFw9hXxZC4izo/AZ5R3bL7w4pQ/XHQlYxPGR+fM D9LJQH5gf2M2XZrxG4ancdi18CrsjVkkT3YyemTSUQTlF0E7zOplewzWoIXFeRLQeASUbITciAAT NkjpGoy5FhQeR8kO/JhA29/brnVoJ8AniyMxu9QFbrQitskkLtNzcWi3EqQt+66ro68qbBmtDeGM rb8AjYwOOcKYWVqNwh7HC/ODKlirWKiVoM+J3XTxxVctfmBNMprIvJcI1hURY0McYs6aiY8/7ugq JdP3Rb30ih8uufVC+lA4moiFy0fPDMWZ39M1vvmZZ+kvmZbzsfV5StLHPpY2AV8J8pPOJGSCCT5n HDzKoozKKmUEuN0A25HLWyWwFQW2krg/AUyEgFe2ZK0CpkTgjMlotuNzEn4P/uOeZDUvB4OGQmcO pBVJAqNxawIPMaPEHhPkbQlMx2i04uGnrnVjnyTGqxUZnKX/KZWFMeWDI+GJU3drojQqTiUa7pjU lGiljalUcaRV3uMp5rN5j8g1fRDL+keXCzfjU8ggi3EdTTaHQy34aXqsH3h5B3hpIwc6R0BTqzDH zLYl2BscKgljjIJmfBgt88PbIbEormXR1yCgHnraAxyogbEchiXBr5GAs3ZcwTJYvLiarVe14b7K bpf14GA96heBay8Al1OUbCjpCcuJYRvjMY8c37VUEpxeg/4G6VRQGQXC2NvEcK7HXwPxosQsvhqc 1ew3Wf6Fur9yZBkXfFtG4OrkbBf421nsosujYEiVGRKEFYSrKlsSJoU512tTqVjK/BdNJp5MUF1T wmmx1Ibanrpel0rG0ubrHndnRxdiDVQfDMZKnxqSyVjGSAflOLJdSsKHYXwsEEy6o5JCOvok3YXc mKI8R5iOgFgAqwgh4aiNNTFiQ2RPwn7CZBRdBp+2CfhqApksxflq6IObAWvgid4M6rsJbSwP+h6M fivaduGsB0bCsBQIrgsDs6OgNcP47iiMnXBHgWcj2DF3FJ4wClpwFHg6hSO70oyZQuYK+oOYQbbC kyZuzGAnnmlEC7Of2UybICWLaAvhypFoVWOOdSDoxZAfi6DVFqPuw9GBmoRzGfUpgDkAEaAj2POw txs5+ubPWEZI5XuQ6tdJQ5Nbh8GPRsLNaPxIJcVmNOeXkfjxCFqL+MM/lCopOIyX2B0jAezVWLLO aOSQgNcAFrwooNpXz/gLdFHJwzk1K4flVpzyCclxjhvK1KGu5oowP4Env5dc3FZM0rX+UkuxUe4P pJra7bRL/qWxrbZ+3P6mYnOD+oP9jpamQhOVgslSs0/+lJ6rTWQKE95sLBUyLYPr4pFYJBWIR/BJ d2OQO8aR2LvvhqPJaDKI7zrfk7fF0R+JhRNfM3pphX2+DvSSJy92loCwEGzpEFkAWMhnlcXQCkAA sxF7MIN5zHagOsewKzHHzAMqAJVsl9o8rqrsR6sGD9shFS/AWcK8eXkJPjDmD9Eyc2Xyjucesu9M OGfa+VQxxLPnMYHHJoKtOhA+HUHU8E1gJamHzwTiZDzluILEoTxNfEj3nyVfdR5Ugjd7WgPiXfX5 eDL54aPyXVwCulq4BDRRe3J0Q6L1m3Qy13KMwM7k1jUdIbzF9ACXgR8KLNUJMhD8h5cDLl8H7+mB yyQVOuchskNgeyah7ZLgHjtZgPpynJdDRi2HBlyD8hqUmf15P8r3o8xsza0oV9bnrMC4HWADWFHC Bz3wgZKQrDZIyiT4xgY+SwKzNswM81uSuIpFNXuAPQVmwoPZUwB3HswBypgtNosK8LkBV9sxl0wj KUkM1+tRo2CNGLjSgbMZnJjCbPVjE4oStwDxwQf2LIORCO0MKfoS5yE8BlPCzB7CRCXLsCpwPjjx 89tK+L+Zhoeyjo6rJBVdR78CfiMNI48+1tLmqRM6ZGSKxmKjxgmuMWNra9c1TENEaEttsi7nLdQJ 7fXnwCfalk5iB4fTmKBCxMYrrxV3KMygwlWdtZAkQVjgIYw4A6qzYiRsLdOLMUkoMxvbAZplK3le HB1UB+WpJxmUo/i/yDDRgP0PcdVleI6FXAos62Bpu5k1h0+ygQusd7L8oz6kGHOTpGKUcAyxTcn4 x3V8b45KgtXQppxshf74Thc8TsuMZME7f0quzeCeXpfZeuvI65PI5TX5tty2NV073aIdUZxC9wfX bVl/4RijKOrHRBJPfrFk6VynMg7fWy2qor+8+vNtychonUj1Ey65+4nKmqiQltXCo8o8xmAtq5C4 Q6/AToV8t0OWvFNviQrp5cuV+W8+PAF3RXJTZx54ywJzbGWJaQEW5fYBgywaxtbYmUbPAk8xrKNq sa6ig/bUV3HZh7tiwCDFPR48h+EPX80Cfx5gLwkcIi2743AVf/AvhhDI4xhsRY/FIwuUf6aI7+jY Nm4soQE44m4GCIdtVlXxK9AHbA7nXzQKOxackWsx1EzLZLbe9mjQHPIHQzr79lu3ZrPTrOrOwhl0 v3/dlrsvPo1hsJxIbvv86lcjSkkTDUVSSkGKvLbkiyeTybJeEHRjFq/ffAfsOP4PuU/LKqVTjrNQ Z//XByX45P/vXbq/36Ob+Xj/33fonoW4cDfWtM6DBmUSysrnh3E85Pn4zknjp56eHXXZ0isvWnBl tYddtgSwCnAnYBMAgRz6MuBtwEHAIRbYAZgBIUABUAZMAcwBXA5YBbgTsAmwHfAy4G3AQcAhhkCA GRACFABlwBTAHMDlgFWAOwGbANsBLwPeBhwEHGLGJMAMCAEKgDJgCmAO4HLAKsCdgE2A7YCXAW8D DgIOMfMTYAaEAAVAGTAFMAdwOWAV4E7AJsB2wMuAtwEHAYcYAgFmQAhQAJQBUwBzAJcDVgHuBGwC bAe8DHgbcBBwiLmMAPOx6j9UyPEyJaFT6pFT6tFT6vFT6slT6qlT6iyj58TfY1b6iXUuVk94H+YR n9iPdaqT6nWn1JmuPvH6wil1bn6d8PzSKf31p9RZhPzE5zWeUmdW7on9zafUmXdyYn/rKfW2U+rM Bz7x+o5T6sNOqQ8/pT7i/3R1J7sJw0AAQH8NKAUVxFIJtVxYCgUkqFqWA2v/nUxOk3d8GjlxFtma ia3gGq7jBn7BTfyKW7iNi33Zlet5wx3cxfH1Kd+PHu7jAR7idxyrEfLxoy6QPcJRpc3xD/yJxzgy 0ty+/JNBeh9jhM/xCZ7iGZ7jL7zAS/yNV3iNNzh2g+f+R/advcU7/IOLenKl/S/+w3t8wEd8wsX8 UzlfZK+5/+W8nJ7XmfgFX/EN3/ED/4efr1KhGwplbmRzdHJlYW0KZW5kb2JqCjEyNyAwIG9iagox OTg4OAplbmRvYmoKMTEgMCBvYmoKPDwgL1R5cGUgL0ZvbnQgL1N1YnR5cGUgL1RydWVUeXBlIC9C YXNlRm9udCAvTlNTWEZDK0NvdXJpZXItQm9sZCAvRm9udERlc2NyaXB0b3IKMTI4IDAgUiAvRW5j b2RpbmcgL01hY1JvbWFuRW5jb2RpbmcgL0ZpcnN0Q2hhciAzMiAvTGFzdENoYXIgMTI0IC9XaWR0 aHMgWwo2MDAgMCA2MDAgMCAwIDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAg NjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAKNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMAo2MDAgNjAwIDYwMCA2MDAg NjAwIDYwMCA2MDAgNjAwIDYwMCAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw CjYwMCAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYw MCA2MDAgNjAwIDYwMCA2MDAKNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw IDYwMCA2MDAgNjAwIDAgNjAwIF0gPj4KZW5kb2JqCjEyOCAwIG9iago8PCAvVHlwZSAvRm9udERl c2NyaXB0b3IgL0ZvbnROYW1lIC9OU1NYRkMrQ291cmllci1Cb2xkIC9GbGFncyAzMiAvRm9udEJC b3gKWy02NTYgLTQwMyA3ODQgMTExOV0gL0l0YWxpY0FuZ2xlIDAgL0FzY2VudCA3NTQgL0Rlc2Nl bnQgLTI0NiAvQ2FwSGVpZ2h0IDU5NQovU3RlbVYgMCAvWEhlaWdodCA0NjIgL01heFdpZHRoIDgy MyAvRm9udEZpbGUyIDEyOSAwIFIgPj4KZW5kb2JqCjEyOSAwIG9iago8PCAvTGVuZ3RoIDEzMCAw IFIgL0xlbmd0aDEgMjUzNzIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngB1bx5fJTV vT9+zvM8s2Ums2XWZCazZCbbZDJ7JrOETFa2gAiIgASRTUQUASkiUlxq1YvU61KqlnrVWl5ey6Xe fm0rVq3RKLWCaMV6Kfi1XqOtEKmXoldtePi+z5lJCKne3/f355dwznO253nO+ZzP+ezPXLt+4wpS Tm4kIpm18LJrVhL+b9ESQpTPLrvqsmuKddPtuP5+2beu9RbruiFChGdXXnP5VcW64WFcd1y+ZnPp /godIVMWrVpx2fJiPxnBtWUVGop1msQ1sOqqa68r1o1RQuj8NWuXlfrNi9C+96rLriu9nxxD3Xv1 ZVetKI5f1Ipr/TVrN1xbrF+yCtc3rlm/ojSezidEeyehaJ1H40RDbiAKIhAjKRATIaq/aP8Z66W8 H2NuW+o9cKkh/xk1qfnjLn0iy5/z6r/bjn01MPKKslf9N4xV8vFsBO5RqmUMVu78auCr3yl7x3r4 /cjmdZwVbqQLiI6ImIsG+cXkfxMtUeDqRm0evQh9CjqPVKPGyiKdS97FDBW47kZtDmlGPpv8F3ZH gSurXUi+Qj6D9pEGtM0gV6LGyiKdTqeRO9E2ncisRl4gEp1Gp5IFaGM9IvIb0TaVTiG1aGM9IvIC 2liLSCeTfuS9/P4ennfzvIv8G5mMO7rIVvR3nX0Dd3TyeXTw/naeTyqNmsRH5Xhblvwad2T42Fbe kuZ5C88TZCd647wcI3GUoySFPEIbiQXvi/D5NJPlaAvzsU38SaFSf4jfycaKtIFkkdfzd9fxci3v DdAa/qwAr7GySL287KHVgLKC5yJ18bYqDslKMgejnHxGDt5uJ79Fi42XrSSDcgXvNVMTZqSgZt7D yiI18j3RE7njLGo6qkWfguciLePjNDxX81ziuchzgVI+V5aLQLCPSBnuxCkBpp7FCDsw+Cy5DjVW FskZMh35CLuX/J3BCu9n5S+Ld+LKal+Q/2ZzxJXVWFkkn5PPeNvnvO0z8leixwjWJpLT/Kl/Kz3j b2xHyCmGexwPRfJpafSn/N6/kpPAbQVvE3lZJJ+QYZwxBa7sLlYWyQlyCHujwJXN4jj5mNyH2vFS DbiKlr+Qy9DGekTkwFW0/BnPUPAeETlwFS0cLrxH5GWRfMCwg/wngxt5n/yJVOKe9/mz/0TeYyeK t4m8LPJTKPKTJoKqAEPJUfI4gzWubHZ/5PkRvvL/YBhF3iFNyA8zTCRv8d7fk6dIB+74PYf7m7zt DZ6zdYrk9eL+k4O87QDPXyO/Y/tLXuM1VhbJqwyPgF3svfvJK+yc4cpqrCySl8kgv4flInmJz+BF DtcB/p4XyG9IEPe8wO9hZZE8X5rb87zteXZeyXPkWVAdBa7sfc+dZRB/trRq1iOSfeRpRj9wZW/f x+gHWn7F6AfvEZGzPfkV+SWjH7xHRM72hLWI5Bel9/6CP4HBRyT/i/wcNQWubP6sLJJ/5/mTPP8Z X8XeIu0ge/k+Mmojkj3kp3w+e/i4PXw+PyVP8PmwHhH9bD5PkH/l82E9ImpsPv9aWhnrEXlZxFk3 oPwTjo2PkUc5VjzGn/1jnrMWkTyCpzDcfYS0ovYvvOchnv+Iz20Xzx8kDzD6Sx7ks2dlkdzPR/2A 599nOc7/fbx2L7mH7+G9HNdYWSR3gaaL5Hv8aTuwmjl42g4+mpVFsp2X/4lUoXwHL9/O89vId/FO Bc9Fcgtvu5Hn28i3iQ892/hsvo1Ry1FjbSIvi+CAbJ5b+Ojreb4Z1IThPctFsolj17d4z0aeX8vz DWQ9h/AGXmNlkazjeLSWz/9qXr6SrOY0heUiuZyfnpX8jhU8X87bl5GlZBbeuIy3sbJIFvPyIp5f wkct5JBiOyGS+UTNqdN8Mgm1i3k+Dy0iuYjM5T0X8TtZWQTsZmM2Cp6L5ELeM4s/7QJSgz8FuYDP dibvmcHzPp5PJ9MYdwb1YzjKyiKZyiE2hSQ5jZvCeybzvJdTBM4lSRfJY2wnb+9g1B84yPZfxlwZ XNv4juZL68hzmGX56AzPOWckadJCPHg/55Aop4CvCt4m8rLIZyGSBH9znD8lVnpmjL8hyp8WYdwP FIJRoTBvaSIhjhmce6LcwDGDtYmksVRr5M9rKD2PjRBJPW+r48/g3BTUhcEmUIJkgMO1pnQPg65I /PxOHx/n5fd70MrohYdTymre4yYu3ubmNVYWgens2ZU8d3K8dxArnq0gDr4Ldt5jK7XZ+LtZv4jz xO6sIGZ+yip4jZVF4I+R46SJt7GyCKiy0eU810JOYzhRVrpqSmvR8JkzvBMh8yk452W5CNpSXI3E 4cvKIqRK9kTKW9jzUKaOW3fQ0P9b/8j/W9P9/zNbN6SQHeRvVKA6wSf0kYepAHnofaoW1ORNmqNP g0+/SR+lf6aPAhM2Qt7ZSAVxO3HiDoHoqU7qFMvQ9wW1QEZ4RxomAyijj/pAb2PkGfFVPO8d/LF/ 88g2sU9cKu4CX/0QI4m0StxBBujj9DYyTPeTXnEncOUQRm4lW8WDpBdPPSTm8EQd3UsfQvsX+CNS J9QTvfAmnnCX4AbH+AKrkMHh8EfbwRWWkpXSq+Q2spasQvvPIR28i/RzcRXeMkzb6EOQimN8nj56 F9kpfEp34nlucZo4G7x8N9kt3I3855BBCLlXuEUiUoY8Q2+hEtWTV5Gb6QfkTfJLidC7MWJ2cb7I CRmWPpceLf6h5sS7hnFifkmOoOaTThb/yP2Cj43ByT8COeYI+1NalPPp04DBQbpZCAoP00XkA7qZ HJFOotdHduFvg1SG8lPkKToL9x4RbkWNwXQrL+1SWqQycVfxD71twlzFQUWbwk2O0EcB8SMKt8JH d9C7xV3QO96iO9hbyePo2UXeEQ8qBzgk76KfA/6P0nboMUvJZkBxM/62cjg+IaohMSzB8xaR54Ug g5vweRFydL9gFKfRk6KPPEixSsU67M4OskOxjuwQ3sRs9zA4Cilyi2QhB8UcXUXWCkeIkxxRsbm9 RpzK2eRlFeA0Br0j5HPFVcC+eXhfHd0pYMXAR7bmIzb7trPkZhItqJQKSRQoafIanxSCU5c/Wbhw vve3C3zhpglVr1HlfZLMerJ8s/fps2dnzZeqFAueVLieFIPqJ6Vgzfvf1Pl+uGn6rPnep+klPd2l x/Ys6UbjnPl4A/6zZryupzuMrZAOAu8OsivN4boB18+R7kZKoX4IqRflRbg+iOtOXN9C2li6bsX1 XiTWvgPpIaQtSPcjlcbze+tQn4bEnvOxdPDsKVzxXNKG1Fkqz8I1Uao/j+tVpXII4/9c6ovhug5p NhLmyu+34yqUxkxBeSbSdsz1UaQwypjv2ZO4Yl1kFRJb53yk7tJ1f6nM7tuNdBPSQiSsid/H5sXm infw6yZc2TpZO5t7BuNexXV1scyeISgB2qI9gsAWoITcT4gXPBMKIDhM8R/jPwr0qcCnNOBaWows B5cygM+ZwP8qwPWsxAZO5QDWVYKLunCjGxYGD57lI35wpwC4eC2pA3dvAPcPQZogkBOaSYREQS3i kC+SkDda0JqGDJyBNJGDfNMGWaYdck0H5Jwu0k16SC+k9CmQkKZBYuojM8hMSFazIHHNhiwyF3df hMT++fF3A43SpaB/w8I/C38S/eJM8RrxMfEvUqf0gqJPMaRconxG5VB9T/WR2qW+Qf1bjVozV/N8 WbLsD9qs9mHdonKpfKe+RX+jftjwHcOfjN82KU0zTU+Zl1R0VjxlqbV811pmfdRms91j+w97pX2x /Vr7HkfAscupd97uPFW5pPKPVaurDrgaXU+7ifvn1YXq2z1qz+2eU97nfXnfU36bf3dNsubRgCPQ jNkKZKW8U1qpeAxcXEXsBY1ElFStECQSOXDsQIwYDx84fCBaYfKZgj6Tb6VERjaIVSMfyjtV+i9O rVc2sBULNCfeK96t2IY9qSGdhQZvtd2q1ylEtZk8WaneE6jxVlVazcpqm0mvUUPC0EnVZTapTBcw Hh4+Nmwy2zMs4WUj+aG4PROl/to6MZVsydG4zU1FPa3x/UML3eG0SR677bt2h0eyOWm60iZ6HPZb 7bZqyVYp3usM0nU6p8Pp0Ml3BZ28hoqT1/i6N5x9T4pIW4FXfeTuwrwt1VsAjMZud5foryifVpbJ psKa6kizolFZ8VKZ/8VG5UCb7YXGsmnPtT2f0k6igbqaVCTcXNPob1HHs+4yTXVG6TR2d0GVc2om x411k0VNYYbx2PDg4cFB40lTxpzhq+SLzcT6SWRIHnzlpJH/seXzfj7ElOmPUj21WmyJeEu6YhJN xG1Wi7LGX1vjV1otdpu9oiXdkhN4q0pPVfbigBDgFsGNGAjgpeuaKS7ooq/FYxd3eDuDlxvMam+o q8G1tTbQFNJIf9UZvBcEGjyhpmhZwJUwNTal4hf4fDpPYfecnc+v2pS2OX98T+4y+oFneqQwr7JK nCeJibrEBdPq/Y35MqX8ZE1ma2tjc0ydvrRxUjgUjpUbG6Lpn92x9okL5/sXNFx3uxuS4efivcI7 HDcCBY4VEnlSvcc8igplkhlYUNz9oa/de2FKpU2qdthvwU6LY1vrcJa2FlSE3i2vFR+U9uPcBwsW VXnFy2SPp0VNjaKuvYyWaZ0evKJ/KA6oG0eGMkAwBjqVUqUUAGR7NUDNoFtXK6SS5vQkKq62uKI1 lgunZPPe1VXmustzt29fv37aNmm/22Kdna3dKZ+6++bPr2//hc1S1d3xAzpv3+M0fdeiZcArSlOY Szufi69gctkML4t7PFEndWo1OjPBRPKnh/sZqvN58P2x28xWi4CN5BuXxt6aU8labB9NuSrCN01b t/6fbs+urjNXxQJ8Tr4rpZ0W97JFO+Tf/us++YkfFHqqLLZZuSCknXtu+fz6zn9n8yCH6E5RBo/u Jd8qzOyZ1JHPtSSbw021QU+1224zGvRqFSVWyV/ZKnXsmdzZkSfVih7WHVa05VLJZinWwMcpethI qUKrryjviekbytsmGw8PDR0bGjIBaYtHl12KWzgYH4yzdgZkQBLYB7sjg69KUYSzoYigEVpcb4Ry LG2nwdI1xTDWQ88df+FxWaMBsdBUSZLBKJ96WqU2G3q1FqVSr7xzu6pcqbTqeo0GteoZ+ZTRJElu vV5ZrvzKbfHMr7aIK9dKgqFyrrZCodGJ2TdUBpXCpE1oNLqykyd1ZVpNQmtUovFAXixXK6za2UKd KG6g9jJzebmZaUkU8Jsm3SY9Bo7SXvAaNDqVx+naDwOpbj+kD7vJYgBwDGqCgsPgxfYOgYixo55h BG18NUp9xXPsM3F0S5lA1dgJ9Zk4GliFQ7Qv0tYWkZ/KNYfa5Kcibe1h2pdtbs4J72bC4ay8O9JW aKILs+HGPF0YbZsUYfi2SH5G7KYLwQGbC1Vqq0EvaW0qp/Y18qrThhrbZbVUYXaeO2WM0rCTVqQa qtEN4RvAyI2QOGmsUEjy26pKo6RV9JnMlH5P46YLdWUKg+bML40VIq0C1LVahaD2WwGjByHBJIR2 8GVfwVyuU0gSOag+YNSoKZEkndF4eJBjx2l2wCsABTcFBLD6NppseVlsczg95pGXLHaH0O6wb7X6 q51brZVsbTvPnhLTdDX4vqWgIa8r9+pEi0aHlQC0p4eLx5idXEBRWLl4w4bFi669lq5eNXfOFVfM mXMFtg9ze+vsdsmueAiyQnXBqJcsSjA4QavBzEwqS3FmIAuDg1HNKOlsp3SU5opfnfllVbOneXKV IEx1NXvCU3TS0b87c83ZkLtNkj5sQ8Fcj/cIZCP4yXyFHnO1k3DBpTxkJod0+8y/cIS0IVWABhT/ aldoJIMoWR1YAJaAtw6NDBk/ArsDVWe0np36ODEZSY2f5cLK1Vuuv/LKLVuu+ojq5VMfDcmfUa0U /suBQx9/fOjAX96Xfyi/Lh+Uf0hX0AT+lpfWC0nVozBC+rmgEIsYqa+q0mRUWKr36cmASl1p0kv2 Ko6zTiOgQySjFJVEyW7QerSC1m883D842H+4fxhIYi4e6shwfAT7F+0PFhGGbRwAnqOmUZLV0l4C mCA/2pXP9pz5eU821/3MNZV+dUM4nvzCU19e7387nmmNx1szcbHPrVQmozXR8m61ugluMWZJIJIa sIuRKwod1lgVKStXCxZRQaoOGfwev1HhVUT8Cn9on4YMKMqlJkuTECD+mBCj5YLUbCUWvRR0lKkd kro5aIpjUw8PYgGcq9oz/YzZDrJF9A8VGS07nNGgr8gd3ZwSFdeUxjqwCWCzjDmU+OgoLqjo+3Rx uqUpqhac3jOxbHtdiP6gs+PiBckLbTpTNBtPeKMz/23Fc+9u2Py+MhGPhct/2OyIN9dObaB3FG4s LJzvcendMzs7ujp9yfiBPRveYghKyb1n34WQq4c0emcHk0KtkGMNyF9CiwsSpgtWX5aC8EQwy7cL vYeIDp42JSTNl0gQpRDs10rYo2OQl5sgEzdxCRrsBvVmyMnMilMPmdmBZzrQ54DUEwOY+gcZJpqZ OAJcHB42nvzoD/0nzdj5aJFqF0GAfS9hJ6MRYFCjUBrrBoEX3RuuOfPHJz9qTzoPzFy84qLr2kPz dMo1hRm9056uqYsM/9veQ5cKewM/vOHXR6+dE2tbuGLxinkKIZydpaPUMHX25Av6E3UXXf/U95fe xvBYgH5NpJSiDDJ5jtxc6KvMUJvLnGkFZ1LElA3loq5RYQwrs+TFoLHG/GJsn2tBM83WhsWG5hq3 GPDqnJpUMuCqMJZLxKlp91KvNRNwaqwm0pA3Hi7S5X7jYJFXASFKyMJw5aScfzsv5wdHuRt6o/2A B2BQPAGMh4WolYOFS2ajJyJVomkMj9DLWZ+K+sR1olJlSZobo6JoU7ps1+Q0LikQz3XLC7sz2a57 5ERllbacPmaoMGnKFT83GI/Ir9AsPU1poiFYZtNMs1q2CqmGeFNTPBHe6q1uCzbYhd85ATiPWGl7 4AzMMJTsAP2pgl2hkdzQEcLOU2hEErSgGkDThfJLqFUAc4zAlzLgFcwcSATWlhryBlp+ASxqhLZU B32qBvcTXCXUVCg5oXV5SAgYM4z/HFqcvQ2NjBzoB9IY5cFSY5RaS+dFKgJlDHdwqBi6MF5X4oP0 yY7VzU/9b/lT+cwzA90R90DPuhs2Li886c1E3TXCXZNi0XZJ/+cK8ycDf/xw9qxoT3bjlau2zG7v o0MtrlihHQ50hicPnX1fauB0N0ByhRqd+KZBc8jqr9pn/UVQqrHUzLXNrZR0DiWRqqvMlUrJEQT5 PT3EVlFE+0HjR384CYTn575IiMfof41fACHm8wVF0FMxtOai2Vevm3/h5fKW2O0zHjn23wcOn6ab aXrVwh25ml376JalWzcvWvbtTfTxdO6zX/zmBE1RA51FH/DXXaKWJNMgmzMlW85+Kr6GvfKQuYUU tBaxSg/HqWTSDVS9If3eq9E6tQEa0nXr5uqW61QWr77KUS7ZXTqtQqJKNVHbIWgMctyF4AUCx0/v oAl8neEs52RMGQCBS1PfGJVOMYGMrUV8TX5WXencp7cIAl0pz5YUiUBjvWAWA27hJZdTuuXvD1ZW mHXl5QrxfbOvobZeMip+6Kp2VhHQkfuBZykO7xro0JcUsg5d442gTQJRvmQOvFQNlhfVuiVP3NGm 63TM0M129OvUOp/GUSWG3b5qjdtQ566qNohuaxQbMXgaROf0ySL2lMiQ8eTh/teZADmOL6aZECnV +ANsTVxSKR7F8WOElYuuWb+w/5r1d6y7/iw59Jp85vp1V6/9+8svy+vkvXOvvnruvCvXCM6VF114 xcq5c1Zd3fDw6p+88cYjax5pjN6z7MHf/u7+ZffRHy3v61t+2QV9y4u49SDWGlToQC8DJFOoIf43 Rdchjc3wC82+oNZeZb+k7BL9FklBnJKu0uMxVymBW0PDp4c5Zg2fHsWsUZUsETczbGIbw4loxTiU E93R22cCn147/Jn8Xfl3VyzckQ8+9IvadfNnr1wzd87VQiid//yp35yQX5NPyT+TL6+pu0QlSRUD Al2xddOSZVs3s7NQlJfEbVwGqS4YdK+b32JSk8MgWqwaiB15zAyS08jI+bJTRVEu5QgzJkctWrxu ff+iazfQ1ZfPmbv6yjmzVwnWy+dctPrKuXMuZ+/icifexWAztVBnsOptqqCaaPXO1z2H9RA/gzZK 9GqFy2rwm1WS3+KCFAr4jDCGg/0e1RiGgAEvoIXJG/+DUHreHL9eQJ3JJcANG75JUBWCbP6rL5qN 0BkKyrZB2gD930XiBZ+rwqQto0Rl+4PqbbcAjukl4mibU/Ia3EDVOGRY8EkuxGrG2GMdhd6YSo6T GVX0VmF7uikZMoc8I8PK8tVr1WJlfa0+lAy3CJvk1ypx2JI6Pb1SVMQ6uxIKut6sTTYGUpB4GT2b RldJt4i3guJWkbqCjfxWZf2t3jUmypslr1PrYlvJ5gMNAxYULlMzHbZIcpmEfa72uLgtFIuFRm4K JRIhcVtjvFQWb01Houl0NJKWn2Sl1kgzQowoWQS47D4HF7OOwUX1B9vb7nJY1iIMLsU2vdcpAS55 KO+MApXgMno27dRe1LFHpeqWtDjtzLWpcLzR2FArOtRrryxTjnxcHapojIfSwiaaqkwxuJjk7ykS XV1RpSB/X69LhAKJElw+hi5wWvoQuB0l0woN9aG6aktFuV2nCBjJz5TV7wRCe5R7Y/YKXVWgWVch +g0aqmn21cWMx4Ygzh5mNhhQfEYpB4eN8kHO+E1AuHG4n2ZQK2olTAsvSYL89DJNpUhxBOf8NVdd fPGaK1/MJRO5WLctdP/Si2a2l5U3N4ca/vTIr976DY1cPLl3wYLeyRcfn9kQaa7PTZsW0FmnXj71 InckG4gktqX7nn/s5l8T4ewpyDjvQkcPY01LCh1Nzf5jDZGXDMa1RsH4x4ajXrNeJANOVZmJKsPK Zo3fGTXaPFplcyTq8zeGicFoMusktxbxSVKdrdbNRLrB0/3gxSWpF3sTHz7dDxIbh8BbnP+Y+F7n U01oKVmOwCPsVpXokxabWlohpLzVk8321DTIs0I13TnU5Z5sa4uJ6maxGt20IHDobuo/mk4BHvls fOPGRCaXTOZSaeF4MptLLhGvlxeCb/RirXdgrWrYYePkZx0dkEFDwHgKeTcE6YRA+nAhPuWvvI0g JqwGvqdKyCdMfg0i6SHZBkFtWNmNHjvqzAasw5PqIBnHudyrRksA0jABrjbx9iaM8DKtDG9gb6nB ybJAHk7A3ohjNBRnQjDwociEGGkCPkeGR4b7R4A1kBGZOGwqSsA1waI1gwmAxdMGPagkBhePHZML OerQp3f+y803/JAuvmrl/NnRTVfNlad1ZlqSJkhA2Q564K2jXWdeuG3LiktWCkr5UO/sOb1r67ev uWRn1OUsAq+1JZt67KGZm2h0JNvTkWeQaoOss016CavqK4RVZUpiFG0DsG4NRGDmCsLQ9Hx9wBSw hgwhe86rKK9QkohLVdHkb66Hunx4cAhUtshj84NAilfYiUBTtCTuVHDsh90JolpRDuL4IdV4mTaK sviwpdEbaxDCucawsXL9igcf2/3gFWd8dSn5dy/KX8nP0ikjk/9JuilQnWyXR3qi9S2Xznnj5cHf 39kZm7+LLqR2Wk6XexmN6yzhQjVwYU4h4qmjx9RHvWTAVlVb5Q/VhvySL+Apsxk1do2nWlCQQJMx WqUIexodalLfyLdtKH6aiXCMafBVcGmOqaojg5lourQlzEY6Zl0LCZzBJca20q8cAILnu57Nvfli 9+ab7r2t7bFH1z7LkJtWZJ576ldPO5xHheNsGwKNU+TPfrZPPjHZ607kgdknz5j3vfDcM8x/wfB6 EfB6EnmjYyqXtxlemoCtEqRqFVabho8BIZiI0CpH7SX0vY9eAuy0AxutPJYMrBIY3wT8zyFeMgHM bwTmu1CuQSmMHQ/gaSyGJokWJp0zf38cLQ6U43iHBzSkDiNtmFMMTwjhjnrSPobj+ZE8eFgJVuwC HB8aHhkaHu6PGwfx95Gch348Ck2UYLAyJYpKMtCB22wYcawxjWnOYyznvENQGpkSb5UjT0JjyQjR lkTySfpmIpuJNU4aOVg8Bol0tkNMtIXirdmEeOgs0WVaE3WCTXuoK9uSMstvb+rKZrpPtQSKpyGT yqaC6T915/JdWDDWOAtwXwm4p8mzHZ2gAwac8lGIRwHJIsS1HOIGQBzxuaAcx0Ad/ooyhQY9lyQB 3ybAuga7AGjjWosddAOGLkCXcrpM8GwWhcKsgXHA2AnIMwg3YCSj202AsxuQbmWQHhyKj+QHjfLb JxmkGZRZAqRPxuWPTvbH5YlgHgdjt1DiPjWgNeMY+NfD9i458rMEYAvQJn7W2pnJdshvd2QZeUmk cwUG10QGthYG19ZMoq4GUE21mOWj54hzCaJd+Vw3g2cCtOUQaEuGfLswZSXoW2NjzFlpK1KZ+spj ZT7jAKiN7z9jz6fFPVnJarEyWpOxKqp81c76oKrcqVSRamdjMEkiDX6QnWRzlpGdfH4IPBdw4ADh 8IAYNYzzC75kPMghBSpUHMA07aIC+Y/UKJ06j9CGKEM0pt2M0aedFSFOn/KNEUPVNSse/PFPfxRY NGlddybTTa/ozWRajHpr5ottJVrVu/0crWpILZn9xssvv2MyPxTP5hPxXCpzUud1lvuT5wgX5XRr O3Cui2wvzKl5iaZMIkIq82VHE0GfWDFgoGsRItFUmci0iNGwxaQX7VqfpBK6ahtItSrtryoThUZ7 WFtoSLc1BRCMVGlu114As1trNJxPhuu7GQoNDfXH4yN2eMJwItmFQayYisZ2YFP+lf6T9rjM2Lvx JFRu30TI/AMG4SR/I04xqYe+RCcbWzLg50J3Jp0ygTBmexinB8zkfbynxPdNqTSgKXTlsciXP/qo tYUx+5bWM7aiAJBK0zr5yGiZkc9iPz+zz+PM6qWHQatSBbeJHHMcNdABtUHjMEtGncepFiSXgjRa dUav8dggDHYQcZksgxWDsA/HORf+ppPBViH8+XFGIM7s7c5lex5HOdsjzJ6MlYgvn7El4NJL5rJx LpbE47ksi8in5Crg/aOYU4jML8S1Cq22SlGllVwGPZWcZoGanQNqNzkWOKp+vilQ7XNZbPpQsJ74 XI31JGPTN8FBenqQozfbJLZPXMYcxsa8wurMcEpNmFxRDQd3LYqS8OJVM4tS6nzpoUY8VNOQevY7 /f82q6kqPmmBhgq6uYvW92MtmV4q92KHsJZ3Kr57XaRtUiBgKUx5fV73LXbdtRdtfpiehLxVWlgR V3cDV7vJ+sLk8oBZ8AuiKUCDkqtNaDGQY23qo8lay0DYBY7rb/F3+yXBaLK4Az6P2kk6GtNEoXNO CgeBpc3ZWCzclmqu7+H4acwbgXeHIVEz3ORKUSR/Ms7QMR4fW3HRr8M8uFh7iEJfso9V/HXMu1Wn YhY0tm1fL0gxnEwlGzPdn+H8pu3yuxd+d2G5JQfL8pYL4xpF59XTFn8jXspv0pQykmCol07L7+Vf +l0L8PAqi+7O+9sX/vprsJMyWVS6H/AKQLaqLyvXiEpqI8fcR5UWOlBu0bvtktVUrhGAA0SIa7KV JiBqkPl3QciMg/yIlnD1ZPwVuUjVuOBY4pZW5vX5ppV+RffHMplkY/vIxo7WdOf8+R2tuQJ9opAD iwTqcnu6fJDxwiL+ZlOpbBF/z/4Z8/4A8+4g3ynMI8FANQKCOqjW16I91iZhi6vE8oGwBfKhoCgo OqpolWDpsBRCNCQEOgIFnSPlbkwF3Xl1WKfIuax5U7g8mM+G21pysbClPFybTzV3cm1zMD50Oj80 bPzoZPx0/qNh45BxCLIkdp4RIiyZUSkgO4UDaWyjK4obXLJF5ai2qAzWaUu+p7GOiiJlZzfahVW/ MRdSu4DwLUaXqaUl0/0+SBJI9z1G7Geb8W69sSWd7frPriwa3RwFdiXbLQIR0q2J80mRsFTOJsLh BH3lzENs00cF61wyninyvFPSXsAuRTYXukPOABEcJh9xVqYaDfRYTH20vnLA4gvVB+N+X1VKrHYa dLCjqAWHqNhN8jrEB+x25puDYWM7dM1Yg7+thcsA/VApmGNHhruLQYWfCdACLggMQhJgp4VV0cmI wwSuBjxhcKljcurXHQ8OJHFmujOT6aSujmw6YbLULI/W6eUl2Y7WTEF+H3JAymhMAIUeyzVW0oeE umSWYUwqM3JtxGFxCkfPvB+HanZOsvLAlQhJKQZa+CBkAObDShUCygEzGdDtMT/vsFALqGIV92Mx f5Za02RoF5uszQ5w+NMlXxbY+Xk2u/N9WTfde9+NN913782f00ny4BefyS/QNvHoG/v2/f7NZ/a9 8Rf5Yfmv8ifyo/QyakQg3qWYDuazDri9GfvjgXw1txDz4ZsoSrymEt+QKqVqwWzQYUc8znq/UkGC TS6FlzS6ClZd2GHUNBiPgZ/G4ZHl2j/X8JgCxKSxk3F4OsA6vx7GoyZqEXtQVObeu7wj3VqQd5+T XemPPvv7V58/8b1vbdqynj5+8HyAPvurgVcEtzw4a9b0C4trQTyhxGLmkogt2l1YSVrMktVYrmh5 yZqqO0asRqtgbT4atCsGqsvhkVNYolXmQDSgSEZbzN2m7ugVJm190O9xWNNilS2Sbasyl8dVZQp4 NBVS/FIzNZNsU1kyXpVOVdtgUfGHm2s9HZM4wY4PAgA4ricPv9IPes3YFMtwKdY4SDgFf6VffoXb STjaRimUJ3vF2Gn2R6jYDL33G/CyBDPWzUEmLql0SuKPtZYszARbumvFz/QBC0g2xAdZxuGFkJFs zXXSg4f/uPnM6du2Lr9kheAzNiolWWbEOifQzTa7/MW5c8sE1p88cs1j9Bb5w46+6SU9YANwdj5w touKHcshxzsh5TsRz8X8RjrEk+kQpx8n1yOp0FIOBGL6lB8YpcQ4DdoE7IkHVyfyDtgntNx6YCYv EC2+ZGMa1wslWT9MrsG9NyJJJIy+IO54Hvewrze60VaNSLACIsILaJkGHY/iLZOgKTjx9DR0Bj/m Z0CJRbSxSLEI+pidQoW2JugcVuQNuKMb4g9sEodBREobxQmJmfsymeicH2ZGnZNF4sJ4Tz8r9o8K z55iRAtns1yZ59IGY7WgK9yeFQFrhUFrTApJ8rHwmOE8iEsMtXVZnyBFWifXKETP6ikL18oh5wt7 vvr4kru6jI3B9jiVYm0dTWXKuu0rFq38c0/9izspPdB9i7Td6wgVXtDmIn1a1aT2OR2LUhpF457v P73f4ay0R9tOaDuTi+26GX19PVemjdrEA7f+9IgLUGrD2bhLegyrX1pIBdzeptoqq0QaHGbygfeo URjQGCvKRIvJ664qD/iCSqIRRdoUtFQFO5W0saqz3BSG5QtKxpDxdePrRUsOw3CO4EXlCwxqLC7l a/QrVRE2bYx7MTy2V5SAJT795uNd2SxEys5spuvxN5WpSGtKK4Y6xUWdIaks3toSEcT9Z2zM0pXM 5RLC8dec0ZbMJDUNLQgEFshvq9tb01MY2bIDT5/C+Q+T5YVWFa12IP54oMpjQ0DcsVrD0arnm701 1bYKIyJMwo1ElzaoGivCxsZ0HWm0txupsSZcW90MgjY02A8dk7GXUXWdHeiSabOoEXA+bCqGFIxa QkYFsWLsifOcqY+zGHr/ZevWLTVCtO/6isv/R/5r5Ci3/o1K+mc+277xW/8EVWVU3v9y5P13KRFU ow1sjUKJxtWTrkKjjQbgxBQdZipaK40ClunTHLVaCEIpCBVMZmelqrxaWR6sbsDmHeZGS0abR9ga 2Ar6aVVplmMUiPtdQYYmzv6OT7+oAjvsHumGg9goH3I0pbdc7BfkV2G/SHfSho4sl6NywsuJHGd7 mZEfdVcvUorLWlvyiZIoReiYLJUh/YWOgD/pFxpr/L5KMBiqcStCjjIsIm46qqh1N/hqaxY2XlR5 MZlfdjnOLxXUmjJnpc9f0xgqt0b01pZIdmxZzJyYBxFmCysqBFVFJdf+DytEsCNn/kxS4gXxnGTE UJL2BrboC4lEm2FrTVW2tbXnv/h2LVFUpyONdRW/etJcF4q0uBXLjKnWbNcpwCMHAfKX9MlotDku zxKmweDFhaSRu5JeT4cw+8zedp8nJa4rbmMri0CgiHMl0r3A1QK5rnCRn4b9U+P3x6W434w4sISB bWVWfTRaw3TehkpPdcY0Nb7AtKR2tWlT4rqa603Xm++ouT+ui8UTfKMrABWdPazQVdsnpWvb4RkI dwA2CD4YNL5y+BUGEg6hUZW2uPn2optvdO8FsSQzlmTodJ2KW2LHREjN+UhB/3z7LbF4tutPXblM pqLsK1rnzEB5kk9355LpBx/KpnPdH0OvyDipWf7ckWWaL0GX+PJvfiO1xhmSQHH4ibwhnWbllpT4 3nsUQZe8nW6i64rtCbhMAK+ZgNdawCtOLi60KMxQj2lFgKN8SHPUVzFQmVf2kCmmPiWc7oIpoKgv V5Z7IzRSby/vMjfWd1X7E5yADQEg/cYxiDBRkeHM15+FiaJL6nwA1NC3dn1fCkdiuaGu1nTSKP/t lu4MdOOvurKtPbfIQzBDt3ZRZS4RCYsvy8/QXnYUEvmWVln3eVFVzsWOCCbWCjkR4jLWuR3rtGCd DWRTYWqDx++2V1otLFZHQawfIEanUqj0HyUfKMqVMKEFSMgqWfRWUtOgrDX5PZWi215ephAvpZTW qqO2gm2WTbS5TY1Y+oF+loraPteiQAgGhxGxM97Gy8Tlc1E7pbDg8T7uNh5yCPKNk6KiH9BZ6Xwq VSaFe89cmcgbdEKV/DulmMqxtoZpwtZETq9799HOtkxWJ8sLAskmW6RCNHwP3o6M7uT8mlTIHqvA shGH9qi8Q1yFddvJpIJfp6blRkKH1B+SIeNRiJk6uwmWC2JR9LQDRt06Ft+FaFOgMWYMa8AIJOQi jT7fgDEuFELYsdMbDHjkg4GmpgBNeAJBr6T8ezAUDDQG3Yq73cHGQJDHWlMalncIp/lcsgUvmwtm 8SFmc24miiifRo9FwVy+CDfFTLjywWfCeEVUMV7pOKeYJgT1933BgJcmasLhGvmgNxD0vS0dbQgG G2pdX6111aIUwsPfwtc+XykWcQ+lo8oM36mEKEOHfo+LV+AwtKrgoyxG/fHgMargYgffLW7fs5/z oAor5YNqa5nDpy+nCW3QagvoaEpX7rNpDCppnaxSe+zlXj1dZTAaDfL95T6D3aNg/h169qTslt6T j0DaMhWUAtxgCGc7PAiQHx6Mij6rzyz9198N8pFnGe5+Lp4S2xQLEQXVXKg2lmkEoig34Nv7tfQu +jOqoCa0qQSKz99MozM/3M/i3qiKx6amR6Pc7GKb/8xnOj0+X29QOfQS4jraZzyjsOkVKvzKgcEI 9sZ0l1X4ImOr+EvY5JPgJglHld0esmhjqvokCb1VXXcjVKpPYgP6qncCx8kJ/V6VWmun0pR6u0ZF JjcHfKbelPH04DAkvfhQEY+YtR5Cn7wufxDh5GwbS0hVcuxxdjEKZYhx9qL/sqRd4lComkEhSp6d tChzzXlxPGac88yljzx98p3omq6LL+o8GI1kPznw9tOn4nMDV2+dNb3n+txRCN6J2ng6+/D2nbvL tBULFy9Nhy+89LHBn2u10zqybfVwqwkkh/Xehu+SmH92WSEdbQo6HS6lzkCUA9bgiSYyYDhu3dv0 ac0JYFGN1+V0hCW3qAmYRZ3GPKOhzzu9KeCeGitaQCHKMTWEoS08VtDXTg7JpUB5tmiOwuMjP4IM pQhkCybf4vCPMYXx0o9w19Kbbly27Kab5YHod6a8QTXyqYOX3RX2uB7k5gWAI9vza69b2H/vumvv vW/DNfdtaYzKn7wzKH/Z1dVpsTO/j7g8AxbgqWH4NB/rXSg+hf1d08GipMq41sC+qXbilwNs8Cd4 SBl+08KIEvtK/Tjqe6EPLOc6SDn8ECwuCz+oAS6rBPyU3G/phz+JO+v68wdGI3vyPDCPrxvYyE9P ycUCK9rYjnJFFhEyJJXkvrq7dIn6luZ4Mhh31d+8eOP3H7z5Wx9XBmPyB4OnYB1rGppxj7iyrq5j 1mNtWX+0u+OBTVvvvyUTWnwfNf7hTWqr5TjcjTXuwJ4GsKerCm0Br9MRtGp1qtCAwXnCGxywHjfs 9X5KTqi8DnxrYnS3uy9wSz61Vic5KHy0k5odGmmKitQHzDNj3BXAZHQshHF8XJhddxhxh+wjiDGM HvVTsz1s4/ai0ors443c43dfMnIr0QNuT+zBJYPyF1T7+uTbWm9lXmua9jvlUGnfuYvabuntmky1 v32DmiOhMymI7a7aM8OjW459YPt6lfhz+NU82Fmmu70FjY+Qf+YQ+RNyinQKOzoA3dKF3Iy91WFv lfjNEi/u0+CeAHIWy1lAEpCYx+4C6H69xAtAxEFZhhlmG+EawfJP96/7hEVcQnM+fxvhZVHWFHdZ RedVfv+GG045gxH5+EG2h5FT/0FdmQWrTTvWXXVrJb137dWb06HFt2MD36bGs/tyTbv6V162lM13 P/j2UoUPGujFhWis2R8koeZ3gk7VaS/5W/Bzu+aE0VtpN0kOi7EM0eykXKrH91Zuiy/qoI648Vh/ Hsb4PJPRixya7Vt8GPJsvBj4x8ycfN44eN9gHMgV9U2ubBS/YxF2v8OihN/Zz/IzR+Bp6F29mue/ +9u3N6XCvs2O/unitgTsnHK6aFzJxumrzMSdGfxJvr0xbkaIt0C65bXSDpxDLejskkKyviHo9Dc0 Kct1xH7C6A8OYIfiyoEm1xfx48YvUzpjuVhvt5g09RrLFIdJDHgiMzmhhWJVdFLxqBqg5WGGlvDX IRyWE9p/IDppMLNR6ZSChxZtu4ADdrGIuIgLYkdRyC296aaly2666ftu9497WmH4OCl/+eMHJiXK 75l011WTt09/9SzVvrHwduH97129ZseONVd/b3HSYk1k4VS54OgrhZ5o3rzmznBD3d9ffo0qud2S yZuM1mbIbYUZmVSz264UVaRSbD6RqhwQj6c+baq2iqoTQX0k3tRQazUb1FplS63HTwzmC8yXmkXz YzaDRjtF6Z8SdBNNw3S98sJ4XypcOytbpL/MZAYVc0jOf7SOHVcOAJ7zQ8tsvicZQUYfR4lRsmQt 7f45+luMcPuH5nFKDX255sYFD/2Uu5W+6Mq0tBjb+2at5ybeLziwTCkQ5mf9lWK6rfD0Hnl70SDU 0kJrblx201L53VFrfpE4u2qBE7sBnymKJUw+IbML4Sq70fWV33jC/qUetMpu0quloMXhYVHwJDgH QdK4WgxaqiUaQz1M+jidkMPfLoZHsGVzFxQzGr7L2kYp1Nda88WizbYYS3eKo/iZRcx58846JnjT sKv6n6dGQ7NmhpuPjmH1R1BL43YL/Wvr6pWx5p4be7GGm+R14srSGqYUglU6q1ZFsAyrY8BATvhV Xxq+qFd7tFgDlqA1S1oNGAdsRoPGwyViyh1RBxDsxJkpEyKitISkTEYuWgK4GYihbKpi/MzXyvA5 ZHqFMpfn/Q9+9J1k3L4jsvKC3JRYaOYFzc3CADuGdsvIv7xxqL0vGrWs3yd90rp6VSTSjblTshDw 3w78zJFrC1PwwYXZ4xNz6WjAV+E34xtBRSXVq6In0vq/q75Mf9pccaKustn3U/+v/fvwFbbJDH1R aSeS9ifV9mRfDdGEpqcj9bPyHDUhDR0ePD1mLAAJ4kIRQ1Iu5LLt6afnqY5wvBkQSc1XV0JMKI/f JCXQ/W957C0973ZnfInI1OhkqnZmwUg+68j66368pdL/FAzAMK4z7fopf6Xgeb7MH2iD062pvkzT GJsmP81sl03RQMiwf93rtS5mYheXZ2G5BGLiHy3FtbuBm/mCtwpI+SlDSjWwUrI4OEpaeEAX0WgN TIaGEsRDkNgpHMPD/xkHhfff6WnNdJ9Z2JVJ97xzNXOD0pDLU8K3XExczvie3cLmc/Yk9upj0M8Z 5AeFOWRKt63JqaytULQFzXpVg21AbDvR/eV08XguXAmKkvTpJ3XkWnumpJpjTX4SrIJPxKzWzjPP V8Yeaap+RK+8yNmRbJrfOq87n7rI57w4OBM4CXslPEdx5jAEUTGeZAIt2zFOWFlelPLynK7glCFc Dd3F8HuGtFzkOY+2mP6RrnxNE/9IZRyp4c8Rdjde3X77dfoINOMnqqob6+NpQ3M0jrK3vj6eMUQi 8dwH2XgkotdHYoncbQ3u4KpCdp44Pxx55Dn51nQqn7BbhFRX54I58qPnagtny4+2FHXlNP2IScy+ SCLFvh/HnrNYldsA4wy5tTAjnmiusBkzYh2pGGipO9H8ZcvxoB2BfieqVfWhoD8ST+BD1iqbXqsG WTIgPuBSrah9zKCGKEWqplTbNP7pKnJhqA8G/vH0mlsEObkG7Bh0x6TnceSa8W+mRZ93GhBg8o/g nAA7d2kTpLLyVqDW58yqouuaOecKRO1ku74AacvoeMzAEy53812LH/7Ru0UDSRoB6Net2Lxcfm+s PsQIts06c8rUF/eDzvUyvQHyFvM5ZQp1RZ/TcfNeB76aUkxXdSsuUc1VLFdcCZ9TgBioYaEYsM7k bqf+b/Y7cVWAyY3Cyo0/+MHGjff/4Ft/o83y7/92Sv49jQjvPbDpuh/96LpND7wlf/r2H+RPiyIT 2yt4EeUNfK/qIU9cWciRSK3L3eAw0BPqyEBtw4DXdMLxpXqk1ns8pTEbRKtRUDcpnG6XaCTxQI2i iWhqZuisfQ7j1BQI1hCzSnPyW4R8kZUYh9HMpd4SpmNTosFvlJzY93IMdUsKTsWoDgf9jj6+jZ1u eT477zlQpdaeB92uxN2XHMQXY1/tv3DH/1p2I9N5blwsf8p8xzGYP8UNsPXFrZYp3T0Y8ob817Cw 55716++5d936e9h+YP2vluSpKwpZLkoZSR3kfUhREKkgTh33ftEEWcpYrhPrK712WObrfAGNJQCh ys2kqhligEtV0F6HQL8GEabKjjrsIUXh6mtWP16eP1+wKqLqOV7LNNySRiDkSqt7yO1+gMsKeRYz VoTGtuSO2a/II1AGFt4jvDe6wL4pRclqZEcRHPkENYbC1PTGfgoTHTurm3BW74XeHiILC8mW6pZQ b3VvSGI4QGopNr+24Yz3uONLhhCIWzFIVr75apgTaqwEHyc2Md/N4GFob/wIcpLNuFRRpS2ePzh9 Jy7rHJkaPWrcWwP1TsgMswCmM28yhtwXgrLa+3ZV9VXPXbXs2lnt4S2O6M2CR352oixx38blC6Zn p3fOY2t66OyHUkJ8Bn6WTzoWkxXQTq9ARNtGXDfjuhv+790oK6GdhiAx+fDNWDX0mBT4d/WYZrsE cYtr0XMNrttwlXA9Cw13HjShEPIA2s5i/HHcJUIbmoTfSQiTS5BWwrv1LaTvwCt3H9JP8RsLKv78 GN5Vh3g6As1EiesleEMdnl6HX3+pw6+R1eEtdfDkxdCjBMecxP1iRasgI3Ewr7Ev1xAbxKT1k9wJ VsQ1xlTwxSI3h0wIuBl1dTFVy85ZQkmb5qr0OE8ZXVyZdodqmlpyQZshdvOcKfP+nHDvfeLAcx13 TLFG3A2hpvqG/ctnznsqWf2f//rewVn36S3W5vZbO9MZj6GpqTV8oUepcOzYtONBq83pSCS2hCJ3 JcK9DqXku+WmH/yEfTc76+ywtER6DX6vLdA0q6AnaqBRaqAnqtBWy72DLK5xAD1utJ1GS4BtKOp7 AdkA4O3DffA/AIYsTtoH/yXBE4JohVMM8hHUNn76SoFJeXwJWdTaOCoyyjPuu2QmCHLMhCGBxei0 jUYnjOlvgo/GmMYmH+qcM/NwoCEnf/zvl+8K+1yL4WvoWZzp7MyIyxkyniVrZi3saJ6xrTVZf80t +BYE7rHY8R5QKEwQ8+08+7G0Gb8SEyOrCzmHvbkiFqrGR30QcpvhFiMnalVfVu3Vnaioa4RfrNxo UdsdkpZKfSqiMU6p0F5Y09eoqa2eGgeVHWaRKSC2JZ7HEIOpqGhiYVgMIRgzxCVaMpFztW2cUjKq ro03F5X8Z6IEVaS157mqam4getzliW5f/Mgu8LpM77NVru6Zc64UBhhBtVvOrG5N5hMOa9+UKS/+ ls4sNsqRLcu3LMd6M+Bz+JUenLFp+Ii7wWkuOsVO+DRfWvc2NDppPYJMKp0Ebo0gs0WKghkft1cH mXfsGOyQXPxjH1qwZTGnAMPwr3WR1bD4qvErZX6jXz71HBaQ6T3Rm0HwvvyOL5VeXiMJ8sd8WSzQ LyUMyPPoE2zaXPe8o9szt0whbBptgKz46tk/46d5duEsbynM8TG3mKK13u+tlNyKBuYcOxE1fRl0 721VNmjKNE6Fv8zrLHM6G3yT/Rf7y9IxQqXWaEO9mGwMN/gEv1etSDodzHqsqVTrrclwK5bKjMZF nRI5to2vGNYHRERy8wMzyP5P3jOGt6NhRhN9Z4lZV5qSiUTSvLaP798JtmrT1rIpPd1TjBtXlc/s 6ukt2wZNtLXnE8ZOABAL3ZqvDUySb6HDo3A4c0cyEknSW+Ut8VgkyeCTTTCAYY9Xg3dcBfh0kKsL U7w1zoTfRCUz4gsMJ3LqL2PmE43OiNvb3mDMGBN1eUWiPe+ealxgLIsnknAMgU0yT5mtWaGra9a5 vTZqa25vRfTV4CA0Uqik5zxDiNZgUUTAAe5kiFJ7mmucY/YI1cTQq7rSxx5jqnm67hzLgTIkkNUb fNWJ2NvgoPm6N7+yZ3Nt3adiCY9fvW2LFPDGEm+D86QrPvnQk8vnu04lYh7hra1bI4k4girTqaGz hAl4qVgysmNHGD5y5j/79DRThvC9XjPDf3kdx/8YmVkI++ADihOv+bSzhrnJTjRqvnR+Ea8l1FYO EHCvobq8zl1XrqxrZt9zH4NWywQI4yAn+PwEFGWnr3UTT2Cu6f+Pw7AizL9rmcYshj9cLL/5TUeC Cw346CeXfFUYOyeMljF7A8G+1+G3Nnphx62zEEtF2u112epEJ36xQC1U4GN2y2mDkyjw8fiX5DSC KysaKlosOSKVV3hFl7XOJ+ikAH7OiAbUVqMLqjx2Hd948i3mYuM4lxinBgAHiHelSh9ShIK+4o9t cE5W1PEheDPjYfFzplJsjop+THuVyjB+CaR2xpl78m2VdvqhfDCWaI0EZwozJ7VVVb7aMyOa6b73 gqZEzJV1CiRSaG+dvG1mKJmqbIG5muJjFbWwX4nvwIi5gK8bJLqYOV3YLzLA6UITphpBOTCgjPz3 EciS/B/8M3DAfM0/iCZ4igLc6v/ul53c4Hajv+v0j7/qdP5vOrFfdJr4e04FnMv/u19zugi/TwbP Pn4bdSEkj0WIIuIBadhpMxL7x6z1ZOacOfN7u0Jdazeuv2LF+nDn2jXLWV9xBCssQVqDdAPSnUi7 kPYgAR70ANIxpGGkESgeOiQXUhNSHqkPaRHSGqQbkO5E2oW0B+lZpANIx5CGkUYASB2SC6kJKY/U h7QIaQ3SDUh3Iu1C2oP0LNIBpGNIw0gjwF8dkgupCSmP1Ie0CGkN0g1IdyLtQtqD9CzSAaRjSMNI I4QodEgupCakPFIf0iKkNUg3IN2JtAtpD9KzSAeQjiENI40AoDokF1ITUh6pD2kR0hqkG5DuRNqF tOds6R8D9ViZEu+Eun9CnZtfxo2vm9BfP6HO3a3jxrNvx8a/j327Nr6OeZ9X56r/uPubJ/SziMvx 9/PP2ceNj03oj0+os2+Kxt/PotnH11MT6iyyY3x/ekKdRTKM72ce//H17IR6bkIde3beeMR0nVef NKHePqHeMaHeOaHOw/3Gwad7Qj8XK8f1907onzyhjhiX8+Y3dUJ92oT69Al14Od598+YUIeN/rz+ CybUYRM6r5/93uR4eM+ZUJ87oc5/b27cehk1HX//xRPq8yfUF0yow2Z73v2XTKj3T6gvnlDnFHLc fJZM6L9sQn3phPqyCXVOSsc9b8WE/pUT6pdPqK+aUL9iQh2y2nnrvXJCHXTnvP6rJtSvnlBfO6F+ zYQ6YpnPe976CfUNE+rXTqhvnFD/1oQ67BbnPf+6CfXNE+rXT6iDxhLyfwBJKXd/CmVuZHN0cmVh bQplbmRvYmoKMTMwIDAgb2JqCjE2NTI5CmVuZG9iago4IDAgb2JqCjw8IC9UeXBlIC9Gb250IC9T dWJ0eXBlIC9UcnVlVHlwZSAvQmFzZUZvbnQgL09ZQkVCVCtMdWNpZGFHcmFuZGUgL0ZvbnREZXNj cmlwdG9yCjEzMSAwIFIgL0VuY29kaW5nIC9NYWNSb21hbkVuY29kaW5nIC9GaXJzdENoYXIgMzIg L0xhc3RDaGFyIDEyMCAvV2lkdGhzIFsKMzE2IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDU3OSAz MTYgNTI0IDYzMiA2MzIgNjMyIDYzMiA2MzIgNjMyIDYzMiA2MzIgNjMyCjYzMiAzMTYgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgODYxIDAgMCA1NTMgMCAwIDAgMCAwIDAgMCAw IDAKMCAwIDAgMCAwIDAgMCA1NTIgMCA1MTIgNjI5IDU1NyAzNjggNjI0IDYyMSAyODkgMCAwIDI4 OSA5MzQgMCA2MTQgNjI5IDAgNDA5CjUxMCAzNzQgMCA1MTggNzcxIDYxMyBdID4+CmVuZG9iagox MzEgMCBvYmoKPDwgL1R5cGUgL0ZvbnREZXNjcmlwdG9yIC9Gb250TmFtZSAvT1lCRUJUK0x1Y2lk YUdyYW5kZSAvRmxhZ3MgMzIgL0ZvbnRCQm94ClstMTA2NyAtNzM3IDE2NDEgMTE2Ml0gL0l0YWxp Y0FuZ2xlIDAgL0FzY2VudCA5NjcgL0Rlc2NlbnQgLTIxMSAvQ2FwSGVpZ2h0CjcyMyAvU3RlbVYg MTAzIC9YSGVpZ2h0IDUzMCAvU3RlbUggNzcgL0F2Z1dpZHRoIC00OTAgL01heFdpZHRoIDE2NDAg L0ZvbnRGaWxlMgoxMzIgMCBSID4+CmVuZG9iagoxMzIgMCBvYmoKPDwgL0xlbmd0aCAxMzMgMCBS IC9MZW5ndGgxIDE4NDQ0IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4Ab18CXxURbZ3 nap7b+/dt9csnaU7DWFpNJAQSDBKAwkGEI0ImKiRoGFVBARUBCEigRBwGQWDoo4+921sAkIYF9Ah GRn1yfjcZ0ZcUETNjDNPBxfSef+63YmQx8w33++977vk1Kn9Vp0659SpU7dZevWyWczBGphgVRfN XDSbGU9FCWP8rcsXzFyUTOetBf7d5dcsDSXTTjNj2q7Zi+YsSKZ9+xhzFM25cnmqfeQexsLmubNm 1ifL2XHgEXORkUzTcOB+cxcsvS6ZDn8LfNuVCy9PlUeqkJ64YOZ1qfezPyIdumrmglnJ+hU68MBF C5csTabLHwK+ctHVs1L1qZox+zOMkNuPXctc7DxmQkpnQ9kKxtSPHEWYLxnlGmmHl01yz3CVfUdB TAvPztW/eV7iVxd/esexa34MOsKWyUhajPqyAP2ank9gjI6cY9ccG+cI95bIUvn0a2OLo21sDqAW cEF0jBMUHc90AGereTkjPpqXoV2Un8XLWin6l+f4mcg8EwlfLnsBZTqA03pqas3MjbXRhh16oJSN cVIT0wGcbqJG9BWltSm8jhpbebThOVqNbg/RythsOvRRIC3rrbcRrFgZCLpW5K4oWCFWrMz4/ZvI uuZaBAsWIbhyIYIrrgoEZ1y1+gp+xVWrr85cusznz5ozH8HseQhmzfUFb511/6yDs8SsuY2LMzOW BK4flxFeDuB7xBQxEW/WXxDjWRWAs5gobbU5S/d07xMlrc5UZIfFXlo1xiZOYySGimFYgSj/lv8n MwN/2voij7bxP+54sR5z5X/YMWxUqcStkQGyF0R8PiPyfmtRaSoy+PRUJBxJRdIyUhGn24gcbHUj whv4dXJ4Y6J8KasCcJC2FrFaxGz8HBYEXAEQSE1CahLjfBRXWIDl8hJgD3AhHyaJzYemcAFwDvJP 58Nac3JDbUCeQOkeOkaftoqodUyIvmVEf6E/y1bUmcJfp/BXKfwFHZFkoM+BFeDPgFG/+3f06Q4b hj4mGxnErkG4ThbRZrrd6PCOFL6dbmMaGv4C2AR8K7B84S10G6a8dy+SxBYhbJAFdGHr7Uq0jS5o /YVE57W2SDRix2oRBYOVtnrSS8dYqB/1Nwalk9vASuyM4yDf91Xf89jnmZmld28T0Xu2KdFtLdbo HejvF7dr0dvR0xbA1hYevbNFRO9voV+2PNOyt0U8LyrFBDk5MaG1kUclS4zbobtLc18UEAL2kQxF sRgOqoXGeEQRGwqIAaoAiigSPjkIUZjCBcKHmgV7kYQUgntCAM6/aX1BA/980rrXLF/BP25NG2iw wMet4IU2/lHreivKD+3Yq2Cq/N0dkf6Sv95t9WPRUP/NVgxpjIN38HZJT/4y32fgl1J4kxz78/wa fq2cCr82NRW+ODkVfrWcihHGeF1Pp3WtVpvR+4zWtHQjcmlrv0FG5CKj3Rgfv9hoKEMXn4gwwCew fABnFn4aywBwDC/a6vYb7QbtcLhLwW0RyW0v8DweksvNwzzUqkQPoL8QdEgOQilcuclS+ju9YSzk R/QsC7EwHaJnW/PDoTY61JoTLh2TSX+iPxpc84cU/iCF30/h9+hdo4N36R2j3jv0FrgrvhdJorfp LSPzP4zMeWNs9CbmsUeG9Gaq7PdGGd54sBVKYA/4+w3J39G99CB7CLATILo/okdavX4sA91Mm4wX bkzhZmDJ1tNb10FN0LTWBgE0tXWdCjSldb1E57c2SVTV2iTLzm1tlOgcuVBtVNK6XqJhrXtlZl4y 0xmzofDHn5ToT7JS976Y9TvJmH+nj/5OMmnZ7s8qjX0Glpep059xuEox0tjOqp11OxftbNi5b+fB nR/t/GanZecz9blfHFGiG5pN0eaNWnQTAE123zK0sPSWm/FKNPfdnBMpvXkjj25sNEfX3KhEb5Rz 6N63o2HiZNn/jobR45J4eGkSDzzdeK+9ITtS2rCKR1evMnqN2W+omFB6AxKr0JPsOtSErpsww/XI WNeoRW9aa42uBV7U2NDI9zbSGKu4QExlTlElzkd4rjhPhq2iPnfMNHGOmMxcIiiyRDazC5fQhRvY LhzCCTwAeBBziDDKI8A5KA8BD2BlIgzIAQQBLoCdlfGn+a/4M8zOH+D/xh8Evo//kt8PvAf4Oebg O1D+LHAc5a3Ae9BmByAu2wIeANwHuJGvYU6+iq9GuJLfIENjvMv49XwFZEXnbu5Bvw7u5C5g4pwL ZqcEdXPs/dDkbrYNwGVd6Hqd/RKwF3AIoEJzO9howGqAYLmUgNxkoG0QY/KiTz9wBsbhBegAB0AD ECtD3TJ6gV6kvXjfdmqlHcC/omcoDnwA+FXmoN+gvB14H8pfBj6ANr8B7JNtAdsBvwIsoKtoIdrN pMvocuBLaQbVGenZrWm5uWPG0mw2GrAaIGg5SlegtyVotQx4EVpdDbwcPS0BLJI9AmYDZgIuBQyh 05iL8mkAwoE0iDlpMEURplMGcjzkRegjP3IClIZQJQ0hJ4EQIizD2GNglUS3KzjSnz7C7y/2e4b7 XUV+e6HfMsyvDfWLAj873Z8/wDlwgGtw1Dkk6sqLOPtFXDm5zlCuy6W77Rarza6ZzHahqHZQ2s5E zJsZYcKbq4ms3FzXaNdqlwgJyhXnib2iWyhBynakmzIdfj3N4VF8jtuCNKRscNnAsvyyfmV5ZaGy nLJgWXqZv8xT5iqzlGllooyVVRVR3DOJTZo6Nu4l4AvGxouik9pEaEq8MDopbqm6uHo70S01yI3z pjZiU+NKUxsH8oy76OLqNsqQxY3BPXLe8Ul1jTfXbOdsbJya4pELqiWKnV8dDzW16Wxq9XZOY2tq auIjJ1UhzsbWRLPj9ZNQrSG7Jl4oI7dl17BJ8VHnx4ORsdG+zxKZsWSpgX4u2z4wvyI+uGJmfEhF XfnP2dEoQwIDrognKma2EY+cVNhTsU9nPdnAS/Ckkm18ZUUbvx7d8FWn7qa3XZs4t6JNnIOqokpW XbqEestOEVmyFJlkhH1LjZcvXYaBnFSCDDxLQAbZVNLDQCcExrCXJAvYicWst6ee3B58wktOmHaq T9lqSZTGVQdrotF4ejwCJulpkOpRImqjlaGK+eVtdEMSrUqi1UnUkEQ3JtGaJLopidYmUWMSrUui 9UnUlEQbJErNDFbJGUYuL0uiM5PorCQanUSxJBqTRGOTaFwSlSdRRRKNT6KzJQLdMLcl2y2S+6um jJ0UN08BVF0cz4wg8QoSI5CwR8YyLcoycDJ6hfXvCZMHmWSonMXSZaz7D0b4RU88sazbiDOWeE/m /U8eefaSoPxPOpFt2xkUavcZ3b/o/pbtZXOZr3tM99bur0/Z7ZruVewQe5MdYDvZ02wb+xDxdvYi 28OeZJ8i3oHY02wLuwytH2L3skbgJ9gDbDO7GvkSy5z2/943DTwp7xg7xlpoDJsI3PfZjF429838 h+nPuzNPUfZhdx5byVbyZfwwW4Z/d6PHp9j9J9Sch/jDbAnOv+3UyS6j59lszKeJ1bNbeVX3l+oB FhDX4cizULlfcsJJz52smi1n9eKe7r+CT1ymKmyqz3T/VZ6lT3r+Wb2FeHfPs4dtIitbBboNw8n8 bja2p+BkDBoewxwux1zW4F8LVmMH/q3Ee39xYk2tXKZ6xm1mSW7t4SNV+hrwdB8BXGdE2yW9Uxz7 MbsGbyhjp+E45+rOBd9Uds/qXt59b/cL4Aa5+o+kuGIvUo+zX1ALRnAZu4RN56/hYCdTC5GeziZS NjnYfei72HhLb5CSKpHMkDwun57xKSkqpmQLo0w+3Wf0xOh2bMzH2CvsN6zNGM897HbWzBpAh6Xg 74tYFcY+Cm6JZL3PDB6WI/+5zqVsKngPD3jwLMznw56+JVbfNmQ/5bv5b+OTst8uXk62kVRMPome CGOvYyWT0tAEaiwDPS7Hyh4zpEeuXztW7QHwWk/Z9N7SDmNtZf2zWKEcRfeo7lWg/b+zC9lCvgMG y01o1/Tzq3pjTyG3h5PT2Yd0Vm/JyZH/Cd+vhAy1sztP6rCR1bJZJ+X0SfSlX5/iUyTVTpiOm7Fq u/C+Ffi38hSV9oC/20Gn69n5bAxbj3X8EPIxFzJcD4q/SSGsz++hxU71zES/B7EqC8VskVrlU1UD h8h/p3jUzmSmmZECzu/l3Z6qSd7tSZ2Ez1IFe4884I872HvgiafZbuiSOTIXXJx8/u/WaA27ig1O /WOx2JQJlWVnjCotGTmieHhR4bChBaefNiQ6eNDAAfn9+0XywqHcnOysYGZGelrA7/N63LrL6bDb rBazSVMVAXt+CKXH08dVV8yPZ4yrw15YHtFDcfu530wuiDNPMBxxh4oKak5L1Yqr0TjzTor7YPOx WElNXIv2rXJuXPTX/xZG48nBUEVc6Y+/yMSZ9fGBU6rDEf2dYG95DbqNZ46rDoeDcd4ffxNQhL+J M0P1cb0K+SgwcibEWVW1hLbuT0qQyUrCNQinVMdzepIwRU8xyD2QqH19hnkuNevb7RnjyuPMt53Z P4kzv6z2TQnDISw+EKZxfx0xozdWECff3+LkjZN/MqZ08itks49KTkGDivr5kYr6eaBofd3PNP0m SdFwqDnUPKXaXRQMh41BwxI5v3q7zTouMm6WFbOA0YwMtt1qQ45NZmBZFm0n+1lkRLi9YhQsbrMD 5PPI4VZImB+PbaxDJFIOuqHE+3MJDsmbTixiaJasxFDNiJHxzrg2Lm5KDiI0Lx6bGWcbQ9uH7Gve BIv/srqovT5SP/OS6riYiUFtZ6J/xdyp8axJVRchC4MA1M0NyeUuNwK5eKGKuaFmpGXdOoSRcjQ9 Ob9+7qw6ySZUFylHmWVc9frwviCOJNXrK+LuaNyB5o7rDwdFc0X6vJBMNjevD8Xvx1HkhNKwrAMm SD9tSKi5IoK3obOK+WPlihX0LpvBjRPqjcWJbZwZijdcNh80w9/MTT38H27W4/a/h7E6WB+0lNIh CSyhvm6+nMp8tFSAQs0bZxlT3WRMDfwqzU4JsiG4n01D64uqK+ZGKkDP1AtBELQX/fu2DYfjGVHZ sLm5Qg5xZj1GLymDvwwY6xhGMgGZCEYJ4xkXj001EJtqrAHeGJtZXpPKSlVAiYJ1iMfqymtq5KSS CxA39V+vnh4JNctOTf3jvqge3o+yfacNmTSluqJccidq8nHVZ3amBzsRx0GvJ5vSUae5oFMSSZZc EJl0fpIL5kr6yKBualKAQbXUyqNqqr7R6+vpwdfRdnxkfF1z8/hIaHxzXfPMtu6GyyIhPdK83W5v XlRRFzIkn5D/643B+PhNNXG9bi6NwiJLfhsPC957/sVyecaH5s5EDv5GR8IlwbAbXSfrQHOcujgl Z+B48L2Us2b9a8zYDo0UDI2X6qUNWiEY10ukmGIk06ohB5fjFRX1RgD5wDGXB6WkiJr+FfMuSBEo GMYrDYaReu/8VC46CYelDG1si7HLkIg3nF+dTIfYZcFWFiuIYu3qZMm+nhL/NFnS0FPS27wugrVK l8dsgyf+EU9Dn/fyc7M74gmVSmWO0eFvQn1831TM8fuSuBkUM5bbO65aBLmsghgPChmzRrEllMXT okZDSRNoyWY9EjoYievRuDquel+wrCaku6EgqZcZUj1KNtUPRg6QVKLMp8epLE4BKVYMShVkhNJP K0Fhb8NQRXNdivtOnB+qytr1c3vlKDkLCK6cJMigRyC3wSQ93J6InOprktuTG1xc7T9eChXWxqDY xJq4U252cefXRoDJBcdVh6CGILbnG5FQRWiuXPV4qK7c0Ac1QVnek93W/VFdudR/1WA0VAmm+Btc DrKlZCJFhklTq3tiU6pvCF5fcxpuxYZMamMW7KTSJ9NG3Y1trDx7D+7ZxIxLUTx1SChUMa8cL0Ri 2hBkDA4jNn0IeFOyfnWkRu4kE+qbQ5L56zEtA6NgVnNNAfj1gmroS7hqwvFYTbA3OqumZhT6uVD2 gyao3lyDHuanegA2sgq6UKl6yCRoqvyqaijbhnIwerkUYUx3H6Rqn5yxnEhN70gx4hvmpafGfBHG XDMY5RcnewGvNqCLmuZm2ecF1RGweXNzsBnzSKXh4embEUtltDHZBBOvaKOGKrQFihj2QUUkHJGU rynHqy4B3Xu0FO4e/zmFL+0dN1rOwGgvNShc979E4Zn/CoUv+5cofHnvSE+icD3GfLmk8KxTUzjO 8/8JjU8kaSxJ0tgpSDr7JJLO+ecknds7UIxqHoY31yDp/P8lkl7xr5D0yn+JpAt6R3oSSa/CmBdI ki48NUn/XzDtopMovPifU/jq3nFjkEsw2qsNCi/9X6Lwsn+Fwtf8SxS+tnekJ1H4Ooz5Wknh5f// KHz9CRTGxSYxjjO1Av8V8CtKIXtJdbE1qouGAz8BOAiYB/gBsAHwIWA74B7U/1g7zPYqVwKuYHOU DLZQtcBrhFM//yurUroQP8baeVUSTNexduVLo047Pg1oV3zsXp5gFUo/5tEGM7vyBXxLDAMi4yho x+DktxchVpPKMbL7BBxXNgoucTTceZuxX1iZDVc+DubElx7/yiO/HmHM/X+s6kENL/MxP/xiafCC wD+BJ5MFEWaxbIT4BABjZSzM8lgEWD4h/BvOzmVNpFElfcTv4d+L25WYskm9RONaTDtsmm52mu+2 jLV8Yh1oPWyrtF1la7Ln29scEx23Occ673Yx1+f6WvSE0ym8M/iH+ZqYb7fGFSah4PW3XjeCYUPD 7rC7PwICQY7HRMPxBpX9xGJKA1qCgpu5ptj53Wjvepa9SFylAr2DFXQOG+otDvs3i+u4tnkz6r2C yntxOhcsGHPANBHPoA+VPTN0aJQy0/XJnUabouIi/yvHjhkuTGIvJd4Ti+HbEmxaLLpcUIDn83Vc jBfTBRe/JHKBNtyuEVJ7Gcn7+hDiOoMBtVvlczGPWRye9pISlj569LCh69XJ0fU37KcZl9bWzqit ZbVeKqKXuH9b11eJ97RvfsCicbam+w/KLfBG2LAuj8WuHaDQQCsdsZOw0gYrrTPTIJ1q9A36Xfrj +lFdzbANsvF5NsqgQfJ6bx7xgCnfhGA2ApUC6myVz/GSwJ+N7A6yukh1k024cOnloSxV36aZ7NtY hrPZ4mkWMb9lJfeJFXLUBlH0Tja6czSImRw0Bi4fVru49x+Sixerecyts6JCGQ4IufUwgK/5LPEZ ZR89StmJTzupNPFq4rX+uDu8GDeATySmJx5O3JO4cDNfya/q2tTVLNdSfjOlTMTcLaw6NnSDcpey RzmgKIpuc1cKhaYo21TNp2qqZjLRNmZ+zLRRocdCYCHclXKOI/Aub3ol5zar21NaEK1d3FnYJVe1 cPSfQPtoVN/PoovDxWG3WtzfHfbTcBqYeI/+TAM3K7dN3Lrix0fhMiX4vpmShzFksD/F7hvpIqsn 08N/9ND3Djqm0ys6NXt/7f3A+6VXGWCl761kNXsDldeZ6AzzJDM3h9IyK83egV4+xEx2f5afj+Dj ObdyMgfSA/y9wBcBblXpd+qPKl+n0tk6XaiTfZvLlmvjNptlm1tzmijtLpauNbvTNsRszOXOdXOX +w33Ifdf3IpDBN1v4zKYMkQmwyLJRTGCxen6/szJnXrnfmO+paVd71xaK1cNyyRXCg8WLVqLP2QY S1ZUPKK/dCjlR/JMxSOKCuE70lykmcL+J6aTtviDLWvu/n37ywePr376nM7+/KanD3TOan955S3X /qr2oz2N/37HmAO7nzbk7yD4tQD0yiF/LKe/na7xUGnOhJyaHGEK0pE0suilOj+q/4AlwjkklpkW rHwsvS2dz3de72x2igp1mjpLFXsyKKOt+2DMandXKn6fn1v8sL1jN3r8lfNNlOUc4rzEeaVTsStZ yhBF2E2XmK40iRJHpYNjXbLM/vTKx30kcrXztBmacGlvaNympZvvscV82bZ7hg71bHO7tvlMbNtQ IhLbsjMK0len35ouHBsDMbQNuC1as8UdSFfOyyRcPuiM17FF7DYIfkHt4rdq00o7CwoKop21bHTX O7WdCDqjzJCP0qRkLJ6RoiyIjCWRFJaUlmQfWRwoKhxRrIcjxSND7uFhg9oQD1Vx+5RI3sG3rr95 e2LSuRV0d+Jvm1ufeZg6Eq/S7MTXf91ga5v68E1U0kgU/vSCp85IPJ74aeEFiVd//2fQnTN4FJU1 0E1W7AqrY1MHO350cEe6J1BpEnMEXy+OCG4WNNFGJtsA20ibMCHgjyjksNEU2y1C8QmhWDT73beB IlCtGrNvUmiTWcNxxcItLl2QKKjV36ktfL2zEFI0GiJV21mK+a5X9agCYSIp+AxBtBbauZiK3EX+ iJvCbiG6ZvO793R0dF2Fz74e3CJuO77ygUQtL+e3Q75+AL9kYdwB9lmsVKg0R6WR/Gx+IReDzPPM PE2n3TqVeKnFS07TLSZus/gyfNyspWv8WV+7jy/3bfBxb1v3F7HpdldlvnuEm2vugDvfLexW8zaX SzjvsmlsG8Uc7kostT/DebPNbreR1uyJVXnI5cn1LPQIl+dWzxueQ56/eFSHSPe8zRm+NGgg4RHy u5gd2XmVEu+y65Vp9BYELRrtFbXFxsJ7SksLCqAcu96JQj+COF0dYIVLJTVqQRUoypTYpfWsf54J SifsDjG/Twnn/XBH4+2PJoqHl/LOrn24Vokl/pRILNLiZzzVQpNN/OBTiesTP37x3nfGWm8AzVaq f8Y+HWJfx0otngzPII84FqKv0n5K43+10kWm+SZeaaESS6Wl2rLVovwui0Zk7cri+UQDHNc61juE ggWVIhUE1ay+TN9Fvvk+xTLPThfC423ymTabhCKpOhnlmhbQ8jWxKZsC2WSxkp2Z07cN5TFoWe40 69tcbnK4vducppxt5gw95nRX6rrNv1ENsmZbjKnkFnnqSh62GfsICCcp1tWuSzJF5X5iaCeppGuR ZZDNEBhsLCnhkdTDs5igmDx+H4sY+0u4MM2fHwmR1Fma3yfliupufuflY4mv3v4u8TWdSaG1Hb9v TKzj01vW3bDzyZtXt/Du3YnuA0cS71Aztp0b6YmSp6qOz35s32PX/Prj3Yb+wj2RstmQo/pYbLr5 GnOHWdSY7zI/bt5jVpQQuMis3GXSmGK2bohB9dpwh6syMzmF3bySMzWkDlVjqmIXNvXQCRoZs0sv wMwnY4aQnk647SkKaQmfRSMJm5Af37oMz76iiTZ3aWJX12/Lnz7+R968Z8/xPYkSjEuw7VjzW7Hm XlhgUcqIvb7I3+DnfFEOrYxuivLVoVtDfFMabQrSphBdH6Y6P12ec1MOL/bN8vGiCBUNoME2Oocu oU0kZlmo1nqD9WaruBrXjPzx8NEw36LQcjfNSF+Yzqsy6zLxbd58xmvzF+Tzifk0pd9l/XhFv8/6 8cHWUVau5NTnLM0RmilgesS0y9RhUi2ZjAbHrO5KZvXlKq6Mbaqp/zZXRmBTyExmn9WetSmXDTQ2 ZicUEfcM3GjP2+iJnWZfyYd4TrQvpCCBRYA63YjWJg0OT1pplGqHDU0ZHJIZjAcUPOmZUUv5xcOT 21dKo/Yr1vsn9zXJI2lOSnIKdroB9O77f+/Y/SlY5bzEkQ8/SPwnD7/RvHhB04rAtdMeWnfjg7N+ IfJbdj/2Zust725/KNH16y//tJOsf256tGbBFdMuuKnzkg2zV9+77orp106H/r0H69OMfc8Py/iP sexd2R3Z/Hq9WecHTDTWM8VzmUeMcJElHeLkkHKVhsjgTBqkkd8zzTPLI4TqVblFbet+LxZz6JWl Kq3LuTOHT1TmK3yd9U4rt4bQxGLPsA/Cx2oZ2zRngXk0TAyzLxeSx7a5KJe4EyrOlyF1VSwLYkjk tmXBdghshBy6IYcR90qed5Icdupd7YZ9JHUXjARDeYH80lpISR/DHoYnauxjyQ3M49Ygg8XDUzZe OE8Y4meYD9rR59e2vXHn3ucSx8n/5l8pkHg6cWjpmLsab9j+5MYbt1geHUOllLaHvB2fUjRxQyKe WJMYrUSf6njiuheOQAg5+xiG1yO405ZngAt3M0VXQorURlDE/Soljg3yZ1Qq96kuOekCwhd7FEMR xZBN9zGTIhpZzGxhjb3WfCmkrtPQ2qOBwEnSsheAj9vlI67r6ICYYT/ai+/88yH/drLFAq+Y6THR Jvi7UJYuQbxEJjCAb2IP+dIq31PIpgSVqDJJUQbxo5yP5KRwH++HrU3hFhpvmW5ZZxEOK5VaJ1g3 WB+37rEesB61mhSL2bImueVaueCrbVafzWaFBrAIs8WmcCtTTFbB8HmfEDbzas3WwGK6FsJJqkq7 TYtr+zQTQ3KokfhG0+wujbzCqV3Fb8UMYKlwvBUfeBu2YNIixE6UMuDdpRkFLB0beFqp/po7rfTS WrmD4xyyPt1AWPdekYrWshnyaFJb5A5bsJVjP4+Qey+Cu+kRUvYn5r6aWKq+8tN6ZfmPJcrOn55R pv40QdKRSzoqlYYe9bJfxoYWKwQFY3YPdJe4xRduWuZodDzraHcoY7Up2mWasGgZ2iBN6FI+3nWS Uy7yaKur0i9IFctEo/gO5km5MlXhtttHW56xvGE5ZFEsFua9HZ/tuW5QbdZVDFtNSOV24VcXcZ+c vjF/Y9qFOLhA67qlQpETxMaCnTkqdxXsy5hdCPYuC0cySBpnw/OjtJfuIPuXiX2Jw7XTnnvt/udu VF959o2vE9927eRfPXVv49VyjnO6jyilynSciwewH2P9BzlKHRMcRx2wo8gaHhzmP4bpC0FHbfS+ 7ajtB5t410QmafQOCverXG7aYOJf5dEVeSvyNuYJVaMn8mhZXmMeP9KP0vof6c/3wxCTO/SEUKTS TlnQ3OI4EY6dB8T7gmcogxTOvR5vnldYcrc+YyFQg7tdLTjJ2YTT3uLWM9JasgL5d/IAy7TkNGb6 DaLqNlelM9KoQoTm8oHq7N6j3X7YcJ2F7lJjQ+6AMoAW7oRmSJFMqgCQKpo8Osg4qCdPE4sX94cu gNbtFy4qHt57enD7igpHpqFEuAekdmf+3faH1uOHH5RW8PI9z/72V7uenuvIcI47v3nc2H97pb5y RfODj9/YuvemF+oePP+hpxO+x5UFIXJSBl9Rf7b8GonYwu4jYjfo7Wevx+ZZoAdL7eIASOPASTbL caXjHsdTjtcc2jJOjZzSOF3L13Nehk2P91NouPKWclgRR1W4fMpV7nOR4vK56l2bXQ+59ru+dZls jxE10hZ6mNrpO1I1ndbpZG6xSFYc4vBVWmwtmu670+XN9XKH130nC1i8zptEzOUt8J4H8RNp3nk8 IAyKpoycTrgeUmpVGoaS80AyyXwGNVNIHpeLdZY0Z1K0GunX+II/Jj6EfqPV9z46r2X381vX37o3 g8Z/TxYaGHl42Kcv7P6k4gl8BMMlXZRyfKfkhM+mK7a8lJMaoM8C9IOX3nfRWzi0mjJNvNn0gYk/ Z3vVxh+y7bTx3+k/6vxZvV3nzxG+o2klPjuNrGmj0rjtCmWjsg0aN4R9yGKmPeaj5h/MImDON48w 74IV5CObB39Pep7zfOVR7JusT1n5Izj6SsV4FgT4DjOJ1QFayFfzbi5caq5aoK5WD6mqQ7Uzl83d YtFZGvm3iIDLxhqd3rVaLMM5l6drP3Oj3llYCE4sLJS2UiGcJYbDAbqIYRdK0S+aioCWBiXBi+Fi cBwv1j1FhWnuIreAeejWwYhi1XV/2/9x98GXVnd03LUh8dnxh+597TPK+Z5cNHEzn/fD2+KM9Ynz EjftMHSX5LPPlQvhLwuwL2MXjtSJ9GBuZT9luML3g4m4it9vVIhpQnkYeonXiHmCj9Lod9qXGp+m fafxChNVmKaZZpmENxAJ8P8I/GeAjwqQx5nnLHS2Ol92fuLUII0432bmVKqWRpywYBR8FCvPzK20 +2iI7xLf177jPkUstVKBlWJKlVKnCJdCTtXT4nBwf4tZZy0Qdh7wOLyNbpsDAp1um8fTThBovQP6 TrIf9nQoPsl9YEs8MyDGKcs6KcIpyZZynNzTPW5T2BMuhGWqQ4A/7rj5m8TvyXaw/V3quiBKVSt2 dNXRoU8+jZTR6MQxKkt8kUicmbhhLH4ZUSDltAoG62n4Rs3Hzo6dNtREPnM/83CzsLXYnS0WfBkj WjQXv98et3P7UB/5PBprVKrEQbjNCmpf7yot/VNtR61U16WlcvTDhsLwx9YTKS7Csdmw+fO0bILH Jt5x99102eWrGqtmnk0u8cTx6eKJzWtobfieQbWrWuC+kbKRqFXKoTMyWITUWNE4P5VGqFSnEUEa YKf37bSLv8P/zsWzWW9n8WguPZn7XO6ruWKD/YCdN2pb4HyU1toScPUICw22jLJMtDyBnceR4eBH HZTvGOEY7xCjTJSJv1yyZZLtQQdlKoOVUYrQwnRAmtZqzsM5n+XgFwb5VvrcSi5rrrXAeqv1kBUC 4XEF9ewWp56p5W0x44tJ0ZKeFdTcjR54DffFdLyXhdbaYv09c3k/28/yAW1tSAjoA49W4YlCsji5 ylLNGHIhtXYyJpX14lrvyEBRyJ0UFGnApRUXuX2aSQvnkTtfnqQgMAfSnnyEJi/44Tefk3Zw100d xRNuTHzzIjetuavp7p+eTLQ8eT7NfPIwZf31eyrZvPL4l93fnbtBBOk36z94MbHN0NXt2P/PhE5y s02xWXtcNMhV6lru2uC6y6VeY1pn4u+YPjfxPzi+cvzkEI5QZnZlk3Ork5fp5+hP6WKpTleLNTC1 NJ/WTxPwfevKIqVBUSwqftMonFtU3cqsjRbhhp3ntczFDyMMz+rPe32P2gAtpP2y2DiHLyYYMkVu 43gAhjJ8Xe729ns+ufmx9rOnPHu/Fu06+/COluPf8teWz+nsGiP5B/OgZtgx0hbtH/PC6BTw8/4D C3O0dI3KV0jLUtqVylk/vayKdnQi5cLoCzRJ+pwhJBg9fM4/W6lg+mT79nYt+sPbqTbaXuiiIDsa G68opJgpU6cfdcpMox/TaLBnlIcPzhiVwUu99IB3u/cl78depTSTHsjcnvlS5seZimqiZaYtpodN 7abPTOoS49j/XuxSeNI0jcZr0+Ght9II63grz8dplweUfOUa5U5ll6Ies9ExjdxbLHr6nekmtzdT FapOLr+TORvhesTgXQ6Ym7Ba/cznmHWGydfoj2Vl+xvLenzohUkL9OdlKSoaPdqdVpR0IUvHcVL1 GKHkTuhxbI3SdYRFSutdKFgVcr0kam+/7ZMPztv00W33ddxx12Mdd255QjnrtcOHP3t86/Ev+bFf v981kB977oOugT374grIvvSdH4xtzXQOdvJ06Y012WkAHKvqAJWn44vLZDDQ1mTjZn2rzu0Oa7aV y+A0K06rHjOXQZ4ZDOlR8hThmMbJwbPh/LDasLeSquI3JNKbLt3qbrK7KCB0a8jKdXPIzHOVAoXD uZ6m6TAg7C0s4Fxr8ayVzvV5cK7/LNMnO9ehpw1tDRIZoowEiJOSadAKRsN/97FfdTTxJaX95S+U lvjib0kfewYVk8DFzLDEG4njib8nDm6G6Q7/WwJfNUr+TixT7gaNpO3wH7GtXgtVO6ifNI5ooF6t 82M6taW9ksabBGUEaF7gaICX2CvtfJeVpCtgolX014q1Ck14PK0ePsBH2T6CJ7zF+qiV/2CnPe4D bt5s+bWF97cUIzAVmypMwuHKdp3mEjZptsFgJ1ea8EOmHS53iy3Agt61ZvjtwF8Z5nk8HaKd0Tga xnySjaQpDzlL6TzQ6FKc5lJHFnjapGWFJ2lgSW2X5CWPX+eRvAEZJHUfNjVTe/vypEXQsLWZso4/ fG9imXrgtcOJT75P/C3x7OauH/ktTfit06odSbkV2aCRg10cyz3bRhPsNXb+uH2PnZsUstiF1QTV bdWtvEDABtoXS8uNVFoxHygK4ZBiYprPnSdqKMj56C7pQnyn011UZLg1FuMUkuR6+LQMPl92KCdc NOC5VZK/1Tb3h124DiF2L2yTazGWEFFs3UrbJhufjSuhNPo8SN8HaWTGhRktGWKilTKt863XW5ut P1rVc+yX2FfaxRAEmzDYUGaIF2WRyPJmRbIuz7ojS1Vdfhe31OD2xE6POw8433eK0MDsUOUBG+0K 0V0hstuft3OrtwVf8/hCPuHxBVrMjvQchek6b4EbcV+sWN7JqODt9HUOX8zlq/T5HNzcmBM7L4dy Ypl5lYzH+G38fvwMTvWJvJy5+AWnobJBhKjhEIRjDO7AXh8qjqc9lxaGGGALY5L7sbCGjoAE1Kp5 A5Le1OEFKbdPLknq+X25hPsHn0afrX/ppVunLbp3SfeBZy5eN+jhmS/eNuOBdZ9kjH627pKKWWOH zf/tLQ9mmB8a1lxz5sDylsW3thl6uqL7CP+VGoD9cmXMvpW/x7mJ0zEuT6UHYyPhYwjiEHMGbq4U h1VpsZhc3haPjrm7PDM83GWfYcf52+6xmmCVKbGAZx73Kz3b0+uTYdXoHVK0k6bZ64YTXV4PQKLz iw0rZ6RfeoblAQqnANudjzU1tVNW4nDbgJKLM566i6/a3O59b3PXI287muT9LC7usNemw1+isQdi C8yaHOr3RMcUMql0RD2m8u85tfBH+W/5u/wIV1/R3tO+0MTZ2oXaHE1Uwt+LO7SmpD8CTge+npgP dwCaYH6uyO1OgQ93kfqNynEBjc+YBS0S38BYw7fEBUVFGbgSSStKR1jERqcVjS4s/Af+BKwcxDNM RRZcc9IjiSvbqYwmtyUuUM46vkNM/ullYy52+F+yMBc7bYpNvN7WbOPDbd/a+Hca2bSgdoYmfALn 26A4QwgzyWl+TvSFiQaaaav5CzM3mela83rzMbMYqELB07uqJICAW+372Adw35co1cr3ioCnZgBP kkRJs8KnnWEttdbAR/M+/DM/WM2aPWAfYZ9uVywwHEvZUfYDUx+zkMkywMLTLCMtZ1sutOy2/NZy xGIywZnTpJl8mmay4jJyfdKZo9ht9r4kZaCmyWzTyGW3WoSmMq+djRYkr1YoZLHmagXytrzf4Eot lhOu1EwxM4XMMfMic4P5fvM+s1aFgJtVJWRbZGuw3W9Tqmxks/FF8BMU1CYXoqhof+3iqwvTX49G FxcWZmbor9cC47oZC5NWhF8N/+znSbl7TvD6GKpTCpdkxh4pS2lULBtup+UFdUQQjUsceOnPRO0f k/vxxH0dnyeOYw13iwkSfnpZYmMt8Z0DTpJnYf/9KXbrHtNRE79e+VLhuwVt0Z7V+BaVdhNdR1uJ z5c7xC4zzTc/YeZzlEeV3YqYg0saOJjHm66Bk/kdk2Y1mcxWq8Wm2RRcXhB87SqurjRbE1N9+GjA ir0YV78WbjJpCtgWt11TcK5abxY+M3ZuF4NzjdvAwWZ8SG3cycc88NsHhAObDKTIil/zYi/uvUMt KUnXO/QOOKGlE8SwzMDYuLGP7l+PhdinG+F6VXrNTsqC2/TnBxaO5HfjL4K9le5NLPwSNxO5+xJN dNeXiT2J/XwYdyQupX/rer/rKP0qMQWkw75sPN0l+K3DqZ5+yBS4l3RD9k/+XkN+qyG/1BjKilg5 G8/OZpVsAn7jMImdg18eVbEp7AI2Db/duRDfm1zELjY6lxoEhhweDb2x82rGVoydGj1n2eXz6mee ffXMq+pnybJkDRnbCngIsBOwH/AW4DDgW1RSAFgO6gcYDigHTAXUA5YC1gI2Ax4C7ATsB7wFOAz4 FhNXAD5AP8BwQDlgKqAesBSwFrAZ8BBgJ2B/d+rB+1lvnFioT/q0PunT+6RxcD2p/dA+6WF90oV9 0kV90sP7pI1fSJ0wvhF9ykf2SctbnxPnU9onDcfPSeXy/2s5sT7O4CelZ/ZJX94nDfqeVN9Y8hPG a/yK5oT0nD715/ZJ4z76pP6u7JNe0Ce9sE96UZ80HK4n9Wf8tu6E8YA3Tiq/pk/62j7p62T6vwB2 GTGPCmVuZHN0cmVhbQplbmRvYmoKMTMzIDAgb2JqCjExOTI2CmVuZG9iagoxMzQgMCBvYmoKKHdk aWZmIGRyYWZ0LWlldGYtZGltZS1vdmxpLTAwLnR4dCBkcmFmdC1pZXRmLWRpbWUtb3ZsaS0wMS50 eHQpCmVuZG9iagoxMzUgMCBvYmoKKE1hYyBPUyBYIDEwLjguNSBRdWFydHogUERGQ29udGV4dCkK ZW5kb2JqCjEzNiAwIG9iagooSm91bmkgS29yaG9uZW4pCmVuZG9iagoxMzcgMCBvYmoKKCkKZW5k b2JqCjEzOCAwIG9iagooU2FmYXJpKQplbmRvYmoKMTM5IDAgb2JqCihEOjIwMTMxMjAyMTIyMzA3 WjAwJzAwJykKZW5kb2JqCjE0MCAwIG9iagooKQplbmRvYmoKMTQxIDAgb2JqClsgKCkgXQplbmRv YmoKMSAwIG9iago8PCAvVGl0bGUgMTM0IDAgUiAvQXV0aG9yIDEzNiAwIFIgL1N1YmplY3QgMTM3 IDAgUiAvUHJvZHVjZXIgMTM1IDAgUiAvQ3JlYXRvcgoxMzggMCBSIC9DcmVhdGlvbkRhdGUgMTM5 IDAgUiAvTW9kRGF0ZSAxMzkgMCBSIC9LZXl3b3JkcyAxNDAgMCBSIC9BQVBMOktleXdvcmRzCjE0 MSAwIFIgPj4KZW5kb2JqCnhyZWYKMCAxNDIKMDAwMDAwMDAwMCA2NTUzNSBmIAowMDAwMjQ1NzMw IDAwMDAwIG4gCjAwMDAwMDY1MTkgMDAwMDAgbiAKMDAwMDE5MzkwMSAwMDAwMCBuIAowMDAwMDAw MDIyIDAwMDAwIG4gCjAwMDAwMDY0OTkgMDAwMDAgbiAKMDAwMDAwNjYyMyAwMDAwMCBuIAowMDAw MDEyMjY5IDAwMDAwIG4gCjAwMDAyMzI3MDYgMDAwMDAgbiAKMDAwMDAwOTQ5NyAwMDAwMCBuIAow MDAwMTk0NTM1IDAwMDAwIG4gCjAwMDAyMTUzMDEgMDAwMDAgbiAKMDAwMDAwNjc2MSAwMDAwMCBu IAowMDAwMDA5NDc2IDAwMDAwIG4gCjAwMDAwMDk1MzMgMDAwMDAgbiAKMDAwMDAxMjI0OCAwMDAw MCBuIAowMDAwMDE4NDI1IDAwMDAwIG4gCjAwMDAwMTIzMDUgMDAwMDAgbiAKMDAwMDAxODQwNCAw MDAwMCBuIAowMDAwMDE4NTMyIDAwMDAwIG4gCjAwMDAwMjMwNTIgMDAwMDAgbiAKMDAwMDAxODY3 MSAwMDAwMCBuIAowMDAwMDIzMDMxIDAwMDAwIG4gCjAwMDAwMjMxNTkgMDAwMDAgbiAKMDAwMDAy OTQwMiAwMDAwMCBuIAowMDAwMDIzMjk4IDAwMDAwIG4gCjAwMDAwMjkzODEgMDAwMDAgbiAKMDAw MDAyOTUwOSAwMDAwMCBuIAowMDAwMDM1NzcwIDAwMDAwIG4gCjAwMDAwMjk2NDggMDAwMDAgbiAK MDAwMDAzNTc0OSAwMDAwMCBuIAowMDAwMDM1ODc3IDAwMDAwIG4gCjAwMDAwNDMwNzEgMDAwMDAg biAKMDAwMDAzNjAxNiAwMDAwMCBuIAowMDAwMDQzMDUwIDAwMDAwIG4gCjAwMDAwNDMxNzggMDAw MDAgbiAKMDAwMDA1MDAzOSAwMDAwMCBuIAowMDAwMDQzMzE3IDAwMDAwIG4gCjAwMDAwNTAwMTgg MDAwMDAgbiAKMDAwMDA1MDE0NiAwMDAwMCBuIAowMDAwMDU4NDIzIDAwMDAwIG4gCjAwMDAwNTAy ODUgMDAwMDAgbiAKMDAwMDA1ODQwMiAwMDAwMCBuIAowMDAwMDU4NTMwIDAwMDAwIG4gCjAwMDAw NjY2MTggMDAwMDAgbiAKMDAwMDE5NDAyNSAwMDAwMCBuIAowMDAwMDU4NjY5IDAwMDAwIG4gCjAw MDAwNjY1OTcgMDAwMDAgbiAKMDAwMDA2NjcyNiAwMDAwMCBuIAowMDAwMDc0NTM4IDAwMDAwIG4g CjAwMDAwNjY4NjUgMDAwMDAgbiAKMDAwMDA3NDUxNyAwMDAwMCBuIAowMDAwMDc0NjQ2IDAwMDAw IG4gCjAwMDAwODEyMDYgMDAwMDAgbiAKMDAwMDA3NDc4NSAwMDAwMCBuIAowMDAwMDgxMTg1IDAw MDAwIG4gCjAwMDAwODEzMTQgMDAwMDAgbiAKMDAwMDA4NjU0NSAwMDAwMCBuIAowMDAwMDgxNDUz IDAwMDAwIG4gCjAwMDAwODY1MjQgMDAwMDAgbiAKMDAwMDA4NjY1MyAwMDAwMCBuIAowMDAwMDg5 MjIxIDAwMDAwIG4gCjAwMDAwODY3OTIgMDAwMDAgbiAKMDAwMDA4OTIwMCAwMDAwMCBuIAowMDAw MDg5MzI5IDAwMDAwIG4gCjAwMDAwOTM2MTIgMDAwMDAgbiAKMDAwMDA4OTQ2OCAwMDAwMCBuIAow MDAwMDkzNTkxIDAwMDAwIG4gCjAwMDAwOTM3MjAgMDAwMDAgbiAKMDAwMDA5OTM4MiAwMDAwMCBu IAowMDAwMDkzODU5IDAwMDAwIG4gCjAwMDAwOTkzNjEgMDAwMDAgbiAKMDAwMDA5OTQ5MCAwMDAw MCBuIAowMDAwMTA4MTA5IDAwMDAwIG4gCjAwMDAwOTk2MjkgMDAwMDAgbiAKMDAwMDEwODA4OCAw MDAwMCBuIAowMDAwMTA4MjE3IDAwMDAwIG4gCjAwMDAxMTcwMDYgMDAwMDAgbiAKMDAwMDE5NDE1 MSAwMDAwMCBuIAowMDAwMTA4MzU2IDAwMDAwIG4gCjAwMDAxMTY5ODUgMDAwMDAgbiAKMDAwMDEx NzExNCAwMDAwMCBuIAowMDAwMTI1NDg3IDAwMDAwIG4gCjAwMDAxMTcyNTMgMDAwMDAgbiAKMDAw MDEyNTQ2NiAwMDAwMCBuIAowMDAwMTI1NTk1IDAwMDAwIG4gCjAwMDAxMzI5MjUgMDAwMDAgbiAK MDAwMDEyNTczNCAwMDAwMCBuIAowMDAwMTMyOTA0IDAwMDAwIG4gCjAwMDAxMzMwMzMgMDAwMDAg biAKMDAwMDEzOTY3MiAwMDAwMCBuIAowMDAwMTMzMTcyIDAwMDAwIG4gCjAwMDAxMzk2NTEgMDAw MDAgbiAKMDAwMDEzOTc4MCAwMDAwMCBuIAowMDAwMTQ4NDY0IDAwMDAwIG4gCjAwMDAxMzk5MTkg MDAwMDAgbiAKMDAwMDE0ODQ0MyAwMDAwMCBuIAowMDAwMTQ4NTcyIDAwMDAwIG4gCjAwMDAxNTY0 OTEgMDAwMDAgbiAKMDAwMDE0ODcxMSAwMDAwMCBuIAowMDAwMTU2NDY5IDAwMDAwIG4gCjAwMDAx NTY2MDAgMDAwMDAgbiAKMDAwMDE2MjczMSAwMDAwMCBuIAowMDAwMTU2NzQwIDAwMDAwIG4gCjAw MDAxNjI3MDkgMDAwMDAgbiAKMDAwMDE2Mjg0MiAwMDAwMCBuIAowMDAwMTY5MTE4IDAwMDAwIG4g CjAwMDAxNjI5ODIgMDAwMDAgbiAKMDAwMDE2OTA5NiAwMDAwMCBuIAowMDAwMTY5MjI5IDAwMDAw IG4gCjAwMDAxNzg1MTMgMDAwMDAgbiAKMDAwMDE5NDI3OSAwMDAwMCBuIAowMDAwMTY5MzY5IDAw MDAwIG4gCjAwMDAxNzg0OTEgMDAwMDAgbiAKMDAwMDE3ODYyNSAwMDAwMCBuIAowMDAwMTg4MDY3 IDAwMDAwIG4gCjAwMDAxNzg3NjUgMDAwMDAgbiAKMDAwMDE4ODA0NSAwMDAwMCBuIAowMDAwMTg4 MTc5IDAwMDAwIG4gCjAwMDAxOTM2NDkgMDAwMDAgbiAKMDAwMDE4ODMxOSAwMDAwMCBuIAowMDAw MTkzNjI3IDAwMDAwIG4gCjAwMDAxOTM3NjEgMDAwMDAgbiAKMDAwMDE5NDM3NCAwMDAwMCBuIAow MDAwMTk0NDgyIDAwMDAwIG4gCjAwMDAxOTUwNzQgMDAwMDAgbiAKMDAwMDE5NTI5NyAwMDAwMCBu IAowMDAwMjE1Mjc4IDAwMDAwIG4gCjAwMDAyMTU4MzMgMDAwMDAgbiAKMDAwMDIxNjA2MSAwMDAw MCBuIAowMDAwMjMyNjgzIDAwMDAwIG4gCjAwMDAyMzMxMjkgMDAwMDAgbiAKMDAwMDIzMzM4NyAw MDAwMCBuIAowMDAwMjQ1NDA2IDAwMDAwIG4gCjAwMDAyNDU0MjkgMDAwMDAgbiAKMDAwMDI0NTUx MCAwMDAwMCBuIAowMDAwMjQ1NTYzIDAwMDAwIG4gCjAwMDAyNDU1OTcgMDAwMDAgbiAKMDAwMDI0 NTYxNyAwMDAwMCBuIAowMDAwMjQ1NjQzIDAwMDAwIG4gCjAwMDAyNDU2ODYgMDAwMDAgbiAKMDAw MDI0NTcwNiAwMDAwMCBuIAp0cmFpbGVyCjw8IC9TaXplIDE0MiAvUm9vdCAxMjQgMCBSIC9JbmZv IDEgMCBSIC9JRCBbIDxmZDJkMDFmYjk0MmI2ZjIwNzQxMWQ1NzcyNWJhZTQyOD4KPGZkMmQwMWZi OTQyYjZmMjA3NDExZDU3NzI1YmFlNDI4PiBdID4+CnN0YXJ0eHJlZgoyNDU5MTQKJSVFT0YK --Apple-Mail=_BBD37F06-C332-4C95-90E9-50F0D84297CC-- From jouni.nospam@gmail.com Mon Dec 2 04:27:42 2013 Return-Path: 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 06D0D1AE415 for ; Mon, 2 Dec 2013 04:27:42 -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 HE5wWVyX0TuD for ; Mon, 2 Dec 2013 04:27:40 -0800 (PST) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) by ietfa.amsl.com (Postfix) with ESMTP id 46F2A1AE35B for ; Mon, 2 Dec 2013 04:27:40 -0800 (PST) Received: by mail-lb0-f181.google.com with SMTP id q8so8178713lbi.26 for ; Mon, 02 Dec 2013 04:27:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=gWyhmOircdFWizaGms0mLUZb7vWbsmEwvqGdJSdk0IY=; b=cil+FtFxyEBmeN9ACHEhVAD0A2hibUZS+zl7y0lqkPKOqG3PwQWNjYaUzc0p8bcx7n KLPOPEncqCG/abh/wiprkysiPd6BCGELt/dXJYhBeQp1IzlPiVl6FgwPqBJWsgyjcvJQ yUqegz93RbOvcWXDsvqbY8AZnCHV4vt/g7CDkjZLsQ0PxxaytstdmFIxgAt4xY9WvQSO dHgeEVtxvShjI/Ua6Nie0yvgJ5/Zl5kO7+SNUuSVSu8n+AZM8PglHx2etvED8RcbXFcM VbK0h0n5SF8dXeeo3a3bLUxrJtBthu7dGCGHOdJCB+Qo5Y+1CPbZuAY8E5aI5F3C/Y2W BEgA== X-Received: by 10.112.180.37 with SMTP id dl5mr264488lbc.58.1385987257336; Mon, 02 Dec 2013 04:27:37 -0800 (PST) Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id bo10sm31887376lbb.16.2013.12.02.04.27.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 02 Dec 2013 04:27:36 -0800 (PST) From: Jouni Korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: Date: Mon, 2 Dec 2013 14:27:35 +0200 To: "dime@ietf.org list" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Subject: [Dime] draft-ietf-dime-ovli-01 comment #3 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 12:27:42 -0000 I brought back the initial features flag for the default abatement algorithm. It was pointed out to me that just the absence of the OC-Feature-Vector AVP is not adequate enough in a case multiple supported abatement algorithms get announced and something specific is needed to be said about the default algorithm (like the other end specifically does not want to use it). - Jouni From maria.cruz.bartolome@ericsson.com Mon Dec 2 04:51:38 2013 Return-Path: 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 4A3B21ADF9C for ; Mon, 2 Dec 2013 04:51:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=no 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 8vqHPsAZviLQ for ; Mon, 2 Dec 2013 04:51:37 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id B7BBF1AE3E7 for ; Mon, 2 Dec 2013 04:51:30 -0800 (PST) X-AuditID: c1b4fb25-b7eff8e000000eda-7a-529c824f961b Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 30.9C.03802.F428C925; Mon, 2 Dec 2013 13:51:27 +0100 (CET) Received: from ESESSMB101.ericsson.se ([169.254.1.118]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.02.0347.000; Mon, 2 Dec 2013 13:51:25 +0100 From: Maria Cruz Bartolome To: "dime@ietf.org list" Thread-Topic: [Dime] draft-ietf-dime-ovli-01 comment #3 Thread-Index: AQHO71nmF+sITgglgU2txo3eoq0fP5pA25dA Date: Mon, 2 Dec 2013 12:51:24 +0000 Message-ID: <087A34937E64E74E848732CFF8354B920972B6E9@ESESSMB101.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGLMWRmVeSWpSXmKPExsUyM+Jvra5/05wgg8sP1S3m9q5gc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxuyN71gK3rNVbFtwn6mB8TJrFyMnh4SAicSWaQ9ZIGwxiQv3 1rN1MXJxCAkcYpTYvG0jlLOYUeLEnC5GkCo2ATuJS6dfMHUxcnCICGhIrDiRCRIWFjCTOPXz BzOILSJgLvFt3wV2CNtI4vbffjCbRUBFYtGENWA1vAK+EssObgaLCwnYSMx7/p0NxOYUsJV4 cbwb7CBGoIO+n1rDBGIzC4hL3HoynwniUAGJJXvOM0PYohIvH/+DekZRov1pAyNEvY7Egt2f 2CBsbYllC19D7RWUODnzCcsERtFZSMbOQtIyC0nLLCQtCxhZVjGy5yZm5qSXG21iBIb9wS2/ VXcw3jkncohRmoNFSZz3w1vnICGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2MbNY6Ff7fpA6t Y1djVIvgabGZPeP7w1X6d3Yu9erMu7hk7eV7G378Zbhgvjr+jdtc+9oMLuMPRm1Pd2htqX+u eFhYeM3t5XmOhzYwVwYsu3lnXRefdJ3MwxsC+hG2OxI5mBKObFqk/3KvtsReAeGn0xJb5+9h CeTQMHM7o/6Lcafgzjdr24uYlFiKMxINtZiLihMBhsMIskkCAAA= Subject: Re: [Dime] draft-ietf-dime-ovli-01 comment #3 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 12:51:38 -0000 Hello Jouni, What do you mean? Are you proposing to change something from 00 to 01? What= exactly? Best regards /MCruz -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen Sent: lunes, 02 de diciembre de 2013 13:28 To: dime@ietf.org list Subject: [Dime] draft-ietf-dime-ovli-01 comment #3 I brought back the initial features flag for the default abatement algorith= m. It was pointed out to me that just the absence of the OC-Feature-Vector = AVP is not adequate enough in a case multiple supported abatement algorithm= s get announced and something specific is needed to be said about the defau= lt algorithm (like the other end specifically does not want to use it). - Jouni _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From jouni.nospam@gmail.com Mon Dec 2 05:01:36 2013 Return-Path: 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 C44901ADF78 for ; Mon, 2 Dec 2013 05:01:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.3 X-Spam-Level: X-Spam-Status: No, score=0.3 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, MANGLED_TOOL=2.3, SPF_PASS=-0.001] autolearn=no 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 T8q63GSyOO4O for ; Mon, 2 Dec 2013 05:01:35 -0800 (PST) Received: from mail-bk0-x234.google.com (mail-bk0-x234.google.com [IPv6:2a00:1450:4008:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id DE01F1AE48A for ; Mon, 2 Dec 2013 05:01:11 -0800 (PST) Received: by mail-bk0-f52.google.com with SMTP id u14so5330656bkz.39 for ; Mon, 02 Dec 2013 05:01:09 -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=P2mqDaAcBhvCMYOcavNgPUpn4AyCWwmj+dFEcITNvI0=; b=ARwZ7Rua054RsJxxEICeiIKi1lpKehtP4iDiTwir6l2BRhAkCDs3w94SQJFFcTj+Bg 3d/Az6IRCHr9Z26dpRUvhMViVSPhx9rZBmp0VoQC6pMTivivhLOVZV93dqMSBQa0YuDz MGIRXArYTkBNAlslXRe28uW9TdePu1WB+nCVgwOaYiHBE9bYzd+GptQTbQrfB3OInLXy slgUStKebQx0Yp+jcLlJEIt3dNDPufVBYShoXnsBFqG2XKtcXOn7pXxRK1DKsaUWH35V XS+d5fwmkLOt3PyYAa3G1r9Mlats13BJIZnMMlBzkIhHEDNAfvgmZzWY2V+5aFeDkow3 sxXQ== X-Received: by 10.204.173.139 with SMTP id p11mr461930bkz.67.1385989268940; Mon, 02 Dec 2013 05:01:08 -0800 (PST) Received: from ?IPv6:2001:1bc8:101:f101:cc46:9d76:ef6:8824? ([2001:1bc8:101:f101:cc46:9d76:ef6:8824]) by mx.google.com with ESMTPSA id xm9sm18513831bkb.1.2013.12.02.05.01.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 02 Dec 2013 05:01:05 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <087A34937E64E74E848732CFF8354B920972B6E9@ESESSMB101.ericsson.se> Date: Mon, 2 Dec 2013 15:01:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <087A34937E64E74E848732CFF8354B920972B6E9@ESESSMB101.ericsson.se> To: Maria Cruz Bartolome X-Mailer: Apple Mail (2.1510) Cc: "dime@ietf.org list" Subject: Re: [Dime] draft-ietf-dime-ovli-01 comment #3 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 13:01:36 -0000 Hi, See the pages 9 and 10 (Section 4.2) in the diff pdf I sent recently. - Jouni On Dec 2, 2013, at 2:51 PM, Maria Cruz Bartolome = wrote: > Hello Jouni, >=20 > What do you mean? Are you proposing to change something from 00 to 01? = What exactly? > Best regards > /MCruz >=20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen > Sent: lunes, 02 de diciembre de 2013 13:28 > To: dime@ietf.org list > Subject: [Dime] draft-ietf-dime-ovli-01 comment #3 >=20 >=20 > I brought back the initial features flag for the default abatement = algorithm. It was pointed out to me that just the absence of the = OC-Feature-Vector AVP is not adequate enough in a case multiple = supported abatement algorithms get announced and something specific is = needed to be said about the default algorithm (like the other end = specifically does not want to use it). >=20 > - Jouni >=20 >=20 > _______________________________________________ > 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 From nsalot@cisco.com Mon Dec 2 05:58:26 2013 Return-Path: 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 5943F1AE015 for ; Mon, 2 Dec 2013 05:58:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.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 JiSYWmonc312 for ; Mon, 2 Dec 2013 05:58:18 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 300971AE49C for ; Mon, 2 Dec 2013 05:58:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=43597; q=dns/txt; s=iport; t=1385992696; x=1387202296; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Uk2ZhU+Z68UkfBL38j0nF9Sb6ug8uLudMYQFxUXYov8=; b=kkXTIfIcBwJqc5SEVqfcYivsKghGZlZwdQlB917cVOf4eQKL4CvMOlXY IzxG1XQaqnEyJ7qTrYsxC1hD2QbFq08sLNYIH/1G5KeAG9ALfefqosvQN yhqSDEuClmeAfWqF/D7h+rVdKH3VUkjBtPocLKGUKYecU7W85++1DiZdt E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAKCRnFKtJXG+/2dsb2JhbABZgkNEOIFPt2WBJBZ0giUBAQEDAQEBARcBEjoHBgUFBwQCAQgRAQMBAQsWAQYHJwsUAwYIAgQOBQgTh2AGDb9vEwSOJhACAR4tBAcGgxqBEwOJCqEdgyk X-IronPort-AV: E=Sophos;i="4.93,811,1378857600"; d="scan'208,217";a="288717849" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-2.cisco.com with ESMTP; 02 Dec 2013 13:58:14 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id rB2DwEhF026251 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 2 Dec 2013 13:58:14 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.250]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Mon, 2 Dec 2013 07:58:14 -0600 From: "Nirav Salot (nsalot)" To: "Wiehe, Ulrich (NSN - DE/Munich)" Thread-Topic: [Dime] DOIC: Self-Contained OLRs Thread-Index: AQHO67/s/vGpiVuf2UayvwQoJbzwfZo6EVYAgACzUoCAAAFygIAAEJwAgAGNqACAAB+RgP//2REwgAPJ1wCAAEThgIAAvIuA//+diaCAAHKzgP//vRZk Date: Mon, 2 Dec 2013 13:58:13 +0000 Message-ID: References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D90006681519BC90@DEMUMBX014.nsn-intra.net> <6390_1385631044_52970D44_6390_18593_1_6B7134B31289DC4FAF731D844122B36E30748E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BD19@DEMUMBX014.nsn-intra.net> <17872_1385720008_529868C8_17872_2613_1_6B7134B31289DC4FAF731D844122B36E3096B8@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BF1B@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681519BFAE@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681519C017@DEMUMBX014.nsn-intra.net> , <5BCBA1FC2B7F0B4C9D935572D90006681519C087@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681519C087@DEMUMBX014.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_A9CA33BB78081F478946E4F34BF9AAA014D2266Bxmbrcdx10ciscoc_" MIME-Version: 1.0 Cc: Ben Campbell , "dime@ietf.org list" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 13:58:26 -0000 --_000_A9CA33BB78081F478946E4F34BF9AAA014D2266Bxmbrcdx10ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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 "optio= nal" optimization at this stage. Either it is respected by all the nodes su= pporting the solution or we drop that optimization. Regards, Nirav. On Dec 2, 2013 5:27 PM, "Wiehe, Ulrich (NSN - DE/Munich)" 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 answe= r 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 OL= R 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 Joun= i 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 thi= s OLR applicable for realm or host? I am trying to understand which is out-of-context OLR here: realm-type or h= ost-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 Joun= i 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 contain= ing destination-host), it gets back answer containing origin-host (set by t= he 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 me= ssage perspective. The client sends a request of type x (destination host = =3Dx1, destination realm =3Dx2 application=3D x3) and gets back an OLR in t= he answer which says "please throttle request of the type you just sent". T= he client either remembers, or deduces from info received in the answer, wh= at the type x was. E.g. it deduces from the value of Origin Realm in the an= swer the value of Destination Realm in the request; it deduces from the val= ue 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 solut= ion - to define the response message's context based on the request message= . And hence if the request message was sent to destination-realm, the corre= sponding response message can only contain realm-type OLR. But this requires the client to remember the context of the request while p= rocessing the response and hence it was considered as introducing unnecessa= ry 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-co= ntext [Wiehe, Ulrich (NSN - DE/Munich)] That was not my proposal. My propos= al 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-typ= e OLR only when the destination-realm based request is rejected. So basical= ly, realm-type OLR is never included in a response message which contains o= rigin-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-ty= pe 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/Mun= ich)] 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 a= gent wants to offer this optimization), and may be processed by the reactin= g 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 info= rmation 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 ign= ored. [Wiehe, Ulrich (NSN - DE/Munich)] Not the Report-Type AVP is the optimizati= on 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 O= LR is out-of-context. Similary, when the client sends a request containing destination host and g= ets 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 respons= es 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 Joun= i 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 i= n the answer and additional OLRs (not created by the reporting endpoint) ma= y just be present as an optional optimization i.e. optionally inserted by t= he 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 subs= equent request towards the origin-host of the answer containing the OLR. Us= ing 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=E9= : jeudi 28 novembre 2013 11:30 =C0 : MORAND Lionel IMT/OLN; ext Jouni Korh= onen; Ben Campbell Cc : dime@ietf.org list Objet : RE: [Dime] DOIC: Self-Co= ntained 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 act= ual OLR created by the reporting end point and which OLR is an additional O= LR created by another node. We have two cases: a) The request sent by the client (reacting end point) contains no Destinat= ion Host. The agent (reporting node) (after forwarding the request to the s= elected server and receiving the answer) returns a realm-type OLR as the ac= tual 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 Destinat= ion 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 stat= us. It could be provided an agent inserting this info in answers received f= rom a server behind but also from a server that would know this info by som= e internal magic. But in any case, if we assume that the client will received a successful an= swer from the server for an initial request with only Dest-Realm AVP, it sh= ould be possible to have both report types in the answer: one for the serve= r itself, one for the realm for new request sent to the realm with only Des= t-Realm AVP. Lionel -----Message d'origine----- De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN -= DE/Munich) Envoy=E9 : jeudi 28 novembre 2013 10:26 =C0 : ext Jouni Korhone= n; Ben Campbell Cc : dime@ietf.org list Objet : Re: [Dime] DOIC: Self-Conta= ined OLRs Hi, I don't see how the possibility to send more than one OLR in an answer is a= ligned with the "endpoint principle". If the ReportType is "realm" this ind= icates 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 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 endpoin= ts, the more it makes sense to me to keep the ReportType in the OC-OLR. Eve= n if the baseline does not have agent overload etc, the ReportType fits wel= l to the "endpoint principle" we have in the draft. It indeed gives more to= ols to make a host vs. realm base decision on the reacting node and is plai= n 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 Diam= eter 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 fr= om other context. In most cases, that context is in the Diameter answer tha= t carries the OLR. For example, the OLR implicitly refers to the applicatio= n 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 meani= ng in the context of the enclosing answer. If you moved an OLR from one ans= wer to another, it's meaning may change completely. > > I think this approach is a mistake. I would greatly prefer that we explic= itly include such values in the OLR itself, for multiple reasons: > > 1) It's more complex to interpret implicit, contextual values than explic= it values. The consumer cannot simply look at the OLR; it must look in vari= ous other AVPs to find all the information it needs. For example, I think a= common software design for overload control processing to be separated fro= m application processing. The consumer cannot simply hand the OLR to that m= odule 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 "con= text" avps that must be interpreted can grow large. This approach is error = prone, and will likely encourage brittle, hard-to-maintain code. Self-conta= ined 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 r= eporting node realizes that it is overloade, it has to wait for the right a= nswer that contains the right context before it can send the OLR. This is p= articularly troublesome for agents, since they will typically have to inser= t OLRs into answers created by other nodes. > > If the reporting node screws this up, the meaning of the OLR may change s= ignificantly. So again, implicit meaning gives us error prone implementatio= ns. 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 O= C standards. For example, lets say we find a good reason to allow OLRs to b= e sent out of band, or be sent in a dedicated Diameter application. If over= load 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 transpo= rted, this won't work. We would have to create a new or significantly modif= ied 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 im= plementations, less brittle deployments, and more flexibility for future ev= olution 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 confiden= tielles 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. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation 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 dele= te 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 confiden= tielles 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. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation 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 dele= te 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 --_000_A9CA33BB78081F478946E4F34BF9AAA014D2266Bxmbrcdx10ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Ulrich,

Wouldn't that make reacting node's implementation more compl= ex 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 d= efine an "optional" optimization at this stage. Either it is resp= ected by all the nodes supporting the solution or we drop that optimization= .

Regards,
Nirav.

On Dec 2, 2013 5:27 PM, "Wiehe, Ulrich (NSN - D= E/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 answe= r 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 OL= R 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 Joun= i 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 thi= s OLR applicable for realm or host?
I am trying to understand which is out-of-context OLR here: realm-type or h= ost-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 Joun= i 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 contain= ing destination-host), it gets back answer containing origin-host (set by t= he 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 me= ssage perspective. The client sends a request of type x (destination host = =3Dx1, destination realm =3Dx2 application=3D x3) and gets back an OLR in t= he answer which says "please throttle request of the type you just sent". The client either remembers, or deduces f= rom 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 t= he request; it deduces from the value of Report-Type in the answer whether Destination Host was present in the r= equest...

On the other hand, we discussed - as part of Maria Cruz's alternative solut= ion - to define the response message's context based on the request message= . And hence if the request message was sent to destination-realm, the corre= sponding response message can only contain realm-type OLR.
But this requires the client to remember the context of the request while p= rocessing the response and hence it was considered as introducing unnecessa= ry 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-co= ntext [Wiehe, Ulrich (NSN - DE/Munich)] That was not my proposal. My propos= al 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-typ= e OLR only when the destination-realm based request is rejected. So basical= ly, realm-type OLR is never included in a response message which contains o= rigin-host AVP. (And I am ready to reconsider the same if we want to ensure the context of the response me= ssage 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 ho= st-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/Mun= ich)] 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 optimizat= ion), 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 info= rmation 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 -contex= t 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 ign= ored.
[Wiehe, Ulrich (NSN - DE/Munich)] Not the Report-Type AVP is the optimizati= on 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 O= LR is out-of-context.
Similary, when the client sends a request containing destination host and g= ets 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 respons= es 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 Joun= i 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@ie= tf.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 i= n the answer and additional OLRs (not created by the reporting endpoint) ma= y just be present as an optional optimization i.e. optionally inserted by the reporting endpoint and option= ally 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 applie= s for subsequent request towards the origin-host of the answer containing t= he OLR. Using the report Type "Realm report", you know that the O= LR 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=E9 : jeudi 28 novembre = 2013 11:30 =C0 : MORAND Lionel IMT/OLN; ext Jouni Korhonen; Ben Campbe= ll Cc : dime@ietf.org list Objet : RE: [Dime] DOIC: Self-Containe= d 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 act= ual OLR created by the reporting end point and which OLR is an additional O= LR created by another node.

We have two cases:
a) The request sent by the client (reacting end point) contains no Destinat= ion Host. The agent (reporting node) (after forwarding the request to the s= elected server and receiving the answer) returns a realm-type OLR as the ac= tual reporting-node-created OLR and optionally in addition a host-type OLR as learned from the selected se= rver.  The client may ignore the additional OLR.
b) The request sent by the client (reacting endpoint) contains the Destinat= ion 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 stat= us. It could be provided an agent inserting this info in answers received f= rom a server behind but also from a server that would know this info by som= e internal magic.
But in any case, if we assume that the client will received a successful an= swer from the server for an initial request with only Dest-Realm AVP, it sh= ould be possible to have both report types in the answer: one for the serve= r 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-bounce= s@ietf.org] De la part de Wiehe, Ulrich (NSN - DE/Munich) Envoy=E9 = ;: jeudi 28 novembre 2013 10:26 =C0 : 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 a= ligned 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 p= oint that the reporting end point is a server. How can the reporting end po= int be both agent and server?

Ulrich

-----Original Message-----
From: DiME [mailto:dime-bounces@ie= tf.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 endpoin= ts, the more it makes sense to me to keep the ReportType in the OC-OLR. Eve= n if the baseline does not have agent overload etc, the ReportType fits wel= l to the "endpoint principle" we have in the draft. It indeed gives more tools to make a host vs. realm bas= e 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 D= iameter request that corresponds to the answer containing the OLR. My reaso= ns 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 applica= tion identified by the Application-Id field of the enclosing answer, the realm identified by Origin-Realm, and s= o on. This means that the "meaning" of an OLR cannot be determine= d 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 exp= licitly include such values in the OLR itself, for multiple reasons:
>
> 1) It's more complex to interpret implicit, contextual values than exp= licit values. The consumer cannot simply look at the OLR; it must look in v= arious other AVPs to find all the information it needs. For example, I thin= k a common software design for overload control processing to be separated from application processing. The consum= er 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 r= elevant. As OLR contents get extended (assumedly following the same strategy as the base spec), the number of &q= uot;context" avps that must be interpreted can grow large. This approa= ch 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 th= an explicit values. The sender cannot simply set the context to match the O= LR--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 con= text before it can send the OLR. This is particularly troublesome for agent= s, since they will typically have to insert OLRs into answers created by ot= her nodes.
>
> If the reporting node screws this up, the meaning of the OLR may chang= e significantly. So again, implicit meaning gives us error prone implementa= tions. 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.<= br> > 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 <= br> > are distinct from those sent by a server, see Steve's agent overload <= br> > draft, or my dh/dr example.)
>
> OTOH, explicit values will work for all cases where we need to associa= te some arbitrary value with an OLR.
>
> 4) Implicit values seriously constrain the future evolution of Diamete= r OC standards. For example, lets say we find a good reason to allow OLRs t= o be sent out of band, or be sent in a dedicated Diameter application. If o= verload 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 h= ave 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.iet= f.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 confiden= tielles 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 su= sceptibles 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 inf= ormation 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 dele= te 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 confiden= tielles 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 su= sceptibles 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 inf= ormation 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 dele= te 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
 --_000_A9CA33BB78081F478946E4F34BF9AAA014D2266Bxmbrcdx10ciscoc_-- From lionel.morand@orange.com Mon Dec 2 06:19:57 2013 Return-Path: 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 41A071AE425 for ; Mon, 2 Dec 2013 06:19:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 GOqLAxBsSqDM for ; Mon, 2 Dec 2013 06:19:51 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by ietfa.amsl.com (Postfix) with ESMTP id 073871AE435 for ; Mon, 2 Dec 2013 06:19:49 -0800 (PST) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id 135AD37422D; Mon, 2 Dec 2013 15:19:47 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id EC19538406C; Mon, 2 Dec 2013 15:19:46 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0158.001; Mon, 2 Dec 2013 15:19:46 +0100 From: To: "Nirav Salot (nsalot)" , "Wiehe, Ulrich (NSN - DE/Munich)" Thread-Topic: [Dime] DOIC: Self-Contained OLRs Thread-Index: AQHO67/so7y6FFeeaEmQ38aKczpYQJo6EVYAgACzUoCAAAFygIAAEJwAgAGNqACAAB+RgP//2REwgAPJ1wCAAEThgIAAvIuA//+diaCAAHKzgP//vRZkAAC/zEA= Date: Mon, 2 Dec 2013 14:19:45 +0000 Message-ID: <16844_1385993987_529C9702_16844_18637_1_6B7134B31289DC4FAF731D844122B36E310C3F@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D90006681519BC90@DEMUMBX014.nsn-intra.net> <6390_1385631044_52970D44_6390_18593_1_6B7134B31289DC4FAF731D844122B36E30748E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BD19@DEMUMBX014.nsn-intra.net> <17872_1385720008_529868C8_17872_2613_1_6B7134B31289DC4FAF731D844122B36E3096B8@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BF1B@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681519BFAE@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681519C017@DEMUMBX014.nsn-intra.net> , <5BCBA1FC2B7F0B4C9D935572D90006681519C087@DEMUMBX014.nsn-intra.net> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.5] Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E310C3FPEXCVZYM13corpora_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.12.2.94815 Cc: Ben Campbell , "dime@ietf.org list" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 14:19:57 -0000 --_000_6B7134B31289DC4FAF731D844122B36E310C3FPEXCVZYM13corpora_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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 m= atter of interpretation. When sending a request, a client is always targeting a server, even if Dest= ination-Host is not in the answer. So receiving a host-based OLR in respons= e 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 posit= ive 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" offe= red by the use of the Report-Type. But there is nothing wrong. It is only t= o 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 Re= port-type. And having the report type avoids the client to "guess" the cont= ext based on the type of request. Regards, Lionel De : Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Envoy=E9 : lundi 2 d=E9cembre 2013 14:58 =C0 : Wiehe, Ulrich (NSN - DE/Munich) Cc : dime@ietf.org list; ext Jouni Korhonen; MORAND Lionel IMT/OLN; Ben Cam= pbell 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 "optio= nal" optimization at this stage. Either it is respected by all the nodes su= pporting the solution or we drop that optimization. Regards, Nirav. On Dec 2, 2013 5:27 PM, "Wiehe, Ulrich (NSN - DE/Munich)" 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 answe= r 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 OL= R 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 Joun= i 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 thi= s OLR applicable for realm or host? I am trying to understand which is out-of-context OLR here: realm-type or h= ost-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 Joun= i 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 contain= ing destination-host), it gets back answer containing origin-host (set by t= he 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 me= ssage perspective. The client sends a request of type x (destination host = =3Dx1, destination realm =3Dx2 application=3D x3) and gets back an OLR in t= he answer which says "please throttle request of the type you just sent". T= he client either remembers, or deduces from info received in the answer, wh= at the type x was. E.g. it deduces from the value of Origin Realm in the an= swer the value of Destination Realm in the request; it deduces from the val= ue 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 solut= ion - to define the response message's context based on the request message= . And hence if the request message was sent to destination-realm, the corre= sponding response message can only contain realm-type OLR. But this requires the client to remember the context of the request while p= rocessing the response and hence it was considered as introducing unnecessa= ry 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-co= ntext [Wiehe, Ulrich (NSN - DE/Munich)] That was not my proposal. My propos= al 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-typ= e OLR only when the destination-realm based request is rejected. So basical= ly, realm-type OLR is never included in a response message which contains o= rigin-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-ty= pe 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/Mun= ich)] 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 a= gent wants to offer this optimization), and may be processed by the reactin= g 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 info= rmation 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 ign= ored. [Wiehe, Ulrich (NSN - DE/Munich)] Not the Report-Type AVP is the optimizati= on 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 O= LR is out-of-context. Similary, when the client sends a request containing destination host and g= ets 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 respons= es 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 Joun= i 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 i= n the answer and additional OLRs (not created by the reporting endpoint) ma= y just be present as an optional optimization i.e. optionally inserted by t= he 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 subs= equent request towards the origin-host of the answer containing the OLR. Us= ing 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=E9= : jeudi 28 novembre 2013 11:30 =C0 : MORAND Lionel IMT/OLN; ext Jouni Korh= onen; Ben Campbell Cc : dime@ietf.org list Objet : RE: [Dime] DOIC: Self-Co= ntained 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 act= ual OLR created by the reporting end point and which OLR is an additional O= LR created by another node. We have two cases: a) The request sent by the client (reacting end point) contains no Destinat= ion Host. The agent (reporting node) (after forwarding the request to the s= elected server and receiving the answer) returns a realm-type OLR as the ac= tual 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 Destinat= ion 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 stat= us. It could be provided an agent inserting this info in answers received f= rom a server behind but also from a server that would know this info by som= e internal magic. But in any case, if we assume that the client will received a successful an= swer from the server for an initial request with only Dest-Realm AVP, it sh= ould be possible to have both report types in the answer: one for the serve= r itself, one for the realm for new request sent to the realm with only Des= t-Realm AVP. Lionel -----Message d'origine----- De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN -= DE/Munich) Envoy=E9 : jeudi 28 novembre 2013 10:26 =C0 : ext Jouni Korhone= n; Ben Campbell Cc : dime@ietf.org list Objet : Re: [Dime] DOIC: Self-Conta= ined OLRs Hi, I don't see how the possibility to send more than one OLR in an answer is a= ligned with the "endpoint principle". If the ReportType is "realm" this ind= icates 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 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 endpoin= ts, the more it makes sense to me to keep the ReportType in the OC-OLR. Eve= n if the baseline does not have agent overload etc, the ReportType fits wel= l to the "endpoint principle" we have in the draft. It indeed gives more to= ols to make a host vs. realm base decision on the reacting node and is plai= n 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 Diam= eter 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 fr= om other context. In most cases, that context is in the Diameter answer tha= t carries the OLR. For example, the OLR implicitly refers to the applicatio= n 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 meani= ng in the context of the enclosing answer. If you moved an OLR from one ans= wer to another, it's meaning may change completely. > > I think this approach is a mistake. I would greatly prefer that we explic= itly include such values in the OLR itself, for multiple reasons: > > 1) It's more complex to interpret implicit, contextual values than explic= it values. The consumer cannot simply look at the OLR; it must look in vari= ous other AVPs to find all the information it needs. For example, I think a= common software design for overload control processing to be separated fro= m application processing. The consumer cannot simply hand the OLR to that m= odule 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 "con= text" avps that must be interpreted can grow large. This approach is error = prone, and will likely encourage brittle, hard-to-maintain code. Self-conta= ined 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 r= eporting node realizes that it is overloade, it has to wait for the right a= nswer that contains the right context before it can send the OLR. This is p= articularly troublesome for agents, since they will typically have to inser= t OLRs into answers created by other nodes. > > If the reporting node screws this up, the meaning of the OLR may change s= ignificantly. So again, implicit meaning gives us error prone implementatio= ns. 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 O= C standards. For example, lets say we find a good reason to allow OLRs to b= e sent out of band, or be sent in a dedicated Diameter application. If over= load 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 transpo= rted, this won't work. We would have to create a new or significantly modif= ied 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 im= plementations, less brittle deployments, and more flexibility for future ev= olution 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 confiden= tielles 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. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation 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 dele= te 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 confiden= tielles 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. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation 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 dele= te 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 confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. --_000_6B7134B31289DC4FAF731D844122B36E310C3FPEXCVZYM13corpora_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I agree wi= th last part. It was the reason I've reconsidered my position on the need f= or the Report-Type.

 = ;

Ulrich, I = think that what you are considering as out of context is just a matter of i= nterpretation.

When sendi= ng a request, a client is always targeting a server, even if Destination-Ho= st 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 se= nt 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 o= nly 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 cas= e, 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

 <= /p>

 <= /p>

De : Nira= v Salot (nsalot) [mailto:nsalot@cisco.com]
Envoy=E9 : lundi 2 d=E9cembre 2013 14:58
=C0 : 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<= /p>

 

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 whi= ch contains the OLR.

Back to the topic of this thread, I don't think we need to define an &qu= ot;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 - D= E/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 answe= r 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 OL= R 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 Joun= i 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 thi= s OLR applicable for realm or host?
I am trying to understand which is out-of-context OLR here: realm-type or h= ost-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 Joun= i 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 contain= ing destination-host), it gets back answer containing origin-host (set by t= he 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 me= ssage perspective. The client sends a request of type x (destination host = =3Dx1, destination realm =3Dx2 application=3D x3) and gets back an OLR in t= he answer which says "please throttle request of the type you just sent". The client either remembers, or deduces f= rom 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 t= he request; it deduces from the value of Report-Type in the answer whether Destination Host was present in the r= equest...

On the other hand, we discussed - as part of Maria Cruz's alternative solut= ion - to define the response message's context based on the request message= . And hence if the request message was sent to destination-realm, the corre= sponding response message can only contain realm-type OLR.
But this requires the client to remember the context of the request while p= rocessing the response and hence it was considered as introducing unnecessa= ry 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-co= ntext [Wiehe, Ulrich (NSN - DE/Munich)] That was not my proposal. My propos= al 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-typ= e OLR only when the destination-realm based request is rejected. So basical= ly, realm-type OLR is never included in a response message which contains o= rigin-host AVP. (And I am ready to reconsider the same if we want to ensure the context of the response me= ssage 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 ho= st-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/Mun= ich)] 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 optimizat= ion), 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 info= rmation 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 -contex= t 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 ign= ored.
[Wiehe, Ulrich (NSN - DE/Munich)] Not the Report-Type AVP is the optimizati= on 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 O= LR is out-of-context.
Similary, when the client sends a request containing destination host and g= ets 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 respons= es 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 Joun= i 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@ie= tf.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 i= n the answer and additional OLRs (not created by the reporting endpoint) ma= y just be present as an optional optimization i.e. optionally inserted by the reporting endpoint and option= ally 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 applie= s for subsequent request towards the origin-host of the answer containing t= he OLR. Using the report Type "Realm report", you know that the O= LR 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=E9 : jeudi 28 novembre = 2013 11:30 =C0 : MORAND Lionel IMT/OLN; ext Jouni Korhonen; Ben Campbe= ll 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 act= ual OLR created by the reporting end point and which OLR is an additional O= LR created by another node.

We have two cases:
a) The request sent by the client (reacting end point) contains no Destinat= ion Host. The agent (reporting node) (after forwarding the request to the s= elected server and receiving the answer) returns a realm-type OLR as the ac= tual reporting-node-created OLR and optionally in addition a host-type OLR as learned from the selected se= rver.  The client may ignore the additional OLR.
b) The request sent by the client (reacting endpoint) contains the Destinat= ion 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 stat= us. It could be provided an agent inserting this info in answers received f= rom a server behind but also from a server that would know this info by som= e internal magic.
But in any case, if we assume that the client will received a successful an= swer from the server for an initial request with only Dest-Realm AVP, it sh= ould be possible to have both report types in the answer: one for the serve= r 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-bounce= s@ietf.org] De la part de Wiehe, Ulrich (NSN - DE/Munich) Envoy=E9 = ;: jeudi 28 novembre 2013 10:26 =C0 : 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 a= ligned 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 p= oint that the reporting end point is a server. How can the reporting end po= int be both agent and server?

Ulrich

-----Original Message-----
From: DiME [mailto:dime-bounces@ie= tf.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 endpoin= ts, the more it makes sense to me to keep the ReportType in the OC-OLR. Eve= n if the baseline does not have agent overload etc, the ReportType fits wel= l to the "endpoint principle" we have in the draft. It indeed gives more tools to make a host vs. realm bas= e 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 D= iameter request that corresponds to the answer containing the OLR. My reaso= ns 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 applica= tion identified by the Application-Id field of the enclosing answer, the realm identified by Origin-Realm, and s= o on. This means that the "meaning" of an OLR cannot be determine= d 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 exp= licitly include such values in the OLR itself, for multiple reasons:
>
> 1) It's more complex to interpret implicit, contextual values than exp= licit values. The consumer cannot simply look at the OLR; it must look in v= arious other AVPs to find all the information it needs. For example, I thin= k a common software design for overload control processing to be separated from application processing. The consum= er 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 r= elevant. As OLR contents get extended (assumedly following the same strategy as the base spec), the number of &q= uot;context" avps that must be interpreted can grow large. This approa= ch 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 th= an explicit values. The sender cannot simply set the context to match the O= LR--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 con= text before it can send the OLR. This is particularly troublesome for agent= s, since they will typically have to insert OLRs into answers created by ot= her nodes.
>
> If the reporting node screws this up, the meaning of the OLR may chang= e significantly. So again, implicit meaning gives us error prone implementa= tions. 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.<= br> > 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 <= br> > are distinct from those sent by a server, see Steve's agent overload <= br> > draft, or my dh/dr example.)
>
> OTOH, explicit values will work for all cases where we need to associa= te some arbitrary value with an OLR.
>
> 4) Implicit values seriously constrain the future evolution of Diamete= r OC standards. For example, lets say we find a good reason to allow OLRs t= o be sent out of band, or be sent in a dedicated Diameter application. If o= verload 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 h= ave 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.iet= f.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 confiden= tielles 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 su= sceptibles 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 inf= ormation 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 dele= te 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 confiden= tielles 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 su= sceptibles 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 inf= ormation 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 dele= te 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 confiden=
tielles 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 el=
ectroniques 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 inf=
ormation 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 dele=
te 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.
--_000_6B7134B31289DC4FAF731D844122B36E310C3FPEXCVZYM13corpora_-- From jouni.nospam@gmail.com Mon Dec 2 06:38:19 2013 Return-Path: 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 22AD01AE476 for ; Mon, 2 Dec 2013 06:38:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.889 X-Spam-Level: X-Spam-Status: No, score=-0.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no 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 ZVqNiKeKnuEI for ; Mon, 2 Dec 2013 06:38:16 -0800 (PST) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 926341AE22A for ; Mon, 2 Dec 2013 06:38:15 -0800 (PST) Received: by mail-la0-f50.google.com with SMTP id el20so8494479lab.9 for ; Mon, 02 Dec 2013 06:38:12 -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=vI77JMxWRA7QIh+pPevCTgkzSaKToG15OjnpgIxquVg=; b=Y4lBMXO7maTqFektmPH/gLrqizzGsUbuQ4XOYX85xrl1lrrx+NiHPLdhzYgZW1+I+F 7cdQh8rR1AfjVe4cKh1VCxReEiagqQL7dHj9Ifes8cdJwedEKgW18nSxmtr0K3tZXfns 5G8gejIUGIqz8LwdBf9Z0AwYzgJNUZm6Vi90Y8yuX/c0HnkXyNjJk4bMofadjkb+qn9R LN9qeoDOlMTpp1i2y5EK0hCr9L98qscBGo6NAODnl0vS/aTs/Nl6ODcdBDidc1Dypj72 1tRsXHeGLbe+ZC6jJTLoKN0YHz2Tvyg7P+9dviWHOzFT6ZetrS+FNTscFEK3R4U08wcF tvmQ== X-Received: by 10.112.154.129 with SMTP id vo1mr1151006lbb.31.1385995092550; Mon, 02 Dec 2013 06:38:12 -0800 (PST) Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id bo10sm32258219lbb.16.2013.12.02.06.38.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 02 Dec 2013 06:38:09 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <16844_1385993987_529C9702_16844_18637_1_6B7134B31289DC4FAF731D844122B36E310C3F@PEXCVZYM13.corporate.adroot.infra.ftgroup> Date: Mon, 2 Dec 2013 16:38:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <02B93103-E094-4E5D-B6E0-5564115A9E0D@gmail.com> References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D90006681519BC90@DEMUMBX014.nsn-intra.net> <6390_1385631044_52970D44_6390_18593_1_6B7134B31289DC4FAF731D844122B36E30748E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BD19@DEMUMBX014.nsn-intra.net> <17872_1385720008_529868C8_17872_2613_1_6B7134B31289DC4FAF731D844122B36E3096B8@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BF1B@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681519BFAE@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681519C017@DEMUMBX014.nsn-intra.net> , <5BCBA1FC2B7F0B4C9D935572D90006681519C087@DEMUMBX014.nsn-intra.net> <16844_1385993987_529C9702_16844_18637_1_6B7134B31289DC4FAF731D844122B36E310C3F@PEXCVZYM13.corporate.adroot.infra.ftgroup> To: lionel.morand@orange.com X-Mailer: Apple Mail (2.1510) Cc: Ben Campbell , "dime@ietf.org list" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 14:38:19 -0000 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. > =20 > 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. > =20 > 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. > =20 > Regards, > =20 > Lionel > =20 > =20 > De : Nirav Salot (nsalot) [mailto:nsalot@cisco.com]=20 > Envoy=E9 : lundi 2 d=E9cembre 2013 14:58 > =C0 : 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 > =20 > Ulrich, >=20 > 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? >=20 > I would prefer to derive the context of the OLR based on the message = which contains the OLR. >=20 > 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. >=20 > Regards, > Nirav. >=20 > On Dec 2, 2013 5:27 PM, "Wiehe, Ulrich (NSN - DE/Munich)" = wrote: > Nirav, >=20 > 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. >=20 > 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. >=20 > Ulrich >=20 >=20 >=20 > -----Original Message----- > From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com]=20 > 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 >=20 > Ulrich, >=20 > I have a basic question. >=20 > 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? >=20 > Regards, > Nirav. >=20 > -----Original Message----- > From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 > 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 >=20 > Hi Nirav, >=20 > please see inline. >=20 > Regards > Ulrich >=20 > -----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 >=20 > Ulrich, >=20 > 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.=20 > [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 =3Dx1, destination realm =3Dx2 application=3D 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... >=20 > 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.=20 > [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. >=20 > 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) >=20 > , 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). >=20 > 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 >=20 > , 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). >=20 > 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). >=20 >=20 > 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? >=20 > 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. >=20 > Regards, > Nirav. >=20 > -----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 >=20 > Hi Nirav, >=20 > 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. >=20 > Best regards > Ulrich=20 >=20 >=20 > -----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 >=20 > Hi Ulrich, >=20 > If an additional OLR is present with a different ReportType, why it = should be ignored by the reacting node? >=20 > Regards, > Nirav. >=20 > -----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 >=20 > Hi Lionel, >=20 > 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. >=20 > Ulrich > =20 >=20 > -----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 >=20 > Hi Ulrich, >=20 > 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.=20= >=20 > 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. >=20 > I'm not sure of what is missing in this reasoning... >=20 > Lionel >=20 > -----Message d'origine----- > De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] = Envoy=E9 : jeudi 28 novembre 2013 11:30 =C0 : MORAND Lionel IMT/OLN; ext = Jouni Korhonen; Ben Campbell Cc : dime@ietf.org list Objet : RE: [Dime] = DOIC: Self-Contained OLRs >=20 > Lionel, >=20 > my understanding was that _the_ reporting end point provides _the_ = OLR. >=20 > 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. >=20 > 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. >=20 > Ulrich >=20 >=20 >=20 > -----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 >=20 > Hi, >=20 > 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. >=20 > Lionel >=20 > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich = (NSN - DE/Munich) Envoy=E9 : jeudi 28 novembre 2013 10:26 =C0 : ext = Jouni Korhonen; Ben Campbell Cc : dime@ietf.org list Objet : Re: [Dime] = DOIC: Self-Contained OLRs >=20 > Hi, >=20 > 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? >=20 > Ulrich >=20 > -----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 >=20 >=20 > On Nov 28, 2013, at 12:27 AM, Ben Campbell wrote: >=20 > > Hi, > >=20 > > I mentioned in another thread that I prefer putting an explicit=20 > > ReportType AVP in an OLR, rather than >=20 > 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. >=20 > I skip the rest of the mail.. too much text ;-) >=20 >=20 > - Jouni >=20 >=20 >=20 >=20 >=20 > > 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. > >=20 > > 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. > >=20 > > I think this approach is a mistake. I would greatly prefer that we = explicitly include such values in the OLR itself, for multiple reasons: > >=20 > > 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. > >=20 > > 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.=20= > >=20 > > 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. > >=20 > > 3) Implicit values don't work at all for certain problems. For=20 > > example, if an agent needs to originate an OLR, it typically needs = to=20 > > insert that OLR into an existing Diameter answer created by a = server. > > It can't create its own answer without affecting the application=20 > > state. If the responding node assumes the OLR comes from or refers = to=20 > > the node identified by the Origin-Host AVP in the enclosing answer,=20= > > things break. (For examples of when an agent needs to send OLRs that=20= > > are distinct from those sent by a server, see Steve's agent overload=20= > > draft, or my dh/dr example.) > >=20 > > OTOH, explicit values will work for all cases where we need to = associate some arbitrary value with an OLR. > >=20 > > 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. > >=20 > > 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. > >=20 > > Thanks! > >=20 > > Ben. > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime >=20 > _______________________________________________ > 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 >=20 > = __________________________________________________________________________= _______________________________________________ >=20 > 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. >=20 > 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. >=20 >=20 > = __________________________________________________________________________= _______________________________________________ >=20 > 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. >=20 > 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. >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > = __________________________________________________________________________= _______________________________________________ >=20 > 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. >=20 > 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. >=20 From jean-jacques.trottin@alcatel-lucent.com Mon Dec 2 07:15:46 2013 Return-Path: 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 DB2BE1AE425 for ; Mon, 2 Dec 2013 07:15:46 -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 QNTci48PcIzO for ; Mon, 2 Dec 2013 07:15:42 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 3CC2C1AE08D for ; Mon, 2 Dec 2013 07:15:42 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id rB2FFZCB023042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 2 Dec 2013 09:15:36 -0600 (CST) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id rB2FFWKq006983 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 2 Dec 2013 16:15:35 +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; Mon, 2 Dec 2013 16:15:33 +0100 From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" To: "dime@ietf.org" Thread-Topic: [Dime] DOIC: Self-Contained OLRs Thread-Index: AQHO67/uc4Hi6cqE9USGBLWwFB86UZo5m/0AgACzUoCAAAFygIAAEJwAgAGNqACAAB+RgIAAPg6AgANk2wCAAK8dAIAAUk+AgAAHDYCAAAkugIAAIauAgAAGBICAAAUigIAAFfwQ Date: Mon, 2 Dec 2013 15:15:32 +0000 Message-ID: References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D90006681519BC90@DEMUMBX014.nsn-intra.net> <6390_1385631044_52970D44_6390_18593_1_6B7134B31289DC4FAF731D844122B36E30748E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BD19@DEMUMBX014.nsn-intra.net> <17872_1385720008_529868C8_17872_2613_1_6B7134B31289DC4FAF731D844122B36E3096B8@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BF1B@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681519BFAE@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681519C017@DEMUMBX014.nsn-intra.net> , <5BCBA1FC2B7F0B4C9D935572D90006681519C087@DEMUMBX014.nsn-intra.net> <16844_1385993987_529C9702_16844_18637_1_6B7134B31289DC4FAF731D844122B36E310C3F@PEXCVZYM13.corporate.adroot.infra.ftgroup> <02B93103-E094-4E5D-B6E0-5564115A9E0D@gmail.com> In-Reply-To: <02B93103-E094-4E5D-B6E0-5564115A9E0D@gmail.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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 15:15:47 -0000 Hi Ulrich=20 I do not also well see to introduce this concept of in-context versus out-o= f context in the standard. The values in realm and Host OLR reports are stored by the client and used = for throttling of future requests. The fact that an OLR is received in a ce= rtain type of answer or on another has no impact, its value in both type of= answers is relevant. In practice when the client sends a request with only the realm, the serve= r, if overloaded will send a host OLR, then the DA having selected the serv= er, has no particular reason to remove the host OLR which is valuable info= . The client will receive both OLR and handles them. So no need to introduc= e an in-context versus out-of context. So I join Nirav and Lionel views Best regards JJacques=20 -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Jouni Korhonen Envoy=E9=A0: lundi 2 d=E9cembre 2013 15:38 =C0=A0: lionel.morand@orange.com Cc=A0: Ben Campbell; dime@ietf.org list Objet=A0: 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 o= n the need for the Report-Type. > =20 > 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 De= stination-Host is not in the answer. So receiving a host-based OLR in respo= nse 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 pos= itive 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" of= fered 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 th= e client could include a destination-host or not. So the client needs to kn= ow which reduction to apply from a previous answer. > =20 > 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 co= ntext based on the type of request. > =20 > Regards, > =20 > Lionel > =20 > =20 > De : Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Envoy=E9 : lundi 2=20 > d=E9cembre 2013 14:58 =C0 : Wiehe, Ulrich (NSN - DE/Munich) Cc :=20 > dime@ietf.org list; ext Jouni Korhonen; MORAND Lionel IMT/OLN; Ben=20 > Campbell Objet : RE: [Dime] DOIC: Self-Contained OLRs > =20 > Ulrich, >=20 > 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? >=20 > I would prefer to derive the context of the OLR based on the message whic= h contains the OLR. >=20 > Back to the topic of this thread, I don't think we need to define an "opt= ional" optimization at this stage. Either it is respected by all the nodes = supporting the solution or we drop that optimization. >=20 > Regards, > Nirav. >=20 > On Dec 2, 2013 5:27 PM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: > Nirav, >=20 > If the reacting node sends a request without Destination Host, a realm-ty= pe OLR in the answer would be in-context whereas a host-type OLR in the ans= wer would be out of context. >=20 > Similarly, if the reacting node sends a request containing Destination Ho= st, a realm-type OLR in the answer would be out-of-context and a host-type = OLR in the answer would be in-context. >=20 > Ulrich >=20 >=20 >=20 > -----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=20 > Jouni Korhonen; Ben Campbell > Cc: dime@ietf.org list > Subject: RE: [Dime] DOIC: Self-Contained OLRs >=20 > Ulrich, >=20 > I have a basic question. >=20 > When the reacting node sends realm-routed request and it receives (only o= ne) OLR in the response message (which also contains the origin-host), is t= his OLR applicable for realm or host? > I am trying to understand which is out-of-context OLR here: realm-type or= host-type? >=20 > Regards, > Nirav. >=20 > -----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=20 > Korhonen; Ben Campbell > Cc: dime@ietf.org list > Subject: RE: [Dime] DOIC: Self-Contained OLRs >=20 > Hi Nirav, >=20 > please see inline. >=20 > Regards > Ulrich >=20 > -----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=20 > Jouni Korhonen; Ben Campbell > Cc: dime@ietf.org list > Subject: RE: [Dime] DOIC: Self-Contained OLRs >=20 > Ulrich, >=20 > When the client sends request containing destination-realm (and not conta= ining 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 thi= s response message is not out-of-context information.=20 > [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= =3Dx1, destination realm =3Dx2 application=3D 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, w= hat the type x was. E.g. it deduces from the value of Origin Realm in the a= nswer the value of Destination Realm in the request; it deduces from the va= lue of Report-Type in the answer whether Destination Host was present in th= e request... >=20 > On the other hand, we discussed - as part of Maria Cruz's alternative sol= ution - to define the response message's context based on the request messa= ge. And hence if the request message was sent to destination-realm, the cor= responding 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 unneces= sary complexity.=20 > [Wiehe, Ulrich (NSN - DE/Munich)] I agree. This means: the report-type AV= P is needed to let the client deduce from information received in the answe= r whether the request contained a destination host. It does not mean that w= e need two OLRs in one answer. >=20 > If we strictly want to ensure that the realm-type OLR is not sent=20 > out-of-context [Wiehe, Ulrich (NSN - DE/Munich)] That was not my=20 > proposal. My proposal was to clearly mark out-of-context OLRs in=20 > answer messages (if we allow including out-of-context OLRs) >=20 > , then we should agree to Lionel's alternative solution - to send realm-t= ype OLR only when the destination-realm based request is rejected. So basic= ally, 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 ensu= re the context of the response message and the OLR it contains). >=20 > 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 on= e 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=20 > (NSN - DE/Munich)] only the out-of-context one >=20 > , then what is the point of including two OLRs [Wiehe, Ulrich (NSN - DE/M= unich)] 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 a= s 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 react= ing node (if the reacting node wants to make use of this optimization). >=20 > and what is the point of defining Report-Type AVP? > [Wiehe, Ulrich (NSN - DE/Munich)] to let the reacting node deduce from in= formation received in the answer whether the corresponding request containe= d a destination host (so there is no need to remember). >=20 >=20 > In summary, if we define Report-Type AVP and corresponding handling at th= e reacting node, the reacting node must act accordingly and not ignore it. > [Wiehe, Ulrich (NSN - DE/Munich)] What goes wrong when out-of -context O= LR is ignored? >=20 > 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 i= gnored. > [Wiehe, Ulrich (NSN - DE/Munich)] Not the Report-Type AVP is the optimiza= tion but the incusion of out-of-context OLRs. And I'm ok not to proceed wit= h this optimization as it is not needed. >=20 > Regards, > Nirav. >=20 > -----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=20 > Korhonen; Ben Campbell > Cc: dime@ietf.org list > Subject: RE: [Dime] DOIC: Self-Contained OLRs >=20 > Hi Nirav, >=20 > 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-contex= t. > There is nothing wrong with storing such out-of-context OLRs at the clien= t, but it is simply not needed as the client will learn this OLR from respo= nses received within the context. >=20 > Best regards > Ulrich >=20 >=20 > -----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=20 > Jouni Korhonen; Ben Campbell > Cc: dime@ietf.org list > Subject: RE: [Dime] DOIC: Self-Contained OLRs >=20 > Hi Ulrich, >=20 > If an additional OLR is present with a different ReportType, why it shoul= d be ignored by the reacting node? >=20 > Regards, > Nirav. >=20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich=20 > (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 >=20 > Hi Lionel, >=20 > there is nothing missing exept the clarification that everything works fi= ne 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. >=20 > Ulrich > =20 >=20 > -----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 >=20 > Hi Ulrich, >=20 > Using the Report Type "host report", you know that the OLR applies for su= bsequent 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.=20 >=20 > It is not so important to know what the type of request was and which nod= e 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, f= or instance, future development could allow a distributed server architectu= re to provide the same information. >=20 > I'm not sure of what is missing in this reasoning... >=20 > Lionel >=20 > -----Message d'origine----- > De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 > Envoy=E9 : jeudi 28 novembre 2013 11:30 =C0 : MORAND Lionel IMT/OLN; ext= =20 > Jouni Korhonen; Ben Campbell Cc : dime@ietf.org list Objet : RE:=20 > [Dime] DOIC: Self-Contained OLRs >=20 > Lionel, >=20 > my understanding was that _the_ reporting end point provides _the_ OLR. >=20 > If we go for two OLRs in the answer we should indicate which OLR is the a= ctual OLR created by the reporting end point and which OLR is an additional= OLR created by another node. >=20 > We have two cases: > a) The request sent by the client (reacting end point) contains no Destin= ation 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 OL= R as learned from the selected server. The client may ignore the additiona= l OLR. > b) The request sent by the client (reacting endpoint) contains the Destin= ation Host. The Server (reporting node) returns a host-type OLR as the actu= al reporting-node-created OLR in the answer. The agent may optionally inser= t a realm-type OLR as additional OLR to the answer. The client may ignore t= he additional OLR. >=20 > Ulrich >=20 >=20 >=20 > -----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 >=20 > Hi, >=20 > There is no assumption on which entity is providing the realm overload st= atus. 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 s= ome 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 ser= ver itself, one for the realm for new request sent to the realm with only D= est-Realm AVP. >=20 > Lionel >=20 > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich=20 > (NSN - DE/Munich) Envoy=E9 : jeudi 28 novembre 2013 10:26 =C0 : ext Jouni= =20 > Korhonen; Ben Campbell Cc : dime@ietf.org list Objet : Re: [Dime]=20 > DOIC: Self-Contained OLRs >=20 > Hi, >=20 > 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 i= ndicates 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 indicate= s to the reacting end point that the reporting end point is a server. How c= an the reporting end point be both agent and server? >=20 > Ulrich >=20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Jouni=20 > Korhonen > Sent: Wednesday, November 27, 2013 11:44 PM > To: Ben Campbell > Cc: dime@ietf.org list > Subject: Re: [Dime] DOIC: Self-Contained OLRs >=20 >=20 > On Nov 28, 2013, at 12:27 AM, Ben Campbell wrote: >=20 > > Hi, > >=20 > > I mentioned in another thread that I prefer putting an explicit=20 > > ReportType AVP in an OLR, rather than >=20 > The more I spent time thinking/writing the actual procedures on the endpo= ints, the more it makes sense to me to keep the ReportType in the OC-OLR. E= ven if the baseline does not have agent overload etc, the ReportType fits w= ell 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 pl= ain more clear. >=20 > I skip the rest of the mail.. too much text ;-) >=20 >=20 > - Jouni >=20 >=20 >=20 >=20 >=20 > > making a responding node infer the type or meaning of the OLR from a Di= ameter request that corresponds to the answer containing the OLR. My reason= s for that go beyond just ReportType, so I'm starting a separate thread. > >=20 > > 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 t= hat carries the OLR. For example, the OLR implicitly refers to the applicat= ion identified by the Application-Id field of the enclosing answer, the rea= lm 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 mea= ning in the context of the enclosing answer. If you moved an OLR from one a= nswer to another, it's meaning may change completely. > >=20 > > I think this approach is a mistake. I would greatly prefer that we expl= icitly include such values in the OLR itself, for multiple reasons: > >=20 > > 1) It's more complex to interpret implicit, contextual values than expl= icit values. The consumer cannot simply look at the OLR; it must look in va= rious other AVPs to find all the information it needs. For example, I think= a common software design for overload control processing to be separated f= rom 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 OL= R, 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 "c= ontext" avps that must be interpreted can grow large. This approach is erro= r prone, and will likely encourage brittle, hard-to-maintain code. Self-con= tained OLRs would keep all the information related to overload in one place= . making for simpler implementations. > >=20 > > 2) It's more complex for the reporting node to send implicit values tha= n explicit values. The sender cannot simply set the context to match the OL= R--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 ins= ert OLRs into answers created by other nodes.=20 > >=20 > > If the reporting node screws this up, the meaning of the OLR may change= significantly. So again, implicit meaning gives us error prone implementat= ions. Self-contained OLRs are simpler to create and send. > >=20 > > 3) Implicit values don't work at all for certain problems. For=20 > > example, if an agent needs to originate an OLR, it typically needs=20 > > to insert that OLR into an existing Diameter answer created by a server= . > > It can't create its own answer without affecting the application=20 > > state. If the responding node assumes the OLR comes from or refers=20 > > to the node identified by the Origin-Host AVP in the enclosing=20 > > answer, things break. (For examples of when an agent needs to send=20 > > OLRs that are distinct from those sent by a server, see Steve's=20 > > agent overload draft, or my dh/dr example.) > >=20 > > OTOH, explicit values will work for all cases where we need to associat= e some arbitrary value with an OLR. > >=20 > > 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 ov= erload 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 trans= ported, this won't work. We would have to create a new or significantly mod= ified OLR format if we found a need to transport OLRs in different ways. Se= lf-contained OLRs would allow much greater flexibility. > >=20 > > 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. > >=20 > > Thanks! > >=20 > > Ben. > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime >=20 > _______________________________________________ > 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 >=20 > ______________________________________________________________________ > ___________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc pas etre diffuses, exploites o= u copies sans autorisation. Si vous avez recu ce message par erreur, veuill= ez 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= . >=20 > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; they should not be distributed, us= ed or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 >=20 > ______________________________________________________________________ > ___________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc pas etre diffuses, exploites o= u copies sans autorisation. Si vous avez recu ce message par erreur, veuill= ez 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= . >=20 > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; they should not be distributed, us= ed or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > ______________________________________________________________________ > ___________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not be d= istributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From srdonovan@usdonovans.com Mon Dec 2 07:21:41 2013 Return-Path: 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 07B7D1AE435 for ; Mon, 2 Dec 2013 07:21:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no 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 xsVQ5SDHAAhr for ; Mon, 2 Dec 2013 07:21:35 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 0143B1AE0D1 for ; Mon, 2 Dec 2013 07:21:17 -0800 (PST) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:64346 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1VnVJA-00083p-EH for dime@ietf.org; Mon, 02 Dec 2013 07:21:14 -0800 Message-ID: <529CA568.5020902@usdonovans.com> Date: Mon, 02 Dec 2013 09:21:12 -0600 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: dime@ietf.org References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D90006681519BC90@DEMUMBX014.nsn-intra.net> <6390_1385631044_52970D44_6390_18593_1_6B7134B31289DC4FAF731D844122B36E30748E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BD19@DEMUMBX014.nsn-intra.net> <17872_1385720008_529868C8_17872_2613_1_6B7134B31289DC4FAF731D844122B36E3096B8@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BF1B@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681519BFAE@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681519C017@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681519C017@DEMUMBX014.nsn-intra.net> Content-Type: multipart/alternative; boundary="------------060903040109020909060009" X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 15:21:41 -0000 This is a multi-part message in MIME format. --------------060903040109020909060009 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit I'm still catching up on this thread but I wanted to insert here that the "in-context"/"out-of-context" concept is a lot of complexity that is removed by Ben's proposal that started this thread. It is much more straight forward to understand and implement if we include all of the information relevant to the overload report in the actual overload report. Steve On 12/2/13 4:59 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: > 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 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 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > --------------060903040109020909060009 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I'm still catching up on this thread but I wanted to insert here that the "in-context"/"out-of-context" concept  is a lot of complexity that is removed by Ben's proposal that started this thread.

It is much more straight forward to understand and implement if we include all of the information relevant to the overload report in the actual overload report.

Steve
On 12/2/13 4:59 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
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
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime

--------------060903040109020909060009-- From srdonovan@usdonovans.com Mon Dec 2 07:24:16 2013 Return-Path: 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 9CFB11AE018 for ; Mon, 2 Dec 2013 07:24:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no 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 keh7GJ2REXIT for ; Mon, 2 Dec 2013 07:24:13 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 38BF31A1F4C for ; Mon, 2 Dec 2013 07:24:13 -0800 (PST) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:64350 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1VnVLy-0003VO-Td for dime@ietf.org; Mon, 02 Dec 2013 07:24:10 -0800 Message-ID: <529CA616.2040205@usdonovans.com> Date: Mon, 02 Dec 2013 09:24:06 -0600 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: dime@ietf.org References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D90006681519BC90@DEMUMBX014.nsn-intra.net> <6390_1385631044_52970D44_6390_18593_1_6B7134B31289DC4FAF731D844122B36E30748E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BD19@DEMUMBX014.nsn-intra.net> <17872_1385720008_529868C8_17872_2613_1_6B7134B31289DC4FAF731D844122B36E3096B8@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BF1B@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681519BFAE@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681519BFAE@DEMUMBX014.nsn-intra.net> Content-Type: multipart/alternative; boundary="------------040303070607080708010501" X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 15:24:16 -0000 This is a multi-part message in MIME format. --------------040303070607080708010501 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Ulrich, Designing an overload solution that allows a reacting node to ignore an overload report seems strange to me. The system is under stress. Overload reports should be reacted to as quickly as possible, independent of how the overload report is received by the reacting node. Steve On 12/1/13 1:38 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote: > 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 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 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > --------------040303070607080708010501 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Ulrich,

Designing an overload solution that allows a reacting node to ignore an overload report seems strange to me.  The system is under stress.  Overload reports should be reacted to as quickly as possible, independent of how the overload report is received by the reacting node.

Steve
On 12/1/13 1:38 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
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
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime

--------------040303070607080708010501-- From srdonovan@usdonovans.com Mon Dec 2 07:37:31 2013 Return-Path: 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 0A2A11A1DFA for ; Mon, 2 Dec 2013 07:37:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no 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 cAkJAxjdQnxr for ; Mon, 2 Dec 2013 07:37:27 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 2ADE71AE49C for ; Mon, 2 Dec 2013 07:37:27 -0800 (PST) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:64358 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1VnVYm-0003FQ-LY for dime@ietf.org; Mon, 02 Dec 2013 07:37:24 -0800 Message-ID: <529CA930.4030006@usdonovans.com> Date: Mon, 02 Dec 2013 09:37:20 -0600 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: dime@ietf.org References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D90006681519BC90@DEMUMBX014.nsn-intra.net> <6390_1385631044_52970D44_6390_18593_1_6B7134B31289DC4FAF731D844122B36E30748E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BD31@DEMUMBX014.nsn-intra.net> <47383DC2-1A1B-4D1A-ADD5-9E3CE60B06C8@gmail.com> <8467_1385735507_5298A553_8467_17054_3_6B7134B31289DC4FAF731D844122B36E309D0D@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <8467_1385735507_5298A553_8467_17054_3_6B7134B31289DC4FAF731D844122B36E309D0D@PEXCVZYM13.corporate.adroot.infra.ftgroup> Content-Type: multipart/alternative; boundary="------------050803050402010304040806" X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 15:37:31 -0000 This is a multi-part message in MIME format. --------------050803050402010304040806 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit I don't believe that Ben's proposal was to change the piggybacking assumption in the baseline mechanism. Ben's proposal is to design the solution in such a way that it is not dependent on the piggybacking transport mechanism. I share Ben's concern that we have over optimized the content of the overload report in a way that makes implementations brittle, interoperability more difficult to achieve and extensibility more complex. And what do we gain from this optimization? A few bites in answer messages. Self contained overload reports, transported using the piggybacking mechanism, is a cleaner solution. Steve On 11/29/13 8:31 AM, lionel.morand@orange.com wrote: > I totally agree with Nirav. No need to revert at this stage the working assumption on piggybacking of OLR in application answer messages, especially when the aim is to define a basic mechanism called "reduction". > > Anyone would be able to further add extra info for optimization if needed but there is no need at all for the basic mechanism. > > Regards, > > Lionel > > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot (nsalot) > Envoyé : vendredi 29 novembre 2013 12:24 > À : Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list > Cc : Ben Campbell > Objet : Re: [Dime] DOIC: Self-Contained OLRs > > Jouni, Ben, > > I am totally against the idea of self-contained OC-OLR specifically since we have adopted the principles of piggybacking the OC-OLR over existing application message. > Self-contained OC-OLR - which means adding all the information which defines the scope of the OC-OLR into the OC-OLR - does not make sense in the piggybacking approach. In fact, it is adding lot of information, which is anyway available within the message containing the OC-OLR, into the OC-OLR. So it is adding lot of redundant information in a message which increases the processing requirement for the sender as well as the receiver. (And this is un-optimization, in my view). > > Besides, I am not convinced with the other reasons provided here: > - One software module within a node can provide OC-OLR to another software module in the same node without passing other related info > Within a node, based on the design, lots of information may need to be passed between two software modules and we cannot optimize those aspects by replicating unnecessary information in a protocol message. > In summary, it is node's internal software design issue and we need not optimize that at protocol level. > > - Once the reporting node realizes that it is overloaded, it has to wait for right answer to send OC-OLR > What is the point of sending OC-OLR for a context for which there is no messaging? Why should the reacting node care if it never sends a message for a context for which the reporting node is overloaded? > So this waiting is justified since it ensures that the overload is reported only when necessary and only to the applicable reacting node. Not to all the nodes in the network. > > - The agent needs to wait for the answer generated by the server and the right context > The same argument as applicable for the server applies here. The agent need not send out-of-context overload info to a node. > Why should reacting node receive/process/store the overload info for the scope for which it is not sending any messages. > > - For sending OC-OLR in dedicated Diameter application??? > Piggybacking was the first basic principle we agreed before putting other principles in place. So we may want to go back the drawing board if we decide to change this principle. > > Regards, > Nirav. > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen > Sent: Friday, November 29, 2013 2:50 PM > To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list > Cc: Ben Campbell > Subject: Re: [Dime] DOIC: Self-Contained OLRs > > > > So, are we reaching any level of consensus here? > > - JOuni > > (as a note.. that we are converging back to where we started with OLRs ;) > > > > On Nov 28, 2013, at 12:40 PM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: > >> Hi, >> >> another question: >> >> If we go for explicit self contained OLRs, why would we then need the ReportType? >> >> The realm-type OLR would explicitly contain application-Id, Realm, but no Host whereas the host-type OLR would explicitly contain application-Id, Host, but probably (I'm not sure) no Realm. >> >> 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 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. >> > _______________________________________________ > 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. > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > --------------050803050402010304040806 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I don't believe that Ben's proposal was to change the piggybacking assumption in the baseline mechanism.  Ben's proposal is to design the solution in such a way that it is not dependent on the piggybacking transport mechanism. 

I share Ben's concern that we have over optimized the content of the overload report in a way that makes implementations brittle, interoperability more difficult to achieve and extensibility more complex.  And what do we gain from this optimization?  A few bites in answer messages.

Self contained overload reports, transported using the piggybacking mechanism, is a cleaner solution.

Steve
On 11/29/13 8:31 AM, lionel.morand@orange.com wrote:
I totally agree with Nirav. No need to revert at this stage the working assumption on piggybacking of OLR in application answer messages, especially when the aim is to define a basic mechanism called "reduction".

Anyone would be able to further add extra info for optimization if needed but there is no need at all for the basic mechanism.

Regards,

Lionel

-----Message d'origine-----
De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot (nsalot)
Envoyé : vendredi 29 novembre 2013 12:24
À : Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list
Cc : Ben Campbell
Objet : Re: [Dime] DOIC: Self-Contained OLRs

Jouni, Ben,

I am totally against the idea of self-contained OC-OLR specifically since we have adopted the principles of piggybacking the OC-OLR over existing application message.
Self-contained OC-OLR - which means adding all the information which defines the scope of the OC-OLR into the OC-OLR - does not make sense in the piggybacking approach. In fact, it is adding lot of information, which is anyway available within the message containing the OC-OLR, into the OC-OLR. So it is adding lot of redundant information in a message which increases the processing requirement for the sender as well as the receiver. (And this is un-optimization, in my view).

Besides, I am not convinced with the other reasons provided here:
- One software module within a node can provide OC-OLR to another software module in the same node without passing other related info
   Within a node, based on the design, lots of information may need to be passed between two software modules and we cannot optimize those aspects by replicating unnecessary information in a protocol message.
   In summary, it is node's internal software design issue and we need not optimize that at protocol level.

- Once the reporting node realizes that it is overloaded, it has to wait for right answer to send OC-OLR
  What is the point of sending OC-OLR for a context for which there is no messaging? Why should the reacting node care if it never sends a message for a context for which the reporting node is overloaded?
  So this waiting is justified since it ensures that the overload is reported only when necessary and only to the applicable reacting node. Not to all the nodes in the network.

- The agent needs to wait for the answer generated by the server and the right context
   The same argument as applicable for the server applies here. The agent need not send out-of-context overload info to a node.
   Why should reacting node receive/process/store the overload info for the scope for which it is not sending any messages.

- For sending OC-OLR in dedicated Diameter application???
  Piggybacking was the first basic principle we agreed before putting other principles in place. So we may want to go back the drawing board if we decide to change this principle.

Regards,
Nirav.

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen
Sent: Friday, November 29, 2013 2:50 PM
To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list
Cc: Ben Campbell
Subject: Re: [Dime] DOIC: Self-Contained OLRs



So, are we reaching any level of consensus here?

- JOuni

(as a note.. that we are converging back to where we started with OLRs ;)



On Nov 28, 2013, at 12:40 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> wrote:


Hi,

another question:

If we go for explicit self contained OLRs, why would we then need the ReportType?

The realm-type OLR would explicitly contain application-Id, Realm, but no Host whereas the host-type OLR would explicitly contain application-Id, Host, but probably (I'm not sure) no Realm.

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.


_______________________________________________
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.

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

--------------050803050402010304040806-- From srdonovan@usdonovans.com Mon Dec 2 07:39:52 2013 Return-Path: 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 B6ACD1AC3FA for ; Mon, 2 Dec 2013 07:39:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no 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 cXCOP57b1gep for ; Mon, 2 Dec 2013 07:39:51 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 39D011A1F62 for ; Mon, 2 Dec 2013 07:39:51 -0800 (PST) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:64359 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1VnVaQ-0005DO-3V for dime@ietf.org; Mon, 02 Dec 2013 07:39:48 -0800 Message-ID: <529CA996.4020208@usdonovans.com> Date: Mon, 02 Dec 2013 09:39:02 -0600 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: dime@ietf.org References: <2D60D862-45C5-4B13-96E6-F9621AF33759@gmail.com> <19936_1385975192_529C4D98_19936_10950_1_6B7134B31289DC4FAF731D844122B36E30F190@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <19936_1385975192_529C4D98_19936_10950_1_6B7134B31289DC4FAF731D844122B36E30F190@PEXCVZYM13.corporate.adroot.infra.ftgroup> Content-Type: multipart/alternative; boundary="------------090109050203000404030100" X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com Subject: Re: [Dime] draft-ietf-dime-ovli-01 questions #2 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 15:39:52 -0000 This is a multi-part message in MIME format. --------------090109050203000404030100 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit I would phrase it as application specific. It is completely possible that the IETF could define an application that used pseudo sessions as well. Steve On 12/2/13 3:06 AM, lionel.morand@orange.com wrote: > Hi, > > Not sure that it is so "SDO" specific. But it is true that we should clarify that this concept is not clearly described in RFC6733 and it is up to the application to define the specific session states when not relying on the session-id and the session state machine defined in RFC6733. > > Lionel > > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Jouni > Envoyé : lundi 2 décembre 2013 09:25 > À : DiME@ietf.org > Objet : [Dime] draft-ietf-dime-ovli-01 questions #2 > > In Section 3.1.1 where pseudo-session applications are discussed shouldn't > we also state that the pseudo-session application is somewhat a SDO specific > jewel? IMHO it is not really what RFC6733 session-less application is, > although from the base protocol point of view it is compliant. > > - Jouni > _______________________________________________ > 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 > --------------090109050203000404030100 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I would phrase it as application specific.  It is completely possible that the IETF could define an application that used pseudo sessions as well. 

Steve
On 12/2/13 3:06 AM, lionel.morand@orange.com wrote:
Hi,

Not sure that it is so "SDO" specific. But it is true that we should clarify that this concept is not clearly described in RFC6733 and it is up to the application to define the specific session states when not relying on the session-id and the session state machine defined in RFC6733.

Lionel

-----Message d'origine-----
De : DiME [mailto:dime-bounces@ietf.org] De la part de Jouni
Envoyé : lundi 2 décembre 2013 09:25
À : DiME@ietf.org
Objet : [Dime] draft-ietf-dime-ovli-01 questions #2

In Section 3.1.1 where pseudo-session applications are discussed shouldn't
we also state that the pseudo-session application is somewhat a SDO specific
jewel? IMHO it is not really what RFC6733 session-less application is,
although from the base protocol point of view it is compliant.

- Jouni
_______________________________________________
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

--------------090109050203000404030100-- From srdonovan@usdonovans.com Mon Dec 2 07:42:29 2013 Return-Path: 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 C4E371AC404 for ; Mon, 2 Dec 2013 07:42:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no 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 detsJoQ5NIhf for ; Mon, 2 Dec 2013 07:42:28 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB621A1F61 for ; Mon, 2 Dec 2013 07:42:28 -0800 (PST) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:64508 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1VnVd3-00084D-AG for dime@ietf.org; Mon, 02 Dec 2013 07:42:25 -0800 Message-ID: <529CAA39.6050809@usdonovans.com> Date: Mon, 02 Dec 2013 09:41:45 -0600 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: dime@ietf.org References: <16E13E52-0DB9-4E72-964A-FE658536155B@gmail.com> <10629_1385971488_529C3F20_10629_5138_1_emlwd34vyt318xrd8i01xiee.1385971482719@email.android.com> In-Reply-To: <10629_1385971488_529C3F20_10629_5138_1_emlwd34vyt318xrd8i01xiee.1385971482719@email.android.com> Content-Type: multipart/alternative; boundary="------------050805040609000202010806" X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com Subject: Re: [Dime] draft-ietf-dime-ovli-01 questions #1 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 15:42:30 -0000 This is a multi-part message in MIME format. --------------050805040609000202010806 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit The PCC architecture, where agents route based on pre-existing bindings is another example. Steve On 12/2/13 2:04 AM, lionel.morand@orange.com wrote: > It was my understanding. > > Envoyé depuis mon Sony Xperia SP d'Orange > > Jouni Korhonen a écrit : > > > Hi, > > In Section 2 on Diameter routing it says: > > defined in [RFC6733]. Application level routing specifications > that expand on [RFC6733] also exist. > > What does this "expand" actually refer to? RFC5729? RFC7075? > > - Jouni > _______________________________________________ > 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 > --------------050805040609000202010806 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The PCC architecture, where agents route based on pre-existing bindings is another example.

Steve
On 12/2/13 2:04 AM, lionel.morand@orange.com wrote:
It was my understanding.

Envoyé depuis mon Sony Xperia SP d'Orange

Jouni Korhonen <jounikor@gmail.com> a écrit :


Hi,

In Section 2 on Diameter routing it says:

      defined in [RFC6733].  Application level routing specifications
      that expand on [RFC6733] also exist.

What does this "expand" actually refer to? RFC5729? RFC7075?

- Jouni
_______________________________________________
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

--------------050805040609000202010806-- From srdonovan@usdonovans.com Mon Dec 2 07:45:32 2013 Return-Path: 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 6AB5E1A1F19 for ; Mon, 2 Dec 2013 07:45:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no 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 eZ6FOAKPppsM for ; Mon, 2 Dec 2013 07:45:30 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 6965F1A16F0 for ; Mon, 2 Dec 2013 07:45:30 -0800 (PST) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:64510 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1VnVg4-0003Fd-34 for dime@ietf.org; Mon, 02 Dec 2013 07:45:27 -0800 Message-ID: <529CAAF4.6070708@usdonovans.com> Date: Mon, 02 Dec 2013 09:44:52 -0600 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: dime@ietf.org References: <5E28C8B7-2E5E-41E8-9592-24A19AD76826@gmail.com> <9889_1385714340_529852A4_9889_16410_1_6B7134B31289DC4FAF731D844122B36E3093B0@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52EDD6D4-71CD-439F-9D2D-439CC656C3CC@gmail.com> <3468_1385718494_529862DE_3468_4222_1_6B7134B31289DC4FAF731D844122B36E309600@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050001040201080106060308" X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com Subject: Re: [Dime] open issues #1 in DOIC X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 15:45:32 -0000 This is a multi-part message in MIME format. --------------050001040201080106060308 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Agreed, looks good. Steve On 11/29/13 4:04 AM, Jouni Korhonen wrote: > Would work for me. > > - Jouni > > On Nov 29, 2013, at 11:48 AM, lionel.morand@orange.com wrote: > >> Actually, I realized that we are redefining something somehow already in use in RFC 6733: >> >> 9.6. Correlation of Accounting Records >> >> >> If an application uses accounting messages, it can correlate >> accounting records with a specific application session by using the >> Session-Id of the particular application session in the accounting >> messages. Accounting messages MAY also use a different Session-Id >> from that of the application sessions, in which case, other session- >> related information is needed to perform correlation. >> >> We could maybe reuse the same type of wording to simplify the definition: >> >> Pseudo-session applications are applications that >> do not rely on the Session-Id AVP for correlation >> of application messages related to the same session >> but use another session-related information for this >> purpose. The 3GPP defined Cx application [3GPP.29.229] >> is an example of a pseudo-session application. >> >> OK? >> >> Regards, >> >> Lionel >> >> -----Message d'origine----- >> De : Jouni Korhonen [mailto:jouni.nospam@gmail.com] >> Envoyé : vendredi 29 novembre 2013 10:01 >> À : MORAND Lionel IMT/OLN >> Cc : dime@ietf.org list >> Objet : Re: [Dime] open issues #1 in DOIC >> >> >> Pseudo-session applications: >> >> While this class of application does not use the Diameter >> Session-ID AVP to correlate requests, there is an implied ordering >> of transactions defined by the application and except for the >> Session-ID differences pseudo-session based applications are >> generally assumed to behave like session-based application. The >> 3GPP defined Cx application [3GPP.29.229] is an example of a >> pseudo-session application. >> >> >> Would this suffice? >> >> - Jouni >> >> >> >> On Nov 29, 2013, at 10:38 AM, lionel.morand@orange.com wrote: >> >>> Hi, >>> >>> For me, "pseudo-session" refers to session-based oriented applications that do not rely on the session-id for message correlations but on something else e.g. user-name. So it is implied that the same server is contacted by the client managing the session. In the Cx example, the same origin-host will be used in the client-initiated requests after the initial exchange and the server discovery phase. >>> >>> Regards, >>> >>> Lionel >>> >>> -----Message d'origine----- >>> De : DiME [mailto:dime-bounces@ietf.org] De la part de Jouni Korhonen >>> Envoyé : vendredi 29 novembre 2013 09:30 >>> À : dime@ietf.org list >>> Objet : [Dime] open issues #1 in DOIC >>> >>> Folks, >>> >>> [OpenIssue: Do we assume that all requests in a pseudo-session >>> typically need to go to the same server?] >>> >>> >>> The example here is in context of Cx. Not that I am expert on Cx (or anything) >>> but based on the CCF the requests _may_ have destination-host. Thus, I assume >>> that it is an implementation issue whether pseudo-sessions need to go to the >>> same server.. I guess we cannot have such firm requirement. Correct? >>> >>> - Jouni >>> _______________________________________________ >>> 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 > --------------050001040201080106060308 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Agreed, looks good.

Steve
On 11/29/13 4:04 AM, Jouni Korhonen wrote:
Would work for me.

- Jouni

On Nov 29, 2013, at 11:48 AM, lionel.morand@orange.com wrote:


Actually, I realized that we are redefining something somehow already in use in RFC 6733:

9.6. Correlation of Accounting Records


  If an application uses accounting messages, it can correlate
  accounting records with a specific application session by using the
  Session-Id of the particular application session in the accounting
  messages.  Accounting messages MAY also use a different Session-Id
  from that of the application sessions, in which case, other session-
  related information is needed to perform correlation.

We could maybe reuse the same type of wording to simplify the definition:

Pseudo-session applications are applications that
do not rely on the Session-Id AVP for correlation 
of application messages related to the same session
but use another session-related information for this
purpose. The 3GPP defined Cx application [3GPP.29.229]
is an example of a pseudo-session application.

OK?

Regards,

Lionel

-----Message d'origine-----
De : Jouni Korhonen [mailto:jouni.nospam@gmail.com] 
Envoyé : vendredi 29 novembre 2013 10:01
À : MORAND Lionel IMT/OLN
Cc : dime@ietf.org list
Objet : Re: [Dime] open issues #1 in DOIC


  Pseudo-session applications:

     While this class of application does not use the Diameter
     Session-ID AVP to correlate requests, there is an implied ordering
     of transactions defined by the application and except for the
     Session-ID differences pseudo-session based applications are
     generally assumed to behave like session-based application.  The
     3GPP defined Cx application [3GPP.29.229] is an example of a
     pseudo-session application.


Would this suffice?

- Jouni



On Nov 29, 2013, at 10:38 AM, lionel.morand@orange.com wrote:


Hi,

For me, "pseudo-session" refers to session-based oriented applications that do not rely on the session-id for message correlations but on something else e.g. user-name. So it is implied that the same server is contacted by the client managing the session. In the Cx example, the same origin-host will be used in the client-initiated requests after the initial exchange and the server discovery phase.

Regards,

Lionel 

-----Message d'origine-----
De : DiME [mailto:dime-bounces@ietf.org] De la part de Jouni Korhonen
Envoyé : vendredi 29 novembre 2013 09:30
À : dime@ietf.org list
Objet : [Dime] open issues #1 in DOIC

Folks,

         [OpenIssue: Do we assume that all requests in a pseudo-session
         typically need to go to the same server?]


The example here is in context of Cx. Not that I am expert on Cx (or anything)
but based on the CCF the requests _may_ have destination-host. Thus, I assume
that it is an implementation issue whether pseudo-sessions need to go to the
same server.. I guess we cannot have such firm requirement. Correct?

- Jouni
_______________________________________________
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

--------------050001040201080106060308-- From jouni.nospam@gmail.com Mon Dec 2 07:45:52 2013 Return-Path: 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 99FDE1A1F72 for ; Mon, 2 Dec 2013 07:45:52 -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 y2XJupXCYl62 for ; Mon, 2 Dec 2013 07:45:51 -0800 (PST) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id A49FB1A1F6F for ; Mon, 2 Dec 2013 07:45:50 -0800 (PST) Received: by mail-la0-f43.google.com with SMTP id n7so8234272lam.2 for ; Mon, 02 Dec 2013 07:45:47 -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=6Ua2+1/sEzZpkPlT44lmhi8lxLMk0aWlZWSqNqQUh34=; b=Qvo70/mRx/InGhy/KlSEPtLKqqeOU8znuulKUWwl/LMLEwZo+OXEb8uyeerTQ7RQHH KXUGzAVizzxEfZSs5HwvETAFANjQD9whQiVFNCUcNcPseqbzM5OqPuwWQDO8rhxq++qo dM79g9NfVyJPPDd19jwEjQKcNNp/Ss4H4HfjZcTjH1ECYwsY8zcGyn8FWBRe6He5r/tr fyrndyA6hlAh0ZCFNIgspLaFSwMCWL52Xde1XejvL/gO1ZommfIKnSJI2DV2kXrkvgV+ a92tL+AHNmtXIc1fFw9w8d1Dfqg+oCtdMhVJm3xs65ryYn2P1Q6tAjm3xnLC+SifEvgQ DE9g== X-Received: by 10.152.4.230 with SMTP id n6mr45360896lan.1.1385999147648; Mon, 02 Dec 2013 07:45:47 -0800 (PST) Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id ld10sm10373078lab.8.2013.12.02.07.45.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 02 Dec 2013 07:45:42 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <529CAA39.6050809@usdonovans.com> Date: Mon, 2 Dec 2013 17:45:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <16E13E52-0DB9-4E72-964A-FE658536155B@gmail.com> <10629_1385971488_529C3F20_10629_5138_1_emlwd34vyt318xrd8i01xiee.1385971482719@email.android.com> <529CAA39.6050809@usdonovans.com> To: Steve Donovan X-Mailer: Apple Mail (2.1510) Cc: dime@ietf.org Subject: Re: [Dime] draft-ietf-dime-ovli-01 questions #1 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 15:45:52 -0000 Ok. I'll put references to PCC. Would NAI based "source routing" qualify here as an example i.e. RFC5729? - Jouni On Dec 2, 2013, at 5:41 PM, Steve Donovan = wrote: > The PCC architecture, where agents route based on pre-existing = bindings is another example. >=20 > Steve > On 12/2/13 2:04 AM, lionel.morand@orange.com wrote: >> It was my understanding. >>=20 >> Envoy=E9 depuis mon Sony Xperia SP d'Orange >>=20 >> Jouni Korhonen=20 >> >> a =E9crit : >>=20 >>=20 >> Hi, >>=20 >> In Section 2 on Diameter routing it says: >>=20 >> defined in [RFC6733]. Application level routing specifications >> that expand on [RFC6733] also exist. >>=20 >> What does this "expand" actually refer to? RFC5729? RFC7075? >>=20 >> - Jouni >> _______________________________________________ >> DiME mailing list >>=20 >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >>=20 >>=20 >> = __________________________________________________________________________= _______________________________________________ >>=20 >> 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. >>=20 >> 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. >>=20 >> _______________________________________________ >> DiME mailing list >>=20 >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >>=20 >>=20 >>=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From srdonovan@usdonovans.com Mon Dec 2 07:54:40 2013 Return-Path: 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 22C061A1F1A for ; Mon, 2 Dec 2013 07:54:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no 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 mzPiEDD6apzp for ; Mon, 2 Dec 2013 07:54:36 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 176E61A802B for ; Mon, 2 Dec 2013 07:54:36 -0800 (PST) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:64552 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1VnVpP-0007aV-JK for dime@ietf.org; Mon, 02 Dec 2013 07:54:33 -0800 Message-ID: <529CAD37.2060906@usdonovans.com> Date: Mon, 02 Dec 2013 09:54:31 -0600 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: dime@ietf.org References: , <2901_1385634414_52971A6E_2901_2686_1_6B7134B31289DC4FAF731D844122B36E307743@PEXCVZYM13.corporate.adroot.infra.ftgroup> <30095_1385647765_52974E95_30095_213_1_6B7134B31289DC4FAF731D844122B36E307DF6@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060008060708070804060809" X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same type) within a response message X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 15:54:40 -0000 This is a multi-part message in MIME format. --------------060008060708070804060809 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Nirav, I agree with Lionel that what you propose would result in either a new report-type or abatement algorithm. There needs to be a way of telling the reacting node why the new AVP is present. There could be, for instance, two different extensions that need the same AVP included in the overload report. We need a way of indicating to the reacting node which of those extensions should be used. Steve On 11/28/13 10:11 AM, Nirav Salot (nsalot) wrote: > > Hi Lionel, > > > > I am not sure if defining new ReportType for every new AVP 3GPP would > add for a specific application would be a good solution. > > I thought ReportType would indicate if the corresponding OC-OLR should > be used while sending the traffic towards the host or towards the realm. > > So from that point of view, all the OC-OLR generated by the server > should have ReportType=host. i.e. when the reacting node sends the > traffic towards that host, it should make use of the corresponding > OC-OLR. Now, this OC-OLR may contain the AVPs defined by DOIC draft as > well as 3GPP application specific AVPs. > > > > In general, I was just thinking that it may be good idea to define > some of the principles such as > > - More than one instances of OC-OLR with ReportType=host may > be present in the answer message if the OC-OLR definition is extended > by the application using the same. In that case, it is the > responsibility of the application to define the valid combination of > OC-OLR instances in a given message > > - If the reporting node includes more than one instance of > OC-OLR, the reporting node shall always include all the active > instances of OC-OLR in a response message. > > - When the reacting node receives one or more instances of > OC-OLR with the given ReportType and with new timestamp value, it > should overwrite all the existing OC-OLR of the same ReportType. > > > > Regards, > > Nirav. > > > > *From:*lionel.morand@orange.com [mailto:lionel.morand@orange.com] > *Sent:* Thursday, November 28, 2013 7:39 PM > *To:* Nirav Salot (nsalot) > *Cc:* dime@ietf.org > *Subject:* RE: DOIC: Multiple instance of OC-OLR AVP (of the same > type) within a response message > > > > Hi Nirav, > > > > The Report Type should be able to differentiate such cases. In your > example, I would define a specific Report type. > > But difficult to appraise all the future use cases. But for me, the > main use of the report type is to differentiate OC-OLR received in the > same message. > > And it is the reasons of my recommendation. Actually, the exact > wording will be a "SHOULD" saying that it is recommended but you may > have serious reasons to do otherwise. > > > > Lionel > > > > *De :*Nirav Salot (nsalot) [mailto:nsalot@cisco.com] > *Envoyé :* jeudi 28 novembre 2013 13:00 > *À :* MORAND Lionel IMT/OLN > *Cc :* dime@ietf.org > *Objet :* RE: DOIC: Multiple instance of OC-OLR AVP (of the same type) > within a response message > > > > Lionel, > > 3gpp may define an optional avp which can be included by the reporting > node if it wishes to do so. E.g. APN can be additionally included by > the reporting node to indicate APN specific overload within the given > application. > In that case, the reporting node may also want to indicate application > level overload without including the APN (e.g. this overload report is > applicable to all other APNs). > > And hence there is a possibility of including multiple instances of > the overload report. > > I am not suggesting that 3gpp will define APN (or any other avp) > within overload report. But later, if 3gpp need to define the same, > then corresponding handling needs to be defined within IETF now. > > Regards, > Nirav. > > On Nov 28, 2013 3:56 PM, "lionel.morand@orange.com > " > wrote: > > Hi Nirav, > > > > Not sure to understand the proposal or question. > > The OLR is significant per application (piggybacking principle). So if > the 3GPP decides to add specific AVPs in the OLR (that will be > possible), what would be the need to add the OLR without the specific > 3GPP AVPs as the OLR will be anyway handle by 3GPP aware entities? > > > > Lionel > > > > *De :*DiME [mailto:dime-bounces@ietf.org] *De la part de* Nirav Salot > (nsalot) > *Envoyé :* jeudi 28 novembre 2013 10:33 > *À :* dime@ietf.org > *Objet :* [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same > type) within a response message > > > > Hi, > > > > As I understand IETF will define the base overload control solution as > part of DOIC. Then 3GPP would adopt the defined solution for each of > its application. > > When that happens, 3GPP might want to add 3GPP specific AVP within > OC-OLR AVP. Based on the current definition of the OC-OLR AVP this > should be allowed since it contains "* [AVP]" in its definition. > > e.g. for a given application 3GPP decides to add information into > OC-OLR which changes the scope of the OC-OLR from application level to > the provided information level. > > Additionally, the reporting may want to advertise the OC-OLR at the > application level scope -- i.e. the OC-OLR without any 3GPP specific info. > > > > So if the above is allowed, we will have the possibility of the > reporting node wanting to include two instances of OC-OLR with the > Report-Type="host". > > And then we need to define the handling of multiple instances of > OC-OLR in the DOIC draft. > > > > So the questions are, > > - Is 3GPP (or any other SDO) allowed to extend the definition > of OC-OLR by adding information into it? > > - If no, can we guarantee that application level scope of > OC-OLR (which is what we have defined currently) is sufficient (and > not restricting) to all the applications of 3GPP? > > > > Regards, > > Nirav. > > > > _________________________________________________________________________________________________________________________ > > 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 --------------060008060708070804060809 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Nirav,

I agree with Lionel that what you propose would result in either a new report-type or abatement algorithm.  There needs to be a way of telling the reacting node why the new AVP is present.  There could be, for instance, two different extensions that need the same AVP included in the overload report.  We need a way of indicating to the reacting node which of those extensions should be used.

Steve
On 11/28/13 10:11 AM, Nirav Salot (nsalot) wrote:

Hi Lionel,

 

I am not sure if defining new ReportType for every new AVP 3GPP would add for a specific application would be a good solution.

I thought ReportType would indicate if the corresponding OC-OLR should be used while sending the traffic towards the host or towards the realm.

So from that point of view, all the OC-OLR generated by the server should have ReportType=host. i.e. when the reacting node sends the traffic towards that host, it should make use of the corresponding OC-OLR. Now, this OC-OLR may contain the AVPs defined by DOIC draft as well as 3GPP application specific AVPs.

 

In general, I was just thinking that it may be good idea to define some of the principles such as

-          More than one instances of OC-OLR with ReportType=host may be present in the answer message if the OC-OLR definition is extended by the application using the same. In that case, it is the responsibility of the application to define the valid combination of OC-OLR instances in a given message

-          If the reporting node includes more than one instance of OC-OLR, the reporting node shall always include all the active instances of OC-OLR in a response message.

-          When the reacting node receives one or more instances of OC-OLR with the given ReportType and with new timestamp value, it should overwrite all the existing OC-OLR of the same ReportType.

 

Regards,

Nirav.

 

From: lionel.morand@orange.com [mailto:lionel.morand@orange.com]
Sent: Thursday, November 28, 2013 7:39 PM
To: Nirav Salot (nsalot)
Cc: dime@ietf.org
Subject: RE: DOIC: Multiple instance of OC-OLR AVP (of the same type) within a response message

 

Hi Nirav,

 

The Report Type should be able to differentiate such cases. In your example, I would define a specific Report type.

But difficult to appraise all the future use cases. But for me, the main use of the report type is to differentiate OC-OLR received in the same message.

And it is the reasons of my recommendation. Actually, the exact wording will be a "SHOULD" saying that it is recommended but you may have serious reasons to do otherwise.

 

Lionel

 

De : Nirav Salot (nsalot) [mailto:nsalot@cisco.com]
Envoyé : jeudi 28 novembre 2013 13:00
À : MORAND Lionel IMT/OLN
Cc : dime@ietf.org
Objet : RE: DOIC: Multiple instance of OC-OLR AVP (of the same type) within a response message

 

Lionel,

3gpp may define an optional avp which can be included by the reporting node if it wishes to do so. E.g. APN can be additionally included by the reporting node to indicate APN specific overload within the given application.
In that case, the reporting node may also want to indicate application level overload without including the APN (e.g. this overload report is applicable to all other APNs).

And hence there is a possibility of including multiple instances of the overload report.

I am not suggesting that 3gpp will define APN (or any other avp) within overload report. But later, if 3gpp need to define the same, then corresponding handling needs to be defined within IETF now.

Regards,
Nirav.

On Nov 28, 2013 3:56 PM, "lionel.morand@orange.com" <lionel.morand@orange.com> wrote:

Hi Nirav,

 

Not sure to understand the proposal or question.

The OLR is significant per application (piggybacking principle). So if the 3GPP decides to add specific AVPs in the OLR (that will be possible), what would be the need to add the OLR without the specific 3GPP AVPs as the OLR will be anyway handle by 3GPP aware entities?

 

Lionel

 

De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot (nsalot)
Envoyé : jeudi 28 novembre 2013 10:33
À : dime@ietf.org
Objet : [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same type) within a response message

 

Hi,

 

As I understand IETF will define the base overload control solution as part of DOIC. Then 3GPP would adopt the defined solution for each of its application.

When that happens, 3GPP might want to add 3GPP specific AVP within OC-OLR AVP. Based on the current definition of the OC-OLR AVP this should be allowed since it contains "* [AVP]" in its definition.

e.g. for a given application 3GPP decides to add information into OC-OLR which changes the scope of the OC-OLR from application level to the provided information level.

Additionally, the reporting may want to advertise the OC-OLR at the application level scope – i.e. the OC-OLR without any 3GPP specific info.

 

So if the above is allowed, we will have the possibility of the reporting node wanting to include two instances of OC-OLR with the Report-Type="host".

And then we need to define the handling of multiple instances of OC-OLR in the DOIC draft.

 

So the questions are,

-          Is 3GPP (or any other SDO) allowed to extend the definition of OC-OLR by adding information into it?

-          If no, can we guarantee that application level scope of OC-OLR (which is what we have defined currently) is sufficient (and not restricting) to all the applications of 3GPP?

 

Regards,

Nirav.

 

_________________________________________________________________________________________________________________________
 
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

--------------060008060708070804060809-- From maria.cruz.bartolome@ericsson.com Mon Dec 2 07:55:32 2013 Return-Path: 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 42D671ABBB1 for ; Mon, 2 Dec 2013 07:55:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 CMs783OMtnqQ for ; Mon, 2 Dec 2013 07:55:27 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6989F1A1F72 for ; Mon, 2 Dec 2013 07:55:26 -0800 (PST) X-AuditID: c1b4fb2d-b7f1c8e000005ceb-7b-529cad6bdd8b Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 91.B5.23787.B6DAC925; Mon, 2 Dec 2013 16:55:23 +0100 (CET) Received: from ESESSMB101.ericsson.se ([169.254.1.118]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.02.0347.000; Mon, 2 Dec 2013 16:55:22 +0100 From: Maria Cruz Bartolome To: "dime@ietf.org list" Thread-Topic: [Dime] DOIC: Self-Contained OLRs Thread-Index: AQHO67/t2PaAGa/GgUyaCwjRxXVUh5o5m/0AgAC8o/D///ghgIAAFu+wgAGHVQCAACqasIAAMwWAgANxipCAAKJuAIAATHjQgAAM5ICAABPPEIAAFwqAgAAGBICAAAUigIAAJC3w Date: Mon, 2 Dec 2013 15:55:21 +0000 Message-ID: <087A34937E64E74E848732CFF8354B920972B9AE@ESESSMB101.ericsson.se> References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D90006681519BC90@DEMUMBX014.nsn-intra.net> <6390_1385631044_52970D44_6390_18593_1_6B7134B31289DC4FAF731D844122B36E30748E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BD19@DEMUMBX014.nsn-intra.net> <17872_1385720008_529868C8_17872_2613_1_6B7134B31289DC4FAF731D844122B36E3096B8@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BF1B@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681519BFAE@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681519C017@DEMUMBX014.nsn-intra.net> , <5BCBA1FC2B7F0B4C9D935572D90006681519C087@DEMUMBX014.nsn-intra.net> <16844_1385993987_529C9702_16844_18637_1_6B7134B31289DC4FAF731D844122B36E310C3F@PEXCVZYM13.corporate.adroot.infra.ftgroup> <02B93103-E094-4E5D-B6E0-5564115A9E0D@gmail.com> In-Reply-To: <02B93103-E094-4E5D-B6E0-5564115A9E0D@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBLMWRmVeSWpSXmKPExsUyM+JvrW722jlBBif3qVnM7V3B5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujA2XVrEWdB1hrGh/+IW5gXHZfMYuRk4OCQETiYYbF9ghbDGJ C/fWs4HYQgKHGCXe3IjrYuQCshczSnT9e88MkmATsJO4dPoFUxcjB4eIgIbEihOZIGFhAV2J bac+gJWICOhJvDi5kgmkV0RgGqPEmssLWUDqWQRUJM5P1AWp4RXwlfh97jQrxPxTnBKvf/9g AUlwCthKLP7/FcxmBDro+6k1TCA2s4C4xK0n85kgDhWQWLLnPDOELSrx8vE/VghbUaL9aQMj RL2exI2pU9ggbG2JZQtfM0MsFpQ4OfMJywRG0VlIxs5C0jILScssJC0LGFlWMbLnJmbmpJcb bmIEhv7BLb91dzCeOidyiFGag0VJnPfDW+cgIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYwT rDz44rSuJD1eqzktIK1I+9XyE1/l8/4lpV0LXii0nkFg9XneldvLlV7uXhx0Vf63/Scdpum5 BfbtMbJSz1fZt2YwnHtpNnumUvOioD/GU7KFrrEY7nqX2/RRhC/eMux2ya6KPfqKvssCub2v pBduOF4duy9+hzGrZZDcHG45BcnDD9T2SimxFGckGmoxFxUnAgA92ZuLSwIAAA== 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 15:55:32 -0000 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 no= rmal behavior. But I agree in case the request is towards a Destination Host, receiving th= e 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 no= de 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 t= he 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 o= n the need for the Report-Type. > =20 > 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 De= stination-Host is not in the answer. So receiving a host-based OLR in respo= nse 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 pos= itive 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" of= fered 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 th= e client could include a destination-host or not. So the client needs to kn= ow which reduction to apply from a previous answer. > =20 > 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 co= ntext based on the type of request. > =20 > Regards, > =20 > Lionel > =20 > =20 > De : Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Envoy=E9 : lundi 2=20 > d=E9cembre 2013 14:58 =C0 : Wiehe, Ulrich (NSN - DE/Munich) Cc :=20 > dime@ietf.org list; ext Jouni Korhonen; MORAND Lionel IMT/OLN; Ben=20 > Campbell Objet : RE: [Dime] DOIC: Self-Contained OLRs > =20 > Ulrich, >=20 > 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? >=20 > I would prefer to derive the context of the OLR based on the message whic= h contains the OLR. >=20 > Back to the topic of this thread, I don't think we need to define an "opt= ional" optimization at this stage. Either it is respected by all the nodes = supporting the solution or we drop that optimization. >=20 > Regards, > Nirav. >=20 > On Dec 2, 2013 5:27 PM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: > Nirav, >=20 > If the reacting node sends a request without Destination Host, a realm-ty= pe OLR in the answer would be in-context whereas a host-type OLR in the ans= wer would be out of context. >=20 > Similarly, if the reacting node sends a request containing Destination Ho= st, a realm-type OLR in the answer would be out-of-context and a host-type = OLR in the answer would be in-context. >=20 > Ulrich >=20 >=20 >=20 > -----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=20 > Jouni Korhonen; Ben Campbell > Cc: dime@ietf.org list > Subject: RE: [Dime] DOIC: Self-Contained OLRs >=20 > Ulrich, >=20 > I have a basic question. >=20 > When the reacting node sends realm-routed request and it receives (only o= ne) OLR in the response message (which also contains the origin-host), is t= his OLR applicable for realm or host? > I am trying to understand which is out-of-context OLR here: realm-type or= host-type? >=20 > Regards, > Nirav. >=20 > -----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=20 > Korhonen; Ben Campbell > Cc: dime@ietf.org list > Subject: RE: [Dime] DOIC: Self-Contained OLRs >=20 > Hi Nirav, >=20 > please see inline. >=20 > Regards > Ulrich >=20 > -----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=20 > Jouni Korhonen; Ben Campbell > Cc: dime@ietf.org list > Subject: RE: [Dime] DOIC: Self-Contained OLRs >=20 > Ulrich, >=20 > When the client sends request containing destination-realm (and not conta= ining 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 thi= s response message is not out-of-context information.=20 > [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= =3Dx1, destination realm =3Dx2 application=3D 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, w= hat the type x was. E.g. it deduces from the value of Origin Realm in the a= nswer the value of Destination Realm in the request; it deduces from the va= lue of Report-Type in the answer whether Destination Host was present in th= e request... >=20 > On the other hand, we discussed - as part of Maria Cruz's alternative sol= ution - to define the response message's context based on the request messa= ge. And hence if the request message was sent to destination-realm, the cor= responding 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 unneces= sary complexity.=20 > [Wiehe, Ulrich (NSN - DE/Munich)] I agree. This means: the report-type AV= P is needed to let the client deduce from information received in the answe= r whether the request contained a destination host. It does not mean that w= e need two OLRs in one answer. >=20 > If we strictly want to ensure that the realm-type OLR is not sent=20 > out-of-context [Wiehe, Ulrich (NSN - DE/Munich)] That was not my=20 > proposal. My proposal was to clearly mark out-of-context OLRs in=20 > answer messages (if we allow including out-of-context OLRs) >=20 > , then we should agree to Lionel's alternative solution - to send realm-t= ype OLR only when the destination-realm based request is rejected. So basic= ally, 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 ensu= re the context of the response message and the OLR it contains). >=20 > 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 on= e 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=20 > (NSN - DE/Munich)] only the out-of-context one >=20 > , then what is the point of including two OLRs [Wiehe, Ulrich (NSN - DE/M= unich)] 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 a= s 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 react= ing node (if the reacting node wants to make use of this optimization). >=20 > and what is the point of defining Report-Type AVP? > [Wiehe, Ulrich (NSN - DE/Munich)] to let the reacting node deduce from in= formation received in the answer whether the corresponding request containe= d a destination host (so there is no need to remember). >=20 >=20 > In summary, if we define Report-Type AVP and corresponding handling at th= e reacting node, the reacting node must act accordingly and not ignore it. > [Wiehe, Ulrich (NSN - DE/Munich)] What goes wrong when out-of -context O= LR is ignored? >=20 > 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 i= gnored. > [Wiehe, Ulrich (NSN - DE/Munich)] Not the Report-Type AVP is the optimiza= tion but the incusion of out-of-context OLRs. And I'm ok not to proceed wit= h this optimization as it is not needed. >=20 > Regards, > Nirav. >=20 > -----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=20 > Korhonen; Ben Campbell > Cc: dime@ietf.org list > Subject: RE: [Dime] DOIC: Self-Contained OLRs >=20 > Hi Nirav, >=20 > 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-contex= t. > There is nothing wrong with storing such out-of-context OLRs at the clien= t, but it is simply not needed as the client will learn this OLR from respo= nses received within the context. >=20 > Best regards > Ulrich >=20 >=20 > -----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=20 > Jouni Korhonen; Ben Campbell > Cc: dime@ietf.org list > Subject: RE: [Dime] DOIC: Self-Contained OLRs >=20 > Hi Ulrich, >=20 > If an additional OLR is present with a different ReportType, why it shoul= d be ignored by the reacting node? >=20 > Regards, > Nirav. >=20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich=20 > (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 >=20 > Hi Lionel, >=20 > there is nothing missing exept the clarification that everything works fi= ne 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. >=20 > Ulrich > =20 >=20 > -----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 >=20 > Hi Ulrich, >=20 > Using the Report Type "host report", you know that the OLR applies for su= bsequent 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.=20 >=20 > It is not so important to know what the type of request was and which nod= e 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, f= or instance, future development could allow a distributed server architectu= re to provide the same information. >=20 > I'm not sure of what is missing in this reasoning... >=20 > Lionel >=20 > -----Message d'origine----- > De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 > Envoy=E9 : jeudi 28 novembre 2013 11:30 =C0 : MORAND Lionel IMT/OLN; ext= =20 > Jouni Korhonen; Ben Campbell Cc : dime@ietf.org list Objet : RE:=20 > [Dime] DOIC: Self-Contained OLRs >=20 > Lionel, >=20 > my understanding was that _the_ reporting end point provides _the_ OLR. >=20 > If we go for two OLRs in the answer we should indicate which OLR is the a= ctual OLR created by the reporting end point and which OLR is an additional= OLR created by another node. >=20 > We have two cases: > a) The request sent by the client (reacting end point) contains no Destin= ation 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 OL= R as learned from the selected server. The client may ignore the additiona= l OLR. > b) The request sent by the client (reacting endpoint) contains the Destin= ation Host. The Server (reporting node) returns a host-type OLR as the actu= al reporting-node-created OLR in the answer. The agent may optionally inser= t a realm-type OLR as additional OLR to the answer. The client may ignore t= he additional OLR. >=20 > Ulrich >=20 >=20 >=20 > -----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 >=20 > Hi, >=20 > There is no assumption on which entity is providing the realm overload st= atus. 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 s= ome 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 ser= ver itself, one for the realm for new request sent to the realm with only D= est-Realm AVP. >=20 > Lionel >=20 > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich=20 > (NSN - DE/Munich) Envoy=E9 : jeudi 28 novembre 2013 10:26 =C0 : ext Jouni= =20 > Korhonen; Ben Campbell Cc : dime@ietf.org list Objet : Re: [Dime]=20 > DOIC: Self-Contained OLRs >=20 > Hi, >=20 > 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 i= ndicates 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 indicate= s to the reacting end point that the reporting end point is a server. How c= an the reporting end point be both agent and server? >=20 > Ulrich >=20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Jouni=20 > Korhonen > Sent: Wednesday, November 27, 2013 11:44 PM > To: Ben Campbell > Cc: dime@ietf.org list > Subject: Re: [Dime] DOIC: Self-Contained OLRs >=20 >=20 > On Nov 28, 2013, at 12:27 AM, Ben Campbell wrote: >=20 > > Hi, > >=20 > > I mentioned in another thread that I prefer putting an explicit=20 > > ReportType AVP in an OLR, rather than >=20 > The more I spent time thinking/writing the actual procedures on the endpo= ints, the more it makes sense to me to keep the ReportType in the OC-OLR. E= ven if the baseline does not have agent overload etc, the ReportType fits w= ell 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 pl= ain more clear. >=20 > I skip the rest of the mail.. too much text ;-) >=20 >=20 > - Jouni >=20 >=20 >=20 >=20 >=20 > > making a responding node infer the type or meaning of the OLR from a Di= ameter request that corresponds to the answer containing the OLR. My reason= s for that go beyond just ReportType, so I'm starting a separate thread. > >=20 > > 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 t= hat carries the OLR. For example, the OLR implicitly refers to the applicat= ion identified by the Application-Id field of the enclosing answer, the rea= lm 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 mea= ning in the context of the enclosing answer. If you moved an OLR from one a= nswer to another, it's meaning may change completely. > >=20 > > I think this approach is a mistake. I would greatly prefer that we expl= icitly include such values in the OLR itself, for multiple reasons: > >=20 > > 1) It's more complex to interpret implicit, contextual values than expl= icit values. The consumer cannot simply look at the OLR; it must look in va= rious other AVPs to find all the information it needs. For example, I think= a common software design for overload control processing to be separated f= rom 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 OL= R, 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 "c= ontext" avps that must be interpreted can grow large. This approach is erro= r prone, and will likely encourage brittle, hard-to-maintain code. Self-con= tained OLRs would keep all the information related to overload in one place= . making for simpler implementations. > >=20 > > 2) It's more complex for the reporting node to send implicit values tha= n explicit values. The sender cannot simply set the context to match the OL= R--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 ins= ert OLRs into answers created by other nodes.=20 > >=20 > > If the reporting node screws this up, the meaning of the OLR may change= significantly. So again, implicit meaning gives us error prone implementat= ions. Self-contained OLRs are simpler to create and send. > >=20 > > 3) Implicit values don't work at all for certain problems. For=20 > > example, if an agent needs to originate an OLR, it typically needs=20 > > to insert that OLR into an existing Diameter answer created by a server= . > > It can't create its own answer without affecting the application=20 > > state. If the responding node assumes the OLR comes from or refers=20 > > to the node identified by the Origin-Host AVP in the enclosing=20 > > answer, things break. (For examples of when an agent needs to send=20 > > OLRs that are distinct from those sent by a server, see Steve's=20 > > agent overload draft, or my dh/dr example.) > >=20 > > OTOH, explicit values will work for all cases where we need to associat= e some arbitrary value with an OLR. > >=20 > > 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 ov= erload 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 trans= ported, this won't work. We would have to create a new or significantly mod= ified OLR format if we found a need to transport OLRs in different ways. Se= lf-contained OLRs would allow much greater flexibility. > >=20 > > 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. > >=20 > > Thanks! > >=20 > > Ben. > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime >=20 > _______________________________________________ > 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 >=20 > ______________________________________________________________________ > ___________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc pas etre diffuses, exploites o= u copies sans autorisation. Si vous avez recu ce message par erreur, veuill= ez 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= . >=20 > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; they should not be distributed, us= ed or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 >=20 > ______________________________________________________________________ > ___________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc pas etre diffuses, exploites o= u copies sans autorisation. Si vous avez recu ce message par erreur, veuill= ez 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= . >=20 > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; they should not be distributed, us= ed or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > ______________________________________________________________________ > ___________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not be d= istributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From maria.cruz.bartolome@ericsson.com Mon Dec 2 07:57:44 2013 Return-Path: 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 042B81A802B for ; Mon, 2 Dec 2013 07:57:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no 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 e_9EFvxc24O3 for ; Mon, 2 Dec 2013 07:57:41 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 044A91A1F7D for ; Mon, 2 Dec 2013 07:57:40 -0800 (PST) X-AuditID: c1b4fb32-b7f388e0000057e0-2f-529cadf1ac02 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 83.A6.22496.1FDAC925; Mon, 2 Dec 2013 16:57:38 +0100 (CET) Received: from ESESSMB101.ericsson.se ([169.254.1.118]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.02.0347.000; Mon, 2 Dec 2013 16:57:37 +0100 From: Maria Cruz Bartolome To: "dime@ietf.org" Thread-Topic: [Dime] DOIC: Self-Contained OLRs Thread-Index: AQHO67/s/vGpiVuf2UayvwQoJbzwfZo6EVYAgACzUoCAAAFygIAAE10AgAF8EQD//7X5YIAAK7CAgAAJY4CABNXLIA== Date: Mon, 2 Dec 2013 15:57:36 +0000 Message-ID: <087A34937E64E74E848732CFF8354B920972B9BE@ESESSMB101.ericsson.se> References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D90006681519BC90@DEMUMBX014.nsn-intra.net> <6390_1385631044_52970D44_6390_18593_1_6B7134B31289DC4FAF731D844122B36E30748E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BD31@DEMUMBX014.nsn-intra.net> <47383DC2-1A1B-4D1A-ADD5-9E3CE60B06C8@gmail.com> <8467_1385735507_5298A553_8467_17054_3_6B7134B31289DC4FAF731D844122B36E309D0D@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUyM+Jvre6ntXOCDE7u5bKY27uCzYHRY8mS n0wBjFFcNimpOZllqUX6dglcGQ87FzAXfGhgrJh66R9rA2NfZhcjJ4eEgInEhYnLWCBsMYkL 99azdTFycQgJnGCUONN5nhXCWcwocfzNezaQKjYBO4lLp18wdTFycIgIKEuc/uUAEhYW0JXY duoDM4gtIqAn8eLkSiYIO0viTPt/VhCbRUBF4tTSj2DLeAV8Jf4+XcEOMX8Pq8TMfS/BEpwC sRL7D18Ba2YEuuj7qTVgNrOAuMStJ/OZIC4VkFiy5zwzhC0q8fLxP1YIW1Gi/WkDI0S9nsSN qVPYIGxtiWULXzNDLBaUODnzCcsERtFZSMbOQtIyC0nLLCQtCxhZVjFKFqcWF+emGxno5abn luilFmUmFxfn5+kVp25iBMbHwS2/jXYwntxjf4hRmoNFSZz3OmtNkJBAemJJanZqakFqUXxR aU5q8SFGJg5OqQZGmQ0apnlTzG4/MWvSUVObUy/ksGaKsL9RSkbfGVETw2s6Rcc/R0ZmqWvK tXUZxGQf/5DP8SdwjXfF22lpIka+OUpFbsoF7akhCm9aGqWrcx97B034xDBD8Gyp6N9HT+fe eimyYa6Nimdoll7urYOOPgJLi1YeDtVKrxM3j2IxuK7Z/ezdKiWW4oxEQy3mouJEAGH2xFNd AgAA 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 15:57:44 -0000 Dear all, About self-contained OLRs, I agree with Nirav, Lionel and JJ. Duplication of information should be avoided, once we have considered piggy= backing as the overload info conveyance mechanism. Best regards /MCruz -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE= S (JEAN-JACQUES) Sent: viernes, 29 de noviembre de 2013 16:05 To: dime@ietf.org Subject: Re: [Dime] DOIC: Self-Contained OLRs Dear all In the baseline mechanism as currently defined in the draft, the OLR conten= t is simple, and is related to the message conveying it in particular appli= cation origin host/realm and destination to which the OLR is sent back. As= Lionel indicated, it is not so important to know which node inserts the OL= R or to have other information. =20 There is a performance aspect to consider: the OLRs defined in the baseline= may be frequently sent (in particular to compensate possible message los= ses and to manage the loopback to the reporting node ensuring the quick con= vergence towards the optimal throughput). So we have to minimize the proces= sing of these OLRs. As OLRs are piggybacked in the relevant messages, the= y may be simply forwarded in the same message by the DAs on the path except= if there are particular reasons a DA to act on them. =20 I am cautious about duplication of information, it always means additional = checks to ensure consistency. If the OLR has an application id and origin= host different from the message conveying it, what to do with this OLR, i= s it an error case? or should it be put in another message in the path? Our= current piggybacking mechanism allows the OLR to remain in the same messag= e from the reporting node to the reacting node.=20 An important point is extensibility, as we may have to introduce other typ= e of OLRs, additional AVPs, more sophisticated processing, but these extens= ions should not impact the baseline mechanism by making the baseline more = complex. the current draft allows extensions without impacting the baseline= . Currently I do not see drawbacks on the OLRs defined for the baseline mecha= nism. So my comments join the Nirav and Lionel's ones. Best regards=20 JJacques=20 -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de lionel.morand@oran= ge.com Envoy=E9=A0: vendredi 29 novembre 2013 15:32 =C0=A0: Nirav Salot (ns= alot); Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list = Cc=A0: Ben Campbell Objet=A0: Re: [Dime] DOIC: Self-Contained OLRs I totally agree with Nirav. No need to revert at this stage the working ass= umption on piggybacking of OLR in application answer messages, especially w= hen the aim is to define a basic mechanism called "reduction". Anyone would be able to further add extra info for optimization if needed b= ut there is no need at all for the basic mechanism. Regards, Lionel -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot (nsalo= t) Envoy=E9=A0: vendredi 29 novembre 2013 12:24 =C0=A0: Jouni Korhonen; Wie= he, Ulrich (NSN - DE/Munich); dime@ietf.org list Cc=A0: Ben Campbell Objet= =A0: Re: [Dime] DOIC: Self-Contained OLRs Jouni, Ben, I am totally against the idea of self-contained OC-OLR specifically since w= e have adopted the principles of piggybacking the OC-OLR over existing appl= ication message. Self-contained OC-OLR - which means adding all the information which define= s the scope of the OC-OLR into the OC-OLR - does not make sense in the pigg= ybacking approach. In fact, it is adding lot of information, which is anywa= y available within the message containing the OC-OLR, into the OC-OLR. So i= t is adding lot of redundant information in a message which increases the p= rocessing requirement for the sender as well as the receiver. (And this is = un-optimization, in my view). Besides, I am not convinced with the other reasons provided here: - One software module within a node can provide OC-OLR to another software = module in the same node without passing other related info Within a node, based on the design, lots of information may need to be p= assed between two software modules and we cannot optimize those aspects by = replicating unnecessary information in a protocol message. In summary, it is node's internal software design issue and we need not = optimize that at protocol level. - Once the reporting node realizes that it is overloaded, it has to wait fo= r right answer to send OC-OLR What is the point of sending OC-OLR for a context for which there is no m= essaging? Why should the reacting node care if it never sends a message for= a context for which the reporting node is overloaded? So this waiting is justified since it ensures that the overload is report= ed only when necessary and only to the applicable reacting node. Not to all= the nodes in the network. - The agent needs to wait for the answer generated by the server and the ri= ght context The same argument as applicable for the server applies here. The agent n= eed not send out-of-context overload info to a node. Why should reacting node receive/process/store the overload info for the= scope for which it is not sending any messages. - For sending OC-OLR in dedicated Diameter application??? Piggybacking was the first basic principle we agreed before putting other= principles in place. So we may want to go back the drawing board if we dec= ide to change this principle. Regards, Nirav. -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen Sent: Friday, November 29, 2013 2:50 PM To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list Cc: Ben Campbell Subject: Re: [Dime] DOIC: Self-Contained OLRs So, are we reaching any level of consensus here? - JOuni (as a note.. that we are converging back to where we started with OLRs ;) On Nov 28, 2013, at 12:40 PM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: > Hi, >=20 > another question: >=20 > If we go for explicit self contained OLRs, why would we then need the Rep= ortType? >=20 > The realm-type OLR would explicitly contain application-Id, Realm, but no= Host whereas the host-type OLR would explicitly contain application-Id, Ho= st, but probably (I'm not sure) no Realm. >=20 > Ulrich >=20 >=20 >=20 > -----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 >=20 > Hi, >=20 > There is no assumption on which entity is providing the realm overload st= atus. 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 s= ome 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 ser= ver itself, one for the realm for new request sent to the realm with only D= est-Realm AVP. >=20 > Lionel >=20 > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich=20 > (NSN - DE/Munich) Envoy=E9 : jeudi 28 novembre 2013 10:26 =C0 : ext Jouni= =20 > Korhonen; Ben Campbell Cc : dime@ietf.org list Objet : Re: [Dime] > DOIC: Self-Contained OLRs >=20 > Hi, >=20 > 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 i= ndicates 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 indicate= s to the reacting end point that the reporting end point is a server. How c= an the reporting end point be both agent and server? >=20 > Ulrich >=20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Jouni=20 > Korhonen > Sent: Wednesday, November 27, 2013 11:44 PM > To: Ben Campbell > Cc: dime@ietf.org list > Subject: Re: [Dime] DOIC: Self-Contained OLRs >=20 >=20 > On Nov 28, 2013, at 12:27 AM, Ben Campbell wrote: >=20 >> Hi, >>=20 >> I mentioned in another thread that I prefer putting an explicit=20 >> ReportType AVP in an OLR, rather than >=20 > The more I spent time thinking/writing the actual procedures on the=20 > endpoints, the more it makes sense to me to keep the ReportType in the=20 > OC-OLR. Even if the baseline does not have agent overload etc, the=20 > 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. >=20 > I skip the rest of the mail.. too much text ;-) >=20 >=20 > - Jouni >=20 >=20 >=20 >=20 >=20 >> making a responding node infer the type or meaning of the OLR from a Dia= meter request that corresponds to the answer containing the OLR. My reasons= for that go beyond just ReportType, so I'm starting a separate thread. >>=20 >> As currently described, a consumer of an OLR must infer several things f= rom other context. In most cases, that context is in the Diameter answer th= at carries the OLR. For example, the OLR implicitly refers to the applicati= on identified by the Application-Id field of the enclosing answer, the real= m identified by Origin-Realm, and so on. This means that the "meaning" of a= n OLR cannot be determined from the OLR contents alone; OLRs only have mean= ing in the context of the enclosing answer. If you moved an OLR from one an= swer to another, it's meaning may change completely. >>=20 >> I think this approach is a mistake. I would greatly prefer that we expli= citly include such values in the OLR itself, for multiple reasons: >>=20 >> 1) It's more complex to interpret implicit, contextual values than expli= cit values. The consumer cannot simply look at the OLR; it must look in var= ious other AVPs to find all the information it needs. For example, I think = a common software design for overload control processing to be separated fr= om 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 "co= ntext" avps that must be interpreted can grow large. This approach is error= prone, and will likely encourage brittle, hard-to-maintain code. Self-cont= ained OLRs would keep all the information related to overload in one place.= making for simpler implementations. >>=20 >> 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 inse= rt OLRs into answers created by other nodes.=20 >>=20 >> If the reporting node screws this up, the meaning of the OLR may change = significantly. So again, implicit meaning gives us error prone implementati= ons. Self-contained OLRs are simpler to create and send. >>=20 >> 3) Implicit values don't work at all for certain problems. For=20 >> example, if an agent needs to originate an OLR, it typically needs to=20 >> insert that OLR into an existing Diameter answer created by a server. >> It can't create its own answer without affecting the application=20 >> state. If the responding node assumes the OLR comes from or refers to=20 >> the node identified by the Origin-Host AVP in the enclosing answer,=20 >> things break. (For examples of when an agent needs to send OLRs that=20 >> are distinct from those sent by a server, see Steve's agent overload=20 >> draft, or my dh/dr example.) >>=20 >> OTOH, explicit values will work for all cases where we need to associate= some arbitrary value with an OLR. >>=20 >> 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 ove= rload reports were self-contained, one could just reuse the report format w= e specify here. But if the meaning of an OLR depends on the way it's transp= orted, this won't work. We would have to create a new or significantly modi= fied OLR format if we found a need to transport OLRs in different ways. Sel= f-contained OLRs would allow much greater flexibility. >>=20 >> So, in summary, I think that self-contained OLRs would lead to simpler i= mplementations, less brittle deployments, and more flexibility for future e= volution of standards. >>=20 >> Thanks! >>=20 >> Ben. >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >=20 > _______________________________________________ > 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 >=20 > ______________________________________________________________________ > ___________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not be d= istributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 _______________________________________________ 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 confiden= tielles 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. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation 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 dele= te 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 From srdonovan@usdonovans.com Mon Dec 2 07:58:49 2013 Return-Path: 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 125281A1F5B for ; Mon, 2 Dec 2013 07:58:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no 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 pbnBqkDecHQw for ; Mon, 2 Dec 2013 07:58:47 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 289C61A1F1A for ; Mon, 2 Dec 2013 07:58:47 -0800 (PST) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:64581 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1VnVtN-0004Ao-Gc for dime@ietf.org; Mon, 02 Dec 2013 07:58:44 -0800 Message-ID: <529CAE2D.8020600@usdonovans.com> Date: Mon, 02 Dec 2013 09:58:37 -0600 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: dime@ietf.org References: <50C72080-905C-4B1D-BAD8-C0026791BA6E@gmail.com> <6390_1385631299_52970E43_6390_18869_1_6B7134B31289DC4FAF731D844122B36E3074FC@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <6390_1385631299_52970E43_6390_18869_1_6B7134B31289DC4FAF731D844122B36E3074FC@PEXCVZYM13.corporate.adroot.infra.ftgroup> Content-Type: multipart/alternative; boundary="------------060604000700010004080105" X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com Subject: Re: [Dime] DOIC document size and placeholders X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 15:58:49 -0000 This is a multi-part message in MIME format. --------------060604000700010004080105 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit I would prefer to wait to drop the conformance section. Either that or keep it updated as a separate draft/document to keep us focused on the requirements. I agree on the S6a and PCC examples. Much of that information in already contained in either the requirements RFC or 3GGP DOC document. Steve On 11/28/13 3:34 AM, lionel.morand@orange.com wrote: > agreed > > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Jouni Korhonen > Envoyé : jeudi 28 novembre 2013 10:34 > À : dime@ietf.org list > Objet : [Dime] DOIC document size and placeholders > > Folks, > > We have some hefty sized appendices and some of the placeholders include no text. I was thinking whether we could just drop appendices on: > o Conformance to Requirements > o 3GPP S6a interface overload indication - example > o 3GPP PCC interfaces overload indication - example > > They would be very informational nature anyway in a standards track document.. > > Opinions? > > - Jouni > _______________________________________________ > 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 > --------------060604000700010004080105 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I would prefer to wait to drop the conformance section.  Either that or keep it updated as a separate draft/document to keep us focused on the requirements.

I agree on the S6a and PCC examples.  Much of that information in already contained in either the requirements RFC or 3GGP DOC document.

Steve
On 11/28/13 3:34 AM, lionel.morand@orange.com wrote:
agreed

-----Message d'origine-----
De : DiME [mailto:dime-bounces@ietf.org] De la part de Jouni Korhonen
Envoyé : jeudi 28 novembre 2013 10:34
À : dime@ietf.org list
Objet : [Dime] DOIC document size and placeholders

Folks,

We have some hefty sized appendices and some of the placeholders include no text. I was thinking whether we could just drop appendices on:
 o Conformance to Requirements
 o 3GPP S6a interface overload indication - example
 o 3GPP PCC interfaces overload indication - example

They would be very informational nature anyway in a standards track document..

Opinions?

- Jouni
_______________________________________________
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

--------------060604000700010004080105-- From maria.cruz.bartolome@ericsson.com Mon Dec 2 08:08:43 2013 Return-Path: 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 190DE1AC3FA for ; Mon, 2 Dec 2013 08:08:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, 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 r1kKbWtPV7wI for ; Mon, 2 Dec 2013 08:08:40 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5570D1AC862 for ; Mon, 2 Dec 2013 08:08:38 -0800 (PST) X-AuditID: c1b4fb2d-b7f1c8e000005ceb-fe-529cb0844e0f Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id AF.47.23787.480BC925; Mon, 2 Dec 2013 17:08:36 +0100 (CET) Received: from ESESSMB101.ericsson.se ([169.254.1.118]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.02.0347.000; Mon, 2 Dec 2013 17:08:35 +0100 From: Maria Cruz Bartolome To: "dime@ietf.org" Thread-Topic: [Dime] DOIC document size and placeholders Thread-Index: AQHO73dkTCwlO8dmMkyUgln6Ytbi7JpBEPOQ Date: Mon, 2 Dec 2013 16:08:35 +0000 Message-ID: <087A34937E64E74E848732CFF8354B920972BA0C@ESESSMB101.ericsson.se> References: <50C72080-905C-4B1D-BAD8-C0026791BA6E@gmail.com> <6390_1385631299_52970E43_6390_18869_1_6B7134B31289DC4FAF731D844122B36E3074FC@PEXCVZYM13.corporate.adroot.infra.ftgroup> <529CAE2D.8020600@usdonovans.com> In-Reply-To: <529CAE2D.8020600@usdonovans.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: multipart/alternative; boundary="_000_087A34937E64E74E848732CFF8354B920972BA0CESESSMB101erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLLMWRmVeSWpSXmKPExsUyM+JvrW7LhjlBBi1/BS3m9q5gc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXRu+UW4wF95Iq+jtPszcwzgjrYuTkkBAwkVh56TwrhC0mceHe erYuRi4OIYFDjBJ/j6+GchYzSlxf3ckMUsUmYCdx6fQLpi5GDg4RAWWJ078cQMLCAuYSby7M ZwSxRQQsJN623YQqMZLY0OYHEmYRUJG4+mYuC4jNK+Arsa9/D5gtJHCbUeLd2iwQm1NAT+L8 hSawTYxA93w/tYYJxGYWEJe49WQ+E8SdAhJL9pxnhrBFJV4+/gd1v6JE+9MGRoj6fIntrdvZ IXYJSpyc+YRlAqPILCSjZiEpm4WkDCKuJ3Fj6hQ2CFtbYtnC18wQtq7EjH+HWJDFFzCyr2Jk z03MzEkvN9zECIySg1t+6+5gPHVO5BCjNAeLkjjvh7fOQUIC6YklqdmpqQWpRfFFpTmpxYcY mTg4pRoYu22Mvrk+NDQVeau3RCJo+m+2G/W6s+/suXr4/vt7Ord2R+tFphTrdy+qbpMvqbVx OX6a46uXcEWJzMIg53+Nc2W/uBUbxTivKn738er2i55R9REmjvn7L2b9TA+a2rrj3zTJd32X r8ZyMDwJuyaTdM3Iu0xRmcHPMnvDwaMhItesRBtP8NxUYinOSDTUYi4qTgQARa90smACAAA= Subject: Re: [Dime] DOIC document size and placeholders X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 16:08:43 -0000 --_000_087A34937E64E74E848732CFF8354B920972BA0CESESSMB101erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello all, I would agree about removing that, but keep track of conformance is fine. A part from that, we got some introductory chapters that include some defin= itions that are not used along the doc in some cases. I would like to sugge= st again removal of any terminology that is never used, this is misleading = for a reader. As well, I prefer that pure educational chapters are as well removed, or at= least move to an annex, clearly state this is just informational. Best regards /MCruz From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: lunes, 02 de diciembre de 2013 16:59 To: dime@ietf.org Subject: Re: [Dime] DOIC document size and placeholders I would prefer to wait to drop the conformance section. Either that or kee= p it updated as a separate draft/document to keep us focused on the require= ments. I agree on the S6a and PCC examples. Much of that information in already c= ontained in either the requirements RFC or 3GGP DOC document. Steve On 11/28/13 3:34 AM, lionel.morand@orange.com wrote: agreed -----Message d'origine----- De : DiME [mailto:dime-bounces@ietf.org] De la part de Jouni Korhonen Envoy=E9 : jeudi 28 novembre 2013 10:34 =C0 : dime@ietf.org list Objet : [Dime] DOIC document size and placeholders Folks, We have some hefty sized appendices and some of the placeholders include no= text. I was thinking whether we could just drop appendices on: o Conformance to Requirements o 3GPP S6a interface overload indication - example o 3GPP PCC interfaces overload indication - example They would be very informational nature anyway in a standards track documen= t.. Opinions? - Jouni _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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 --_000_087A34937E64E74E848732CFF8354B920972BA0CESESSMB101erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello all,

 <= /p>

I would agree about remov= ing that, but keep track of conformance is fine.

 <= /p>

A part from that, we got = some introductory chapters that include some definitions that are not used = along the doc in some cases. I would like to suggest again removal of any terminology that is never used, this is misleading for a re= ader.

As well, I prefer that pu= re educational chapters are as well removed, or at least move to an annex, = clearly state this is just informational.

 <= /p>

Best regards

/MCruz<= /p>

 <= /p>

 <= /p>

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: lunes, 02 de diciembre de 2013 16:59
To: dime@ietf.org
Subject: Re: [Dime] DOIC document size and placeholders

 

I would prefer to wai= t to drop the conformance section.  Either that or keep it updated as = a separate draft/document to keep us focused on the requirements.

I agree on the S6a and PCC examples.  Much of that information in alre= ady contained in either the requirements RFC or 3GGP DOC document.

Steve

On 11/28/13 3:34 AM, lionel.morand@orange.com wrote:

agreed
 
-----Message d'origine-----
De : DiME [mailto:dime-b=
ounces@ietf.org] De la part de Jouni Korhonen
Envoy=E9 : jeudi 28 novembre 2013 10:34
=C0 : dime@ietf.org list
Objet : [Dime] DOIC document size and placeholders

 


Folks,


 


We have some hefty sized appendices and some of the placeholders inclu=
de no text. I was thinking whether we could just drop appendices on:


 o Conformance to Requirements


 o 3GPP S6a interface overload indication - example


 o 3GPP PCC interfaces overload indication - example


 


They would be very informational nature anyway in a standards track do=
cument..


 


Opinions?


 


- Jouni


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 


______________________________________________________________________=
___________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


 


This message and its attachments may contain confidential or privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
o:p>


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.iet=
f.org/mailman/listinfo/dime


 

 

--_000_087A34937E64E74E848732CFF8354B920972BA0CESESSMB101erics_-- From maria.cruz.bartolome@ericsson.com Mon Dec 2 08:13:26 2013 Return-Path: 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 AD0701AE485 for ; Mon, 2 Dec 2013 08:13:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, 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 n0suci-VIYao for ; Mon, 2 Dec 2013 08:13:20 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id AFE401AC862 for ; Mon, 2 Dec 2013 08:13:05 -0800 (PST) X-AuditID: c1b4fb2d-b7f1c8e000005ceb-c1-529cb18eff8b Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id B8.B7.23787.E81BC925; Mon, 2 Dec 2013 17:13:02 +0100 (CET) Received: from ESESSMB101.ericsson.se ([169.254.1.118]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.02.0347.000; Mon, 2 Dec 2013 17:13:02 +0100 From: Maria Cruz Bartolome To: "dime@ietf.org" Thread-Topic: [Dime] open issues #1 in DOIC Thread-Index: AQHO73WKPMo+1spTgkOJvXaZck4Vy5pBE7xg Date: Mon, 2 Dec 2013 16:13:01 +0000 Message-ID: <087A34937E64E74E848732CFF8354B920972BA1E@ESESSMB101.ericsson.se> References: <5E28C8B7-2E5E-41E8-9592-24A19AD76826@gmail.com> <9889_1385714340_529852A4_9889_16410_1_6B7134B31289DC4FAF731D844122B36E3093B0@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52EDD6D4-71CD-439F-9D2D-439CC656C3CC@gmail.com> <3468_1385718494_529862DE_3468_4222_1_6B7134B31289DC4FAF731D844122B36E309600@PEXCVZYM13.corporate.adroot.infra.ftgroup> <529CAAF4.6070708@usdonovans.com> In-Reply-To: <529CAAF4.6070708@usdonovans.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: multipart/alternative; boundary="_000_087A34937E64E74E848732CFF8354B920972BA1EESESSMB101erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrPLMWRmVeSWpSXmKPExsUyM+JvrW7fxjlBBnPPmlvM7V3B5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujEOP3jEWNE5jrOi9dJupgfFqA2MXIyeHhICJxIrec2wQtpjE hXvrgWwuDiGBQ4wSm/tmskM4ixklrp2aywpSxSZgJ3Hp9AumLkYODhEBZYnTvxxAwsICWhLL Jp5lAbFFBLQl2k98YIYoMZLo+2kNYrIIqEjMPZgCUsEr4CvR2/qOCWL6bmaJFSumMoEkOAX0 JFbu+8MMYjMC3fP91BqwOLOAuMStJ/OZIO4UkFiy5zwzhC0q8fLxP1YIW1Gi/SnEX8wC+RKL j75kh1gmKHFy5hOWCYwis5CMmoWkbBaSMoi4nsSNqVPYIGxtiWULXzND2LoSM/4dYkEWX8DI voqRPTcxMye93HATIzBSDm75rbuD8dQ5kUOM0hwsSuK8H946BwkJpCeWpGanphakFsUXleak Fh9iZOLglGpgLJgooyxpk/26R8Ti4d/C+x5qqi/fl2+75ySx/rLBn7/fPkYwW/Ibvdl/W8ja wYfbYnWuSs7WI4pHOI7O2e+b2FiS+ufeu6UGDtc37nE7tG02k0NK5oWjDqpTOoSnzUjXlVMQ 32G85brPTOZfzseclSJKlh7UZ3BNMjE5s2WSe7K8g4LN1BRtJZbijERDLeai4kQActyn2WIC AAA= Subject: Re: [Dime] open issues #1 in DOIC X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 16:13:26 -0000 --_000_087A34937E64E74E848732CFF8354B920972BA1EESESSMB101erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Looks fine to me MCruz From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: lunes, 02 de diciembre de 2013 16:45 To: dime@ietf.org Subject: Re: [Dime] open issues #1 in DOIC Agreed, looks good. Steve On 11/29/13 4:04 AM, Jouni Korhonen wrote: Would work for me. - Jouni On Nov 29, 2013, at 11:48 AM, lionel.morand@orange.com wrote: Actually, I realized that we are redefining something somehow already in us= e in RFC 6733: 9.6. Correlation of Accounting Records If an application uses accounting messages, it can correlate accounting records with a specific application session by using the Session-Id of the particular application session in the accounting messages. Accounting messages MAY also use a different Session-Id from that of the application sessions, in which case, other session- related information is needed to perform correlation. We could maybe reuse the same type of wording to simplify the definition: Pseudo-session applications are applications that do not rely on the Session-Id AVP for correlation of application messages related to the same session but use another session-related information for this purpose. The 3GPP defined Cx application [3GPP.29.229] is an example of a pseudo-session application. OK? Regards, Lionel -----Message d'origine----- De : Jouni Korhonen [mailto:jouni.nospam@gmail.com] Envoy=E9 : vendredi 29 novembre 2013 10:01 =C0 : MORAND Lionel IMT/OLN Cc : dime@ietf.org list Objet : Re: [Dime] open issues #1 in DOIC Pseudo-session applications: While this class of application does not use the Diameter Session-ID AVP to correlate requests, there is an implied ordering of transactions defined by the application and except for the Session-ID differences pseudo-session based applications are generally assumed to behave like session-based application. The 3GPP defined Cx application [3GPP.29.229] is an example of a pseudo-session application. Would this suffice? - Jouni On Nov 29, 2013, at 10:38 AM, lionel.morand@orange.com wrote: Hi, For me, "pseudo-session" refers to session-based oriented applications that= do not rely on the session-id for message correlations but on something el= se e.g. user-name. So it is implied that the same server is contacted by th= e client managing the session. In the Cx example, the same origin-host will= be used in the client-initiated requests after the initial exchange and th= e server discovery phase. Regards, Lionel -----Message d'origine----- De : DiME [mailto:dime-bounces@ietf.org] De la part de Jouni Korhonen Envoy=E9 : vendredi 29 novembre 2013 09:30 =C0 : dime@ietf.org list Objet : [Dime] open issues #1 in DOIC Folks, [OpenIssue: Do we assume that all requests in a pseudo-session typically need to go to the same server?] The example here is in context of Cx. Not that I am expert on Cx (or anythi= ng) but based on the CCF the requests _may_ have destination-host. Thus, I assu= me that it is an implementation issue whether pseudo-sessions need to go to th= e same server.. I guess we cannot have such firm requirement. Correct? - Jouni _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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 confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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 --_000_087A34937E64E74E848732CFF8354B920972BA1EESESSMB101erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Looks fine to me

 <= /p>

MCruz

 <= /p>

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: lunes, 02 de diciembre de 2013 16:45
To: dime@ietf.org
Subject: Re: [Dime] open issues #1 in DOIC

 

Agreed, looks good.
Steve

On 11/29/13 4:04 AM, Jouni Korhonen wrote:

 
Would work for me.
 
- Jouni
 
On Nov 29, 2013, at 11:48 AM, lionel.morand@orange.com wrote:
 
Actually, I realized that we are redefining something somehow already =
in use in RFC 6733:
 
9.6. Correlation of Accounting Records
 
 
  If an application uses accounting messages, it can correlate
  accounting records with a specific application session by using=
 the
  Session-Id of the particular application session in the account=
ing
  messages.  Accounting messages MAY also use a different Se=
ssion-Id
  from that of the application sessions, in which case, other ses=
sion-
  related information is needed to perform correlation.
 
We could maybe reuse the same type of wording to simplify the definiti=
on:
 
Pseudo-session applications are applications that
do not rely on the Session-Id AVP for correlation 
of application messages related to the same session
but use another session-related information for this
purpose. The 3GPP defined Cx application [3GPP.29.229]

is an example of a pseudo-session application.


 


OK?


 


Regards,


 


Lionel


 


-----Message d'origine-----


De : Jouni Korhonen [mailto:=
jouni.nospam@gmail.com] 


Envoy=E9 : vendredi 29 novembre 2013 10:01


=C0 : MORAND Lionel IMT/OLN


Cc : dime@ietf.org list


Objet : Re: [Dime] open issues #1 in DOIC


 


 


  Pseudo-session applications:


 


     While this class of application does not use =
the Diameter


     Session-ID AVP to correlate requests, there i=
s an implied ordering


     of transactions defined by the application an=
d except for the


     Session-ID differences pseudo-session based a=
pplications are


     generally assumed to behave like session-base=
d application.  The


     3GPP defined Cx application [3GPP.29.229] is =
an example of a


     pseudo-session application.


 


 


Would this suffice?


 


- Jouni


 


 


 


On Nov 29, 2013, at 10:38 AM, lionel.morand@orange.com wrote:


 




Hi,


 


For me, "pseudo-session" refers to session-based oriented ap=
plications that do not rely on the session-id for message correlations but =
on something else e.g. user-name. So it is implied that the same server is =
contacted by the client managing the session. In the Cx example, the same o=
rigin-host will be used in the client-initiated requests after the initial =
exchange and the server discovery phase.


 


Regards,


 


Lionel 


 


-----Message d'origine-----


De : DiME [mailto:dime-bounce=
s@ietf.org] De la part de Jouni Korhonen


Envoy=E9 : vendredi 29 novembre 2013 09:30


=C0 : dime@ietf.org list


Objet : [Dime] open issues #1 in DOIC


 


Folks,


 


         [OpenIssue: Do we ass=
ume that all requests in a pseudo-session


         typically need to go =
to the same server?]


 


 


The example here is in context of Cx. Not that I am expert on Cx (or a=
nything)


but based on the CCF the requests _may_ have destination-host. Thus, I=
 assume


that it is an implementation issue whether pseudo-sessions need to go =
to the


same server.. I guess we cannot have such firm requirement. Correct?


 


- Jouni


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 


______________________________________________________________________=
___________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


 


This message and its attachments may contain confidential or privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
o:p>


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 con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


 


This message and its attachments may contain confidential or privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
o:p>


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.iet=
f.org/mailman/listinfo/dime
 

 

--_000_087A34937E64E74E848732CFF8354B920972BA1EESESSMB101erics_-- From lionel.morand@orange.com Mon Dec 2 08:18:40 2013 Return-Path: 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 1BD081ABD2A for ; Mon, 2 Dec 2013 08:18:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 jwLGk-4HJnZI for ; Mon, 2 Dec 2013 08:18:35 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 7A7071A8032 for ; Mon, 2 Dec 2013 08:18:34 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 7A900264199; Mon, 2 Dec 2013 17:18:31 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 5C8D327C057; Mon, 2 Dec 2013 17:18:31 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0158.001; Mon, 2 Dec 2013 17:18:31 +0100 From: To: Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] DOIC: Self-Contained OLRs Thread-Index: AQHO73Rjo7y6FFeeaEmQ38aKczpYQJpBEWGA Date: Mon, 2 Dec 2013 16:18:30 +0000 Message-ID: <13482_1386001111_529CB2D7_13482_11387_1_6B7134B31289DC4FAF731D844122B36E311068@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D90006681519BC90@DEMUMBX014.nsn-intra.net> <6390_1385631044_52970D44_6390_18593_1_6B7134B31289DC4FAF731D844122B36E30748E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BD31@DEMUMBX014.nsn-intra.net> <47383DC2-1A1B-4D1A-ADD5-9E3CE60B06C8@gmail.com> <8467_1385735507_5298A553_8467_17054_3_6B7134B31289DC4FAF731D844122B36E309D0D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <529CA930.4030006@usdonovans.com> In-Reply-To: <529CA930.4030006@usdonovans.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.3] Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E311068PEXCVZYM13corpora_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.12.2.94815 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 16:18:40 -0000 --_000_6B7134B31289DC4FAF731D844122B36E311068PEXCVZYM13corpora_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Steve, I think that is not only about few bytes in the answer. It is also about th= e solution principles agreed so far: =B7 the current need is for an OLR bound to the application in use =B7 the OLR is received from the node targeted in the request. =B7 the OLR is defined per application So all the implicit information (application, origin-host, origin-realm) ar= e meaningful in this context. And the actual solution is designed based on these assumptions. The extensi= bility of the solution will allow extra info if required in other use cases= but it was agreed to go with a straightforward solution that will satisfy = most of us. Regards, Lionel De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan Envoy=E9 : lundi 2 d=E9cembre 2013 16:37 =C0 : dime@ietf.org Objet : Re: [Dime] DOIC: Self-Contained OLRs I don't believe that Ben's proposal was to change the piggybacking assumpti= on in the baseline mechanism. Ben's proposal is to design the solution in = such a way that it is not dependent on the piggybacking transport mechanism. I share Ben's concern that we have over optimized the content of the overlo= ad report in a way that makes implementations brittle, interoperability mor= e difficult to achieve and extensibility more complex. And what do we gain= from this optimization? A few bites in answer messages. Self contained overload reports, transported using the piggybacking mechani= sm, is a cleaner solution. Steve On 11/29/13 8:31 AM, lionel.morand@orange.com wrote: I totally agree with Nirav. No need to revert at this stage the working ass= umption on piggybacking of OLR in application answer messages, especially w= hen the aim is to define a basic mechanism called "reduction". Anyone would be able to further add extra info for optimization if needed b= ut there is no need at all for the basic mechanism. Regards, Lionel -----Message d'origine----- De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot (nsalot) Envoy=E9 : vendredi 29 novembre 2013 12:24 =C0 : Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list Cc : Ben Campbell Objet : Re: [Dime] DOIC: Self-Contained OLRs Jouni, Ben, I am totally against the idea of self-contained OC-OLR specifically since w= e have adopted the principles of piggybacking the OC-OLR over existing appl= ication message. Self-contained OC-OLR - which means adding all the information which define= s the scope of the OC-OLR into the OC-OLR - does not make sense in the pigg= ybacking approach. In fact, it is adding lot of information, which is anywa= y available within the message containing the OC-OLR, into the OC-OLR. So i= t is adding lot of redundant information in a message which increases the p= rocessing requirement for the sender as well as the receiver. (And this is = un-optimization, in my view). Besides, I am not convinced with the other reasons provided here: - One software module within a node can provide OC-OLR to another software = module in the same node without passing other related info Within a node, based on the design, lots of information may need to be p= assed between two software modules and we cannot optimize those aspects by = replicating unnecessary information in a protocol message. In summary, it is node's internal software design issue and we need not = optimize that at protocol level. - Once the reporting node realizes that it is overloaded, it has to wait fo= r right answer to send OC-OLR What is the point of sending OC-OLR for a context for which there is no m= essaging? Why should the reacting node care if it never sends a message for= a context for which the reporting node is overloaded? So this waiting is justified since it ensures that the overload is report= ed only when necessary and only to the applicable reacting node. Not to all= the nodes in the network. - The agent needs to wait for the answer generated by the server and the ri= ght context The same argument as applicable for the server applies here. The agent n= eed not send out-of-context overload info to a node. Why should reacting node receive/process/store the overload info for the= scope for which it is not sending any messages. - For sending OC-OLR in dedicated Diameter application??? Piggybacking was the first basic principle we agreed before putting other= principles in place. So we may want to go back the drawing board if we dec= ide to change this principle. Regards, Nirav. -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen Sent: Friday, November 29, 2013 2:50 PM To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org li= st Cc: Ben Campbell Subject: Re: [Dime] DOIC: Self-Contained OLRs So, are we reaching any level of consensus here? - JOuni (as a note.. that we are converging back to where we started with OLRs ;) On Nov 28, 2013, at 12:40 PM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: Hi, another question: If we go for explicit self contained OLRs, why would we then need the Repor= tType? The realm-type OLR would explicitly contain application-Id, Realm, but no H= ost whereas the host-type OLR would explicitly contain application-Id, Host= , but probably (I'm not sure) no Realm. 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 stat= us. It could be provided an agent inserting this info in answers received f= rom a server behind but also from a server that would know this info by som= e internal magic. But in any case, if we assume that the client will received a successful an= swer from the server for an initial request with only Dest-Realm AVP, it sh= ould be possible to have both report types in the answer: one for the serve= r itself, one for the realm for new request sent to the realm with only Des= t-Realm AVP. Lionel -----Message d'origine----- De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN - DE/Munich) Envoy=E9 : jeudi 28 novembre 2013 10:26 =C0 : 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 a= ligned with the "endpoint principle". If the ReportType is "realm" this ind= icates 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 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 re= acting 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 Diamet= er request that corresponds to the answer containing the OLR. My reasons fo= r 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 i= dentified by Origin-Realm, and so on. This means that the "meaning" of an O= LR 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 answe= r to another, it's meaning may change completely. I think this approach is a mistake. I would greatly prefer that we explicit= ly 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 variou= s other AVPs to find all the information it needs. For example, I think a c= ommon software design for overload control processing to be separated from = application processing. The consumer cannot simply hand the OLR to that mod= ule and expect things to work. The OC module must not only parse the OLR, b= ut parse any other AVPs that are relevant. As OLR contents get extended (as= sumedly following the same strategy as the base spec), the number of "conte= xt" avps that must be interpreted can grow large. This approach is error pr= one, and will likely encourage brittle, hard-to-maintain code. Self-contain= ed OLRs would keep all the information related to overload in one place. ma= king for simpler implementations. 2) It's more complex for the reporting node to send implicit values than ex= plicit values. The sender cannot simply set the context to match the OLR--a= ll those other AVPs have application or protocol layer meanings. Once a rep= orting node realizes that it is overloade, it has to wait for the right ans= wer that contains the right context before it can send the OLR. This is par= ticularly 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 sig= nificantly. 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 so= me 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 overlo= ad reports were self-contained, one could just reuse the report format we s= pecify here. But if the meaning of an OLR depends on the way it's transport= ed, this won't work. We would have to create a new or significantly modifie= d OLR format if we found a need to transport OLRs in different ways. Self-c= ontained OLRs would allow much greater flexibility. So, in summary, I think that self-contained OLRs would lead to simpler impl= ementations, less brittle deployments, and more flexibility for future evol= ution 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 le= s pieces jointes. Les messages electroniques etant susceptibles d'alteratio= n, 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 dis= tributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te 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 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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 confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. --_000_6B7134B31289DC4FAF731D844122B36E311068PEXCVZYM13corpora_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Steve,

 <= /p>

I think th= at is not only about few bytes in the answer. It is also about the solution= principles agreed so far:

=B7    =      the current need is for an OLR bound to the applicat= ion in use

=B7    =      the OLR is received from the node targeted in the re= quest.

=B7    =      the OLR is defined per application=

So all the= implicit information (application, origin-host, origin-realm) are meaningf= ul in this context.

And the ac= tual solution is designed based on these assumptions. The extensibility of = the solution will allow extra info if required in other use cases but it was agreed to go with a straightforward solution that will sa= tisfy most of us.

 = ;

Regards,

 = ;

Lionel

 = ;

De := DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9 : lundi 2 d=E9cembre 2013 16:37
=C0 : dime@ietf.org
Objet : Re: [Dime] DOIC: Self-Contained OLRs<= /p>

 

I don't believe that = Ben's proposal was to change the piggybacking assumption in the baseline me= chanism.  Ben's proposal is to design the solution in such a way that = it is not dependent on the piggybacking transport mechanism. 

I share Ben's concern that we have over optimized the content of the overlo= ad report in a way that makes implementations brittle, interoperability mor= e difficult to achieve and extensibility more complex.  And what do we= gain from this optimization?  A few bites in answer messages.

Self contained overload reports, transported using the piggybacking mechani= sm, is a cleaner solution.

Steve

On 11/29/13 8:31 AM, lionel.morand@orange.com wrote:

I totally agree with Nirav. No need to revert at this stage the workin=
g assumption on piggybacking of OLR in application answer messages, especia=
lly when the aim is to define a basic mechanism called "reduction"=
;.
 
Anyone would be able to further add extra info for optimization if nee=
ded but there is no need at all for the basic mechanism.
 
Regards,
 
Lionel
 
-----Message d'origine-----
De : DiME [mailto:dime-b=
ounces@ietf.org] De la part de Nirav Salot (nsalot)
Envoy=E9 : vendredi 29 novembre 2013 12:24
=C0 : Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list
Cc : Ben Campbell
Objet : Re: [Dime] DOIC: Self-Contained OLRs
 
Jouni, Ben,
 
I am totally against the idea of self-contained OC-OLR specifically si=
nce we have adopted the principles of piggybacking the OC-OLR over existing=
 application message.
Self-contained OC-OLR - which means adding all the information which d=
efines the scope of the OC-OLR into the OC-OLR - does not make sense in the=
 piggybacking approach. In fact, it is adding lot of information, which is =
anyway available within the message containing the OC-OLR, into the OC-OLR.=
 So it is adding lot of redundant information in a message which increases =
the processing requirement for the sender as well as the receiver. (And thi=
s is un-optimization, in my view).
 
Besides, I am not convinced with the other reasons provided here:=

- One software module within a node can provide OC-OLR to another soft=
ware module in the same node without passing other related info<=
/pre>

   Within a node, based on the design, lots of information m=
ay need to be passed between two software modules and we cannot optimize th=
ose aspects by replicating unnecessary information in a protocol message.


   In summary, it is node's internal software design issue a=
nd we need not optimize that at protocol level.


 


- Once the reporting node realizes that it is overloaded, it has to wa=
it for right answer to send OC-OLR


  What is the point of sending OC-OLR for a context for which the=
re is no messaging? Why should the reacting node care if it never sends a m=
essage for a context for which the reporting node is overloaded?=



  So this waiting is justified since it ensures that the overload=
 is reported only when necessary and only to the applicable reacting node. =
Not to all the nodes in the network.


 


- The agent needs to wait for the answer generated by the server and t=
he right context


   The same argument as applicable for the server applies he=
re. The agent need not send out-of-context overload info to a node.


   Why should reacting node receive/process/store the overlo=
ad info for the scope for which it is not sending any messages.<=
/pre>

 


- For sending OC-OLR in dedicated Diameter application???

  Piggybacking was the first basic principle we agreed before put=
ting other principles in place. So we may want to go back the drawing board=
 if we decide to change this principle.


 


Regards,


Nirav.


 


-----Original Message-----


From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of Jouni Korhonen


Sent: Friday, November 29, 2013 2:50 PM


To: Wiehe, Ulrich (NSN - DE/Munich); =
dime@ietf.org list


Cc: Ben Campbell


Subject: Re: [Dime] DOIC: Self-Contained OLRs


 


 


 


So, are we reaching any level of consensus here?


 


- JOuni


 


(as a note.. that we are converging back to where we started with OLRs=
 ;)


 


 


 


On Nov 28, 2013, at 12:40 PM, "Wiehe, Ulrich (NSN - DE/Munich)&qu=
ot; <ulrich.wiehe@nsn.com> wrote:


 




Hi,


 


another question:


 


If we go for explicit self contained OLRs, why would we then need the =
ReportType?


 


The realm-type OLR would explicitly contain application-Id, Realm, but=
 no Host whereas the host-type OLR would explicitly contain application-Id,=
 Host, but probably (I'm not sure) no Realm.


 


Ulrich


 


 


 


-----Original Message-----


From: ext lionel.morand@or=
ange.com [mailto:lionel.mor=
and@orange.com]


Sent: Thursday, November 28, 2013 10:31 AM


To: Wiehe, Ulrich (NSN - DE/Munich); ext Jouni Korhonen; Ben Campbell<=
o:p>


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 recei=
ved from a server behind but also from a server that would know this info b=
y some internal magic.


But in any case, if we assume that the client will received a successf=
ul 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 onl=
y Dest-Realm AVP.


 


Lionel


 


-----Message d'origine-----


De : DiME [mailto:dime-bounce=
s@ietf.org] De la part de Wiehe, Ulrich 


(NSN - DE/Munich) Envoy=E9 : jeudi 28 novembre 2013 10:26 =C0 : ext Jo=
uni 


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 &=
quot;realm" this indicates to the reacting end point that the reportin=
g 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 repor=
ting end point is a server. How can the reporting end point be both agent a=
nd server?


 


Ulrich


 


-----Original Message-----


From: DiME [mailto:dime-bounc=
es@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 <=
/o:p>


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 t=
he 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 D=
iameter request that corresponds to the answer containing the OLR. My reaso=
ns 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 applica=
tion identified by the Application-Id field of the enclosing answer, the re=
alm identified by Origin-Realm, and so on. This means that the "meanin=
g" of an OLR cannot be determined from the OLR contents alone; OLRs on=
ly 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 exp=
licitly include such values in the OLR itself, for multiple reasons:


 


1) It's more complex to interpret implicit, contextual values than exp=
licit values. The consumer cannot simply look at the OLR; it must look in v=
arious other AVPs to find all the information it needs. For example, I thin=
k a common software design for overload control processing to be separated =
from application processing. The consumer cannot simply hand the OLR to tha=
t module and expect things to work. The OC module must not only parse the O=
LR, but parse any other AVPs that are relevant. As OLR contents get extende=
d (assumedly following the same strategy as the base spec), the number of &=
quot;context" avps that must be interpreted can grow large. This appro=
ach is error prone, and will likely encourage brittle, hard-to-maintain cod=
e. Self-contained OLRs would keep all the information related to overload i=
n one place. making for simpler implementations.


 


2) It's more complex for the reporting node to send implicit values th=
an explicit values. The sender cannot simply set the context to match the O=
LR--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 righ=
t answer that contains the right context before it can send the OLR. This i=
s particularly troublesome for agents, since they will typically have to in=
sert OLRs into answers created by other nodes. 


 


If the reporting node screws this up, the meaning of the OLR may chang=
e significantly. So again, implicit meaning gives us error prone implementa=
tions. 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 <=
o:p>


are distinct from those sent by a server, see Steve's agent overload <=
o:p>


draft, or my dh/dr example.)


 


OTOH, explicit values will work for all cases where we need to associa=
te some arbitrary value with an OLR.


 


4) Implicit values seriously constrain the future evolution of Diamete=
r OC standards. For example, lets say we find a good reason to allow OLRs t=
o be sent out of band, or be sent in a dedicated Diameter application. If o=
verload 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 tran=
sported, this won't work. We would have to create a new or significantly mo=
dified OLR format if we found a need to transport OLRs in different ways. S=
elf-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.iet=
f.org/mailman/listinfo/dime




 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.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 q=
ue les pieces jointes. Les messages electroniques etant susceptibles d'alte=
ration, Orange decline toute responsabilite si ce message a ete altere, def=
orme ou falsifie. Merci.


 


This message and its attachments may contain confidential or 


privileged information that may be protected by law; they should not b=
e 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.iet=
f.org/mailman/listinfo/dime


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 


______________________________________________________________________=
___________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


 


This message and its attachments may contain confidential or privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
o:p>


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.iet=
f.org/mailman/listinfo/dime


 

 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles 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 el=
ectroniques 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 inf=
ormation 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 dele=
te 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.
--_000_6B7134B31289DC4FAF731D844122B36E311068PEXCVZYM13corpora_-- From lionel.morand@orange.com Mon Dec 2 08:31:55 2013 Return-Path: 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 314A31AC863 for ; Mon, 2 Dec 2013 08:31:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 VNvXm2TLpeBP for ; Mon, 2 Dec 2013 08:31:53 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by ietfa.amsl.com (Postfix) with ESMTP id 115221AC862 for ; Mon, 2 Dec 2013 08:31:53 -0800 (PST) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id 8DFD0C01C7; Mon, 2 Dec 2013 17:31:50 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 6BB9AC8056; Mon, 2 Dec 2013 17:31:50 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0158.001; Mon, 2 Dec 2013 17:31:50 +0100 From: To: Jouni Korhonen , Steve Donovan Thread-Topic: [Dime] draft-ietf-dime-ovli-01 questions #1 Thread-Index: AQHO73UdaJz9GfnFkkGuDkGoBEK6cJpA+28AgAAbGAA= Date: Mon, 2 Dec 2013 16:31:50 +0000 Message-ID: <3558_1386001910_529CB5F6_3558_6116_1_6B7134B31289DC4FAF731D844122B36E3110E6@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <16E13E52-0DB9-4E72-964A-FE658536155B@gmail.com> <10629_1385971488_529C3F20_10629_5138_1_emlwd34vyt318xrd8i01xiee.1385971482719@email.android.com> <529CAA39.6050809@usdonovans.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.12.2.94815 Cc: "dime@ietf.org" Subject: Re: [Dime] draft-ietf-dime-ovli-01 questions #1 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 16:31:55 -0000 RFC5729 is another example. Maybe can we be more generic saying that enhanc= ed routing decisions can be performed at the application level based on spe= cific info e.g. NAI and add some examples. Lionel -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Jouni Korhonen Envoy=E9=A0: lundi 2 d=E9cembre 2013 16:46 =C0=A0: Steve Donovan Cc=A0: dime@ietf.org Objet=A0: Re: [Dime] draft-ietf-dime-ovli-01 questions #1 Ok. I'll put references to PCC. Would NAI based "source routing" qualify here as an example i.e. RFC5729? - Jouni On Dec 2, 2013, at 5:41 PM, Steve Donovan wrote: > The PCC architecture, where agents route based on pre-existing bindings i= s another example. >=20 > Steve > On 12/2/13 2:04 AM, lionel.morand@orange.com wrote: >> It was my understanding. >>=20 >> Envoy=E9 depuis mon Sony Xperia SP d'Orange >>=20 >> Jouni Korhonen=20 >> >> a =E9crit : >>=20 >>=20 >> Hi, >>=20 >> In Section 2 on Diameter routing it says: >>=20 >> defined in [RFC6733]. Application level routing specifications >> that expand on [RFC6733] also exist. >>=20 >> What does this "expand" actually refer to? RFC5729? RFC7075? >>=20 >> - Jouni >> _______________________________________________ >> DiME mailing list >>=20 >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >>=20 >>=20 >> ________________________________________________________________________= _________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations confi= dentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez r= ecu 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. >>=20 >> 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 d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >>=20 >> _______________________________________________ >> DiME mailing list >>=20 >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >>=20 >>=20 >>=20 >=20 > _______________________________________________ > 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 confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. From lionel.morand@orange.com Mon Dec 2 08:38:22 2013 Return-Path: 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 D58271A1F4E for ; Mon, 2 Dec 2013 08:38:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 BvmVB5FFuTde for ; Mon, 2 Dec 2013 08:38:20 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 94C191A8028 for ; Mon, 2 Dec 2013 08:38:19 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id E521F324286; Mon, 2 Dec 2013 17:38:16 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id C26E627C064; Mon, 2 Dec 2013 17:38:16 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0158.001; Mon, 2 Dec 2013 17:38:16 +0100 From: To: Maria Cruz Bartolome , "dime@ietf.org" Thread-Topic: [Dime] DOIC document size and placeholders Thread-Index: AQHO73dkwmbYfJyL2UmJyLfEhUWkrppBAc+AgAAX2AA= Date: Mon, 2 Dec 2013 16:38:15 +0000 Message-ID: <13482_1386002296_529CB778_13482_12619_1_6B7134B31289DC4FAF731D844122B36E311133@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <50C72080-905C-4B1D-BAD8-C0026791BA6E@gmail.com> <6390_1385631299_52970E43_6390_18869_1_6B7134B31289DC4FAF731D844122B36E3074FC@PEXCVZYM13.corporate.adroot.infra.ftgroup> <529CAE2D.8020600@usdonovans.com> <087A34937E64E74E848732CFF8354B920972BA0C@ESESSMB101.ericsson.se> In-Reply-To: <087A34937E64E74E848732CFF8354B920972BA0C@ESESSMB101.ericsson.se> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.3] Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E311133PEXCVZYM13corpora_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.12.2.94815 Subject: Re: [Dime] DOIC document size and placeholders X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 16:38:23 -0000 --_000_6B7134B31289DC4FAF731D844122B36E311133PEXCVZYM13corpora_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Everything informational will not be anyway of great use in a standard trac= ks document. So I would also prefer to remove them from the document. Of course, it is n= ot to forget about these points, especially the requirement compliance. Regards, Lionel De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome Envoy=E9 : lundi 2 d=E9cembre 2013 17:09 =C0 : dime@ietf.org Objet : Re: [Dime] DOIC document size and placeholders Hello all, I would agree about removing that, but keep track of conformance is fine. A part from that, we got some introductory chapters that include some defin= itions that are not used along the doc in some cases. I would like to sugge= st again removal of any terminology that is never used, this is misleading = for a reader. As well, I prefer that pure educational chapters are as well removed, or at= least move to an annex, clearly state this is just informational. Best regards /MCruz From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: lunes, 02 de diciembre de 2013 16:59 To: dime@ietf.org Subject: Re: [Dime] DOIC document size and placeholders I would prefer to wait to drop the conformance section. Either that or kee= p it updated as a separate draft/document to keep us focused on the require= ments. I agree on the S6a and PCC examples. Much of that information in already c= ontained in either the requirements RFC or 3GGP DOC document. Steve On 11/28/13 3:34 AM, lionel.morand@orange.com wrote: agreed -----Message d'origine----- De : DiME [mailto:dime-bounces@ietf.org] De la part de Jouni Korhonen Envoy=E9 : jeudi 28 novembre 2013 10:34 =C0 : dime@ietf.org list Objet : [Dime] DOIC document size and placeholders Folks, We have some hefty sized appendices and some of the placeholders include no= text. I was thinking whether we could just drop appendices on: o Conformance to Requirements o 3GPP S6a interface overload indication - example o 3GPP PCC interfaces overload indication - example They would be very informational nature anyway in a standards track documen= t.. Opinions? - Jouni _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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 confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. --_000_6B7134B31289DC4FAF731D844122B36E311133PEXCVZYM13corpora_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Everything= informational will not be anyway of great use in a standard tracks documen= t.

So I would= also prefer to remove them from the document. Of course, it is not to forg= et about these points, especially the requirement compliance.

 = ;

Regards,

 = ;

Lionel

 = ;

De := DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome
Envoy=E9 : lundi 2 d=E9cembre 2013 17:09
=C0 : dime@ietf.org
Objet : Re: [Dime] DOIC document size and placeholders

 

Hello all,=

 

I would ag= ree about removing that, but keep track of conformance is fine.

 

A part fro= m that, we got some introductory chapters that include some definitions tha= t are not used along the doc in some cases. I would like to suggest again removal of any terminology that is never used, this is misle= ading for a reader.

As well, I= prefer that pure educational chapters are as well removed, or at least mov= e to an annex, clearly state this is just informational.

 

Best regar= ds

/MCruz

 

 

From:= DiME [mailto:dime-b= ounces@ietf.org] On Behalf Of Steve Donovan
Sent: lunes, 02 de diciembre de 2013 16:59
To: dime@ietf.org
Subject: Re: [Dime] DOIC document size and placeholders

 

= I would prefer to wait to drop the conformance section.  Either that o= r keep it updated as a separate draft/document to keep us focused on the re= quirements.

I agree on the S6a and PCC examples.  Much of that information in alre= ady contained in either the requirements RFC or 3GGP DOC document.

Steve

On 11/28/13 3:34 AM, lionel.morand@orange.com wrote:

agreed
 
-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de Jouni Korhonen=



Envoy=E9 : jeudi 28 novembre 2013 10:34=



=C0 : dime@=
ietf.org list


Objet : [Dime] DOIC document size and placeh=
olders


 


Folks,


 


We have some hefty sized appendices and some of t=
he placeholders include no text. I was thinking whether we could just drop =
appendices on:


 o Conformance to Requirements<=
/pre>

 o 3GPP S6a interface overload indication - examp=
le


 o 3GPP PCC interfaces overload indication - exam=
ple


 


They would be very informational nature anyway in=
 a standards track document..


 


Opinions?


 


- Jouni


_______________________________________________


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 autor=
isation. Si vous avez recu ce message par erreur, veuillez le signaler=



a l'expediteur et le detruire ainsi que les piece=
s 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 conf=
idential or privileged information that may be protected by law;=



they should not be distributed, used or copied wi=
thout 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 fo=
r 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 confiden=
tielles 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 el=
ectroniques 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 inf=
ormation 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 dele=
te 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.
--_000_6B7134B31289DC4FAF731D844122B36E311133PEXCVZYM13corpora_-- From internet-drafts@ietf.org Mon Dec 2 10:13:31 2013 Return-Path: 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 1ED091ADBD0; Mon, 2 Dec 2013 10:13:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 uhuQld5VQVio; Mon, 2 Dec 2013 10:13:29 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A21C71ADBC7; Mon, 2 Dec 2013 10:13:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131202181326.24953.50333.idtracker@ietfa.amsl.com> Date: Mon, 02 Dec 2013 10:13:26 -0800 Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-rfc4005bis-14.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 18:13:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Diameter Maintenance and Extensions Worki= ng Group of the IETF. Title : Diameter Network Access Server Application Author(s) : Glen Zorn Filename : draft-ietf-dime-rfc4005bis-14.txt Pages : 67 Date : 2013-11-28 Abstract: This document describes the Diameter protocol application used for Authentication, Authorization, and Accounting (AAA) services in the Network Access Server (NAS) environment; it obsoletes RFC 4005. When combined with the Diameter Base protocol, Transport Profile, and Extensible Authentication Protocol specifications, this application specification satisfies typical network access services requirements. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-rfc4005bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dime-rfc4005bis-14 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-rfc4005bis-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jouni.nospam@gmail.com Mon Dec 2 12:10:23 2013 Return-Path: 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 CEF621ADED8 for ; Mon, 2 Dec 2013 12:10:23 -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 br5P6kP2_nzZ for ; Mon, 2 Dec 2013 12:10:22 -0800 (PST) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id ACB5D1ADEC4 for ; Mon, 2 Dec 2013 12:10:21 -0800 (PST) Received: by mail-la0-f48.google.com with SMTP id n7so8416842lam.21 for ; Mon, 02 Dec 2013 12:10:18 -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=ofrUJ1TDz5EukgsoMdowhqvntfTGvBA/IgORd8flmEY=; b=jDZnVNLVzx0IAaFvmqcNP463W0n7OwgS1r1vrET18BwOZzy3Mexcb1ny+e5JqaN/VV FyqgcIgSVnaxFrNuWz1rKIo16pS8GdBpDbdd/5yvNPTkUuPLDWzGzzISoKK3xK+I2RnU 0hS+/ZOK31jEIWMHjnZkJUtc4EuKeljC45rYLfbI2t46lJRcLBmBDkDtOId5MKFUnaPS jgEEJGuhLfOhpnk1uiwEpWYAuAr9nzvSoFfRVzkGx0GYSmDTarA7O/T70Hc6d4hynSH9 rbsB9DOk888zVSbiLJGVsLxOYhg95DgnL2lE/PcW+It2Tca0ILGg9PpTybSt5XbPQ0Ll Q82A== X-Received: by 10.152.184.35 with SMTP id er3mr1955223lac.23.1386015018571; Mon, 02 Dec 2013 12:10:18 -0800 (PST) Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id c8sm29218397lag.3.2013.12.02.12.10.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 02 Dec 2013 12:10:15 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <529CAE2D.8020600@usdonovans.com> Date: Mon, 2 Dec 2013 22:10:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7409C6AE-167B-4966-923F-68E53CEF9C8B@gmail.com> References: <50C72080-905C-4B1D-BAD8-C0026791BA6E@gmail.com> <6390_1385631299_52970E43_6390_18869_1_6B7134B31289DC4FAF731D844122B36E3074FC@PEXCVZYM13.corporate.adroot.infra.ftgroup> <529CAE2D.8020600@usdonovans.com> To: Steve Donovan X-Mailer: Apple Mail (2.1510) Cc: dime@ietf.org Subject: Re: [Dime] DOIC document size and placeholders X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 20:10:24 -0000 On Dec 2, 2013, at 5:58 PM, Steve Donovan = wrote: > I would prefer to wait to drop the conformance section. Either that = or keep it updated as a separate draft/document to keep us focused on = the requirements. I still have have that in the XML source but just commented out. - Jouni >=20 > I agree on the S6a and PCC examples. Much of that information in = already contained in either the requirements RFC or 3GGP DOC document. >=20 > Steve >=20 > On 11/28/13 3:34 AM, lionel.morand@orange.com wrote: >> agreed >>=20 >> -----Message d'origine----- >> De : DiME [ >> mailto:dime-bounces@ietf.org >> ] De la part de Jouni Korhonen >> Envoy=E9 : jeudi 28 novembre 2013 10:34 >> =C0 :=20 >> dime@ietf.org >> list >> Objet : [Dime] DOIC document size and placeholders >>=20 >> Folks, >>=20 >> We have some hefty sized appendices and some of the placeholders = include no text. I was thinking whether we could just drop appendices = on: >> o Conformance to Requirements >> o 3GPP S6a interface overload indication - example >> o 3GPP PCC interfaces overload indication - example >>=20 >> They would be very informational nature anyway in a standards track = document.. >>=20 >> Opinions? >>=20 >> - Jouni >> _______________________________________________ >> DiME mailing list >>=20 >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >>=20 >>=20 >> = __________________________________________________________________________= _______________________________________________ >>=20 >> 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. >>=20 >> 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. >>=20 >> _______________________________________________ >> DiME mailing list >>=20 >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >>=20 >>=20 >>=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From maria.cruz.bartolome@ericsson.com Tue Dec 3 00:27:08 2013 Return-Path: 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 B355F1AE022 for ; Tue, 3 Dec 2013 00:27:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, 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 n1nb-oQgIZAD for ; Tue, 3 Dec 2013 00:27:03 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 43F621ADF73 for ; Tue, 3 Dec 2013 00:27:01 -0800 (PST) X-AuditID: c1b4fb2d-b7f1c8e000005ceb-af-529d95d21be1 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 7E.65.23787.2D59D925; Tue, 3 Dec 2013 09:26:58 +0100 (CET) Received: from ESESSMB101.ericsson.se ([169.254.1.118]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.02.0347.000; Tue, 3 Dec 2013 09:26:58 +0100 From: Maria Cruz Bartolome To: "dime@ietf.org" Thread-Topic: DOIC: Multiple instance of OC-OLR AVP (of the same type) within a response message Thread-Index: Ac7sHN1kcwdoL1xIRoywlc8N1o+kQQABwsSAAANc20sABC8OAAAEKULQAOtOLoA= Date: Tue, 3 Dec 2013 08:26:57 +0000 Message-ID: <087A34937E64E74E848732CFF8354B920972BDDB@ESESSMB101.ericsson.se> References: , <2901_1385634414_52971A6E_2901_2686_1_6B7134B31289DC4FAF731D844122B36E307743@PEXCVZYM13.corporate.adroot.infra.ftgroup> <30095_1385647765_52974E95_30095_213_1_6B7134B31289DC4FAF731D844122B36E307DF6@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: multipart/alternative; boundary="_000_087A34937E64E74E848732CFF8354B920972BDDBESESSMB101erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrALMWRmVeSWpSXmKPExsUyM+Jvre6lqXODDM5PMLaY27uCzYHRY8mS n0wBjFFcNimpOZllqUX6dglcGTv7r7AV3JjGVHFs/QGWBsYFHxm7GDk5JARMJDrv7GCFsMUk LtxbzwZiCwkcYpT415/axcgFZC9mlLj9agJYA5uAncSl0y+Yuhg5OEQElCVO/3IACQsLJEos uXAOrFdEIEni3fxPLBC2n8TEnW+ZQWwWARWJ9RdmgI3hFfCV2L5uEzPE/BPMEpNmbWUCSXAC Jbbsewg2iBHooO+n1oDFmQXEJW49mc8EcaiAxJI955khbFGJl4//QT2gKNH+tIERoj5f4sDq TjaIZYISJ2c+YZnAKDILyahZSMpmISmDiOtJ3Jg6hQ3C1pZYtvA1M4StKzHj3yEWZPEFjOyr GNlzEzNz0ssNNzECY+Xglt+6OxhPnRM5xCjNwaIkzvvhrXOQkEB6YklqdmpqQWpRfFFpTmrx IUYmDk6pBkZllnUd21hXXX/14ZOlnOQFY9bzG9XPfjLgmaViu+zK+S0X+YsY0r9e2dZtoFy5 e1fAEhH3Tx/awy/LnG5b3L/91HfF5bO3u6f6B9r2G5ov2HprUXVdo/FK/ssRWrvEPryftFfa lcH/AXfDkfxpB75xxU52Ct+/QMJxrehOnuh1E+zelOh/S4lTYinOSDTUYi4qTgQAjZFP9WMC AAA= Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same type) within a response message X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 08:27:08 -0000 --_000_087A34937E64E74E848732CFF8354B920972BDDBESESSMB101erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Nirav, I think I understand your concern. It may occur that we need that a reactin= g node should apply two different OLR when sending a request towards one sp= ecific host. Then, we may think that we need two different OLRs with ReportType=3Dhost, = and one of them includes the extra info (AVPs) required for that applicatio= n, I think this is your interpretation, but... we can as well consider a ne= w ReportType=3DapplicX_ReportY, that may apply e.g. for any request send to= this application, or just for this application+host, and then Host could b= e another AVP to be included in the OLR, or we could define expected behavi= our when defining this new ReportType. Would this cover your concerns? If not, could you try to provide an example= that requires two OLR with ReportType=3Dhost? A part from that, a question for all, if we extend ReportType, does it need= to be done by IETF, or could it be done per application by 3GPP? Thanks /MCruz From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Nirav Salot (nsalot) Sent: jueves, 28 de noviembre de 2013 17:11 To: lionel.morand@orange.com Cc: dime@ietf.org Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same type= ) within a response message Hi Lionel, I am not sure if defining new ReportType for every new AVP 3GPP would add f= or a specific application would be a good solution. I thought ReportType would indicate if the corresponding OC-OLR should be u= sed while sending the traffic towards the host or towards the realm. So from that point of view, all the OC-OLR generated by the server should h= ave ReportType=3Dhost. i.e. when the reacting node sends the traffic toward= s that host, it should make use of the corresponding OC-OLR. Now, this OC-O= LR may contain the AVPs defined by DOIC draft as well as 3GPP application s= pecific AVPs. In general, I was just thinking that it may be good idea to define some of = the principles such as - More than one instances of OC-OLR with ReportType=3Dhost may be = present in the answer message if the OC-OLR definition is extended by the a= pplication using the same. In that case, it is the responsibility of the ap= plication to define the valid combination of OC-OLR instances in a given me= ssage - If the reporting node includes more than one instance of OC-OLR,= the reporting node shall always include all the active instances of OC-OLR= in a response message. - When the reacting node receives one or more instances of OC-OLR = with the given ReportType and with new timestamp value, it should overwrite= all the existing OC-OLR of the same ReportType. Regards, Nirav. From: lionel.morand@orange.com [mailto:lionel.morand@orange.com] Sent: Thursday, November 28, 2013 7:39 PM To: Nirav Salot (nsalot) Cc: dime@ietf.org Subject: RE: DOIC: Multiple instance of OC-OLR AVP (of the same type) withi= n a response message Hi Nirav, The Report Type should be able to differentiate such cases. In your example= , I would define a specific Report type. But difficult to appraise all the future use cases. But for me, the main us= e of the report type is to differentiate OC-OLR received in the same messag= e. And it is the reasons of my recommendation. Actually, the exact wording wil= l be a "SHOULD" saying that it is recommended but you may have serious reas= ons to do otherwise. Lionel De : Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Envoy=E9 : jeudi 28 novembre 2013 13:00 =C0 : MORAND Lionel IMT/OLN Cc : dime@ietf.org Objet : RE: DOIC: Multiple instance of OC-OLR AVP (of the same type) within= a response message Lionel, 3gpp may define an optional avp which can be included by the reporting node= if it wishes to do so. E.g. APN can be additionally included by the report= ing node to indicate APN specific overload within the given application. In that case, the reporting node may also want to indicate application leve= l overload without including the APN (e.g. this overload report is applicab= le to all other APNs). And hence there is a possibility of including multiple instances of the ove= rload report. I am not suggesting that 3gpp will define APN (or any other avp) within ove= rload report. But later, if 3gpp need to define the same, then correspondin= g handling needs to be defined within IETF now. Regards, Nirav. On Nov 28, 2013 3:56 PM, "lionel.morand@orange.com" > wrote= : Hi Nirav, Not sure to understand the proposal or question. The OLR is significant per application (piggybacking principle). So if the = 3GPP decides to add specific AVPs in the OLR (that will be possible), what = would be the need to add the OLR without the specific 3GPP AVPs as the OLR = will be anyway handle by 3GPP aware entities? Lionel De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot (nsalot) Envoy=E9 : jeudi 28 novembre 2013 10:33 =C0 : dime@ietf.org Objet : [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same type) wit= hin a response message Hi, As I understand IETF will define the base overload control solution as part= of DOIC. Then 3GPP would adopt the defined solution for each of its applic= ation. When that happens, 3GPP might want to add 3GPP specific AVP within OC-OLR A= VP. Based on the current definition of the OC-OLR AVP this should be allowe= d since it contains "* [AVP]" in its definition. e.g. for a given application 3GPP decides to add information into OC-OLR wh= ich changes the scope of the OC-OLR from application level to the provided = information level. Additionally, the reporting may want to advertise the OC-OLR at the applica= tion level scope - i.e. the OC-OLR without any 3GPP specific info. So if the above is allowed, we will have the possibility of the reporting n= ode wanting to include two instances of OC-OLR with the Report-Type=3D"host= ". And then we need to define the handling of multiple instances of OC-OLR in = the DOIC draft. So the questions are, - Is 3GPP (or any other SDO) allowed to extend the definition of O= C-OLR by adding information into it? - If no, can we guarantee that application level scope of OC-OLR (= which is what we have defined currently) is sufficient (and not restricting= ) to all the applications of 3GPP? Regards, Nirav. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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 confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. --_000_087A34937E64E74E848732CFF8354B920972BDDBESESSMB101erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Nirav,

 

I think I understand y= our concern. It may occur that we need that a reacting node should apply tw= o different OLR when sending a request towards one specific host.

Then, we may think tha= t we need two different OLRs with ReportType=3Dhost, and one of them includ= es the extra info (AVPs) required for that application, I think this is you= r interpretation, but… we can as well consider a new ReportType=3DapplicX_ReportY, that may apply e.g. for any r= equest send to this application, or just for this application+host, and= then Host could be another AVP to be included in the OLR, or we could defi= ne expected behaviour when defining this new ReportType.

 

Would this cover your = concerns? If not, could you try to provide an example that requires two OLR= with ReportType=3Dhost?

 

A part from that, a qu= estion for all, if we extend ReportType, does it need to be done by IETF, o= r could it be done per application by 3GPP?

 

Thanks

/MCruz

 

From: DiME [ma= ilto:dime-bounces@ietf.org] On Behalf Of Nirav Salot (nsalot)
Sent: jueves, 28 de noviembre de 2013 17:11
To: lionel.morand@orange.com
Cc: dime@ietf.org
Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the sa= me type) within a response message

 

Hi Lionel,<= /span>

 

I am not sure if defin= ing new ReportType for every new AVP 3GPP would add for a specific applicat= ion would be a good solution.

I thought ReportType w= ould indicate if the corresponding OC-OLR should be used while sending the = traffic towards the host or towards the realm.

So from that point of = view, all the OC-OLR generated by the server should have ReportType=3Dhost.= i.e. when the reacting node sends the traffic towards that host, it should= make use of the corresponding OC-OLR. Now, this OC-OLR may contain the AVPs defined by DOIC draft as well as 3GP= P application specific AVPs.

 

In general, I was just= thinking that it may be good idea to define some of the principles such as=

-&n= bsp;         More than one = instances of OC-OLR with ReportType=3Dhost may be present in the answer mes= sage if the OC-OLR definition is extended by the application using the same= . In that case, it is the responsibility of the application to define the valid combination of OC-OLR instances in = a given message

-&n= bsp;         If the reporti= ng node includes more than one instance of OC-OLR, the reporting node shall= always include all the active instances of OC-OLR in a response message.

-&n= bsp;         When the react= ing node receives one or more instances of OC-OLR with the given ReportType= and with new timestamp value, it should overwrite all the existing OC-OLR = of the same ReportType.

 

Regards,

Nirav.

 

From: lionel.m= orand@orange.com [mailto:lionel.morand@orange.com]
Sent: Thursday, November 28, 2013 7:39 PM
To: Nirav Salot (nsalot)
Cc: dime@ietf.org
Subject: RE: DOIC: Multiple instance of OC-OLR AVP (of the same type= ) within a response message

 

Hi Nirav,<= o:p>

 = ;

The Report Type should= be able to differentiate such cases. In your example, I would define a spe= cific Report type.

But difficult to appra= ise all the future use cases. But for me, the main use of the report type i= s to differentiate OC-OLR received in the same message.

And it is the reasons = of my recommendation. Actually, the exact wording will be a "SHOULD&qu= ot; saying that it is recommended but you may have serious reasons to do ot= herwise.

 

Lionel

 

De : Nirav Salot (nsalot) [mailto:nsalot@cisco.com]
Envoy=E9 : jeudi 28 novembre 2013 13:00
=C0 : MORAND Lionel IMT/OLN
Cc : dime@ietf.org
Objet : RE: DOIC: Multiple instance of OC-OLR AVP (of the same = type) within a response message

 

Lionel,

3gpp may define an optional avp which can be included = by the reporting node if it wishes to do so. E.g. APN can be additionally i= ncluded by the reporting node to indicate APN specific overload within the = given application.
In that case, the reporting node may also want to indicate application leve= l overload without including the APN (e.g. this overload report is applicab= le to all other APNs).

And hence there is a possibility of including multiple= instances of the overload report.

I am not suggesting that 3gpp will define APN (or any = other avp) within overload report. But later, if 3gpp need to define the sa= me, then corresponding handling needs to be defined within IETF now.

Regards,
Nirav.

On Nov 28, 2013 3:56 PM,= "lionel.morand@orange.com= " <lionel.morand@or= ange.com> wrote:

Hi Nirav,<= /span>

 

Not sure to understand= the proposal or question.

The OLR is significant= per application (piggybacking principle). So if the 3GPP decides to add sp= ecific AVPs in the OLR (that will be possible), what would be the need to a= dd the OLR without the specific 3GPP AVPs as the OLR will be anyway handle by 3GPP aware entities?

 

Lionel

 

De : DiME [mailto:d= ime-bounces@ietf.org] De la part de Nirav Salot (nsalot)
Envoy=E9 : jeudi 28 novembre 2013 10:33
=C0 : dime@ietf.org
Objet : [Dime] DOIC: Multiple instance of OC-OLR AVP (of the sa= me type) within a response message

 

Hi,

 

As I understand IETF will define the base overload c= ontrol solution as part of DOIC. Then 3GPP would adopt the defined solution= for each of its application.

When that happens, 3GPP might want to add 3GPP speci= fic AVP within OC-OLR AVP. Based on the current definition of the OC-OLR AV= P this should be allowed since it contains "* [AVP]" in its defin= ition.

e.g. for a given application 3GPP decides to add inf= ormation into OC-OLR which changes the scope of the OC-OLR from application= level to the provided information level.

Additionally, the reporting may want to advertise th= e OC-OLR at the application level scope – i.e. the OC-OLR without any= 3GPP specific info.

 

So if the above is allowed, we will have the possibi= lity of the reporting node wanting to include two instances of OC-OLR with = the Report-Type=3D"host".

And then we need to define the handling of multiple = instances of OC-OLR in the DOIC draft.<= /p>

 

So the questions are,

-          Is 3GPP (or any other SDO) allowed to extend the definition of OC-OL= R by adding information into it?

-          If no, can we guarantee that application level scope of OC-OLR (whic= h is what we have defined currently) is sufficient (and not restricting) to= all the applications of 3GPP?

 

Regards,

Nirav.

 

____________________________________________________=
_____________________________________________________________________<=
/o:p>
 
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces j=
ointes. 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 confide=
ntial or privileged information that may be protected by law;
they should not be distributed, used or copied witho=
ut authorisation.
If you have received this email in error, please not=
ify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.


____________________________________________________=
_____________________________________________________________________<=
/o:p>
 
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces j=
ointes. 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 confide=
ntial or privileged information that may be protected by law;
they should not be distributed, used or copied witho=
ut authorisation.
If you have received this email in error, please not=
ify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.
--_000_087A34937E64E74E848732CFF8354B920972BDDBESESSMB101erics_-- From maria.cruz.bartolome@ericsson.com Tue Dec 3 00:42:59 2013 Return-Path: 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 A49581AE097 for ; Tue, 3 Dec 2013 00:42:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, 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 swTGgRMo_qhS for ; Tue, 3 Dec 2013 00:42:57 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 2CAD81ADFD6 for ; Tue, 3 Dec 2013 00:42:56 -0800 (PST) X-AuditID: c1b4fb25-b7eff8e000000eda-2f-529d998c8f27 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id CF.A8.03802.C899D925; Tue, 3 Dec 2013 09:42:52 +0100 (CET) Received: from ESESSMB101.ericsson.se ([169.254.1.118]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.02.0347.000; Tue, 3 Dec 2013 09:42:51 +0100 From: Maria Cruz Bartolome To: "dime@ietf.org" Thread-Topic: OLR applicable for any/all applications Thread-Index: Ac7wA2nX03YOMS5NT1qqOpqV4/v8iQ== Date: Tue, 3 Dec 2013 08:42:50 +0000 Message-ID: <087A34937E64E74E848732CFF8354B920972BE0C@ESESSMB101.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: multipart/alternative; boundary="_000_087A34937E64E74E848732CFF8354B920972BE0CESESSMB101erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGLMWRmVeSWpSXmKPExsUyM+JvrW7PzLlBBvN321jM7V3B5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujMu9u1kLbtVWLGk9xNLA+CWvi5GTQ0LARGLqjoXsELaYxIV7 69m6GLk4hAQOMUpMXbKLGcJZzCjx6OAeVpAqNgE7iUunXzB1MXJwiAgoS5z+5QASFhYwkLgy fSITiC0iYCpx/fwqZghbT2LpvQ1grSwCKhJnbkPEeQV8JbYseg1Wzwi0+PupNWA2s4C4xK0n 85kgDhKQWLLnPDOELSrx8vE/VghbUaL9aQMjRH2+xLWdK9khZgpKnJz5hGUCo9AsJKNmISmb haQMIq4jsWD3JzYIW1ti2cLXzDD2mQOPmZDFFzCyr2Jkz03MzEkvN9rECAz7g1t+q+5gvHNO 5BCjNAeLkjjvh7fOQUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYQ6c7RFe8+rG/48OdDMMa Y49Zu8v9TLZMDMjg050asIBX7sLndIOkxVtNFoZ0B38Tu7C9NvJL6fsfVX9+OT2sU7qw5sJJ kagjmy9yK4sVX77jlHmM/4rQFYWXP9QnnWS4s0jm+sm/+2zWvTSQ+c6s/Oecrvq77RGp5ox8 Mqe25OmsK+xqya1NVGIpzkg01GIuKk4EAAW56dRJAgAA Subject: [Dime] OLR applicable for any/all applications X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 08:42:59 -0000 --_000_087A34937E64E74E848732CFF8354B920972BE0CESESSMB101erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, There may be a need by a reporting node to request traffic reduction for al= l traffic, application independent, e.g. if an operator's network becomes s= everely overloaded, it may be of interest to signal directly general overlo= ad to the client. In this case, since reacting node obtains affected application from the app= lication message, we may need to extend OLR. At least we got following options: A) Define a new optional AVP that could be included into OLR, like e.g.= : OC-OLR ::=3D < AVP Header: TBD2 > < TimeStamp > [ Reduction-Percentage ] [ ValidityDuration ] [ ReportType ] [All applications] * [ AVP ] B) Extend ReportTypes like e.g.: 3 Destination-Host All Applications report. Similar to Destination-Hos= t report but it would apply to any application regardless the application m= essage this report is received within. 4 Realm (aggregated) All Applications report. Similar to Realm report = but it would apply to any application regardless the application message th= is report is received within. I tend to prefer option A, but let me know your opinions and preferences. Best regards /MCruz --_000_087A34937E64E74E848732CFF8354B920972BE0CESESSMB101erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Dear all,

 

There may be a need by a reporting node to request t= raffic reduction for all traffic, application independent, e.g. if an opera= tor’s network becomes severely overloaded, it may be of interest to s= ignal directly general overload to the client. 

In this case, since reacting node obtains affected a= pplication from the application message, we may need to extend OLR.

 

At least we got following options:

 

 

A)     Define a new optional AVP that could be included in= to OLR, like e.g.:

   OC-OLR ::=3D < AVP Header: TBD2 >
           =
;   < TimeStamp >
           =
;   [ Reduction-Percentage ]
           =
;   [ ValidityDuration ]
           =
;   [ ReportType ]
           =
;   [All application=
s]

           =
; * [ AVP ]


 


 



B)     
Extend  ReportTypes like e.g.:


 


  =
; 3  Destination-Host
All Applications
report.  Similar to Destination-Host report but it would =
apply to any application regardless the application message this report is =
received within.


 =



  =
; 4  Realm (aggregated)
All Applications report.  Similar to Realm rep=
ort but it would apply to any application regardless the application
 message this report is received within.


 


 


 


I tend to prefer option A, but let me know your opin=
ions and preferences.


Best regards


/MCruz


 


 
--_000_087A34937E64E74E848732CFF8354B920972BE0CESESSMB101erics_-- From jouni.nospam@gmail.com Tue Dec 3 01:15:50 2013 Return-Path: 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 DE6F41AE0E5 for ; Tue, 3 Dec 2013 01:15:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 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, FREEMAIL_REPLY=1, SPF_PASS=-0.001] autolearn=no 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 BY_I_iGHH6g9 for ; Tue, 3 Dec 2013 01:15:48 -0800 (PST) Received: from mail-bk0-x230.google.com (mail-bk0-x230.google.com [IPv6:2a00:1450:4008:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 5F77F1AE0E4 for ; Tue, 3 Dec 2013 01:15:48 -0800 (PST) Received: by mail-bk0-f48.google.com with SMTP id v10so5776839bkz.7 for ; Tue, 03 Dec 2013 01:15:45 -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=JFYfYCdBXyohN8jvUliHxa4r4USBuRLDR6Ijig7xwR0=; b=MULq++M54Fn/gD9o2J/tCh5+s63aCv4Snyrz4eMxDLAf+bPqQiXIsXGUstVRhEUnH2 bLwIZtSGRGvnWRVmKYtKftylZZLxefduabpZBUtaSiL5i0nqGUBfNXWhTdEY+ThVTiJW TouVxUM6EjfZytdZV02cTPJ61b4zM63Khbk2ySzO9VFPq2ONrpvxa/9k5rit0CYbE8o0 1eS7heQuwmdmo4TlSfsDy0EbQSCGpkNB9+E5GEcr0oz43B8DwziamGnQnM8VK/cAaJh+ 5A6OG54KCd/+kfvyass4v48Je71CLeNjqa76QxD6Rgg0JqDzq2KvLgCc6FXA9/CheGIi VJ6Q== X-Received: by 10.204.234.202 with SMTP id kd10mr677082bkb.53.1386062145093; Tue, 03 Dec 2013 01:15:45 -0800 (PST) Received: from ?IPv6:2001:6e8:480:60:8140:b30:4238:2452? ([2001:6e8:480:60:8140:b30:4238:2452]) by mx.google.com with ESMTPSA id j6sm67370152bki.17.2013.12.03.01.15.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Dec 2013 01:15:42 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <087A34937E64E74E848732CFF8354B920972BDDB@ESESSMB101.ericsson.se> Date: Tue, 3 Dec 2013 11:15:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7EFBB091-6B6F-4595-A197-70115DA8DDF4@gmail.com> References: , <2901_1385634414_52971A6E_2901_2686_1_6B7134B31289DC4FAF731D844122B36E307743@PEXCVZYM13.corporate.adroot.infra.ftgroup> <30095_1385647765_52974E95_30095_213_1_6B7134B31289DC4FAF731D844122B36E307DF6@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B920972BDDB@ESESSMB101.ericsson.se> To: Maria Cruz Bartolome X-Mailer: Apple Mail (2.1510) Cc: "dime@ietf.org" Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same type) within a response message X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 09:15:51 -0000 On Dec 3, 2013, at 10:26 AM, Maria Cruz Bartolome = wrote: > Nirav, > =20 > I think I understand your concern. It may occur that we need that a = reacting node should apply two different OLR when sending a request = towards one specific host. > Then, we may think that we need two different OLRs with = ReportType=3Dhost, and one of them includes the extra info (AVPs) = required for that application, I think this is your interpretation, but=85= we can as well consider a new ReportType=3DapplicX_ReportY, that may = apply e.g. for any request send to this application, or just for this = application+host, and then Host could be another AVP to be included in = the OLR, or we could define expected behaviour when defining this new = ReportType. > =20 > Would this cover your concerns? If not, could you try to provide an = example that requires two OLR with ReportType=3Dhost? > =20 > A part from that, a question for all, if we extend ReportType, does it = need to be done by IETF, or could it be done per application by 3GPP? Section 4.6 defines a new "Overload Report Type" registry with its initial assignments. New types can be added using the Specification Required policy [RFC5226]. So no.. as long as the report type value is documented somewhere in a = publicly available document that can be expected to be around for long = enough. Good point that this came up. We need to define the handling procedure = for an OLR whose report type is not understood by the receiver. - Jouni > =20 > Thanks > /MCruz > =20 > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Nirav Salot = (nsalot) > Sent: jueves, 28 de noviembre de 2013 17:11 > To: lionel.morand@orange.com > Cc: dime@ietf.org > Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same = type) within a response message > =20 > Hi Lionel, > =20 > I am not sure if defining new ReportType for every new AVP 3GPP would = add for a specific application would be a good solution. > I thought ReportType would indicate if the corresponding OC-OLR should = be used while sending the traffic towards the host or towards the realm. > So from that point of view, all the OC-OLR generated by the server = should have ReportType=3Dhost. i.e. when the reacting node sends the = traffic towards that host, it should make use of the corresponding = OC-OLR. Now, this OC-OLR may contain the AVPs defined by DOIC draft as = well as 3GPP application specific AVPs. > =20 > In general, I was just thinking that it may be good idea to define = some of the principles such as > - More than one instances of OC-OLR with ReportType=3Dhost = may be present in the answer message if the OC-OLR definition is = extended by the application using the same. In that case, it is the = responsibility of the application to define the valid combination of = OC-OLR instances in a given message > - If the reporting node includes more than one instance of = OC-OLR, the reporting node shall always include all the active instances = of OC-OLR in a response message. > - When the reacting node receives one or more instances of = OC-OLR with the given ReportType and with new timestamp value, it should = overwrite all the existing OC-OLR of the same ReportType. > =20 > Regards, > Nirav. > =20 > From: lionel.morand@orange.com [mailto:lionel.morand@orange.com]=20 > Sent: Thursday, November 28, 2013 7:39 PM > To: Nirav Salot (nsalot) > Cc: dime@ietf.org > Subject: RE: DOIC: Multiple instance of OC-OLR AVP (of the same type) = within a response message > =20 > Hi Nirav, > =20 > The Report Type should be able to differentiate such cases. In your = example, I would define a specific Report type. > But difficult to appraise all the future use cases. But for me, the = main use of the report type is to differentiate OC-OLR received in the = same message. > And it is the reasons of my recommendation. Actually, the exact = wording will be a "SHOULD" saying that it is recommended but you may = have serious reasons to do otherwise. > =20 > Lionel > =20 > De : Nirav Salot (nsalot) [mailto:nsalot@cisco.com]=20 > Envoy=E9 : jeudi 28 novembre 2013 13:00 > =C0 : MORAND Lionel IMT/OLN > Cc : dime@ietf.org > Objet : RE: DOIC: Multiple instance of OC-OLR AVP (of the same type) = within a response message > =20 > Lionel, >=20 > 3gpp may define an optional avp which can be included by the reporting = node if it wishes to do so. E.g. APN can be additionally included by the = reporting node to indicate APN specific overload within the given = application. > In that case, the reporting node may also want to indicate application = level overload without including the APN (e.g. this overload report is = applicable to all other APNs). >=20 > And hence there is a possibility of including multiple instances of = the overload report. >=20 > I am not suggesting that 3gpp will define APN (or any other avp) = within overload report. But later, if 3gpp need to define the same, then = corresponding handling needs to be defined within IETF now. >=20 > Regards, > Nirav. >=20 > On Nov 28, 2013 3:56 PM, "lionel.morand@orange.com" = wrote: > Hi Nirav, > =20 > Not sure to understand the proposal or question. > The OLR is significant per application (piggybacking principle). So if = the 3GPP decides to add specific AVPs in the OLR (that will be = possible), what would be the need to add the OLR without the specific = 3GPP AVPs as the OLR will be anyway handle by 3GPP aware entities? > =20 > Lionel > =20 > De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot = (nsalot) > Envoy=E9 : jeudi 28 novembre 2013 10:33 > =C0 : dime@ietf.org > Objet : [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same = type) within a response message > =20 > Hi, > =20 > As I understand IETF will define the base overload control solution as = part of DOIC. Then 3GPP would adopt the defined solution for each of its = application. > When that happens, 3GPP might want to add 3GPP specific AVP within = OC-OLR AVP. Based on the current definition of the OC-OLR AVP this = should be allowed since it contains "* [AVP]" in its definition. > e.g. for a given application 3GPP decides to add information into = OC-OLR which changes the scope of the OC-OLR from application level to = the provided information level. > Additionally, the reporting may want to advertise the OC-OLR at the = application level scope =96 i.e. the OC-OLR without any 3GPP specific = info. > =20 > So if the above is allowed, we will have the possibility of the = reporting node wanting to include two instances of OC-OLR with the = Report-Type=3D"host". > And then we need to define the handling of multiple instances of = OC-OLR in the DOIC draft. > =20 > So the questions are, > - Is 3GPP (or any other SDO) allowed to extend the definition = of OC-OLR by adding information into it? > - If no, can we guarantee that application level scope of = OC-OLR (which is what we have defined currently) is sufficient (and not = restricting) to all the applications of 3GPP? > =20 > Regards, > Nirav. > =20 > = __________________________________________________________________________= _______________________________________________ > =20 > 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. > =20 > 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. > = __________________________________________________________________________= _______________________________________________ > =20 > 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. > =20 > 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 From ulrich.wiehe@nsn.com Tue Dec 3 01:21:11 2013 Return-Path: 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 7CFE21AE0E4 for ; Tue, 3 Dec 2013 01:21:11 -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 VBZzEhDs4tX8 for ; Tue, 3 Dec 2013 01:21:05 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 276261AE0DC for ; Tue, 3 Dec 2013 01:21:03 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rB39KxpU012905 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 3 Dec 2013 10:20:59 +0100 Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rB39KwiF032180 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Dec 2013 10:20:59 +0100 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.123.3; Tue, 3 Dec 2013 10:20:59 +0100 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.152]) by DEMUHTC013.nsn-intra.net ([10.159.42.44]) with mapi id 14.03.0123.003; Tue, 3 Dec 2013 10:20:59 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: ext Maria Cruz Bartolome , "dime@ietf.org list" Thread-Topic: [Dime] DOIC: Self-Contained OLRs Thread-Index: AQHO67/t2PaAGa/GgUyaCwjRxXVUh5o5m/0AgAC8o/D///ghgIAAFu+wgAGHVQCAACqasIAAMwWAgANxipCAAKJuAIAATHjQgAAM5ICAABPPEIAAFwqAgAAGBICAAAUigIAAJC3wgAEbsUA= Date: Tue, 3 Dec 2013 09:20:59 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519C248@DEMUMBX014.nsn-intra.net> References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D90006681519BC90@DEMUMBX014.nsn-intra.net> <6390_1385631044_52970D44_6390_18593_1_6B7134B31289DC4FAF731D844122B36E30748E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BD19@DEMUMBX014.nsn-intra.net> <17872_1385720008_529868C8_17872_2613_1_6B7134B31289DC4FAF731D844122B36E3096B8@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BF1B@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681519BFAE@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681519C017@DEMUMBX014.nsn-intra.net> , <5BCBA1FC2B7F0B4C9D935572D90006681519C087@DEMUMBX014.nsn-intra.net> <16844_1385993987_529C9702_16844_18637_1_6B7134B31289DC4FAF731D844122B36E310C3F@PEXCVZYM13.corporate.adroot.infra.ftgroup> <02B93103-E094-4E5D-B6E0-5564115A9E0D@gmail.com> <087A34937E64E74E848732CFF8354B920972B9AE@ESESSMB101.ericsson.se> In-Reply-To: <087A34937E64E74E848732CFF8354B920972B9AE@ESESSMB101.ericsson.se> 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: 26620 X-purgate-ID: 151667::1386062459-000022AE-296322F1/0-0/0-0 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 09:21:11 -0000 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 retu= rns a host-type OLR to C (via A) and there is no need for A to insert a rea= lm-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 Destinat= ion Host in which case any realm-type OLR inserted by A would be useless to= C.=20 Similarly In figure 5 when C sends a request without Destination Host, A ma= y 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 rece= ived 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 Barto= lome 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 no= rmal behavior. But I agree in case the request is towards a Destination Host, receiving th= e 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 no= de 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 t= he 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 o= n the need for the Report-Type. > =20 > 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 De= stination-Host is not in the answer. So receiving a host-based OLR in respo= nse 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 pos= itive 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" of= fered 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 th= e client could include a destination-host or not. So the client needs to kn= ow which reduction to apply from a previous answer. > =20 > 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 co= ntext based on the type of request. > =20 > Regards, > =20 > Lionel > =20 > =20 > De : Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Envoy=E9 : lundi 2=20 > d=E9cembre 2013 14:58 =C0 : Wiehe, Ulrich (NSN - DE/Munich) Cc :=20 > dime@ietf.org list; ext Jouni Korhonen; MORAND Lionel IMT/OLN; Ben=20 > Campbell Objet : RE: [Dime] DOIC: Self-Contained OLRs > =20 > Ulrich, >=20 > 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? >=20 > I would prefer to derive the context of the OLR based on the message whic= h contains the OLR. >=20 > Back to the topic of this thread, I don't think we need to define an "opt= ional" optimization at this stage. Either it is respected by all the nodes = supporting the solution or we drop that optimization. >=20 > Regards, > Nirav. >=20 > On Dec 2, 2013 5:27 PM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: > Nirav, >=20 > If the reacting node sends a request without Destination Host, a realm-ty= pe OLR in the answer would be in-context whereas a host-type OLR in the ans= wer would be out of context. >=20 > Similarly, if the reacting node sends a request containing Destination Ho= st, a realm-type OLR in the answer would be out-of-context and a host-type = OLR in the answer would be in-context. >=20 > Ulrich >=20 >=20 >=20 > -----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=20 > Jouni Korhonen; Ben Campbell > Cc: dime@ietf.org list > Subject: RE: [Dime] DOIC: Self-Contained OLRs >=20 > Ulrich, >=20 > I have a basic question. >=20 > When the reacting node sends realm-routed request and it receives (only o= ne) OLR in the response message (which also contains the origin-host), is t= his OLR applicable for realm or host? > I am trying to understand which is out-of-context OLR here: realm-type or= host-type? >=20 > Regards, > Nirav. >=20 > -----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=20 > Korhonen; Ben Campbell > Cc: dime@ietf.org list > Subject: RE: [Dime] DOIC: Self-Contained OLRs >=20 > Hi Nirav, >=20 > please see inline. >=20 > Regards > Ulrich >=20 > -----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=20 > Jouni Korhonen; Ben Campbell > Cc: dime@ietf.org list > Subject: RE: [Dime] DOIC: Self-Contained OLRs >=20 > Ulrich, >=20 > When the client sends request containing destination-realm (and not conta= ining 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 thi= s response message is not out-of-context information.=20 > [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= =3Dx1, destination realm =3Dx2 application=3D 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, w= hat the type x was. E.g. it deduces from the value of Origin Realm in the a= nswer the value of Destination Realm in the request; it deduces from the va= lue of Report-Type in the answer whether Destination Host was present in th= e request... >=20 > On the other hand, we discussed - as part of Maria Cruz's alternative sol= ution - to define the response message's context based on the request messa= ge. And hence if the request message was sent to destination-realm, the cor= responding 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 unneces= sary complexity.=20 > [Wiehe, Ulrich (NSN - DE/Munich)] I agree. This means: the report-type AV= P is needed to let the client deduce from information received in the answe= r whether the request contained a destination host. It does not mean that w= e need two OLRs in one answer. >=20 > If we strictly want to ensure that the realm-type OLR is not sent=20 > out-of-context [Wiehe, Ulrich (NSN - DE/Munich)] That was not my=20 > proposal. My proposal was to clearly mark out-of-context OLRs in=20 > answer messages (if we allow including out-of-context OLRs) >=20 > , then we should agree to Lionel's alternative solution - to send realm-t= ype OLR only when the destination-realm based request is rejected. So basic= ally, 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 ensu= re the context of the response message and the OLR it contains). >=20 > 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 on= e 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=20 > (NSN - DE/Munich)] only the out-of-context one >=20 > , then what is the point of including two OLRs [Wiehe, Ulrich (NSN - DE/M= unich)] 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 a= s 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 react= ing node (if the reacting node wants to make use of this optimization). >=20 > and what is the point of defining Report-Type AVP? > [Wiehe, Ulrich (NSN - DE/Munich)] to let the reacting node deduce from in= formation received in the answer whether the corresponding request containe= d a destination host (so there is no need to remember). >=20 >=20 > In summary, if we define Report-Type AVP and corresponding handling at th= e reacting node, the reacting node must act accordingly and not ignore it. > [Wiehe, Ulrich (NSN - DE/Munich)] What goes wrong when out-of -context O= LR is ignored? >=20 > 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 i= gnored. > [Wiehe, Ulrich (NSN - DE/Munich)] Not the Report-Type AVP is the optimiza= tion but the incusion of out-of-context OLRs. And I'm ok not to proceed wit= h this optimization as it is not needed. >=20 > Regards, > Nirav. >=20 > -----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=20 > Korhonen; Ben Campbell > Cc: dime@ietf.org list > Subject: RE: [Dime] DOIC: Self-Contained OLRs >=20 > Hi Nirav, >=20 > 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-contex= t. > There is nothing wrong with storing such out-of-context OLRs at the clien= t, but it is simply not needed as the client will learn this OLR from respo= nses received within the context. >=20 > Best regards > Ulrich >=20 >=20 > -----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=20 > Jouni Korhonen; Ben Campbell > Cc: dime@ietf.org list > Subject: RE: [Dime] DOIC: Self-Contained OLRs >=20 > Hi Ulrich, >=20 > If an additional OLR is present with a different ReportType, why it shoul= d be ignored by the reacting node? >=20 > Regards, > Nirav. >=20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich=20 > (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 >=20 > Hi Lionel, >=20 > there is nothing missing exept the clarification that everything works fi= ne 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. >=20 > Ulrich > =20 >=20 > -----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 >=20 > Hi Ulrich, >=20 > Using the Report Type "host report", you know that the OLR applies for su= bsequent 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.=20 >=20 > It is not so important to know what the type of request was and which nod= e 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, f= or instance, future development could allow a distributed server architectu= re to provide the same information. >=20 > I'm not sure of what is missing in this reasoning... >=20 > Lionel >=20 > -----Message d'origine----- > De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 > Envoy=E9 : jeudi 28 novembre 2013 11:30 =C0 : MORAND Lionel IMT/OLN; ext= =20 > Jouni Korhonen; Ben Campbell Cc : dime@ietf.org list Objet : RE:=20 > [Dime] DOIC: Self-Contained OLRs >=20 > Lionel, >=20 > my understanding was that _the_ reporting end point provides _the_ OLR. >=20 > If we go for two OLRs in the answer we should indicate which OLR is the a= ctual OLR created by the reporting end point and which OLR is an additional= OLR created by another node. >=20 > We have two cases: > a) The request sent by the client (reacting end point) contains no Destin= ation 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 OL= R as learned from the selected server. The client may ignore the additiona= l OLR. > b) The request sent by the client (reacting endpoint) contains the Destin= ation Host. The Server (reporting node) returns a host-type OLR as the actu= al reporting-node-created OLR in the answer. The agent may optionally inser= t a realm-type OLR as additional OLR to the answer. The client may ignore t= he additional OLR. >=20 > Ulrich >=20 >=20 >=20 > -----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 >=20 > Hi, >=20 > There is no assumption on which entity is providing the realm overload st= atus. 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 s= ome 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 ser= ver itself, one for the realm for new request sent to the realm with only D= est-Realm AVP. >=20 > Lionel >=20 > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich=20 > (NSN - DE/Munich) Envoy=E9 : jeudi 28 novembre 2013 10:26 =C0 : ext Jouni= =20 > Korhonen; Ben Campbell Cc : dime@ietf.org list Objet : Re: [Dime]=20 > DOIC: Self-Contained OLRs >=20 > Hi, >=20 > 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 i= ndicates 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 indicate= s to the reacting end point that the reporting end point is a server. How c= an the reporting end point be both agent and server? >=20 > Ulrich >=20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Jouni=20 > Korhonen > Sent: Wednesday, November 27, 2013 11:44 PM > To: Ben Campbell > Cc: dime@ietf.org list > Subject: Re: [Dime] DOIC: Self-Contained OLRs >=20 >=20 > On Nov 28, 2013, at 12:27 AM, Ben Campbell wrote: >=20 > > Hi, > >=20 > > I mentioned in another thread that I prefer putting an explicit=20 > > ReportType AVP in an OLR, rather than >=20 > The more I spent time thinking/writing the actual procedures on the endpo= ints, the more it makes sense to me to keep the ReportType in the OC-OLR. E= ven if the baseline does not have agent overload etc, the ReportType fits w= ell 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 pl= ain more clear. >=20 > I skip the rest of the mail.. too much text ;-) >=20 >=20 > - Jouni >=20 >=20 >=20 >=20 >=20 > > making a responding node infer the type or meaning of the OLR from a Di= ameter request that corresponds to the answer containing the OLR. My reason= s for that go beyond just ReportType, so I'm starting a separate thread. > >=20 > > 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 t= hat carries the OLR. For example, the OLR implicitly refers to the applicat= ion identified by the Application-Id field of the enclosing answer, the rea= lm 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 mea= ning in the context of the enclosing answer. If you moved an OLR from one a= nswer to another, it's meaning may change completely. > >=20 > > I think this approach is a mistake. I would greatly prefer that we expl= icitly include such values in the OLR itself, for multiple reasons: > >=20 > > 1) It's more complex to interpret implicit, contextual values than expl= icit values. The consumer cannot simply look at the OLR; it must look in va= rious other AVPs to find all the information it needs. For example, I think= a common software design for overload control processing to be separated f= rom 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 OL= R, 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 "c= ontext" avps that must be interpreted can grow large. This approach is erro= r prone, and will likely encourage brittle, hard-to-maintain code. Self-con= tained OLRs would keep all the information related to overload in one place= . making for simpler implementations. > >=20 > > 2) It's more complex for the reporting node to send implicit values tha= n explicit values. The sender cannot simply set the context to match the OL= R--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 ins= ert OLRs into answers created by other nodes.=20 > >=20 > > If the reporting node screws this up, the meaning of the OLR may change= significantly. So again, implicit meaning gives us error prone implementat= ions. Self-contained OLRs are simpler to create and send. > >=20 > > 3) Implicit values don't work at all for certain problems. For=20 > > example, if an agent needs to originate an OLR, it typically needs=20 > > to insert that OLR into an existing Diameter answer created by a server= . > > It can't create its own answer without affecting the application=20 > > state. If the responding node assumes the OLR comes from or refers=20 > > to the node identified by the Origin-Host AVP in the enclosing=20 > > answer, things break. (For examples of when an agent needs to send=20 > > OLRs that are distinct from those sent by a server, see Steve's=20 > > agent overload draft, or my dh/dr example.) > >=20 > > OTOH, explicit values will work for all cases where we need to associat= e some arbitrary value with an OLR. > >=20 > > 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 ov= erload 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 trans= ported, this won't work. We would have to create a new or significantly mod= ified OLR format if we found a need to transport OLRs in different ways. Se= lf-contained OLRs would allow much greater flexibility. > >=20 > > 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. > >=20 > > Thanks! > >=20 > > Ben. > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime >=20 > _______________________________________________ > 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 >=20 > ______________________________________________________________________ > ___________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc pas etre diffuses, exploites o= u copies sans autorisation. Si vous avez recu ce message par erreur, veuill= ez 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= . >=20 > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; they should not be distributed, us= ed or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 >=20 > ______________________________________________________________________ > ___________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc pas etre diffuses, exploites o= u copies sans autorisation. Si vous avez recu ce message par erreur, veuill= ez 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= . >=20 > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; they should not be distributed, us= ed or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > ______________________________________________________________________ > ___________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not be d= istributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 _______________________________________________ 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 From nsalot@cisco.com Tue Dec 3 01:26:04 2013 Return-Path: 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 EEC191AE0DC for ; Tue, 3 Dec 2013 01:26:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.501 X-Spam-Level: X-Spam-Status: No, score=-9.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.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 BE1FaMsLgmkb for ; Tue, 3 Dec 2013 01:25:57 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id 0EECB1AE0E4 for ; Tue, 3 Dec 2013 01:25:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=41012; q=dns/txt; s=iport; t=1386062754; x=1387272354; h=from:to:subject:date:message-id:mime-version; bh=Vo7CSJadlOh1wCSj+oXzLDgnQLScPYiEQAItzblEKG4=; b=mHyCFLe4uUzQmictQWSa5SOelSLBVJFz1C4nWeXIqAZ8IW6XTWXi0mSg oe9dojFCG6bF4u8HiA7qC/RLGYkFpux0Wrvx74cNrEJT1mlNLcPDbM0fn l5CMt4GBa0xIsKqrrVMcUEh9MCdzfRws3g/F2PScGPA5Kvk+OFsKvIJRq 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAAGjnVKtJXG//2dsb2JhbABagkNEOFO4Z4EZFnSCJQEBAQMBLVENAQgRBAEBCxYBBjkUCQkBBAESCBOHYAbBGheOHBEBHzcHgxqBEwOJCqEdgWuBPoFxOQ X-IronPort-AV: E=Sophos;i="4.93,816,1378857600"; d="scan'208,217";a="3892609" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by alln-iport-6.cisco.com with ESMTP; 03 Dec 2013 09:25:53 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id rB39PrLQ021503 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Dec 2013 09:25:53 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.250]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Tue, 3 Dec 2013 03:25:52 -0600 From: "Nirav Salot (nsalot)" To: Maria Cruz Bartolome , "dime@ietf.org" Thread-Topic: DOIC: Multiple instance of OC-OLR AVP (of the same type) within a response message Thread-Index: Ac7wCaL7vn3WS3V+QYqfk/QVoAmaPA== Date: Tue, 3 Dec 2013 09:25:51 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.233.77] Content-Type: multipart/alternative; boundary="_000_A9CA33BB78081F478946E4F34BF9AAA014D22C9Cxmbrcdx10ciscoc_" MIME-Version: 1.0 Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same type) within a response message X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 09:26:04 -0000 --_000_A9CA33BB78081F478946E4F34BF9AAA014D22C9Cxmbrcdx10ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Maria-Cruz, > we may think that we need two different OLRs with ReportType=3Dhost, and = one of them includes the extra info (AVPs) required for that application Yes. The above is my concern. I tried giving APN as one example AVP which w= e may want to include in OC-OLR. Let me give another possible example. As of now, the OC-OLR can indicate application + host/realm level "required= -reduction-percentage". However, for the given application (e.g. Gx) we may want to define a narrow= er scope with "session-type =3D {M2M, Others}" AVP. So basically, the Gx no= des can advertise different "required-reduction-percentage" for M2M session= s v/s other type of sessions for the same application Gx and for the same d= estination-host. So in general, if any application needs to define a different (i.e. narrowe= r) scope than application + host/realm, it can do so by adding a new AVP in= OC-OLR. And then we might have two instances of OC-OLR from the same host. We could achieve the above by defining new Report-Type for each new AVP add= ed by each application. But would this scale or is this a reasonable approa= ch? I am not sure and you have already identified one of my concerns below > if we extend ReportType, does it need to be done by IETF, or could it be = done per application by 3GPP? In summary, in my view, we need to define the handling of multiple instance= s with the same Report-Type as part of the DOIC draft. Or we say that multi= ple instances with the same Report-Type is not allowed - this seems unneces= sary restriction to me. Otherwise, if later, we realize the need to do so then we may not be able t= o do so since the handling is not defined in the base solution. Regards, Nirav. From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Maria Cruz Bartolome Sent: Tuesday, December 03, 2013 1:57 PM To: dime@ietf.org Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same type= ) within a response message Nirav, I think I understand your concern. It may occur that we need that a reactin= g node should apply two different OLR when sending a request towards one sp= ecific host. Then, we may think that we need two different OLRs with ReportType=3Dhost, = and one of them includes the extra info (AVPs) required for that applicatio= n, I think this is your interpretation, but... we can as well consider a ne= w ReportType=3DapplicX_ReportY, that may apply e.g. for any request send to= this application, or just for this application+host, and then Host could b= e another AVP to be included in the OLR, or we could define expected behavi= our when defining this new ReportType. Would this cover your concerns? If not, could you try to provide an example= that requires two OLR with ReportType=3Dhost? A part from that, a question for all, if we extend ReportType, does it need= to be done by IETF, or could it be done per application by 3GPP? Thanks /MCruz From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Nirav Salot (nsalot) Sent: jueves, 28 de noviembre de 2013 17:11 To: lionel.morand@orange.com Cc: dime@ietf.org Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same type= ) within a response message Hi Lionel, I am not sure if defining new ReportType for every new AVP 3GPP would add f= or a specific application would be a good solution. I thought ReportType would indicate if the corresponding OC-OLR should be u= sed while sending the traffic towards the host or towards the realm. So from that point of view, all the OC-OLR generated by the server should h= ave ReportType=3Dhost. i.e. when the reacting node sends the traffic toward= s that host, it should make use of the corresponding OC-OLR. Now, this OC-O= LR may contain the AVPs defined by DOIC draft as well as 3GPP application s= pecific AVPs. In general, I was just thinking that it may be good idea to define some of = the principles such as - More than one instances of OC-OLR with ReportType=3Dhost may be = present in the answer message if the OC-OLR definition is extended by the a= pplication using the same. In that case, it is the responsibility of the ap= plication to define the valid combination of OC-OLR instances in a given me= ssage - If the reporting node includes more than one instance of OC-OLR,= the reporting node shall always include all the active instances of OC-OLR= in a response message. - When the reacting node receives one or more instances of OC-OLR = with the given ReportType and with new timestamp value, it should overwrite= all the existing OC-OLR of the same ReportType. Regards, Nirav. From: lionel.morand@orange.com [mailto:lio= nel.morand@orange.com] Sent: Thursday, November 28, 2013 7:39 PM To: Nirav Salot (nsalot) Cc: dime@ietf.org Subject: RE: DOIC: Multiple instance of OC-OLR AVP (of the same type) withi= n a response message Hi Nirav, The Report Type should be able to differentiate such cases. In your example= , I would define a specific Report type. But difficult to appraise all the future use cases. But for me, the main us= e of the report type is to differentiate OC-OLR received in the same messag= e. And it is the reasons of my recommendation. Actually, the exact wording wil= l be a "SHOULD" saying that it is recommended but you may have serious reas= ons to do otherwise. Lionel De : Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Envoy=E9 : jeudi 28 novembre 2013 13:00 =C0 : MORAND Lionel IMT/OLN Cc : dime@ietf.org Objet : RE: DOIC: Multiple instance of OC-OLR AVP (of the same type) within= a response message Lionel, 3gpp may define an optional avp which can be included by the reporting node= if it wishes to do so. E.g. APN can be additionally included by the report= ing node to indicate APN specific overload within the given application. In that case, the reporting node may also want to indicate application leve= l overload without including the APN (e.g. this overload report is applicab= le to all other APNs). And hence there is a possibility of including multiple instances of the ove= rload report. I am not suggesting that 3gpp will define APN (or any other avp) within ove= rload report. But later, if 3gpp need to define the same, then correspondin= g handling needs to be defined within IETF now. Regards, Nirav. On Nov 28, 2013 3:56 PM, "lionel.morand@orange.com" > wrote= : Hi Nirav, Not sure to understand the proposal or question. The OLR is significant per application (piggybacking principle). So if the = 3GPP decides to add specific AVPs in the OLR (that will be possible), what = would be the need to add the OLR without the specific 3GPP AVPs as the OLR = will be anyway handle by 3GPP aware entities? Lionel De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot (nsalot) Envoy=E9 : jeudi 28 novembre 2013 10:33 =C0 : dime@ietf.org Objet : [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same type) wit= hin a response message Hi, As I understand IETF will define the base overload control solution as part= of DOIC. Then 3GPP would adopt the defined solution for each of its applic= ation. When that happens, 3GPP might want to add 3GPP specific AVP within OC-OLR A= VP. Based on the current definition of the OC-OLR AVP this should be allowe= d since it contains "* [AVP]" in its definition. e.g. for a given application 3GPP decides to add information into OC-OLR wh= ich changes the scope of the OC-OLR from application level to the provided = information level. Additionally, the reporting may want to advertise the OC-OLR at the applica= tion level scope - i.e. the OC-OLR without any 3GPP specific info. So if the above is allowed, we will have the possibility of the reporting n= ode wanting to include two instances of OC-OLR with the Report-Type=3D"host= ". And then we need to define the handling of multiple instances of OC-OLR in = the DOIC draft. So the questions are, - Is 3GPP (or any other SDO) allowed to extend the definition of O= C-OLR by adding information into it? - If no, can we guarantee that application level scope of OC-OLR (= which is what we have defined currently) is sufficient (and not restricting= ) to all the applications of 3GPP? Regards, Nirav. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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 confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. --_000_A9CA33BB78081F478946E4F34BF9AAA014D22C9Cxmbrcdx10ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Maria-Cruz,=

 

> we may think that we need two different OLRs with Repor= tType=3Dhost, and one of them includes the extra info (AVPs) required for t= hat application

Yes. The above is my c= oncern. I tried giving APN as one example AVP which we may want to include = in OC-OLR. Let me give another possible example.

As of now, the OC-OLR = can indicate application + host/realm level "required-reduction-pe= rcentage".

However, for the given= application (e.g. Gx) we may want to define a narrower scope with "se= ssion-type =3D {M2M, Others}" AVP. So basically, the Gx nodes can adve= rtise different "required-reduction-percentage" for M2M sessions v/s other type of sessions for the same application Gx an= d for the same destination-host.

 

So in general, if any = application needs to define a different (i.e. narrower) scope than applicat= ion + host/realm, it can do so by adding a new AVP in OC-OLR.

And then we might have= two instances of OC-OLR from the same host.

 

We could achieve the a= bove by defining new Report-Type for each new AVP added by each application= . But would this scale or is this a reasonable approach?

I am not sure and you = have already identified one of my concerns below

> if we extend ReportType, does it need to be done by IET= F, or could it be done per application by 3GPP?

 

In summary, in my view= , we need to define the handling of multiple instances with the same Report= -Type as part of the DOIC draft. Or we say that multiple instances with the= same Report-Type is not allowed – this seems unnecessary restriction to me.

Otherwise, if later, w= e realize the need to do so then we may not be able to do so since the hand= ling is not defined in the base solution.

 

Regards,

Nirav.

 

From: DiME [ma= ilto:dime-bounces@ietf.org] On Behalf Of Maria Cruz Bartolome
Sent: Tuesday, December 03, 2013 1:57 PM
To: dime@ietf.org
Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the sa= me type) within a response message

 

Nirav,

 

I think I understand y= our concern. It may occur that we need that a reacting node should apply tw= o different OLR when sending a request towards one specific host.

Then, we may think tha= t we need two different OLRs with ReportType=3Dhost, and one of them includ= es the extra info (AVPs) required for that application, I think this is you= r interpretation, but… we can as well consider a new ReportType=3DapplicX_ReportY, that may apply e.g. for any r= equest send to this application, or just for this application+host, and= then Host could be another AVP to be included in the OLR, or we could defi= ne expected behaviour when defining this new ReportType.

 

Would this cover your = concerns? If not, could you try to provide an example that requires two OLR= with ReportType=3Dhost?

 

A part from that, a qu= estion for all, if we extend ReportType, does it need to be done by IETF, o= r could it be done per application by 3GPP?

 

Thanks

/MCruz

 

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Nirav Salot (nsalot)
Sent: jueves, 28 de noviembre de 2013 17:11
To: lionel.morand@orange= .com
Cc: dime@ietf.org
Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the sa= me type) within a response message

 

Hi Lionel,<= /span>

 

I am not sure if defin= ing new ReportType for every new AVP 3GPP would add for a specific applicat= ion would be a good solution.

I thought ReportType w= ould indicate if the corresponding OC-OLR should be used while sending the = traffic towards the host or towards the realm.

So from that point of = view, all the OC-OLR generated by the server should have ReportType=3Dhost.= i.e. when the reacting node sends the traffic towards that host, it should= make use of the corresponding OC-OLR. Now, this OC-OLR may contain the AVPs defined by DOIC draft as well as 3GP= P application specific AVPs.

 

In general, I was just= thinking that it may be good idea to define some of the principles such as=

-&nb= sp;         More than one = instances of OC-OLR with ReportType=3Dhost may be present in the answer mes= sage if the OC-OLR definition is extended by the application using the same= . In that case, it is the responsibility of the application to define the valid combination of OC-OLR instances in = a given message

-&nb= sp;         If the reporti= ng node includes more than one instance of OC-OLR, the reporting node shall= always include all the active instances of OC-OLR in a response message.

-&nb= sp;         When the react= ing node receives one or more instances of OC-OLR with the given ReportType= and with new timestamp value, it should overwrite all the existing OC-OLR = of the same ReportType.

 

Regards,

Nirav.

 

From: lionel.morand@orange.com [<= a href=3D"mailto:lionel.morand@orange.com">mailto:lionel.morand@orange.com<= /a>]
Sent: Thursday, November 28, 2013 7:39 PM
To: Nirav Salot (nsalot)
Cc: dime@ietf.org
Subject: RE: DOIC: Multiple instance of OC-OLR AVP (of the same type= ) within a response message

 

Hi Nirav,<= o:p>

 = ;

The Report Type should= be able to differentiate such cases. In your example, I would define a spe= cific Report type.

But difficult to appra= ise all the future use cases. But for me, the main use of the report type i= s to differentiate OC-OLR received in the same message.

And it is the reasons = of my recommendation. Actually, the exact wording will be a "SHOULD&qu= ot; saying that it is recommended but you may have serious reasons to do ot= herwise.

 

Lionel

 

De : Nirav Salot (nsalot) [mailto:nsalot@cisco.com]
Envoy=E9 : jeudi 28 novembre 2013 13:00
=C0 : MORAND Lionel IMT/OLN
Cc : dime@ietf.org
Objet : RE: DOIC: Multiple instance of OC-OLR AVP (of the same = type) within a response message

 

Lionel,

3gpp may define an optional avp which can be included = by the reporting node if it wishes to do so. E.g. APN can be additionally i= ncluded by the reporting node to indicate APN specific overload within the = given application.
In that case, the reporting node may also want to indicate application leve= l overload without including the APN (e.g. this overload report is applicab= le to all other APNs).

And hence there is a possibility of including multiple= instances of the overload report.

I am not suggesting that 3gpp will define APN (or any = other avp) within overload report. But later, if 3gpp need to define the sa= me, then corresponding handling needs to be defined within IETF now.

Regards,
Nirav.

On Nov 28, 2013 3:56 PM,= "lionel.morand@orange.com= " <lionel.morand@or= ange.com> wrote:

Hi Nirav,<= /span>

 

Not sure to understand= the proposal or question.

The OLR is significant= per application (piggybacking principle). So if the 3GPP decides to add sp= ecific AVPs in the OLR (that will be possible), what would be the need to a= dd the OLR without the specific 3GPP AVPs as the OLR will be anyway handle by 3GPP aware entities?

 

Lionel

 

De : DiME [mailto:d= ime-bounces@ietf.org] De la part de Nirav Salot (nsalot)
Envoy=E9 : jeudi 28 novembre 2013 10:33
=C0 : dime@ietf.org
Objet : [Dime] DOIC: Multiple instance of OC-OLR AVP (of the sa= me type) within a response message

 

Hi,

 

As I understand IETF will define the base overload c= ontrol solution as part of DOIC. Then 3GPP would adopt the defined solution= for each of its application.

When that happens, 3GPP might want to add 3GPP speci= fic AVP within OC-OLR AVP. Based on the current definition of the OC-OLR AV= P this should be allowed since it contains "* [AVP]" in its defin= ition.

e.g. for a given application 3GPP decides to add inf= ormation into OC-OLR which changes the scope of the OC-OLR from application= level to the provided information level.

Additionally, the reporting may want to advertise th= e OC-OLR at the application level scope – i.e. the OC-OLR without any= 3GPP specific info.

 

So if the above is allowed, we will have the possibi= lity of the reporting node wanting to include two instances of OC-OLR with = the Report-Type=3D"host".

And then we need to define the handling of multiple = instances of OC-OLR in the DOIC draft.<= /p>

 

So the questions are,

-=           Is 3GPP (or any other SDO) allowed to extend the definition of OC-OL= R by adding information into it?

-=           If no, can we guarantee that application level scope of OC-OLR (whic= h is what we have defined currently) is sufficient (and not restricting) to= all the applications of 3GPP?

 

Regards,

Nirav.

 

____________________________________________________=
_____________________________________________________________________<=
/o:p>
 
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces j=
ointes. 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 confide=
ntial or privileged information that may be protected by law;
they should not be distributed, used or copied witho=
ut authorisation.
If you have received this email in error, please not=
ify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.


____________________________________________________=
_____________________________________________________________________<=
/o:p>
 
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces j=
ointes. 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 confide=
ntial or privileged information that may be protected by law;
they should not be distributed, used or copied witho=
ut authorisation.
If you have received this email in error, please not=
ify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.
--_000_A9CA33BB78081F478946E4F34BF9AAA014D22C9Cxmbrcdx10ciscoc_-- From jouni.nospam@gmail.com Tue Dec 3 01:26:13 2013 Return-Path: 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 7190C1AE0E2 for ; Tue, 3 Dec 2013 01:26:13 -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 pJkFTb1UMtjE for ; Tue, 3 Dec 2013 01:26:11 -0800 (PST) Received: from mail-bk0-x234.google.com (mail-bk0-x234.google.com [IPv6:2a00:1450:4008:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 09FEA1AE0EE for ; Tue, 3 Dec 2013 01:26:10 -0800 (PST) Received: by mail-bk0-f52.google.com with SMTP id u14so5844721bkz.39 for ; Tue, 03 Dec 2013 01:26:08 -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=BjlgZIrYbwTJ07Tgv/qAsFO8OcF4sSeYPb8ESlzI5Ok=; b=JwrlJpRp4pcrDgDYc/H1CuiHKhzVSEQJ4A1fLkYeGhVuAoQiEgzf+qlwJ25cqZ4BSB aNxQtvtkZbviLygaYmR5dzl29Mn1SpuMvSBhMzfEELTVS8pwIdsb1V533zgGg+eyEJHV lMGrd46ZilU6H1Tl3H+7/XulOcnCmI/yjqXFhS14B5sMsGv1DkohVnww10Ed3zeww7lu pva1F4cpTBV9aNPFfRMMnuA93mZVaWV7XW2U+XT/dS9lH7Cra2eX5Lg8GUnZpxoFCfm8 oZA9jfOnAyuvWj1Vq3vSi1dpebopAfmCln5DNPoFAcrcaEx9y0l3iqNKZ0d8oPhpbZQ4 zuSQ== X-Received: by 10.205.68.69 with SMTP id xx5mr429283bkb.143.1386062767941; Tue, 03 Dec 2013 01:26:07 -0800 (PST) Received: from ?IPv6:2001:6e8:480:60:8140:b30:4238:2452? ([2001:6e8:480:60:8140:b30:4238:2452]) by mx.google.com with ESMTPSA id t2sm77734181bkh.3.2013.12.03.01.26.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Dec 2013 01:26:07 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <087A34937E64E74E848732CFF8354B920972BE0C@ESESSMB101.ericsson.se> Date: Tue, 3 Dec 2013 11:26:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <14D4A644-96B1-4B0F-892E-B969922C94D3@gmail.com> References: <087A34937E64E74E848732CFF8354B920972BE0C@ESESSMB101.ericsson.se> To: Maria Cruz Bartolome X-Mailer: Apple Mail (2.1510) Cc: "dime@ietf.org" Subject: Re: [Dime] OLR applicable for any/all applications X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 09:26:13 -0000 Hmm.. wasn't there just recently rather strong opposition=20 to include anything beyond "implicit" information into the OLR? - Jouni On Dec 3, 2013, at 10:42 AM, Maria Cruz Bartolome = wrote: > =20 > Dear all, > =20 > There may be a need by a reporting node to request traffic reduction = for all traffic, application independent, e.g. if an operator=92s = network becomes severely overloaded, it may be of interest to signal = directly general overload to the client. =20 >=20 > In this case, since reacting node obtains affected application from = the application message, we may need to extend OLR. > =20 > At least we got following options: > =20 > =20 > A) Define a new optional AVP that could be included into OLR, like = e.g.: > OC-OLR ::=3D < AVP Header: TBD2 > > < TimeStamp > > [ Reduction-Percentage ] > [ ValidityDuration ] > [ ReportType ] > [All applications] > * [ AVP ] > =20 > =20 > B) Extend ReportTypes like e.g.: > =20 > 3 Destination-Host All Applications report. Similar to = Destination-Host report but it would apply to any application regardless = the application message this report is received within. > =20 > 4 Realm (aggregated) All Applications report. Similar to Realm = report but it would apply to any application regardless the application = message this report is received within. > =20 > =20 > =20 > I tend to prefer option A, but let me know your opinions and = preferences. > Best regards > /MCruz > =20 > =20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From maria.cruz.bartolome@ericsson.com Tue Dec 3 01:34:24 2013 Return-Path: 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 057C41AE0E6 for ; Tue, 3 Dec 2013 01:34:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 UiKbczA2gWyU for ; Tue, 3 Dec 2013 01:34:22 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9967E1AE0E5 for ; Tue, 3 Dec 2013 01:34:21 -0800 (PST) X-AuditID: c1b4fb2d-b7f1c8e000005ceb-11-529da59abbbd Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 4E.91.23787.A95AD925; Tue, 3 Dec 2013 10:34:18 +0100 (CET) Received: from ESESSMB101.ericsson.se ([169.254.1.118]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.02.0347.000; Tue, 3 Dec 2013 10:34:18 +0100 From: Maria Cruz Bartolome To: "dime@ietf.org" Thread-Topic: [Dime] OLR applicable for any/all applications Thread-Index: Ac7wA2nX03YOMS5NT1qqOpqV4/v8if//+8sA///tSKA= Date: Tue, 3 Dec 2013 09:34:16 +0000 Message-ID: <087A34937E64E74E848732CFF8354B920972BE76@ESESSMB101.ericsson.se> References: <087A34937E64E74E848732CFF8354B920972BE0C@ESESSMB101.ericsson.se> <14D4A644-96B1-4B0F-892E-B969922C94D3@gmail.com> In-Reply-To: <14D4A644-96B1-4B0F-892E-B969922C94D3@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKLMWRmVeSWpSXmKPExsUyM+Jvre6spXODDE5PULWY27uCzYHRY8mS n0wBjFFcNimpOZllqUX6dglcGXt+32UvWC9QcelhcAPjbp4uRk4OCQETiVWrFrBA2GISF+6t Z+ti5OIQEjjEKLGzsYENJCEksJhRYsr7UBCbTcBO4tLpF0xdjBwcIgLKEqd/OYCEhQWsJT5d ugRWLiJgI7Hy3xJmCNtKorvzPZjNIqAi8fbtNlYQm1fAV+LqjeWMELsaGCW+PF/ABJLgFLCV uHvxMpjNCHTQ91NrwGxmAXGJW0/mM0EcKiCxZM95ZghbVOLl43+sELaiRPvTBkaIeh2JBbs/ sUHY2hLLFr5mhlgsKHFy5hOWCYyis5CMnYWkZRaSlllIWhYwsqxiZM9NzMxJLzfcxAgM+oNb fuvuYDx1TuQQozQHi5I474e3zkFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGO3ez+mLS+JR vLWL8dD2lLcrHljMvC59dlfU5onKi1QDU/KN2E8cX3j5yepnNvF6+3Mmdsnlaakm9VzduKXj e+Sji2I9vAIzzt6ot3Lcsv1279Rz7n7CyjX3bq499o71gNJL5dnb6mfUCT9XML+8WOQ+15YZ /1V1pp6e8CL/lkjkbo+30XdnKTcqsRRnJBpqMRcVJwIAvsWv7UgCAAA= Subject: Re: [Dime] OLR applicable for any/all applications X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 09:34:24 -0000 Not exactly. It was opposition to duplicate information. Cheers /MCruz -----Original Message----- From: Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20 Sent: martes, 03 de diciembre de 2013 10:26 To: Maria Cruz Bartolome Cc: dime@ietf.org Subject: Re: [Dime] OLR applicable for any/all applications Hmm.. wasn't there just recently rather strong opposition to include anythi= ng beyond "implicit" information into the OLR? - Jouni On Dec 3, 2013, at 10:42 AM, Maria Cruz Bartolome wrote: > =20 > Dear all, > =20 > There may be a need by a reporting node to request traffic reduction for = all traffic, application independent, e.g. if an operator's network becomes= severely overloaded, it may be of interest to signal directly general over= load to the client. =20 >=20 > In this case, since reacting node obtains affected application from the a= pplication message, we may need to extend OLR. > =20 > At least we got following options: > =20 > =20 > A) Define a new optional AVP that could be included into OLR, like e.= g.: > OC-OLR ::=3D < AVP Header: TBD2 > > < TimeStamp > > [ Reduction-Percentage ] > [ ValidityDuration ] > [ ReportType ] > [All applications] > * [ AVP ] > =20 > =20 > B) Extend ReportTypes like e.g.: > =20 > 3 Destination-Host All Applications report. Similar to Destination-H= ost report but it would apply to any application regardless the application= message this report is received within. > =20 > 4 Realm (aggregated) All Applications report. Similar to Realm repor= t but it would apply to any application regardless the application message = this report is received within. > =20 > =20 > =20 > I tend to prefer option A, but let me know your opinions and preferences. > Best regards > /MCruz > =20 > =20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From nsalot@cisco.com Tue Dec 3 01:41:31 2013 Return-Path: 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 B4E351AE099 for ; Tue, 3 Dec 2013 01:41:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.501 X-Spam-Level: X-Spam-Status: No, score=-9.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.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 PRjC345svm5u for ; Tue, 3 Dec 2013 01:41:29 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id 1E0131AE067 for ; Tue, 3 Dec 2013 01:41:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13804; q=dns/txt; s=iport; t=1386063686; x=1387273286; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=6BqlpvCK/OcnJSBbRaMUXrSgBJzNRrAkvD8iO9petDU=; b=E8sQz02UVQr/DKh8bNwwScPKn6zDOpa6mtE90dMWY7O/97OAhYRisHTi wt3EjhPU9sXnWLBgBEI5K1riX4RKP29T61+ajVmlmavwMXab9VV6adjo1 juI7DWwET4A7gSSzD4L6YUhvAsDJYiRiqc8k/OGtBqEVHUnOVbet76aGL E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAEemnVKtJV2Z/2dsb2JhbABagkNEOFO4Z4EZFnSCJQEBAQQtXAIBCBEEAQELHQcyFAkIAQEEARIIh3nBHBeOTTcBBoMagRMDqieDKYIq X-IronPort-AV: E=Sophos;i="4.93,816,1378857600"; d="scan'208,217";a="3899150" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-7.cisco.com with ESMTP; 03 Dec 2013 09:41:26 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rB39fQgZ016395 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Dec 2013 09:41:26 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.250]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Tue, 3 Dec 2013 03:41:25 -0600 From: "Nirav Salot (nsalot)" To: Maria Cruz Bartolome , "dime@ietf.org" Thread-Topic: OLR applicable for any/all applications Thread-Index: Ac7wA2nX03YOMS5NT1qqOpqV4/v8iQAB0nIQ Date: Tue, 3 Dec 2013 09:41:25 +0000 Message-ID: References: <087A34937E64E74E848732CFF8354B920972BE0C@ESESSMB101.ericsson.se> In-Reply-To: <087A34937E64E74E848732CFF8354B920972BE0C@ESESSMB101.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.233.77] Content-Type: multipart/alternative; boundary="_000_A9CA33BB78081F478946E4F34BF9AAA014D22CDCxmbrcdx10ciscoc_" MIME-Version: 1.0 Subject: Re: [Dime] OLR applicable for any/all applications X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 09:41:31 -0000 --_000_A9CA33BB78081F478946E4F34BF9AAA014D22CDCxmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Maria-Cruz, The existing OC-OLR definition (without "All Application" AVP) already addr= esses your use case. E.g. reporting node includes same value of "Reduction= -Percentage" in all the application messages sent by it. So we don't need "= All Application" AVP additionally. Besides, reporting "Reduction-Percentage" of a different application violat= es the basic principle of the piggybacking. Finally, in 3GPP (as far as I remember) we do not have any use case of two = nodes interfacing with each other over more than one application. i.e. we h= ave only one application between any pair of nodes and if that is so then I= fail to see the practicality of the use case you have mentioned below. Regards, Nirav. From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Maria Cruz Bartolome Sent: Tuesday, December 03, 2013 2:13 PM To: dime@ietf.org Subject: [Dime] OLR applicable for any/all applications Dear all, There may be a need by a reporting node to request traffic reduction for al= l traffic, application independent, e.g. if an operator's network becomes s= everely overloaded, it may be of interest to signal directly general overlo= ad to the client. In this case, since reacting node obtains affected application from the app= lication message, we may need to extend OLR. At least we got following options: A) Define a new optional AVP that could be included into OLR, like e.g.= : OC-OLR ::=3D < AVP Header: TBD2 > < TimeStamp > [ Reduction-Percentage ] [ ValidityDuration ] [ ReportType ] [All applications] * [ AVP ] B) Extend ReportTypes like e.g.: 3 Destination-Host All Applications report. Similar to Destination-Hos= t report but it would apply to any application regardless the application m= essage this report is received within. 4 Realm (aggregated) All Applications report. Similar to Realm report = but it would apply to any application regardless the application message th= is report is received within. I tend to prefer option A, but let me know your opinions and preferences. Best regards /MCruz --_000_A9CA33BB78081F478946E4F34BF9AAA014D22CDCxmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Maria-Cruz,=

 

The existing OC-OLR de= finition (without "All Application" AVP) already addresses your u= se case. E.g. reporting  node includes same value of "Reduction-P= ercentage" in all the application messages sent by it. So we don’t need "All Application" AVP additionally.

Besides, reporting &qu= ot;Reduction-Percentage" of a different application violates the basic= principle of the piggybacking.

Finally, in 3GPP (as f= ar as I remember) we do not have any use case of two nodes interfacing with= each other over more than one application. i.e. we have only one applicati= on between any pair of nodes and if that is so then I fail to see the practicality of the use case you have me= ntioned below.

 

Regards,

Nirav.

 

From: DiME [ma= ilto:dime-bounces@ietf.org] On Behalf Of Maria Cruz Bartolome
Sent: Tuesday, December 03, 2013 2:13 PM
To: dime@ietf.org
Subject: [Dime] OLR applicable for any/all applications

 

 

Dear all,

 

There may be a need b= y a reporting node to request traffic reduction for all traffic, applicatio= n independent, e.g. if an operator’s network becomes severely overloa= ded, it may be of interest to signal directly general overload to the client. 

In this case, since reacting node obtains affected a= pplication from the application message, we may need to extend OLR.

 

At least we got following options:

 

 

A)     Define a new optional AVP that could be included in= to OLR, like e.g.:

   OC-OLR ::=3D < AVP Header: TBD2 >
           =
;   < TimeStamp >
           =
;   [ Reduction-Percentage ]
           =
;   [ ValidityDuration ]
           =
;   [ ReportType ]
           =
;   [All application=
s]

           =
; * [ AVP ]


 


 



B)     
Extend  ReportTypes like e.g.:


 


  =
; 3  Destination-Host
All Applications
report.  Similar to Destination-Host report but it would =
apply to any application regardless the application message this report is =
received within.


 =



  =
; 4  Realm (aggregated)
All Applications report.  Similar to Realm rep=
ort but it would apply to any application regardless the application
 message this report is received within.


 


 


 


I tend to prefer option A, but let me know your opin=
ions and preferences.


Best regards


/MCruz


 


 
--_000_A9CA33BB78081F478946E4F34BF9AAA014D22CDCxmbrcdx10ciscoc_-- From maria.cruz.bartolome@ericsson.com Tue Dec 3 01:43:11 2013 Return-Path: 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 A9D9B1AE099 for ; Tue, 3 Dec 2013 01:43:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 3AdwFOYXQPHS for ; Tue, 3 Dec 2013 01:43:06 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 02C081AE067 for ; Tue, 3 Dec 2013 01:43:04 -0800 (PST) X-AuditID: c1b4fb38-b7f2c8e000006d25-2f-529da7a5a5ca Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 0D.7B.27941.5A7AD925; Tue, 3 Dec 2013 10:43:01 +0100 (CET) Received: from ESESSMB101.ericsson.se ([169.254.1.118]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.02.0347.000; Tue, 3 Dec 2013 10:43:01 +0100 From: Maria Cruz Bartolome To: "dime@ietf.org" Thread-Topic: DOIC: Multiple instance of OC-OLR AVP (of the same type) within a response message Thread-Index: Ac7wCaL7cwdoL1xIRoywlc8N1o+kQQAAb2rA Date: Tue, 3 Dec 2013 09:43:00 +0000 Message-ID: <087A34937E64E74E848732CFF8354B920972BE90@ESESSMB101.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: multipart/alternative; boundary="_000_087A34937E64E74E848732CFF8354B920972BE90ESESSMB101erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrILMWRmVeSWpSXmKPExsUyM+Jvre7S5XODDPp3mlnM7V3B5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujL3Pd7MW3L/KVDFp6mXWBsb5y5m6GDk5JARMJHp+/WWHsMUk Ltxbz9bFyMUhJHCEUeLJpj5mCGcxkHNzAjNIFZuAncSl0y+Aujk4RASUJU7/cgAJCwskSiy5 cI4NxBYRSJJ4N/8TC4RtJDFl6wGwOIuAikTT532MIDavgK9EW1cPWI2QgI/E1l/HwOKcQPFT dyaB1TMCHfT91BqwQ5kFxCVuPZkPdbSAxJI955khbFGJl4//sULYihLtTxsYIerzJTZ0P2WC 2CUocXLmE5YJjCKzkIyahaRsFpIyiLiexI2pU9ggbG2JZQtfM0PYuhIz/h1iQRZfwMi+ipGj OLU4KTfdyGATIzBaDm75bbGD8fJfm0OM0hwsSuK8H986BwkJpCeWpGanphakFsUXleakFh9i ZOLglGpgnJZZltT2NipgcnTblP/VV9yfXhTjiGSdkBh14GPEj9qVQg8ZZwWVnHF551/QYLfh RVyCRn/hRUEjO6nLfcyij1xm+bz3ethZFN2vxNCkkcSxUJBvC+O3c2f16maeL5/RUjFtX4o5 f+Jilg2+X3a1KTBP/aDtoymYviftYp5ywZkJCaW/012VWIozEg21mIuKEwE1gbr/ZAIAAA== Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same type) within a response message X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 09:43:11 -0000 --_000_087A34937E64E74E848732CFF8354B920972BE90ESESSMB101erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Nirav, Yes, I agree the restriction to do not allow multiple instances with the sa= me Report-Type does not seem necessary. In fact, if we want to narrow OLR applicability, in case a new ReportType i= s defined, it means that it should apply to host OR/AND realm plus somethin= g else. This information should be either provided by the ReportType defini= tion and/or by adding extra AVPs into corresponding OLR, what makes things = more complex. I agree we could benefit from the flexibility to allow more t= han one instance of same ReportType. Best regards /MCruz From: Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Sent: martes, 03 de diciembre de 2013 10:26 To: Maria Cruz Bartolome; dime@ietf.org Subject: RE: DOIC: Multiple instance of OC-OLR AVP (of the same type) withi= n a response message Maria-Cruz, > we may think that we need two different OLRs with ReportType=3Dhost, and = one of them includes the extra info (AVPs) required for that application Yes. The above is my concern. I tried giving APN as one example AVP which w= e may want to include in OC-OLR. Let me give another possible example. As of now, the OC-OLR can indicate application + host/realm level "required= -reduction-percentage". However, for the given application (e.g. Gx) we may want to define a narrow= er scope with "session-type =3D {M2M, Others}" AVP. So basically, the Gx no= des can advertise different "required-reduction-percentage" for M2M session= s v/s other type of sessions for the same application Gx and for the same d= estination-host. So in general, if any application needs to define a different (i.e. narrowe= r) scope than application + host/realm, it can do so by adding a new AVP in= OC-OLR. And then we might have two instances of OC-OLR from the same host. We could achieve the above by defining new Report-Type for each new AVP add= ed by each application. But would this scale or is this a reasonable approa= ch? I am not sure and you have already identified one of my concerns below > if we extend ReportType, does it need to be done by IETF, or could it be = done per application by 3GPP? In summary, in my view, we need to define the handling of multiple instance= s with the same Report-Type as part of the DOIC draft. Or we say that multi= ple instances with the same Report-Type is not allowed - this seems unneces= sary restriction to me. Otherwise, if later, we realize the need to do so then we may not be able t= o do so since the handling is not defined in the base solution. Regards, Nirav. From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Maria Cruz Bartolome Sent: Tuesday, December 03, 2013 1:57 PM To: dime@ietf.org Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same type= ) within a response message Nirav, I think I understand your concern. It may occur that we need that a reactin= g node should apply two different OLR when sending a request towards one sp= ecific host. Then, we may think that we need two different OLRs with ReportType=3Dhost, = and one of them includes the extra info (AVPs) required for that applicatio= n, I think this is your interpretation, but... we can as well consider a ne= w ReportType=3DapplicX_ReportY, that may apply e.g. for any request send to= this application, or just for this application+host, and then Host could b= e another AVP to be included in the OLR, or we could define expected behavi= our when defining this new ReportType. Would this cover your concerns? If not, could you try to provide an example= that requires two OLR with ReportType=3Dhost? A part from that, a question for all, if we extend ReportType, does it need= to be done by IETF, or could it be done per application by 3GPP? Thanks /MCruz From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Nirav Salot (nsalot) Sent: jueves, 28 de noviembre de 2013 17:11 To: lionel.morand@orange.com Cc: dime@ietf.org Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same type= ) within a response message Hi Lionel, I am not sure if defining new ReportType for every new AVP 3GPP would add f= or a specific application would be a good solution. I thought ReportType would indicate if the corresponding OC-OLR should be u= sed while sending the traffic towards the host or towards the realm. So from that point of view, all the OC-OLR generated by the server should h= ave ReportType=3Dhost. i.e. when the reacting node sends the traffic toward= s that host, it should make use of the corresponding OC-OLR. Now, this OC-O= LR may contain the AVPs defined by DOIC draft as well as 3GPP application s= pecific AVPs. In general, I was just thinking that it may be good idea to define some of = the principles such as - More than one instances of OC-OLR with ReportType=3Dhost may be = present in the answer message if the OC-OLR definition is extended by the a= pplication using the same. In that case, it is the responsibility of the ap= plication to define the valid combination of OC-OLR instances in a given me= ssage - If the reporting node includes more than one instance of OC-OLR,= the reporting node shall always include all the active instances of OC-OLR= in a response message. - When the reacting node receives one or more instances of OC-OLR = with the given ReportType and with new timestamp value, it should overwrite= all the existing OC-OLR of the same ReportType. Regards, Nirav. From: lionel.morand@orange.com [mailto:lio= nel.morand@orange.com] Sent: Thursday, November 28, 2013 7:39 PM To: Nirav Salot (nsalot) Cc: dime@ietf.org Subject: RE: DOIC: Multiple instance of OC-OLR AVP (of the same type) withi= n a response message Hi Nirav, The Report Type should be able to differentiate such cases. In your example= , I would define a specific Report type. But difficult to appraise all the future use cases. But for me, the main us= e of the report type is to differentiate OC-OLR received in the same messag= e. And it is the reasons of my recommendation. Actually, the exact wording wil= l be a "SHOULD" saying that it is recommended but you may have serious reas= ons to do otherwise. Lionel De : Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Envoy=E9 : jeudi 28 novembre 2013 13:00 =C0 : MORAND Lionel IMT/OLN Cc : dime@ietf.org Objet : RE: DOIC: Multiple instance of OC-OLR AVP (of the same type) within= a response message Lionel, 3gpp may define an optional avp which can be included by the reporting node= if it wishes to do so. E.g. APN can be additionally included by the report= ing node to indicate APN specific overload within the given application. In that case, the reporting node may also want to indicate application leve= l overload without including the APN (e.g. this overload report is applicab= le to all other APNs). And hence there is a possibility of including multiple instances of the ove= rload report. I am not suggesting that 3gpp will define APN (or any other avp) within ove= rload report. But later, if 3gpp need to define the same, then correspondin= g handling needs to be defined within IETF now. Regards, Nirav. On Nov 28, 2013 3:56 PM, "lionel.morand@orange.com" > wrote= : Hi Nirav, Not sure to understand the proposal or question. The OLR is significant per application (piggybacking principle). So if the = 3GPP decides to add specific AVPs in the OLR (that will be possible), what = would be the need to add the OLR without the specific 3GPP AVPs as the OLR = will be anyway handle by 3GPP aware entities? Lionel De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot (nsalot) Envoy=E9 : jeudi 28 novembre 2013 10:33 =C0 : dime@ietf.org Objet : [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same type) wit= hin a response message Hi, As I understand IETF will define the base overload control solution as part= of DOIC. Then 3GPP would adopt the defined solution for each of its applic= ation. When that happens, 3GPP might want to add 3GPP specific AVP within OC-OLR A= VP. Based on the current definition of the OC-OLR AVP this should be allowe= d since it contains "* [AVP]" in its definition. e.g. for a given application 3GPP decides to add information into OC-OLR wh= ich changes the scope of the OC-OLR from application level to the provided = information level. Additionally, the reporting may want to advertise the OC-OLR at the applica= tion level scope - i.e. the OC-OLR without any 3GPP specific info. So if the above is allowed, we will have the possibility of the reporting n= ode wanting to include two instances of OC-OLR with the Report-Type=3D"host= ". And then we need to define the handling of multiple instances of OC-OLR in = the DOIC draft. So the questions are, - Is 3GPP (or any other SDO) allowed to extend the definition of O= C-OLR by adding information into it? - If no, can we guarantee that application level scope of OC-OLR (= which is what we have defined currently) is sufficient (and not restricting= ) to all the applications of 3GPP? Regards, Nirav. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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 confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. --_000_087A34937E64E74E848732CFF8354B920972BE90ESESSMB101erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Nirav,

 

Yes, I agree the restr= iction to do not allow multiple instances with the same Report-Type does no= t seem necessary.

 

In fact, if we want to= narrow OLR applicability, in case a new ReportType is defined, it means th= at it should apply to host OR/AND realm plus something else. This informati= on should be either provided by the ReportType definition and/or by adding extra AVPs into corresponding OLR, = what makes things more complex. I agree we could benefit from the flexibili= ty to allow more than one instance of same ReportType.

 

Best regards

/MCruz

 

From: Nirav Sa= lot (nsalot) [mailto:nsalot@cisco.com]
Sent: martes, 03 de diciembre de 2013 10:26
To: Maria Cruz Bartolome; dime@ietf.org
Subject: RE: DOIC: Multiple instance of OC-OLR AVP (of the same type= ) within a response message

 

Maria-Cruz,=

 

> we may think that we need two different OLRs with Repor= tType=3Dhost, and one of them includes the extra info (AVPs) required for t= hat application

Yes. The above is my c= oncern. I tried giving APN as one example AVP which we may want to include = in OC-OLR. Let me give another possible example.

As of now, the OC-OLR = can indicate application + host/realm level "required-reduction-pe= rcentage".

However, for the given= application (e.g. Gx) we may want to define a narrower scope with "se= ssion-type =3D {M2M, Others}" AVP. So basically, the Gx nodes can adve= rtise different "required-reduction-percentage" for M2M sessions v/s other type of sessions for the same application Gx an= d for the same destination-host.

 

So in general, if any = application needs to define a different (i.e. narrower) scope than applicat= ion + host/realm, it can do so by adding a new AVP in OC-OLR.

And then we might have= two instances of OC-OLR from the same host.

 

We could achieve the a= bove by defining new Report-Type for each new AVP added by each application= . But would this scale or is this a reasonable approach?

I am not sure and you = have already identified one of my concerns below

> if we extend ReportType, does it need to be done by IET= F, or could it be done per application by 3GPP?

 

In summary, in my view= , we need to define the handling of multiple instances with the same Report= -Type as part of the DOIC draft. Or we say that multiple instances with the= same Report-Type is not allowed – this seems unnecessary restriction to me.

Otherwise, if later, w= e realize the need to do so then we may not be able to do so since the hand= ling is not defined in the base solution.

 

Regards,

Nirav.

 

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Maria Cruz Bartolome
Sent: Tuesday, December 03, 2013 1:57 PM
To: dime@ietf.org
Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the sa= me type) within a response message

 

Nirav,

 

I think I understand y= our concern. It may occur that we need that a reacting node should apply tw= o different OLR when sending a request towards one specific host.

Then, we may think tha= t we need two different OLRs with ReportType=3Dhost, and one of them includ= es the extra info (AVPs) required for that application, I think this is you= r interpretation, but… we can as well consider a new ReportType=3DapplicX_ReportY, that may apply e.g. for any r= equest send to this application, or just for this application+host, and= then Host could be another AVP to be included in the OLR, or we could defi= ne expected behaviour when defining this new ReportType.

 

Would this cover your = concerns? If not, could you try to provide an example that requires two OLR= with ReportType=3Dhost?

 

A part from that, a qu= estion for all, if we extend ReportType, does it need to be done by IETF, o= r could it be done per application by 3GPP?

 

Thanks

/MCruz

 

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Nirav Salot (nsalot)
Sent: jueves, 28 de noviembre de 2013 17:11
To: lionel.morand@orange= .com
Cc: dime@ietf.org
Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the sa= me type) within a response message

 

Hi Lionel,<= /span>

 

I am not sure if defin= ing new ReportType for every new AVP 3GPP would add for a specific applicat= ion would be a good solution.

I thought ReportType w= ould indicate if the corresponding OC-OLR should be used while sending the = traffic towards the host or towards the realm.

So from that point of = view, all the OC-OLR generated by the server should have ReportType=3Dhost.= i.e. when the reacting node sends the traffic towards that host, it should= make use of the corresponding OC-OLR. Now, this OC-OLR may contain the AVPs defined by DOIC draft as well as 3GP= P application specific AVPs.

 

In general, I was just= thinking that it may be good idea to define some of the principles such as=

-&n= bsp;         More than one = instances of OC-OLR with ReportType=3Dhost may be present in the answer mes= sage if the OC-OLR definition is extended by the application using the same= . In that case, it is the responsibility of the application to define the valid combination of OC-OLR instances in = a given message

-&n= bsp;         If the reporti= ng node includes more than one instance of OC-OLR, the reporting node shall= always include all the active instances of OC-OLR in a response message.

-&n= bsp;         When the react= ing node receives one or more instances of OC-OLR with the given ReportType= and with new timestamp value, it should overwrite all the existing OC-OLR = of the same ReportType.

 

Regards,

Nirav.

 

From: lionel.morand@orange.com [<= a href=3D"mailto:lionel.morand@orange.com">mailto:lionel.morand@orange.com<= /a>]
Sent: Thursday, November 28, 2013 7:39 PM
To: Nirav Salot (nsalot)
Cc: dime@ietf.org
Subject: RE: DOIC: Multiple instance of OC-OLR AVP (of the same type= ) within a response message

 

Hi Nirav,<= o:p>

 = ;

The Report Type should= be able to differentiate such cases. In your example, I would define a spe= cific Report type.

But difficult to appra= ise all the future use cases. But for me, the main use of the report type i= s to differentiate OC-OLR received in the same message.

And it is the reasons = of my recommendation. Actually, the exact wording will be a "SHOULD&qu= ot; saying that it is recommended but you may have serious reasons to do ot= herwise.

 

Lionel

 

De : Nirav Salot (nsalot) [mailto:nsalot@cisco.com]
Envoy=E9 : jeudi 28 novembre 2013 13:00
=C0 : MORAND Lionel IMT/OLN
Cc : dime@ietf.org
Objet : RE: DOIC: Multiple instance of OC-OLR AVP (of the same = type) within a response message

 

Lionel,

3gpp may define an optional avp which can be included = by the reporting node if it wishes to do so. E.g. APN can be additionally i= ncluded by the reporting node to indicate APN specific overload within the = given application.
In that case, the reporting node may also want to indicate application leve= l overload without including the APN (e.g. this overload report is applicab= le to all other APNs).

And hence there is a possibility of including multiple= instances of the overload report.

I am not suggesting that 3gpp will define APN (or any = other avp) within overload report. But later, if 3gpp need to define the sa= me, then corresponding handling needs to be defined within IETF now.

Regards,
Nirav.

On Nov 28, 2013 3:56 PM,= "lionel.morand@orange.com= " <lionel.morand@or= ange.com> wrote:

Hi Nirav,<= /span>

 

Not sure to understand= the proposal or question.

The OLR is significant= per application (piggybacking principle). So if the 3GPP decides to add sp= ecific AVPs in the OLR (that will be possible), what would be the need to a= dd the OLR without the specific 3GPP AVPs as the OLR will be anyway handle by 3GPP aware entities?

 

Lionel

 

De : DiME [mailto:d= ime-bounces@ietf.org] De la part de Nirav Salot (nsalot)
Envoy=E9 : jeudi 28 novembre 2013 10:33
=C0 : dime@ietf.org
Objet : [Dime] DOIC: Multiple instance of OC-OLR AVP (of the sa= me type) within a response message

 

Hi,

 

As I understand IETF will define the base overload c= ontrol solution as part of DOIC. Then 3GPP would adopt the defined solution= for each of its application.

When that happens, 3GPP might want to add 3GPP speci= fic AVP within OC-OLR AVP. Based on the current definition of the OC-OLR AV= P this should be allowed since it contains "* [AVP]" in its defin= ition.

e.g. for a given application 3GPP decides to add inf= ormation into OC-OLR which changes the scope of the OC-OLR from application= level to the provided information level.

Additionally, the reporting may want to advertise th= e OC-OLR at the application level scope – i.e. the OC-OLR without any= 3GPP specific info.

 

So if the above is allowed, we will have the possibi= lity of the reporting node wanting to include two instances of OC-OLR with = the Report-Type=3D"host".

And then we need to define the handling of multiple = instances of OC-OLR in the DOIC draft.<= /p>

 

So the questions are,

-          Is 3GPP (or any other SDO) allowed to extend the definition of OC-OL= R by adding information into it?

-          If no, can we guarantee that application level scope of OC-OLR (whic= h is what we have defined currently) is sufficient (and not restricting) to= all the applications of 3GPP?

 

Regards,

Nirav.

 

____________________________________________________=
_____________________________________________________________________<=
/o:p>
 
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces j=
ointes. 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 confide=
ntial or privileged information that may be protected by law;
they should not be distributed, used or copied witho=
ut authorisation.
If you have received this email in error, please not=
ify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.


____________________________________________________=
_____________________________________________________________________<=
/o:p>
 
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces j=
ointes. 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 confide=
ntial or privileged information that may be protected by law;
they should not be distributed, used or copied witho=
ut authorisation.
If you have received this email in error, please not=
ify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.
--_000_087A34937E64E74E848732CFF8354B920972BE90ESESSMB101erics_-- From ulrich.wiehe@nsn.com Tue Dec 3 01:48:30 2013 Return-Path: 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 01B3F1AE067 for ; Tue, 3 Dec 2013 01:48:30 -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 BSuM9jitKVnZ for ; Tue, 3 Dec 2013 01:48:24 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id A44CD1A1F71 for ; Tue, 3 Dec 2013 01:48:23 -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 rB39mFnx018967 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 3 Dec 2013 10:48:15 +0100 Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rB39m61I008032 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Dec 2013 10:48:15 +0100 Received: from DEMUHTC011.nsn-intra.net (10.159.42.42) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 3 Dec 2013 10:48:10 +0100 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.152]) by DEMUHTC011.nsn-intra.net ([10.159.42.42]) with mapi id 14.03.0123.003; Tue, 3 Dec 2013 10:48:10 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: "ext Nirav Salot (nsalot)" , Maria Cruz Bartolome , "dime@ietf.org" Thread-Topic: DOIC: Multiple instance of OC-OLR AVP (of the same type) within a response message Thread-Index: Ac7wCaL7cwdoL1xIRoywlc8N1o+kQQAAkVNQ Date: Tue, 3 Dec 2013 09:48:10 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519C296@DEMUMBX014.nsn-intra.net> References: In-Reply-To: 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: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D90006681519C296DEMUMBX014nsnin_" 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: 45872 X-purgate-ID: 151667::1386064096-00006154-A6DF2E6F/0-0/0-0 Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same type) within a response message X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 09:48:30 -0000 --_000_5BCBA1FC2B7F0B4C9D935572D90006681519C296DEMUMBX014nsnin_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Nirav, I still do not see the need for more than one OLR in an answer. More than one OLR means more complexity. Let's try to avoid that. The server gets a request that either is or is not in the narrower scope. I= f it is not, why shoud the server return an OLR for the narrower scope? It = can do so when it gets a request within the narrower scope (which possibly = never happens). Ulrich From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Nirav Salot (nsa= lot) Sent: Tuesday, December 03, 2013 10:26 AM To: Maria Cruz Bartolome; dime@ietf.org Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same type= ) within a response message Maria-Cruz, > we may think that we need two different OLRs with ReportType=3Dhost, and = one of them includes the extra info (AVPs) required for that application Yes. The above is my concern. I tried giving APN as one example AVP which w= e may want to include in OC-OLR. Let me give another possible example. As of now, the OC-OLR can indicate application + host/realm level "required= -reduction-percentage". However, for the given application (e.g. Gx) we may want to define a narrow= er scope with "session-type =3D {M2M, Others}" AVP. So basically, the Gx no= des can advertise different "required-reduction-percentage" for M2M session= s v/s other type of sessions for the same application Gx and for the same d= estination-host. So in general, if any application needs to define a different (i.e. narrowe= r) scope than application + host/realm, it can do so by adding a new AVP in= OC-OLR. And then we might have two instances of OC-OLR from the same host. We could achieve the above by defining new Report-Type for each new AVP add= ed by each application. But would this scale or is this a reasonable approa= ch? I am not sure and you have already identified one of my concerns below > if we extend ReportType, does it need to be done by IETF, or could it be = done per application by 3GPP? In summary, in my view, we need to define the handling of multiple instance= s with the same Report-Type as part of the DOIC draft. Or we say that multi= ple instances with the same Report-Type is not allowed - this seems unneces= sary restriction to me. Otherwise, if later, we realize the need to do so then we may not be able t= o do so since the handling is not defined in the base solution. Regards, Nirav. From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Maria Cruz Bartolome Sent: Tuesday, December 03, 2013 1:57 PM To: dime@ietf.org Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same type= ) within a response message Nirav, I think I understand your concern. It may occur that we need that a reactin= g node should apply two different OLR when sending a request towards one sp= ecific host. Then, we may think that we need two different OLRs with ReportType=3Dhost, = and one of them includes the extra info (AVPs) required for that applicatio= n, I think this is your interpretation, but... we can as well consider a ne= w ReportType=3DapplicX_ReportY, that may apply e.g. for any request send to= this application, or just for this application+host, and then Host could b= e another AVP to be included in the OLR, or we could define expected behavi= our when defining this new ReportType. Would this cover your concerns? If not, could you try to provide an example= that requires two OLR with ReportType=3Dhost? A part from that, a question for all, if we extend ReportType, does it need= to be done by IETF, or could it be done per application by 3GPP? Thanks /MCruz From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Nirav Salot (nsalot) Sent: jueves, 28 de noviembre de 2013 17:11 To: lionel.morand@orange.com Cc: dime@ietf.org Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same type= ) within a response message Hi Lionel, I am not sure if defining new ReportType for every new AVP 3GPP would add f= or a specific application would be a good solution. I thought ReportType would indicate if the corresponding OC-OLR should be u= sed while sending the traffic towards the host or towards the realm. So from that point of view, all the OC-OLR generated by the server should h= ave ReportType=3Dhost. i.e. when the reacting node sends the traffic toward= s that host, it should make use of the corresponding OC-OLR. Now, this OC-O= LR may contain the AVPs defined by DOIC draft as well as 3GPP application s= pecific AVPs. In general, I was just thinking that it may be good idea to define some of = the principles such as - More than one instances of OC-OLR with ReportType=3Dhost may be = present in the answer message if the OC-OLR definition is extended by the a= pplication using the same. In that case, it is the responsibility of the ap= plication to define the valid combination of OC-OLR instances in a given me= ssage - If the reporting node includes more than one instance of OC-OLR,= the reporting node shall always include all the active instances of OC-OLR= in a response message. - When the reacting node receives one or more instances of OC-OLR = with the given ReportType and with new timestamp value, it should overwrite= all the existing OC-OLR of the same ReportType. Regards, Nirav. From: lionel.morand@orange.com [mailto:lio= nel.morand@orange.com] Sent: Thursday, November 28, 2013 7:39 PM To: Nirav Salot (nsalot) Cc: dime@ietf.org Subject: RE: DOIC: Multiple instance of OC-OLR AVP (of the same type) withi= n a response message Hi Nirav, The Report Type should be able to differentiate such cases. In your example= , I would define a specific Report type. But difficult to appraise all the future use cases. But for me, the main us= e of the report type is to differentiate OC-OLR received in the same messag= e. And it is the reasons of my recommendation. Actually, the exact wording wil= l be a "SHOULD" saying that it is recommended but you may have serious reas= ons to do otherwise. Lionel De : Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Envoy=E9 : jeudi 28 novembre 2013 13:00 =C0 : MORAND Lionel IMT/OLN Cc : dime@ietf.org Objet : RE: DOIC: Multiple instance of OC-OLR AVP (of the same type) within= a response message Lionel, 3gpp may define an optional avp which can be included by the reporting node= if it wishes to do so. E.g. APN can be additionally included by the report= ing node to indicate APN specific overload within the given application. In that case, the reporting node may also want to indicate application leve= l overload without including the APN (e.g. this overload report is applicab= le to all other APNs). And hence there is a possibility of including multiple instances of the ove= rload report. I am not suggesting that 3gpp will define APN (or any other avp) within ove= rload report. But later, if 3gpp need to define the same, then correspondin= g handling needs to be defined within IETF now. Regards, Nirav. On Nov 28, 2013 3:56 PM, "lionel.morand@orange.com" > wrote= : Hi Nirav, Not sure to understand the proposal or question. The OLR is significant per application (piggybacking principle). So if the = 3GPP decides to add specific AVPs in the OLR (that will be possible), what = would be the need to add the OLR without the specific 3GPP AVPs as the OLR = will be anyway handle by 3GPP aware entities? Lionel De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot (nsalot) Envoy=E9 : jeudi 28 novembre 2013 10:33 =C0 : dime@ietf.org Objet : [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same type) wit= hin a response message Hi, As I understand IETF will define the base overload control solution as part= of DOIC. Then 3GPP would adopt the defined solution for each of its applic= ation. When that happens, 3GPP might want to add 3GPP specific AVP within OC-OLR A= VP. Based on the current definition of the OC-OLR AVP this should be allowe= d since it contains "* [AVP]" in its definition. e.g. for a given application 3GPP decides to add information into OC-OLR wh= ich changes the scope of the OC-OLR from application level to the provided = information level. Additionally, the reporting may want to advertise the OC-OLR at the applica= tion level scope - i.e. the OC-OLR without any 3GPP specific info. So if the above is allowed, we will have the possibility of the reporting n= ode wanting to include two instances of OC-OLR with the Report-Type=3D"host= ". And then we need to define the handling of multiple instances of OC-OLR in = the DOIC draft. So the questions are, - Is 3GPP (or any other SDO) allowed to extend the definition of O= C-OLR by adding information into it? - If no, can we guarantee that application level scope of OC-OLR (= which is what we have defined currently) is sufficient (and not restricting= ) to all the applications of 3GPP? Regards, Nirav. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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 confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. --_000_5BCBA1FC2B7F0B4C9D935572D90006681519C296DEMUMBX014nsnin_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Nirav,<= o:p>

&n= bsp;

I still= do not see the need for more than one OLR in an answer.<= /p>

&n= bsp;

More th= an one OLR means more complexity. Let’s try to avoid that.=

&n= bsp;

The ser= ver gets a request that either is or is not in the narrower scope. If it is= not, why shoud the server return an OLR for the narrower scope? It can do = so when it gets a request within the narrower scope (which possibly never happens).

&n= bsp;

Ulrich<= o:p>

&n= bsp;

&n= bsp;

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Nirav Salot (nsalot)
Sent: Tuesday, December 03, 2013 10:26 AM
To: Maria Cruz Bartolome; dime@ietf.org
Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the sa= me type) within a response message

 

Maria-C= ruz,

&n= bsp;

> we may think that we need= two different OLRs with ReportType=3Dhost, and one of them includes the ex= tra info (AVPs) required for that application

Yes. Th= e above is my concern. I tried giving APN as one example AVP which we may w= ant to include in OC-OLR. Let me give another possible example.<= /span>

As of n= ow, the OC-OLR can indicate application + host/realm level "requir= ed-reduction-percentage".

However= , for the given application (e.g. Gx) we may want to define a narrower scop= e with "session-type =3D {M2M, Others}" AVP. So basically, the Gx= nodes can advertise different "required-reduction-percentage" for M2M sessions v/s other type of sessions for the same application Gx an= d for the same destination-host.

&n= bsp;

So in g= eneral, if any application needs to define a different (i.e. narrower) scop= e than application + host/realm, it can do so by adding a new AVP in OC= -OLR.

And the= n we might have two instances of OC-OLR from the same host.

&n= bsp;

We coul= d achieve the above by defining new Report-Type for each new AVP added by e= ach application. But would this scale or is this a reasonable approach?

I am no= t sure and you have already identified one of my concerns below<= /span>

> if we extend ReportType, = does it need to be done by IETF, or could it be done per application by 3GP= P?

&n= bsp;

In summ= ary, in my view, we need to define the handling of multiple instances with = the same Report-Type as part of the DOIC draft. Or we say that multiple ins= tances with the same Report-Type is not allowed – this seems unnecessary restriction to me.

Otherwi= se, if later, we realize the need to do so then we may not be able to do so= since the handling is not defined in the base solution.<= /p>

&n= bsp;

Regards= ,

Nirav.<= o:p>

&n= bsp;

From: DiME [mailto= :dime-bounces@ietf.org] On Behalf Of Maria Cruz Bartolome
Sent: Tuesday, December 03, 2013 1:57 PM
To: dime@ietf.org
Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the sa= me type) within a response message

 

Nirav, =

&n= bsp;

I think= I understand your concern. It may occur that we need that a reacting node = should apply two different OLR when sending a request towards one specific = host.

Then, w= e may think that we need two different OLRs with ReportType=3Dhost, and one= of them includes the extra info (AVPs) required for that application, I th= ink this is your interpretation, but… we can as well consider a new ReportType=3DapplicX_ReportY, that may apply e.= g. for any request send to this application, or just for this application&#= 43;host, and then Host could be another AVP to be included in the OLR, or w= e could define expected behaviour when defining this new ReportType.

&n= bsp;

Would t= his cover your concerns? If not, could you try to provide an example that r= equires two OLR with ReportType=3Dhost?

&n= bsp;

A part = from that, a question for all, if we extend ReportType, does it need to be = done by IETF, or could it be done per application by 3GPP?

&n= bsp;

Thanks<= o:p>

/MCruz<= o:p>

&n= bsp;

From: DiME [mailto= :dime-bounces@ietf.org] On Behalf Of Nirav Salot (nsalot)
Sent: jueves, 28 de noviembre de 2013 17:11
To: lionel.morand@orange= .com
Cc: dime@ietf.org
Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the sa= me type) within a response message

 

Hi Lion= el,

&n= bsp;

I am no= t sure if defining new ReportType for every new AVP 3GPP would add for a sp= ecific application would be a good solution.

I thoug= ht ReportType would indicate if the corresponding OC-OLR should be used whi= le sending the traffic towards the host or towards the realm.

So from= that point of view, all the OC-OLR generated by the server should have Rep= ortType=3Dhost. i.e. when the reacting node sends the traffic towards that = host, it should make use of the corresponding OC-OLR. Now, this OC-OLR may contain the AVPs defined by DOIC draft as wel= l as 3GPP application specific AVPs.

&n= bsp;

In gene= ral, I was just thinking that it may be good idea to define some of the pri= nciples such as

= -          More than one instances of OC-OLR with ReportType=3Dhost may be present in= the answer message if the OC-OLR definition is extended by the application= using the same. In that case, it is the responsibility of the application to define the valid combination of OC-OL= R instances in a given message

= -          If the reporting node includes more than one instance of OC-OLR, the repor= ting node shall always include all the active instances of OC-OLR in a resp= onse message.

= -          When the reacting node receives one or more instances of OC-OLR with the g= iven ReportType and with new timestamp value, it should overwrite all the e= xisting OC-OLR of the same ReportType.

&n= bsp;

Regards= ,

Nirav.<= o:p>

&n= bsp;

From: lionel.morand@orange.com [<= a href=3D"mailto:lionel.morand@orange.com">mailto:lionel.morand@orange.com<= /a>]
Sent: Thursday, November 28, 2013 7:39 PM
To: Nirav Salot (nsalot)
Cc: dime@ietf.org
Subject: RE: DOIC: Multiple instance of OC-OLR AVP (of the same type= ) within a response message

 

Hi Nirav,<= o:p>

 = ;

The Rep= ort Type should be able to differentiate such cases. In your example, I wou= ld define a specific Report type.

But dif= ficult to appraise all the future use cases. But for me, the main use of th= e report type is to differentiate OC-OLR received in the same message.=

And it = is the reasons of my recommendation. Actually, the exact wording will be a = "SHOULD" saying that it is recommended but you may have serious r= easons to do otherwise.

&n= bsp;

Lionel<= o:p>

&n= bsp;

De : Nirav Salot (nsalot) [mailto:nsalot@cisco.com]
Envoy=E9 : jeudi 28 novembre 2013 13:00
=C0 : MORAND Lionel IMT/OLN
Cc : dime@ietf.org
Objet : RE: DOIC: Multiple instance of OC-OLR AVP (of the same = type) within a response message

 

Lionel,

3gpp may define an optional avp which can be included = by the reporting node if it wishes to do so. E.g. APN can be additionally i= ncluded by the reporting node to indicate APN specific overload within the = given application.
In that case, the reporting node may also want to indicate application leve= l overload without including the APN (e.g. this overload report is applicab= le to all other APNs).

And hence there is a possibility of including multiple= instances of the overload report.

I am not suggesting that 3gpp will define APN (or any = other avp) within overload report. But later, if 3gpp need to define the sa= me, then corresponding handling needs to be defined within IETF now.

Regards,
Nirav.

On Nov 28, 2013 3:56 PM,= "lionel.morand@orange.com= " <lionel.morand@or= ange.com> wrote:

Hi Nirav,<= /span>

 

Not sur= e to understand the proposal or question.

The OLR= is significant per application (piggybacking principle). So if the 3GPP de= cides to add specific AVPs in the OLR (that will be possible), what would b= e the need to add the OLR without the specific 3GPP AVPs as the OLR will be anyway handle by 3GPP aware entities= ?

 <= /span>

Lionel =

 <= /span>

De : DiME [mailto:d= ime-bounces@ietf.org] De la part de Nirav Salot (nsalot)
Envoy=E9 : jeudi 28 novembre 2013 10:33
=C0 : dime@ietf.org
Objet : [Dime] DOIC: Multiple instance of OC-OLR AVP (of the sa= me type) within a response message

 

Hi,

 =

As I understand IETF will defin= e the base overload control solution as part of DOIC. Then 3GPP would adopt= the defined solution for each of its application.=

When that happens, 3GPP might w= ant to add 3GPP specific AVP within OC-OLR AVP. Based on the current defini= tion of the OC-OLR AVP this should be allowed since it contains "* [AV= P]" in its definition.

e.g. for a given application 3G= PP decides to add information into OC-OLR which changes the scope of the OC= -OLR from application level to the provided information level.

Additionally, the reporting may= want to advertise the OC-OLR at the application level scope – i.e. t= he OC-OLR without any 3GPP specific info.

 =

So if the above is allowed, we = will have the possibility of the reporting node wanting to include two inst= ances of OC-OLR with the Report-Type=3D"host".

And then we need to define the = handling of multiple instances of OC-OLR in the DOIC draft.

 =

So the questions are,

-     &= nbsp;    Is 3GPP (or any other SDO) allowed to extend th= e definition of OC-OLR by adding information into it?

-     &= nbsp;    If no, can we guarantee that application level = scope of OC-OLR (which is what we have defined currently) is sufficient (an= d not restricting) to all the applications of 3GPP?

 =

Regards,

Nirav.=

 = 

____________________________________________________=
_____________________________________________________________________<=
/o:p>
 
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces j=
ointes. 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 confide=
ntial or privileged information that may be protected by law;
they should not be distributed, used or copied witho=
ut authorisation.
If you have received this email in error, please not=
ify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.


____________________________________________________=
_____________________________________________________________________<=
/o:p>
 
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces j=
ointes. 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 confide=
ntial or privileged information that may be protected by law;
they should not be distributed, used or copied witho=
ut authorisation.
If you have received this email in error, please not=
ify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.
--_000_5BCBA1FC2B7F0B4C9D935572D90006681519C296DEMUMBX014nsnin_-- From lionel.morand@orange.com Tue Dec 3 02:04:48 2013 Return-Path: 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 772421AE0E6 for ; Tue, 3 Dec 2013 02:04:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 HqkQFumQ9W6X for ; Tue, 3 Dec 2013 02:04:43 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 8CEFB1AE061 for ; Tue, 3 Dec 2013 02:04:42 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 01D353B423E; Tue, 3 Dec 2013 11:04:39 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id D52EB35C060; Tue, 3 Dec 2013 11:04:38 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0158.001; Tue, 3 Dec 2013 11:04:38 +0100 From: To: "Wiehe, Ulrich (NSN - DE/Munich)" , "ext Maria Cruz Bartolome" , "dime@ietf.org list" Thread-Topic: [Dime] DOIC: Self-Contained OLRs Thread-Index: AQHO67/to7y6FFeeaEmQ38aKczpYQJo5m/0AgAC8o/D///ghgIAAFu+wgAGHVQCAACqasIAAMwWAgANxipCAAKJuAIAATHjQgAAM5ICAABPPEIAAFwqAgAAGBICAAAUigIAAJC3wgAEbsUCAABVyQA== Date: Tue, 3 Dec 2013 10:04:38 +0000 Message-ID: <4225_1386065078_529DACB6_4225_280_1_6B7134B31289DC4FAF731D844122B36E3128C0@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D90006681519BC90@DEMUMBX014.nsn-intra.net> <6390_1385631044_52970D44_6390_18593_1_6B7134B31289DC4FAF731D844122B36E30748E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BD19@DEMUMBX014.nsn-intra.net> <17872_1385720008_529868C8_17872_2613_1_6B7134B31289DC4FAF731D844122B36E3096B8@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BF1B@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681519BFAE@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681519C017@DEMUMBX014.nsn-intra.net> , <5BCBA1FC2B7F0B4C9D935572D90006681519C087@DEMUMBX014.nsn-intra.net> <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> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681519C248@DEMUMBX014.nsn-intra.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.20.60015 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 10:04:48 -0000 Hi Ulrich, Honestly, I don't get your point. It could be done as you've described below and there is no reason to prohib= it 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 an= swer. Regards, Lionel=20 -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN= - DE/Munich) Envoy=E9=A0: mardi 3 d=E9cembre 2013 10:21 =C0=A0: ext Maria Cruz Bartolome; dime@ietf.org list Objet=A0: 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 retu= rns a host-type OLR to C (via A) and there is no need for A to insert a rea= lm-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 Destinat= ion Host in which case any realm-type OLR inserted by A would be useless to= C.=20 Similarly In figure 5 when C sends a request without Destination Host, A ma= y 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 rece= ived 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 Barto= lome 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 no= rmal behavior. But I agree in case the request is towards a Destination Host, receiving th= e 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 no= de 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 t= he 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 o= n the need for the Report-Type. >=20=20 > 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 De= stination-Host is not in the answer. So receiving a host-based OLR in respo= nse 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 pos= itive 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" of= fered 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 th= e client could include a destination-host or not. So the client needs to kn= ow which reduction to apply from a previous answer. >=20=20 > 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 co= ntext based on the type of request. >=20=20 > Regards, >=20=20 > Lionel >=20=20 >=20=20 > De : Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Envoy=E9 : lundi 2=20 > d=E9cembre 2013 14:58 =C0 : Wiehe, Ulrich (NSN - DE/Munich) Cc :=20 > dime@ietf.org list; ext Jouni Korhonen; MORAND Lionel IMT/OLN; Ben=20 > Campbell Objet : RE: [Dime] DOIC: Self-Contained OLRs >=20=20 > Ulrich, >=20 > 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? >=20 > I would prefer to derive the context of the OLR based on the message whic= h contains the OLR. >=20 > Back to the topic of this thread, I don't think we need to define an "opt= ional" optimization at this stage. Either it is respected by all the nodes = supporting the solution or we drop that optimization. >=20 > Regards, > Nirav. >=20 > On Dec 2, 2013 5:27 PM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: > Nirav, >=20 > If the reacting node sends a request without Destination Host, a realm-ty= pe OLR in the answer would be in-context whereas a host-type OLR in the ans= wer would be out of context. >=20 > Similarly, if the reacting node sends a request containing Destination Ho= st, a realm-type OLR in the answer would be out-of-context and a host-type = OLR in the answer would be in-context. >=20 > Ulrich >=20 >=20 >=20 > -----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=20 > Jouni Korhonen; Ben Campbell > Cc: dime@ietf.org list > Subject: RE: [Dime] DOIC: Self-Contained OLRs >=20 > Ulrich, >=20 > I have a basic question. >=20 > When the reacting node sends realm-routed request and it receives (only o= ne) OLR in the response message (which also contains the origin-host), is t= his OLR applicable for realm or host? > I am trying to understand which is out-of-context OLR here: realm-type or= host-type? >=20 > Regards, > Nirav. >=20 > -----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=20 > Korhonen; Ben Campbell > Cc: dime@ietf.org list > Subject: RE: [Dime] DOIC: Self-Contained OLRs >=20 > Hi Nirav, >=20 > please see inline. >=20 > Regards > Ulrich >=20 > -----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=20 > Jouni Korhonen; Ben Campbell > Cc: dime@ietf.org list > Subject: RE: [Dime] DOIC: Self-Contained OLRs >=20 > Ulrich, >=20 > When the client sends request containing destination-realm (and not conta= ining 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 thi= s response message is not out-of-context information.=20 > [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= =3Dx1, destination realm =3Dx2 application=3D 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, w= hat the type x was. E.g. it deduces from the value of Origin Realm in the a= nswer the value of Destination Realm in the request; it deduces from the va= lue of Report-Type in the answer whether Destination Host was present in th= e request... >=20 > On the other hand, we discussed - as part of Maria Cruz's alternative sol= ution - to define the response message's context based on the request messa= ge. And hence if the request message was sent to destination-realm, the cor= responding 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 unneces= sary complexity.=20 > [Wiehe, Ulrich (NSN - DE/Munich)] I agree. This means: the report-type AV= P is needed to let the client deduce from information received in the answe= r whether the request contained a destination host. It does not mean that w= e need two OLRs in one answer. >=20 > If we strictly want to ensure that the realm-type OLR is not sent=20 > out-of-context [Wiehe, Ulrich (NSN - DE/Munich)] That was not my=20 > proposal. My proposal was to clearly mark out-of-context OLRs in=20 > answer messages (if we allow including out-of-context OLRs) >=20 > , then we should agree to Lionel's alternative solution - to send realm-t= ype OLR only when the destination-realm based request is rejected. So basic= ally, 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 ensu= re the context of the response message and the OLR it contains). >=20 > 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 on= e 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=20 > (NSN - DE/Munich)] only the out-of-context one >=20 > , then what is the point of including two OLRs [Wiehe, Ulrich (NSN - DE/M= unich)] 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 a= s 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 react= ing node (if the reacting node wants to make use of this optimization). >=20 > and what is the point of defining Report-Type AVP? > [Wiehe, Ulrich (NSN - DE/Munich)] to let the reacting node deduce from in= formation received in the answer whether the corresponding request containe= d a destination host (so there is no need to remember). >=20 >=20 > In summary, if we define Report-Type AVP and corresponding handling at th= e reacting node, the reacting node must act accordingly and not ignore it. > [Wiehe, Ulrich (NSN - DE/Munich)] What goes wrong when out-of -context O= LR is ignored? >=20 > 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 i= gnored. > [Wiehe, Ulrich (NSN - DE/Munich)] Not the Report-Type AVP is the optimiza= tion but the incusion of out-of-context OLRs. And I'm ok not to proceed wit= h this optimization as it is not needed. >=20 > Regards, > Nirav. >=20 > -----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=20 > Korhonen; Ben Campbell > Cc: dime@ietf.org list > Subject: RE: [Dime] DOIC: Self-Contained OLRs >=20 > Hi Nirav, >=20 > 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-contex= t. > There is nothing wrong with storing such out-of-context OLRs at the clien= t, but it is simply not needed as the client will learn this OLR from respo= nses received within the context. >=20 > Best regards > Ulrich >=20 >=20 > -----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=20 > Jouni Korhonen; Ben Campbell > Cc: dime@ietf.org list > Subject: RE: [Dime] DOIC: Self-Contained OLRs >=20 > Hi Ulrich, >=20 > If an additional OLR is present with a different ReportType, why it shoul= d be ignored by the reacting node? >=20 > Regards, > Nirav. >=20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich=20 > (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 >=20 > Hi Lionel, >=20 > there is nothing missing exept the clarification that everything works fi= ne 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. >=20 > Ulrich >=20=20 >=20 > -----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 >=20 > Hi Ulrich, >=20 > Using the Report Type "host report", you know that the OLR applies for su= bsequent 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.=20 >=20 > It is not so important to know what the type of request was and which nod= e 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, f= or instance, future development could allow a distributed server architectu= re to provide the same information. >=20 > I'm not sure of what is missing in this reasoning... >=20 > Lionel >=20 > -----Message d'origine----- > De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 > Envoy=E9 : jeudi 28 novembre 2013 11:30 =C0 : MORAND Lionel IMT/OLN; ext= =20 > Jouni Korhonen; Ben Campbell Cc : dime@ietf.org list Objet : RE:=20 > [Dime] DOIC: Self-Contained OLRs >=20 > Lionel, >=20 > my understanding was that _the_ reporting end point provides _the_ OLR. >=20 > If we go for two OLRs in the answer we should indicate which OLR is the a= ctual OLR created by the reporting end point and which OLR is an additional= OLR created by another node. >=20 > We have two cases: > a) The request sent by the client (reacting end point) contains no Destin= ation 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 OL= R as learned from the selected server. The client may ignore the additiona= l OLR. > b) The request sent by the client (reacting endpoint) contains the Destin= ation Host. The Server (reporting node) returns a host-type OLR as the actu= al reporting-node-created OLR in the answer. The agent may optionally inser= t a realm-type OLR as additional OLR to the answer. The client may ignore t= he additional OLR. >=20 > Ulrich >=20 >=20 >=20 > -----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 >=20 > Hi, >=20 > There is no assumption on which entity is providing the realm overload st= atus. 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 s= ome 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 ser= ver itself, one for the realm for new request sent to the realm with only D= est-Realm AVP. >=20 > Lionel >=20 > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich=20 > (NSN - DE/Munich) Envoy=E9 : jeudi 28 novembre 2013 10:26 =C0 : ext Jouni= =20 > Korhonen; Ben Campbell Cc : dime@ietf.org list Objet : Re: [Dime]=20 > DOIC: Self-Contained OLRs >=20 > Hi, >=20 > 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 i= ndicates 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 indicate= s to the reacting end point that the reporting end point is a server. How c= an the reporting end point be both agent and server? >=20 > Ulrich >=20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Jouni=20 > Korhonen > Sent: Wednesday, November 27, 2013 11:44 PM > To: Ben Campbell > Cc: dime@ietf.org list > Subject: Re: [Dime] DOIC: Self-Contained OLRs >=20 >=20 > On Nov 28, 2013, at 12:27 AM, Ben Campbell wrote: >=20 > > Hi, > >=20 > > I mentioned in another thread that I prefer putting an explicit=20 > > ReportType AVP in an OLR, rather than >=20 > The more I spent time thinking/writing the actual procedures on the endpo= ints, the more it makes sense to me to keep the ReportType in the OC-OLR. E= ven if the baseline does not have agent overload etc, the ReportType fits w= ell 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 pl= ain more clear. >=20 > I skip the rest of the mail.. too much text ;-) >=20 >=20 > - Jouni >=20 >=20 >=20 >=20 >=20 > > making a responding node infer the type or meaning of the OLR from a Di= ameter request that corresponds to the answer containing the OLR. My reason= s for that go beyond just ReportType, so I'm starting a separate thread. > >=20 > > 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 t= hat carries the OLR. For example, the OLR implicitly refers to the applicat= ion identified by the Application-Id field of the enclosing answer, the rea= lm 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 mea= ning in the context of the enclosing answer. If you moved an OLR from one a= nswer to another, it's meaning may change completely. > >=20 > > I think this approach is a mistake. I would greatly prefer that we expl= icitly include such values in the OLR itself, for multiple reasons: > >=20 > > 1) It's more complex to interpret implicit, contextual values than expl= icit values. The consumer cannot simply look at the OLR; it must look in va= rious other AVPs to find all the information it needs. For example, I think= a common software design for overload control processing to be separated f= rom 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 OL= R, 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 "c= ontext" avps that must be interpreted can grow large. This approach is erro= r prone, and will likely encourage brittle, hard-to-maintain code. Self-con= tained OLRs would keep all the information related to overload in one place= . making for simpler implementations. > >=20 > > 2) It's more complex for the reporting node to send implicit values tha= n explicit values. The sender cannot simply set the context to match the OL= R--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 ins= ert OLRs into answers created by other nodes.=20 > >=20 > > If the reporting node screws this up, the meaning of the OLR may change= significantly. So again, implicit meaning gives us error prone implementat= ions. Self-contained OLRs are simpler to create and send. > >=20 > > 3) Implicit values don't work at all for certain problems. For=20 > > example, if an agent needs to originate an OLR, it typically needs=20 > > to insert that OLR into an existing Diameter answer created by a server. > > It can't create its own answer without affecting the application=20 > > state. If the responding node assumes the OLR comes from or refers=20 > > to the node identified by the Origin-Host AVP in the enclosing=20 > > answer, things break. (For examples of when an agent needs to send=20 > > OLRs that are distinct from those sent by a server, see Steve's=20 > > agent overload draft, or my dh/dr example.) > >=20 > > OTOH, explicit values will work for all cases where we need to associat= e some arbitrary value with an OLR. > >=20 > > 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 ov= erload 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 trans= ported, this won't work. We would have to create a new or significantly mod= ified OLR format if we found a need to transport OLRs in different ways. Se= lf-contained OLRs would allow much greater flexibility. > >=20 > > 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. > >=20 > > Thanks! > >=20 > > Ben. > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime >=20 > _______________________________________________ > 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 >=20 > ______________________________________________________________________ > ___________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc pas etre diffuses, exploites o= u copies sans autorisation. Si vous avez recu ce message par erreur, veuill= ez 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. >=20 > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; they should not be distributed, us= ed or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 >=20 > ______________________________________________________________________ > ___________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc pas etre diffuses, exploites o= u copies sans autorisation. Si vous avez recu ce message par erreur, veuill= ez 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. >=20 > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; they should not be distributed, us= ed or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > ______________________________________________________________________ > ___________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not be d= istributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 _______________________________________________ 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 confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. From lionel.morand@orange.com Tue Dec 3 02:40:39 2013 Return-Path: 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 747721AE08F for ; Tue, 3 Dec 2013 02:40:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 eu-24LPftZGV for ; Tue, 3 Dec 2013 02:40:32 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id A0D641A8026 for ; Tue, 3 Dec 2013 02:40:31 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id AB5472641F4; Tue, 3 Dec 2013 11:40:28 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 8B9E5238072; Tue, 3 Dec 2013 11:40:28 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0158.001; Tue, 3 Dec 2013 11:40:28 +0100 From: To: "Wiehe, Ulrich (NSN - DE/Munich)" , "ext Nirav Salot (nsalot)" , Maria Cruz Bartolome , "dime@ietf.org" Thread-Topic: DOIC: Multiple instance of OC-OLR AVP (of the same type) within a response message Thread-Index: Ac7wCaL7vn3WS3V+QYqfk/QVoAmaPAAAkVNQAAFnIYA= Date: Tue, 3 Dec 2013 10:40:28 +0000 Message-ID: <10558_1386067228_529DB51C_10558_2647_1_6B7134B31289DC4FAF731D844122B36E3129AA@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <5BCBA1FC2B7F0B4C9D935572D90006681519C296@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681519C296@DEMUMBX014.nsn-intra.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.5] Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E3129AAPEXCVZYM13corpora_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.12.3.101814 Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same type) within a response message X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 10:40:39 -0000 --_000_6B7134B31289DC4FAF731D844122B36E3129AAPEXCVZYM13corpora_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Nirav, If there are more than one OLR of the same type in the same answer, based o= n what I understood from the examples given below, the client will have to = figure out which reduction to apply only based on extra AVPs received in th= e OLRs. I'm not so sure that it is something advisable from a standard poin= t of view. Regards, Lionel De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN -= DE/Munich) Envoy=E9 : mardi 3 d=E9cembre 2013 10:48 =C0 : ext Nirav Salot (nsalot); Maria Cruz Bartolome; dime@ietf.org Objet : Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same type)= within a response message Nirav, I still do not see the need for more than one OLR in an answer. More than one OLR means more complexity. Let's try to avoid that. The server gets a request that either is or is not in the narrower scope. I= f it is not, why shoud the server return an OLR for the narrower scope? It = can do so when it gets a request within the narrower scope (which possibly = never happens). Ulrich From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Nirav Salot (nsa= lot) Sent: Tuesday, December 03, 2013 10:26 AM To: Maria Cruz Bartolome; dime@ietf.org Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same type= ) within a response message Maria-Cruz, > we may think that we need two different OLRs with ReportType=3Dhost, and = one of them includes the extra info (AVPs) required for that application Yes. The above is my concern. I tried giving APN as one example AVP which w= e may want to include in OC-OLR. Let me give another possible example. As of now, the OC-OLR can indicate application + host/realm level "required= -reduction-percentage". However, for the given application (e.g. Gx) we may want to define a narrow= er scope with "session-type =3D {M2M, Others}" AVP. So basically, the Gx no= des can advertise different "required-reduction-percentage" for M2M session= s v/s other type of sessions for the same application Gx and for the same d= estination-host. So in general, if any application needs to define a different (i.e. narrowe= r) scope than application + host/realm, it can do so by adding a new AVP in= OC-OLR. And then we might have two instances of OC-OLR from the same host. We could achieve the above by defining new Report-Type for each new AVP add= ed by each application. But would this scale or is this a reasonable approa= ch? I am not sure and you have already identified one of my concerns below > if we extend ReportType, does it need to be done by IETF, or could it be = done per application by 3GPP? In summary, in my view, we need to define the handling of multiple instance= s with the same Report-Type as part of the DOIC draft. Or we say that multi= ple instances with the same Report-Type is not allowed - this seems unneces= sary restriction to me. Otherwise, if later, we realize the need to do so then we may not be able t= o do so since the handling is not defined in the base solution. Regards, Nirav. From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Maria Cruz Bartolome Sent: Tuesday, December 03, 2013 1:57 PM To: dime@ietf.org Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same type= ) within a response message Nirav, I think I understand your concern. It may occur that we need that a reactin= g node should apply two different OLR when sending a request towards one sp= ecific host. Then, we may think that we need two different OLRs with ReportType=3Dhost, = and one of them includes the extra info (AVPs) required for that applicatio= n, I think this is your interpretation, but... we can as well consider a ne= w ReportType=3DapplicX_ReportY, that may apply e.g. for any request send to= this application, or just for this application+host, and then Host could b= e another AVP to be included in the OLR, or we could define expected behavi= our when defining this new ReportType. Would this cover your concerns? If not, could you try to provide an example= that requires two OLR with ReportType=3Dhost? A part from that, a question for all, if we extend ReportType, does it need= to be done by IETF, or could it be done per application by 3GPP? Thanks /MCruz From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Nirav Salot (nsalot) Sent: jueves, 28 de noviembre de 2013 17:11 To: lionel.morand@orange.com Cc: dime@ietf.org Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same type= ) within a response message Hi Lionel, I am not sure if defining new ReportType for every new AVP 3GPP would add f= or a specific application would be a good solution. I thought ReportType would indicate if the corresponding OC-OLR should be u= sed while sending the traffic towards the host or towards the realm. So from that point of view, all the OC-OLR generated by the server should h= ave ReportType=3Dhost. i.e. when the reacting node sends the traffic toward= s that host, it should make use of the corresponding OC-OLR. Now, this OC-O= LR may contain the AVPs defined by DOIC draft as well as 3GPP application s= pecific AVPs. In general, I was just thinking that it may be good idea to define some of = the principles such as - More than one instances of OC-OLR with ReportType=3Dhost may be = present in the answer message if the OC-OLR definition is extended by the a= pplication using the same. In that case, it is the responsibility of the ap= plication to define the valid combination of OC-OLR instances in a given me= ssage - If the reporting node includes more than one instance of OC-OLR,= the reporting node shall always include all the active instances of OC-OLR= in a response message. - When the reacting node receives one or more instances of OC-OLR = with the given ReportType and with new timestamp value, it should overwrite= all the existing OC-OLR of the same ReportType. Regards, Nirav. From: lionel.morand@orange.com [mailto:lio= nel.morand@orange.com] Sent: Thursday, November 28, 2013 7:39 PM To: Nirav Salot (nsalot) Cc: dime@ietf.org Subject: RE: DOIC: Multiple instance of OC-OLR AVP (of the same type) withi= n a response message Hi Nirav, The Report Type should be able to differentiate such cases. In your example= , I would define a specific Report type. But difficult to appraise all the future use cases. But for me, the main us= e of the report type is to differentiate OC-OLR received in the same messag= e. And it is the reasons of my recommendation. Actually, the exact wording wil= l be a "SHOULD" saying that it is recommended but you may have serious reas= ons to do otherwise. Lionel De : Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Envoy=E9 : jeudi 28 novembre 2013 13:00 =C0 : MORAND Lionel IMT/OLN Cc : dime@ietf.org Objet : RE: DOIC: Multiple instance of OC-OLR AVP (of the same type) within= a response message Lionel, 3gpp may define an optional avp which can be included by the reporting node= if it wishes to do so. E.g. APN can be additionally included by the report= ing node to indicate APN specific overload within the given application. In that case, the reporting node may also want to indicate application leve= l overload without including the APN (e.g. this overload report is applicab= le to all other APNs). And hence there is a possibility of including multiple instances of the ove= rload report. I am not suggesting that 3gpp will define APN (or any other avp) within ove= rload report. But later, if 3gpp need to define the same, then correspondin= g handling needs to be defined within IETF now. Regards, Nirav. On Nov 28, 2013 3:56 PM, "lionel.morand@orange.com" > wrote: Hi Nirav, Not sure to understand the proposal or question. The OLR is significant per application (piggybacking principle). So if the = 3GPP decides to add specific AVPs in the OLR (that will be possible), what = would be the need to add the OLR without the specific 3GPP AVPs as the OLR = will be anyway handle by 3GPP aware entities? Lionel De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot (nsalot) Envoy=E9 : jeudi 28 novembre 2013 10:33 =C0 : dime@ietf.org Objet : [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same type) wit= hin a response message Hi, As I understand IETF will define the base overload control solution as part= of DOIC. Then 3GPP would adopt the defined solution for each of its applic= ation. When that happens, 3GPP might want to add 3GPP specific AVP within OC-OLR A= VP. Based on the current definition of the OC-OLR AVP this should be allowe= d since it contains "* [AVP]" in its definition. e.g. for a given application 3GPP decides to add information into OC-OLR wh= ich changes the scope of the OC-OLR from application level to the provided = information level. Additionally, the reporting may want to advertise the OC-OLR at the applica= tion level scope - i.e. the OC-OLR without any 3GPP specific info. So if the above is allowed, we will have the possibility of the reporting n= ode wanting to include two instances of OC-OLR with the Report-Type=3D"host= ". And then we need to define the handling of multiple instances of OC-OLR in = the DOIC draft. So the questions are, - Is 3GPP (or any other SDO) allowed to extend the definition of O= C-OLR by adding information into it? - If no, can we guarantee that application level scope of OC-OLR (= which is what we have defined currently) is sufficient (and not restricting= ) to all the applications of 3GPP? Regards, Nirav. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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 confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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 confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. --_000_6B7134B31289DC4FAF731D844122B36E3129AAPEXCVZYM13corpora_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Nirav, =

&n= bsp;

If ther= e are more than one OLR of the same type in the same answer, based on what = I understood from the examples given below, the client will have to figure = out which reduction to apply only based on extra AVPs received in the OLRs. I'm not so sure that it is something a= dvisable from a standard point of view.

&n= bsp;

Regards= ,

&n= bsp;

Lionel<= o:p>

&n= bsp;

De : DiME= [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN - DE/Munich)
Envoy=E9 : mardi 3 d=E9cembre 2013 10:48
=C0 : ext Nirav Salot (nsalot); Maria Cruz Bartolome; dime@ietf= .org
Objet : Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of th= e same type) within a response message

 

Nirav,<= o:p>

&n= bsp;

I still= do not see the need for more than one OLR in an answer.<= /p>

&n= bsp;

More th= an one OLR means more complexity. Let’s try to avoid that.=

&n= bsp;

The ser= ver gets a request that either is or is not in the narrower scope. If it is= not, why shoud the server return an OLR for the narrower scope? It can do = so when it gets a request within the narrower scope (which possibly never happens).

&n= bsp;

Ulrich<= o:p>

&n= bsp;

&n= bsp;

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Nirav Salot (nsalot)
Sent: Tuesday, December 03, 2013 10:26 AM
To: Maria Cruz Bartolome; dime@ietf.org
Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the sa= me type) within a response message

 

Maria-C= ruz,

&n= bsp;

> we may think that we need= two different OLRs with ReportType=3Dhost, and one of them includes the ex= tra info (AVPs) required for that application

Yes. Th= e above is my concern. I tried giving APN as one example AVP which we may w= ant to include in OC-OLR. Let me give another possible example.<= /span>

As of n= ow, the OC-OLR can indicate application + host/realm level "requir= ed-reduction-percentage".

However= , for the given application (e.g. Gx) we may want to define a narrower scop= e with "session-type =3D {M2M, Others}" AVP. So basically, the Gx= nodes can advertise different "required-reduction-percentage" for M2M sessions v/s other type of sessions for the same application Gx an= d for the same destination-host.

&n= bsp;

So in g= eneral, if any application needs to define a different (i.e. narrower) scop= e than application + host/realm, it can do so by adding a new AVP in OC= -OLR.

And the= n we might have two instances of OC-OLR from the same host.

&n= bsp;

We coul= d achieve the above by defining new Report-Type for each new AVP added by e= ach application. But would this scale or is this a reasonable approach?

I am no= t sure and you have already identified one of my concerns below<= /span>

> if we extend ReportType, = does it need to be done by IETF, or could it be done per application by 3GP= P?

&n= bsp;

In summ= ary, in my view, we need to define the handling of multiple instances with = the same Report-Type as part of the DOIC draft. Or we say that multiple ins= tances with the same Report-Type is not allowed – this seems unnecessary restriction to me.

Otherwi= se, if later, we realize the need to do so then we may not be able to do so= since the handling is not defined in the base solution.<= /p>

&n= bsp;

Regards= ,

Nirav.<= o:p>

&n= bsp;

From: DiME [mailto= :dime-bounces@ietf.org] On Behalf Of Maria Cruz Bartolome
Sent: Tuesday, December 03, 2013 1:57 PM
To: dime@ietf.org
Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the sa= me type) within a response message

 

Nirav, =

&n= bsp;

I think= I understand your concern. It may occur that we need that a reacting node = should apply two different OLR when sending a request towards one specific = host.

Then, w= e may think that we need two different OLRs with ReportType=3Dhost, and one= of them includes the extra info (AVPs) required for that application, I th= ink this is your interpretation, but… we can as well consider a new ReportType=3DapplicX_ReportY, that may apply e.= g. for any request send to this application, or just for this application&#= 43;host, and then Host could be another AVP to be included in the OLR, or w= e could define expected behaviour when defining this new ReportType.

&n= bsp;

Would t= his cover your concerns? If not, could you try to provide an example that r= equires two OLR with ReportType=3Dhost?

&n= bsp;

A part = from that, a question for all, if we extend ReportType, does it need to be = done by IETF, or could it be done per application by 3GPP?

&n= bsp;

Thanks<= o:p>

/MCruz<= o:p>

&n= bsp;

From: DiME [mailto= :dime-bounces@ietf.org] On Behalf Of Nirav Salot (nsalot)
Sent: jueves, 28 de noviembre de 2013 17:11
To: lionel.morand@orange= .com
Cc: dime@ietf.org
Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the sa= me type) within a response message

 

Hi Lion= el,

&n= bsp;

I am no= t sure if defining new ReportType for every new AVP 3GPP would add for a sp= ecific application would be a good solution.

I thoug= ht ReportType would indicate if the corresponding OC-OLR should be used whi= le sending the traffic towards the host or towards the realm.

So from= that point of view, all the OC-OLR generated by the server should have Rep= ortType=3Dhost. i.e. when the reacting node sends the traffic towards that = host, it should make use of the corresponding OC-OLR. Now, this OC-OLR may contain the AVPs defined by DOIC draft as wel= l as 3GPP application specific AVPs.

&n= bsp;

In gene= ral, I was just thinking that it may be good idea to define some of the pri= nciples such as

= -          More than one instances of OC-OLR with ReportType= =3Dhost may be present in the answer message if the OC-OLR definition is ex= tended by the application using the same. In that case, it is the responsibility of the application to define the va= lid combination of OC-OLR instances in a given message

= -          If the reporting node includes more than one inst= ance of OC-OLR, the reporting node shall always include all the active inst= ances of OC-OLR in a response message.

= -          When the reacting node receives one or more insta= nces of OC-OLR with the given ReportType and with new timestamp value, it s= hould overwrite all the existing OC-OLR of the same ReportType.

&n= bsp;

Regards= ,

Nirav.<= o:p>

&n= bsp;

From: lionel.morand@orange.com [<= a href=3D"mailto:lionel.morand@orange.com">mailto:lionel.morand@orange.com<= /a>]
Sent: Thursday, November 28, 2013 7:39 PM
To: Nirav Salot (nsalot)
Cc: dime@ietf.org
Subject: RE: DOIC: Multiple instance of OC-OLR AVP (of the same type= ) within a response message

 

Hi Nirav,

 

The Rep= ort Type should be able to differentiate such cases. In your example, I wou= ld define a specific Report type.

But dif= ficult to appraise all the future use cases. But for me, the main use of th= e report type is to differentiate OC-OLR received in the same message.=

And it = is the reasons of my recommendation. Actually, the exact wording will be a = "SHOULD" saying that it is recommended but you may have serious r= easons to do otherwise.

&n= bsp;

Lionel<= o:p>

&n= bsp;

De : Nira= v Salot (nsalot) [mailto:nsalot@cisco.c= om]
Envoy=E9 : jeudi 28 novembre 2013 13:00
=C0 : MORAND Lionel IMT/OLN
Cc : dime@ietf.org
Objet : RE: DOIC: Multiple instance of OC-OLR AVP (of the same = type) within a response message

 

Lionel,

3gpp may define an optional avp which can be included by the reporting n= ode if it wishes to do so. E.g. APN can be additionally included by the rep= orting node to indicate APN specific overload within the given application.=
In that case, the reporting node may also want to indicate application leve= l overload without including the APN (e.g. this overload report is applicab= le to all other APNs).

And hence there is a possibility of including multiple instances of the = overload report.

I am not suggesting that 3gpp will define APN (or any other avp) within = overload report. But later, if 3gpp need to define the same, then correspon= ding handling needs to be defined within IETF now.

Regards,
Nirav.

On Nov 28, 2013 3:56 PM, "lionel.morand@orange.com" &= lt;lionel.morand@orange.com= > wrote:

Hi Nirav,<= /o:p>

 

Not sur= e to understand the proposal or question.

The OLR= is significant per application (piggybacking principle). So if the 3GPP de= cides to add specific AVPs in the OLR (that will be possible), what would b= e the need to add the OLR without the specific 3GPP AVPs as the OLR will be anyway handle by 3GPP aware entities= ?

 <= /span>

Lionel =

 <= /span>

De : DiME= [mailto:dime-bounces@ietf.org] De la part de Nirav Salot (nsalot)
Envoy=E9 : jeudi 28 novembre 2013 10:33
=C0 : dime@ietf.org
Objet : [Dime] DOIC: Multiple instance of OC-OLR AVP (of the sa= me type) within a response message

 

Hi,

 

As I understand IETF will defin= e the base overload control solution as part of DOIC. Then 3GPP would adopt= the defined solution for each of its application.

When that happens, 3GPP might w= ant to add 3GPP specific AVP within OC-OLR AVP. Based on the current defini= tion of the OC-OLR AVP this should be allowed since it contains "* [AV= P]" in its definition.

e.g. for a given application 3G= PP decides to add information into OC-OLR which changes the scope of the OC= -OLR from application level to the provided information level.<= /o:p>

Additionally, the reporting may= want to advertise the OC-OLR at the application level scope – i.e. t= he OC-OLR without any 3GPP specific info.

 

So if the above is allowed, we = will have the possibility of the reporting node wanting to include two inst= ances of OC-OLR with the Report-Type=3D"host".<= /p>

And then we need to define the = handling of multiple instances of OC-OLR in the DOIC draft.

 

So the questions are,

-     &= nbsp;    Is 3GPP (or any other SDO) allowed to extend th= e definition of OC-OLR by adding information into it?

-     &= nbsp;    If no, can we guarantee that application level = scope of OC-OLR (which is what we have defined currently) is sufficient (an= d not restricting) to all the applications of 3GPP?

 

Regards,

Nirav.

 

_=
___________________________________________________________________________=
_____________________________________________
<=
o:p> 
C=
e message et ses pieces jointes peuvent contenir des informations confident=
ielles ou privilegiees et ne doivent donc
p=
as 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 ele=
ctroniques etant susceptibles d'alteration,
O=
range decline toute responsabilite si ce message a ete altere, deforme ou f=
alsifie. Merci.
<=
o:p> 
T=
his message and its attachments may contain confidential or privileged info=
rmation that may be protected by law;
t=
hey should not be distributed, used or copied without authorisation.
I=
f you have received this email in error, please notify the sender and delet=
e this message and its attachments.
A=
s emails may be altered, Orange is not liable for messages that have been m=
odified, changed or falsified.
T=
hank you.
_=
___________________________________________________________________________=
_____________________________________________
<=
o:p> 
C=
e message et ses pieces jointes peuvent contenir des informations confident=
ielles ou privilegiees et ne doivent donc
p=
as 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 ele=
ctroniques etant susceptibles d'alteration,
O=
range decline toute responsabilite si ce message a ete altere, deforme ou f=
alsifie. Merci.
<=
o:p> 
T=
his message and its attachments may contain confidential or privileged info=
rmation that may be protected by law;
t=
hey should not be distributed, used or copied without authorisation.
I=
f you have received this email in error, please notify the sender and delet=
e this message and its attachments.
A=
s emails may be altered, Orange is not liable for messages that have been m=
odified, changed or falsified.
T=
hank you.
______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles 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 el=
ectroniques 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 inf=
ormation 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 dele=
te 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.
--_000_6B7134B31289DC4FAF731D844122B36E3129AAPEXCVZYM13corpora_-- From maria.cruz.bartolome@ericsson.com Tue Dec 3 02:42:16 2013 Return-Path: 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 A10921AD739 for ; Tue, 3 Dec 2013 02:42:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no 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 ZFwKps4CFaHy for ; Tue, 3 Dec 2013 02:42:14 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 1A51A1A8026 for ; Tue, 3 Dec 2013 02:42:13 -0800 (PST) X-AuditID: c1b4fb32-b7f388e0000057e0-1c-529db582872e Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 34.71.22496.285BD925; Tue, 3 Dec 2013 11:42:10 +0100 (CET) Received: from ESESSMB101.ericsson.se ([169.254.1.118]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.02.0347.000; Tue, 3 Dec 2013 11:42:10 +0100 From: Maria Cruz Bartolome To: "dime@ietf.org" Thread-Topic: [Dime] Proposed Example Text for draft-docdt-dime-ovli-01 Thread-Index: AQHO6uUDqVgnzlBjcUaitdkVWblShJo46aSAgAFVyACAAA3VAIAIBQBQ Date: Tue, 3 Dec 2013 10:42:09 +0000 Message-ID: <087A34937E64E74E848732CFF8354B920972BF1E@ESESSMB101.ericsson.se> References: <66DEB166-8DEB-42CA-A46E-8128F0D0900B@nostrum.com> <4CFE9D80-E25A-4B8F-96D1-EB7C21F2F11A@nostrum.com> <9AC5C876-99AD-4C43-9B13-3288C76459FB@gmail.com> <18796_1385626955_5296FD4B_18796_11001_1_6B7134B31289DC4FAF731D844122B36E3071A0@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrKLMWRmVeSWpSXmKPExsUyM+JvrW7T1rlBBvNOWlvM7V3B5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujGuLsguOaFXsm/OSrYHxuVIXIyeHhICJxMbtp9khbDGJC/fW s3UxcnEICZxglJj//zwjSEJIYDGjxNF/OiA2m4CdxKXTL5i6GDk4RASUJU7/cgAJCwu4SUy/ uYcFxBYRcJc4+fwnI4TtJnG8dRJYOYuAikTrPF6QMK+Ar8Thc9fYIVY9Y5J4dPoUO0gNJ1Bi 3vdikBpGoHO+n1rDBGIzC4hL3HoynwniTAGJJXvOM0PYohIvH/9jhbAVJdqfNjBC1OtJ3Jg6 hQ3C1pZYtvA1M8ReQYmTM5+wTGAUnYVk7CwkLbOQtMxC0rKAkWUVo2RxanFxbrqRgV5uem6J XmpRZnJxcX6eXnHqJkZgVBzc8ttoB+PJPfaHGKU5WJTEea+z1gQJCaQnlqRmp6YWpBbFF5Xm pBYfYmTi4JRqYHSsm3jNR+pqTHXp7qnvQllX3Zi+7+6lS5JLFQUk5F8ebz6z2MRE3Fjs9qfl z84f7rUonarCqqawiUFDp8pJ9LNwh+cNfddldQGTtGUnBZh/yG2/adVbEJ05YbY9U+MNO65l F058Wz2t14zbU3BjYM72yQHcG9/UBxedUSid+Yz/pa7pT2n2S0osxRmJhlrMRcWJAM1dqmtY AgAA Subject: Re: [Dime] Proposed Example Text for draft-docdt-dime-ovli-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 10:42:16 -0000 Fine with principles, except for "multiple OLRs" that still we haven't reac= hed a conclusion. Regards MCruz -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Nirav Salot (nsalot) Sent: jueves, 28 de noviembre de 2013 10:12 To: lionel.morand@orange.com; Jouni Korhonen; Ben Campbell; dime@ietf.org Subject: Re: [Dime] Proposed Example Text for draft-docdt-dime-ovli-01 I am fine with all the principles mentioned below except for "Multiple OLRs= can be found in the answer only if the OLRs have different Report types". I am not 100% sure if the above restriction is needed yet. I will initiate = a separate e-mail thread for the related discussion. Regards, Nirav. -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange= .com Sent: Thursday, November 28, 2013 1:53 PM To: Jouni Korhonen; Ben Campbell; dime@ietf.org Subject: Re: [Dime] Proposed Example Text for draft-docdt-dime-ovli-01 I could discuss the need for the report type for a longtime... But I can live with the following approach: - Keep the report type AVP - Keep the Report type as optional in the OC-OLR - Clarify that the OC-OLR applies to the Origin-Host of the Answer when the= report type is absent - Multiple OLRs can be found in the answer only if the OLRs have different = Report types e.g. response to an initial request (with only dest-Realm AVP)= may contain overload status of the node and of the realm - Remove "aggregated" Is it OK for everyone? Lionel -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Jouni Korhonen Env= oy=E9=A0: mercredi 27 novembre 2013 12:59 =C0=A0: Ben Campbell; dime@ietf.o= rg Objet=A0: Re: [Dime] Proposed Example Text for draft-docdt-dime-ovli-01 On Nov 26, 2013, at 10:20 PM, Ben Campbell wrote: > 2) Lionel argued that OLRs are best used to describe overload for the re= alm as a whole. Overload for specific nodes would be better handled by send= ing Diameter error codes, either by fixing one or more existing error codes= to have the correct semantics, or introducing new ones. If we did this, we= would not need different report types. >=20 > My opinion is that I would like a consistent way of reporting overload, t= hat is, I don't like using OLRs for one kind of overload, and error result = codes for another. In particular, I would like to be able to report overloa= d before reaching the point that I need to fail a transaction, i.e. I would= like to be able to report any kind of overload in a Diameter answer messag= e with a result code of DIAMETER_SUCCESS. I am towards Ben's conclusion here. > 3) Are we allowed to put more than one OLRs in a single answer, as my exa= mple shows in step 8? >=20 > It might be possible to construct an example where you never see more tha= n one OLR in a single answer. But I don't see what purpose would be served = by such a limitation, as long as multiple OLRs do not contradict each other= . Since the reports in the example have different report types, there is no= conflict. On disadvantage of _not_ allowing multiple reports in one answer= is that, if the servers choose to send reports in every answer, life gets = complicated for the agent when trying to find a place to put the "realm" re= port. It either needs to strip the server reports (which is hard given tha= t the server overload conditions are best handled by the clients.) Or it ne= eds to originate its own answers, which means forcing the failure of at lea= st some transactions. My recollection was that we want to get rid off the ReportType in the basel= ine. That would also imply a single OLR in an answer. I might remember wron= g, though. Anyway, just to be on the safe side the current draft-ietf-*-01 still has t= he ReportType. Could we conclude this point asap? Removing the ReportType has implications= in multiple places. - Jouni _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation 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 dele= te 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 From ulrich.wiehe@nsn.com Tue Dec 3 02:46:01 2013 Return-Path: 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 69DC91AE105 for ; Tue, 3 Dec 2013 02:46:01 -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 o3EtE2j7NhkT for ; Tue, 3 Dec 2013 02:45:56 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 126081A8026 for ; Tue, 3 Dec 2013 02:45:55 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rB3AjovK029978 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 3 Dec 2013 11:45:50 +0100 Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rB3AjndK030862 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Dec 2013 11:45:50 +0100 Received: from DEMUHTC009.nsn-intra.net (10.159.42.40) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 3 Dec 2013 11:45:49 +0100 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.152]) by DEMUHTC009.nsn-intra.net ([10.159.42.40]) with mapi id 14.03.0123.003; Tue, 3 Dec 2013 11:45:49 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: "ext lionel.morand@orange.com" , "ext Maria Cruz Bartolome" , "dime@ietf.org list" Thread-Topic: [Dime] DOIC: Self-Contained OLRs Thread-Index: AQHO67/t2PaAGa/GgUyaCwjRxXVUh5o5m/0AgAC8o/D///ghgIAAFu+wgAGHVQCAACqasIAAMwWAgANxipCAAKJuAIAATHjQgAAM5ICAABPPEIAAFwqAgAAGBICAAAUigIAAJC3wgAEbsUCAAAYOAIAAGIwQ Date: Tue, 3 Dec 2013 10:45:49 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519C2D8@DEMUMBX014.nsn-intra.net> References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D90006681519BC90@DEMUMBX014.nsn-intra.net> <6390_1385631044_52970D44_6390_18593_1_6B7134B31289DC4FAF731D844122B36E30748E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BD19@DEMUMBX014.nsn-intra.net> <17872_1385720008_529868C8_17872_2613_1_6B7134B31289DC4FAF731D844122B36E3096B8@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BF1B@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681519BFAE@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681519C017@DEMUMBX014.nsn-intra.net> , <5BCBA1FC2B7F0B4C9D935572D90006681519C087@DEMUMBX014.nsn-intra.net> <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> In-Reply-To: <4225_1386065078_529DACB6_4225_280_1_6B7134B31289DC4FAF731D844122B36E3128C0@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: 29003 X-purgate-ID: 151667::1386067550-00006154-1295A2F8/0-0/0-0 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 10:46:01 -0000 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=20 -----Original Message----- From: ext lionel.morand@orange.com [mailto:lionel.morand@orange.com]=20 Sent: Tuesday, December 03, 2013 11:05 AM To: Wiehe, Ulrich (NSN - DE/Munich); ext Maria Cruz Bartolome; dime@ietf.or= g 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 prohib= it 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 an= swer. Regards, Lionel=20 -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN= - DE/Munich) Envoy=E9=A0: mardi 3 d=E9cembre 2013 10:21 =C0=A0: ext Maria Cruz Bartolome; dime@ietf.org list Objet=A0: 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 retu= rns a host-type OLR to C (via A) and there is no need for A to insert a rea= lm-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 Destinat= ion Host in which case any realm-type OLR inserted by A would be useless to= C.=20 Similarly In figure 5 when C sends a request without Destination Host, A ma= y 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 rece= ived 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 Barto= lome 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 no= rmal behavior. But I agree in case the request is towards a Destination Host, receiving th= e 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 no= de 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 t= he 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 o= n the need for the Report-Type. > =20 > 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 De= stination-Host is not in the answer. So receiving a host-based OLR in respo= nse 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 pos= itive 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" of= fered 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 th= e client could include a destination-host or not. So the client needs to kn= ow which reduction to apply from a previous answer. > =20 > 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 co= ntext based on the type of request. > =20 > Regards, > =20 > Lionel > =20 > =20 > De : Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Envoy=E9 : lundi 2=20 > d=E9cembre 2013 14:58 =C0 : Wiehe, Ulrich (NSN - DE/Munich) Cc :=20 > dime@ietf.org list; ext Jouni Korhonen; MORAND Lionel IMT/OLN; Ben=20 > Campbell Objet : RE: [Dime] DOIC: Self-Contained OLRs > =20 > Ulrich, >=20 > 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? >=20 > I would prefer to derive the context of the OLR based on the message whic= h contains the OLR. >=20 > Back to the topic of this thread, I don't think we need to define an "opt= ional" optimization at this stage. Either it is respected by all the nodes = supporting the solution or we drop that optimization. >=20 > Regards, > Nirav. >=20 > On Dec 2, 2013 5:27 PM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: > Nirav, >=20 > If the reacting node sends a request without Destination Host, a realm-ty= pe OLR in the answer would be in-context whereas a host-type OLR in the ans= wer would be out of context. >=20 > Similarly, if the reacting node sends a request containing Destination Ho= st, a realm-type OLR in the answer would be out-of-context and a host-type = OLR in the answer would be in-context. >=20 > Ulrich >=20 >=20 >=20 > -----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=20 > Jouni Korhonen; Ben Campbell > Cc: dime@ietf.org list > Subject: RE: [Dime] DOIC: Self-Contained OLRs >=20 > Ulrich, >=20 > I have a basic question. >=20 > When the reacting node sends realm-routed request and it receives (only o= ne) OLR in the response message (which also contains the origin-host), is t= his OLR applicable for realm or host? > I am trying to understand which is out-of-context OLR here: realm-type or= host-type? >=20 > Regards, > Nirav. >=20 > -----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=20 > Korhonen; Ben Campbell > Cc: dime@ietf.org list > Subject: RE: [Dime] DOIC: Self-Contained OLRs >=20 > Hi Nirav, >=20 > please see inline. >=20 > Regards > Ulrich >=20 > -----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=20 > Jouni Korhonen; Ben Campbell > Cc: dime@ietf.org list > Subject: RE: [Dime] DOIC: Self-Contained OLRs >=20 > Ulrich, >=20 > When the client sends request containing destination-realm (and not conta= ining 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 thi= s response message is not out-of-context information.=20 > [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= =3Dx1, destination realm =3Dx2 application=3D 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, w= hat the type x was. E.g. it deduces from the value of Origin Realm in the a= nswer the value of Destination Realm in the request; it deduces from the va= lue of Report-Type in the answer whether Destination Host was present in th= e request... >=20 > On the other hand, we discussed - as part of Maria Cruz's alternative sol= ution - to define the response message's context based on the request messa= ge. And hence if the request message was sent to destination-realm, the cor= responding 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 unneces= sary complexity.=20 > [Wiehe, Ulrich (NSN - DE/Munich)] I agree. This means: the report-type AV= P is needed to let the client deduce from information received in the answe= r whether the request contained a destination host. It does not mean that w= e need two OLRs in one answer. >=20 > If we strictly want to ensure that the realm-type OLR is not sent=20 > out-of-context [Wiehe, Ulrich (NSN - DE/Munich)] That was not my=20 > proposal. My proposal was to clearly mark out-of-context OLRs in=20 > answer messages (if we allow including out-of-context OLRs) >=20 > , then we should agree to Lionel's alternative solution - to send realm-t= ype OLR only when the destination-realm based request is rejected. So basic= ally, 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 ensu= re the context of the response message and the OLR it contains). >=20 > 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 on= e 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=20 > (NSN - DE/Munich)] only the out-of-context one >=20 > , then what is the point of including two OLRs [Wiehe, Ulrich (NSN - DE/M= unich)] 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 a= s 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 react= ing node (if the reacting node wants to make use of this optimization). >=20 > and what is the point of defining Report-Type AVP? > [Wiehe, Ulrich (NSN - DE/Munich)] to let the reacting node deduce from in= formation received in the answer whether the corresponding request containe= d a destination host (so there is no need to remember). >=20 >=20 > In summary, if we define Report-Type AVP and corresponding handling at th= e reacting node, the reacting node must act accordingly and not ignore it. > [Wiehe, Ulrich (NSN - DE/Munich)] What goes wrong when out-of -context O= LR is ignored? >=20 > 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 i= gnored. > [Wiehe, Ulrich (NSN - DE/Munich)] Not the Report-Type AVP is the optimiza= tion but the incusion of out-of-context OLRs. And I'm ok not to proceed wit= h this optimization as it is not needed. >=20 > Regards, > Nirav. >=20 > -----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=20 > Korhonen; Ben Campbell > Cc: dime@ietf.org list > Subject: RE: [Dime] DOIC: Self-Contained OLRs >=20 > Hi Nirav, >=20 > 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-contex= t. > There is nothing wrong with storing such out-of-context OLRs at the clien= t, but it is simply not needed as the client will learn this OLR from respo= nses received within the context. >=20 > Best regards > Ulrich >=20 >=20 > -----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=20 > Jouni Korhonen; Ben Campbell > Cc: dime@ietf.org list > Subject: RE: [Dime] DOIC: Self-Contained OLRs >=20 > Hi Ulrich, >=20 > If an additional OLR is present with a different ReportType, why it shoul= d be ignored by the reacting node? >=20 > Regards, > Nirav. >=20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich=20 > (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 >=20 > Hi Lionel, >=20 > there is nothing missing exept the clarification that everything works fi= ne 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. >=20 > Ulrich > =20 >=20 > -----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 >=20 > Hi Ulrich, >=20 > Using the Report Type "host report", you know that the OLR applies for su= bsequent 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.=20 >=20 > It is not so important to know what the type of request was and which nod= e 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, f= or instance, future development could allow a distributed server architectu= re to provide the same information. >=20 > I'm not sure of what is missing in this reasoning... >=20 > Lionel >=20 > -----Message d'origine----- > De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 > Envoy=E9 : jeudi 28 novembre 2013 11:30 =C0 : MORAND Lionel IMT/OLN; ext= =20 > Jouni Korhonen; Ben Campbell Cc : dime@ietf.org list Objet : RE:=20 > [Dime] DOIC: Self-Contained OLRs >=20 > Lionel, >=20 > my understanding was that _the_ reporting end point provides _the_ OLR. >=20 > If we go for two OLRs in the answer we should indicate which OLR is the a= ctual OLR created by the reporting end point and which OLR is an additional= OLR created by another node. >=20 > We have two cases: > a) The request sent by the client (reacting end point) contains no Destin= ation 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 OL= R as learned from the selected server. The client may ignore the additiona= l OLR. > b) The request sent by the client (reacting endpoint) contains the Destin= ation Host. The Server (reporting node) returns a host-type OLR as the actu= al reporting-node-created OLR in the answer. The agent may optionally inser= t a realm-type OLR as additional OLR to the answer. The client may ignore t= he additional OLR. >=20 > Ulrich >=20 >=20 >=20 > -----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 >=20 > Hi, >=20 > There is no assumption on which entity is providing the realm overload st= atus. 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 s= ome 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 ser= ver itself, one for the realm for new request sent to the realm with only D= est-Realm AVP. >=20 > Lionel >=20 > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich=20 > (NSN - DE/Munich) Envoy=E9 : jeudi 28 novembre 2013 10:26 =C0 : ext Jouni= =20 > Korhonen; Ben Campbell Cc : dime@ietf.org list Objet : Re: [Dime]=20 > DOIC: Self-Contained OLRs >=20 > Hi, >=20 > 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 i= ndicates 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 indicate= s to the reacting end point that the reporting end point is a server. How c= an the reporting end point be both agent and server? >=20 > Ulrich >=20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Jouni=20 > Korhonen > Sent: Wednesday, November 27, 2013 11:44 PM > To: Ben Campbell > Cc: dime@ietf.org list > Subject: Re: [Dime] DOIC: Self-Contained OLRs >=20 >=20 > On Nov 28, 2013, at 12:27 AM, Ben Campbell wrote: >=20 > > Hi, > >=20 > > I mentioned in another thread that I prefer putting an explicit=20 > > ReportType AVP in an OLR, rather than >=20 > The more I spent time thinking/writing the actual procedures on the endpo= ints, the more it makes sense to me to keep the ReportType in the OC-OLR. E= ven if the baseline does not have agent overload etc, the ReportType fits w= ell 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 pl= ain more clear. >=20 > I skip the rest of the mail.. too much text ;-) >=20 >=20 > - Jouni >=20 >=20 >=20 >=20 >=20 > > making a responding node infer the type or meaning of the OLR from a Di= ameter request that corresponds to the answer containing the OLR. My reason= s for that go beyond just ReportType, so I'm starting a separate thread. > >=20 > > 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 t= hat carries the OLR. For example, the OLR implicitly refers to the applicat= ion identified by the Application-Id field of the enclosing answer, the rea= lm 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 mea= ning in the context of the enclosing answer. If you moved an OLR from one a= nswer to another, it's meaning may change completely. > >=20 > > I think this approach is a mistake. I would greatly prefer that we expl= icitly include such values in the OLR itself, for multiple reasons: > >=20 > > 1) It's more complex to interpret implicit, contextual values than expl= icit values. The consumer cannot simply look at the OLR; it must look in va= rious other AVPs to find all the information it needs. For example, I think= a common software design for overload control processing to be separated f= rom 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 OL= R, 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 "c= ontext" avps that must be interpreted can grow large. This approach is erro= r prone, and will likely encourage brittle, hard-to-maintain code. Self-con= tained OLRs would keep all the information related to overload in one place= . making for simpler implementations. > >=20 > > 2) It's more complex for the reporting node to send implicit values tha= n explicit values. The sender cannot simply set the context to match the OL= R--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 ins= ert OLRs into answers created by other nodes.=20 > >=20 > > If the reporting node screws this up, the meaning of the OLR may change= significantly. So again, implicit meaning gives us error prone implementat= ions. Self-contained OLRs are simpler to create and send. > >=20 > > 3) Implicit values don't work at all for certain problems. For=20 > > example, if an agent needs to originate an OLR, it typically needs=20 > > to insert that OLR into an existing Diameter answer created by a server= . > > It can't create its own answer without affecting the application=20 > > state. If the responding node assumes the OLR comes from or refers=20 > > to the node identified by the Origin-Host AVP in the enclosing=20 > > answer, things break. (For examples of when an agent needs to send=20 > > OLRs that are distinct from those sent by a server, see Steve's=20 > > agent overload draft, or my dh/dr example.) > >=20 > > OTOH, explicit values will work for all cases where we need to associat= e some arbitrary value with an OLR. > >=20 > > 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 ov= erload 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 trans= ported, this won't work. We would have to create a new or significantly mod= ified OLR format if we found a need to transport OLRs in different ways. Se= lf-contained OLRs would allow much greater flexibility. > >=20 > > 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. > >=20 > > Thanks! > >=20 > > Ben. > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime >=20 > _______________________________________________ > 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 >=20 > ______________________________________________________________________ > ___________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc pas etre diffuses, exploites o= u copies sans autorisation. Si vous avez recu ce message par erreur, veuill= ez 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= . >=20 > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; they should not be distributed, us= ed or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 >=20 > ______________________________________________________________________ > ___________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc pas etre diffuses, exploites o= u copies sans autorisation. Si vous avez recu ce message par erreur, veuill= ez 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= . >=20 > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; they should not be distributed, us= ed or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > ______________________________________________________________________ > ___________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not be d= istributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 _______________________________________________ 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 confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. From lionel.morand@orange.com Tue Dec 3 02:51:39 2013 Return-Path: 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 556C41ADFA0 for ; Tue, 3 Dec 2013 02:51:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 E2QXdOpONtZk for ; Tue, 3 Dec 2013 02:51:34 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by ietfa.amsl.com (Postfix) with ESMTP id 684C21AE101 for ; Tue, 3 Dec 2013 02:51:33 -0800 (PST) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id 053C21B833C; Tue, 3 Dec 2013 11:51:30 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id D9AA5C8069; Tue, 3 Dec 2013 11:51:29 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0158.001; Tue, 3 Dec 2013 11:51:29 +0100 From: To: "Wiehe, Ulrich (NSN - DE/Munich)" , "ext Maria Cruz Bartolome" , "dime@ietf.org list" Thread-Topic: [Dime] DOIC: Self-Contained OLRs Thread-Index: AQHO67/to7y6FFeeaEmQ38aKczpYQJo5m/0AgAC8o/D///ghgIAAFu+wgAGHVQCAACqasIAAMwWAgANxipCAAKJuAIAATHjQgAAM5ICAABPPEIAAFwqAgAAGBICAAAUigIAAJC3wgAEbsUCAAAYOAIAAGIwQgAAEJ9A= Date: Tue, 3 Dec 2013 10:51:28 +0000 Message-ID: <21357_1386067889_529DB7B1_21357_3212_1_6B7134B31289DC4FAF731D844122B36E312A07@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D90006681519BC90@DEMUMBX014.nsn-intra.net> <6390_1385631044_52970D44_6390_18593_1_6B7134B31289DC4FAF731D844122B36E30748E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BD19@DEMUMBX014.nsn-intra.net> <17872_1385720008_529868C8_17872_2613_1_6B7134B31289DC4FAF731D844122B36E3096B8@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BF1B@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681519BFAE@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681519C017@DEMUMBX014.nsn-intra.net> , <5BCBA1FC2B7F0B4C9D935572D90006681519C087@DEMUMBX014.nsn-intra.net> <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> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681519C2D8@DEMUMBX014.nsn-intra.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.12.2.94815 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 10:51:39 -0000 Hi Ulrich, I don't see the complexity if each OLR instance received is clearly disting= uished by the Report-Type.=20 Again, it is not said that it will be mandated for any deployment to rely o= n multiple OLR instances.=20 Regards, Lionel -----Message d'origine----- De=A0: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 Envoy=E9=A0: mardi 3 d=E9cembre 2013 11:46 =C0=A0: MORAND Lionel IMT/OLN; ext Maria Cruz Bartolome; dime@ietf.org list Objet=A0: 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=20 -----Original Message----- From: ext lionel.morand@orange.com [mailto:lionel.morand@orange.com]=20 Sent: Tuesday, December 03, 2013 11:05 AM To: Wiehe, Ulrich (NSN - DE/Munich); ext Maria Cruz Bartolome; dime@ietf.or= g 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 prohib= it 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 an= swer. Regards, Lionel=20 -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN= - DE/Munich) Envoy=E9=A0: mardi 3 d=E9cembre 2013 10:21 =C0=A0: ext Maria Cruz Bartolome; dime@ietf.org list Objet=A0: 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 retu= rns a host-type OLR to C (via A) and there is no need for A to insert a rea= lm-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 Destinat= ion Host in which case any realm-type OLR inserted by A would be useless to= C.=20 Similarly In figure 5 when C sends a request without Destination Host, A ma= y 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 rece= ived 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 Barto= lome 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 no= rmal behavior. But I agree in case the request is towards a Destination Host, receiving th= e 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 no= de 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 t= he 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 o= n the need for the Report-Type. >=20=20 > 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 De= stination-Host is not in the answer. So receiving a host-based OLR in respo= nse 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 pos= itive 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" of= fered 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 th= e client could include a destination-host or not. So the client needs to kn= ow which reduction to apply from a previous answer. >=20=20 > 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 co= ntext based on the type of request. >=20=20 > Regards, >=20=20 > Lionel >=20=20 >=20=20 > De : Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Envoy=E9 : lundi 2=20 > d=E9cembre 2013 14:58 =C0 : Wiehe, Ulrich (NSN - DE/Munich) Cc :=20 > dime@ietf.org list; ext Jouni Korhonen; MORAND Lionel IMT/OLN; Ben=20 > Campbell Objet : RE: [Dime] DOIC: Self-Contained OLRs >=20=20 > Ulrich, >=20 > 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? >=20 > I would prefer to derive the context of the OLR based on the message whic= h contains the OLR. >=20 > Back to the topic of this thread, I don't think we need to define an "opt= ional" optimization at this stage. Either it is respected by all the nodes = supporting the solution or we drop that optimization. >=20 > Regards, > Nirav. >=20 > On Dec 2, 2013 5:27 PM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: > Nirav, >=20 > If the reacting node sends a request without Destination Host, a realm-ty= pe OLR in the answer would be in-context whereas a host-type OLR in the ans= wer would be out of context. >=20 > Similarly, if the reacting node sends a request containing Destination Ho= st, a realm-type OLR in the answer would be out-of-context and a host-type = OLR in the answer would be in-context. >=20 > Ulrich >=20 >=20 >=20 > -----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=20 > Jouni Korhonen; Ben Campbell > Cc: dime@ietf.org list > Subject: RE: [Dime] DOIC: Self-Contained OLRs >=20 > Ulrich, >=20 > I have a basic question. >=20 > When the reacting node sends realm-routed request and it receives (only o= ne) OLR in the response message (which also contains the origin-host), is t= his OLR applicable for realm or host? > I am trying to understand which is out-of-context OLR here: realm-type or= host-type? >=20 > Regards, > Nirav. >=20 > -----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=20 > Korhonen; Ben Campbell > Cc: dime@ietf.org list > Subject: RE: [Dime] DOIC: Self-Contained OLRs >=20 > Hi Nirav, >=20 > please see inline. >=20 > Regards > Ulrich >=20 > -----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=20 > Jouni Korhonen; Ben Campbell > Cc: dime@ietf.org list > Subject: RE: [Dime] DOIC: Self-Contained OLRs >=20 > Ulrich, >=20 > When the client sends request containing destination-realm (and not conta= ining 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 thi= s response message is not out-of-context information.=20 > [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= =3Dx1, destination realm =3Dx2 application=3D 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, w= hat the type x was. E.g. it deduces from the value of Origin Realm in the a= nswer the value of Destination Realm in the request; it deduces from the va= lue of Report-Type in the answer whether Destination Host was present in th= e request... >=20 > On the other hand, we discussed - as part of Maria Cruz's alternative sol= ution - to define the response message's context based on the request messa= ge. And hence if the request message was sent to destination-realm, the cor= responding 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 unneces= sary complexity.=20 > [Wiehe, Ulrich (NSN - DE/Munich)] I agree. This means: the report-type AV= P is needed to let the client deduce from information received in the answe= r whether the request contained a destination host. It does not mean that w= e need two OLRs in one answer. >=20 > If we strictly want to ensure that the realm-type OLR is not sent=20 > out-of-context [Wiehe, Ulrich (NSN - DE/Munich)] That was not my=20 > proposal. My proposal was to clearly mark out-of-context OLRs in=20 > answer messages (if we allow including out-of-context OLRs) >=20 > , then we should agree to Lionel's alternative solution - to send realm-t= ype OLR only when the destination-realm based request is rejected. So basic= ally, 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 ensu= re the context of the response message and the OLR it contains). >=20 > 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 on= e 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=20 > (NSN - DE/Munich)] only the out-of-context one >=20 > , then what is the point of including two OLRs [Wiehe, Ulrich (NSN - DE/M= unich)] 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 a= s 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 react= ing node (if the reacting node wants to make use of this optimization). >=20 > and what is the point of defining Report-Type AVP? > [Wiehe, Ulrich (NSN - DE/Munich)] to let the reacting node deduce from in= formation received in the answer whether the corresponding request containe= d a destination host (so there is no need to remember). >=20 >=20 > In summary, if we define Report-Type AVP and corresponding handling at th= e reacting node, the reacting node must act accordingly and not ignore it. > [Wiehe, Ulrich (NSN - DE/Munich)] What goes wrong when out-of -context O= LR is ignored? >=20 > 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 i= gnored. > [Wiehe, Ulrich (NSN - DE/Munich)] Not the Report-Type AVP is the optimiza= tion but the incusion of out-of-context OLRs. And I'm ok not to proceed wit= h this optimization as it is not needed. >=20 > Regards, > Nirav. >=20 > -----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=20 > Korhonen; Ben Campbell > Cc: dime@ietf.org list > Subject: RE: [Dime] DOIC: Self-Contained OLRs >=20 > Hi Nirav, >=20 > 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-contex= t. > There is nothing wrong with storing such out-of-context OLRs at the clien= t, but it is simply not needed as the client will learn this OLR from respo= nses received within the context. >=20 > Best regards > Ulrich >=20 >=20 > -----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=20 > Jouni Korhonen; Ben Campbell > Cc: dime@ietf.org list > Subject: RE: [Dime] DOIC: Self-Contained OLRs >=20 > Hi Ulrich, >=20 > If an additional OLR is present with a different ReportType, why it shoul= d be ignored by the reacting node? >=20 > Regards, > Nirav. >=20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich=20 > (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 >=20 > Hi Lionel, >=20 > there is nothing missing exept the clarification that everything works fi= ne 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. >=20 > Ulrich >=20=20 >=20 > -----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 >=20 > Hi Ulrich, >=20 > Using the Report Type "host report", you know that the OLR applies for su= bsequent 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.=20 >=20 > It is not so important to know what the type of request was and which nod= e 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, f= or instance, future development could allow a distributed server architectu= re to provide the same information. >=20 > I'm not sure of what is missing in this reasoning... >=20 > Lionel >=20 > -----Message d'origine----- > De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 > Envoy=E9 : jeudi 28 novembre 2013 11:30 =C0 : MORAND Lionel IMT/OLN; ext= =20 > Jouni Korhonen; Ben Campbell Cc : dime@ietf.org list Objet : RE:=20 > [Dime] DOIC: Self-Contained OLRs >=20 > Lionel, >=20 > my understanding was that _the_ reporting end point provides _the_ OLR. >=20 > If we go for two OLRs in the answer we should indicate which OLR is the a= ctual OLR created by the reporting end point and which OLR is an additional= OLR created by another node. >=20 > We have two cases: > a) The request sent by the client (reacting end point) contains no Destin= ation 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 OL= R as learned from the selected server. The client may ignore the additiona= l OLR. > b) The request sent by the client (reacting endpoint) contains the Destin= ation Host. The Server (reporting node) returns a host-type OLR as the actu= al reporting-node-created OLR in the answer. The agent may optionally inser= t a realm-type OLR as additional OLR to the answer. The client may ignore t= he additional OLR. >=20 > Ulrich >=20 >=20 >=20 > -----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 >=20 > Hi, >=20 > There is no assumption on which entity is providing the realm overload st= atus. 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 s= ome 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 ser= ver itself, one for the realm for new request sent to the realm with only D= est-Realm AVP. >=20 > Lionel >=20 > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich=20 > (NSN - DE/Munich) Envoy=E9 : jeudi 28 novembre 2013 10:26 =C0 : ext Jouni= =20 > Korhonen; Ben Campbell Cc : dime@ietf.org list Objet : Re: [Dime]=20 > DOIC: Self-Contained OLRs >=20 > Hi, >=20 > 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 i= ndicates 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 indicate= s to the reacting end point that the reporting end point is a server. How c= an the reporting end point be both agent and server? >=20 > Ulrich >=20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Jouni=20 > Korhonen > Sent: Wednesday, November 27, 2013 11:44 PM > To: Ben Campbell > Cc: dime@ietf.org list > Subject: Re: [Dime] DOIC: Self-Contained OLRs >=20 >=20 > On Nov 28, 2013, at 12:27 AM, Ben Campbell wrote: >=20 > > Hi, > >=20 > > I mentioned in another thread that I prefer putting an explicit=20 > > ReportType AVP in an OLR, rather than >=20 > The more I spent time thinking/writing the actual procedures on the endpo= ints, the more it makes sense to me to keep the ReportType in the OC-OLR. E= ven if the baseline does not have agent overload etc, the ReportType fits w= ell 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 pl= ain more clear. >=20 > I skip the rest of the mail.. too much text ;-) >=20 >=20 > - Jouni >=20 >=20 >=20 >=20 >=20 > > making a responding node infer the type or meaning of the OLR from a Di= ameter request that corresponds to the answer containing the OLR. My reason= s for that go beyond just ReportType, so I'm starting a separate thread. > >=20 > > 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 t= hat carries the OLR. For example, the OLR implicitly refers to the applicat= ion identified by the Application-Id field of the enclosing answer, the rea= lm 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 mea= ning in the context of the enclosing answer. If you moved an OLR from one a= nswer to another, it's meaning may change completely. > >=20 > > I think this approach is a mistake. I would greatly prefer that we expl= icitly include such values in the OLR itself, for multiple reasons: > >=20 > > 1) It's more complex to interpret implicit, contextual values than expl= icit values. The consumer cannot simply look at the OLR; it must look in va= rious other AVPs to find all the information it needs. For example, I think= a common software design for overload control processing to be separated f= rom 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 OL= R, 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 "c= ontext" avps that must be interpreted can grow large. This approach is erro= r prone, and will likely encourage brittle, hard-to-maintain code. Self-con= tained OLRs would keep all the information related to overload in one place= . making for simpler implementations. > >=20 > > 2) It's more complex for the reporting node to send implicit values tha= n explicit values. The sender cannot simply set the context to match the OL= R--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 ins= ert OLRs into answers created by other nodes.=20 > >=20 > > If the reporting node screws this up, the meaning of the OLR may change= significantly. So again, implicit meaning gives us error prone implementat= ions. Self-contained OLRs are simpler to create and send. > >=20 > > 3) Implicit values don't work at all for certain problems. For=20 > > example, if an agent needs to originate an OLR, it typically needs=20 > > to insert that OLR into an existing Diameter answer created by a server. > > It can't create its own answer without affecting the application=20 > > state. If the responding node assumes the OLR comes from or refers=20 > > to the node identified by the Origin-Host AVP in the enclosing=20 > > answer, things break. (For examples of when an agent needs to send=20 > > OLRs that are distinct from those sent by a server, see Steve's=20 > > agent overload draft, or my dh/dr example.) > >=20 > > OTOH, explicit values will work for all cases where we need to associat= e some arbitrary value with an OLR. > >=20 > > 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 ov= erload 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 trans= ported, this won't work. We would have to create a new or significantly mod= ified OLR format if we found a need to transport OLRs in different ways. Se= lf-contained OLRs would allow much greater flexibility. > >=20 > > 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. > >=20 > > Thanks! > >=20 > > Ben. > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime >=20 > _______________________________________________ > 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 >=20 > ______________________________________________________________________ > ___________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc pas etre diffuses, exploites o= u copies sans autorisation. Si vous avez recu ce message par erreur, veuill= ez 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. >=20 > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; they should not be distributed, us= ed or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 >=20 > ______________________________________________________________________ > ___________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc pas etre diffuses, exploites o= u copies sans autorisation. Si vous avez recu ce message par erreur, veuill= ez 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. >=20 > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; they should not be distributed, us= ed or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > ______________________________________________________________________ > ___________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not be d= istributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 _______________________________________________ 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 confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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 confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. From jouni.nospam@gmail.com Tue Dec 3 02:58:51 2013 Return-Path: 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 143C61AE0C5 for ; Tue, 3 Dec 2013 02:58:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 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, FREEMAIL_REPLY=1, SPF_PASS=-0.001] autolearn=no 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 3G9k1xR3BWsk for ; Tue, 3 Dec 2013 02:58:49 -0800 (PST) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 951EF1AE0A0 for ; Tue, 3 Dec 2013 02:58:48 -0800 (PST) Received: by mail-la0-f51.google.com with SMTP id ec20so8903755lab.38 for ; Tue, 03 Dec 2013 02:58:45 -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=ypt/NiigVt5tXU7dhQAJwZUmHynD/w9SLilsslLsHUU=; b=ifvCFf1PS0PdB9jq2aAi8/H6pzA3lNuP+QNLC3b9VTKNJh64zkwSkCu17hsAS2sMzJ PWgaWjajyXYAqW7fc3KlxCB22xk/0m9l0kE9FmVw7JxUMN9xCQUR6wWdnPmEYaBmX2FK c2noOIgUVWOjWSGsCrMpzu2CWO57i9XbEXFwIbkIdhTXGpeoPnSdVsV9v9ZDjQDM80Jy 9UhXILE4g1wpGKv4PxY/4KsKZ1ZCd4KL2y/V2NCv4VN2eW8OVawR9LwRQRkhaY9IaG8r 0+q9E6o1BR+vc4nZZik3oKaJBc1pGczkX/gpuU1Yr7HdZkOpByWGv2e/Vx6Ms8/LtEW2 T6/Q== X-Received: by 10.112.182.72 with SMTP id ec8mr30410lbc.75.1386068325166; Tue, 03 Dec 2013 02:58:45 -0800 (PST) Received: from [192.168.250.149] ([194.100.71.98]) by mx.google.com with ESMTPSA id mx3sm1802242lbc.14.2013.12.03.02.58.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Dec 2013 02:58:42 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <10558_1386067228_529DB51C_10558_2647_1_6B7134B31289DC4FAF731D844122B36E3129AA@PEXCVZYM13.corporate.adroot.infra.ftgroup> Date: Tue, 3 Dec 2013 12:58:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5BCBA1FC2B7F0B4C9D935572D90006681519C296@DEMUMBX014.nsn-intra.net> <10558_1386067228_529DB51C_10558_2647_1_6B7134B31289DC4FAF731D844122B36E3129AA@PEXCVZYM13.corporate.adroot.infra.ftgroup> To: lionel.morand@orange.com X-Mailer: Apple Mail (2.1510) Cc: "dime@ietf.org" Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same type) within a response message X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 10:58:51 -0000 On Dec 3, 2013, at 12:40 PM, lionel.morand@orange.com wrote: > Nirav, > =20 > If there are more than one OLR of the same type in the same answer, = based on what I understood from the examples given below, the client = will have to figure out which reduction to apply only based on extra = AVPs received in the OLRs. I'm not so sure that it is something = advisable from a standard point of view. Agree.. the implementation then needs to go into weird heuristics based = on the presence of different AVPs for the same OC-Report-Type. I have = hard time seeing how that would be better than having explicitly = specified report types where the handling of AVPs is known. Interop = across vendors would at least be easier to achieve. The text I wrote into -01 last week does not allow OLRs with the same = report type..=20 - Jouni > =20 > Regards, > =20 > Lionel > =20 > De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich = (NSN - DE/Munich) > Envoy=E9 : mardi 3 d=E9cembre 2013 10:48 > =C0 : ext Nirav Salot (nsalot); Maria Cruz Bartolome; dime@ietf.org > Objet : Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same = type) within a response message > =20 > Nirav, > =20 > I still do not see the need for more than one OLR in an answer. > =20 > More than one OLR means more complexity. Let=92s try to avoid that. > =20 > The server gets a request that either is or is not in the narrower = scope. If it is not, why shoud the server return an OLR for the narrower = scope? It can do so when it gets a request within the narrower scope = (which possibly never happens). > =20 > Ulrich > =20 > =20 > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Nirav Salot = (nsalot) > Sent: Tuesday, December 03, 2013 10:26 AM > To: Maria Cruz Bartolome; dime@ietf.org > Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same = type) within a response message > =20 > Maria-Cruz, > =20 > > we may think that we need two different OLRs with ReportType=3Dhost, = and one of them includes the extra info (AVPs) required for that = application > Yes. The above is my concern. I tried giving APN as one example AVP = which we may want to include in OC-OLR. Let me give another possible = example. > As of now, the OC-OLR can indicate application + host/realm level = "required-reduction-percentage". > However, for the given application (e.g. Gx) we may want to define a = narrower scope with "session-type =3D {M2M, Others}" AVP. So basically, = the Gx nodes can advertise different "required-reduction-percentage" for = M2M sessions v/s other type of sessions for the same application Gx and = for the same destination-host. > =20 > So in general, if any application needs to define a different (i.e. = narrower) scope than application + host/realm, it can do so by adding a = new AVP in OC-OLR. > And then we might have two instances of OC-OLR from the same host. > =20 > We could achieve the above by defining new Report-Type for each new = AVP added by each application. But would this scale or is this a = reasonable approach? > I am not sure and you have already identified one of my concerns below > > if we extend ReportType, does it need to be done by IETF, or could = it be done per application by 3GPP? > =20 > In summary, in my view, we need to define the handling of multiple = instances with the same Report-Type as part of the DOIC draft. Or we say = that multiple instances with the same Report-Type is not allowed =96 = this seems unnecessary restriction to me. > Otherwise, if later, we realize the need to do so then we may not be = able to do so since the handling is not defined in the base solution. > =20 > Regards, > Nirav. > =20 > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Maria Cruz = Bartolome > Sent: Tuesday, December 03, 2013 1:57 PM > To: dime@ietf.org > Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same = type) within a response message > =20 > Nirav, > =20 > I think I understand your concern. It may occur that we need that a = reacting node should apply two different OLR when sending a request = towards one specific host. > Then, we may think that we need two different OLRs with = ReportType=3Dhost, and one of them includes the extra info (AVPs) = required for that application, I think this is your interpretation, but=85= we can as well consider a new ReportType=3DapplicX_ReportY, that may = apply e.g. for any request send to this application, or just for this = application+host, and then Host could be another AVP to be included in = the OLR, or we could define expected behaviour when defining this new = ReportType. > =20 > Would this cover your concerns? If not, could you try to provide an = example that requires two OLR with ReportType=3Dhost? > =20 > A part from that, a question for all, if we extend ReportType, does it = need to be done by IETF, or could it be done per application by 3GPP? > =20 > Thanks > /MCruz > =20 > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Nirav Salot = (nsalot) > Sent: jueves, 28 de noviembre de 2013 17:11 > To: lionel.morand@orange.com > Cc: dime@ietf.org > Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same = type) within a response message > =20 > Hi Lionel, > =20 > I am not sure if defining new ReportType for every new AVP 3GPP would = add for a specific application would be a good solution. > I thought ReportType would indicate if the corresponding OC-OLR should = be used while sending the traffic towards the host or towards the realm. > So from that point of view, all the OC-OLR generated by the server = should have ReportType=3Dhost. i.e. when the reacting node sends the = traffic towards that host, it should make use of the corresponding = OC-OLR. Now, this OC-OLR may contain the AVPs defined by DOIC draft as = well as 3GPP application specific AVPs. > =20 > In general, I was just thinking that it may be good idea to define = some of the principles such as > - More than one instances of OC-OLR with ReportType=3Dhost = may be present in the answer message if the OC-OLR definition is = extended by the application using the same. In that case, it is the = responsibility of the application to define the valid combination of = OC-OLR instances in a given message > - If the reporting node includes more than one instance of = OC-OLR, the reporting node shall always include all the active instances = of OC-OLR in a response message. > - When the reacting node receives one or more instances of = OC-OLR with the given ReportType and with new timestamp value, it should = overwrite all the existing OC-OLR of the same ReportType. > =20 > Regards, > Nirav. > =20 > From: lionel.morand@orange.com [mailto:lionel.morand@orange.com]=20 > Sent: Thursday, November 28, 2013 7:39 PM > To: Nirav Salot (nsalot) > Cc: dime@ietf.org > Subject: RE: DOIC: Multiple instance of OC-OLR AVP (of the same type) = within a response message > =20 > Hi Nirav, > =20 > The Report Type should be able to differentiate such cases. In your = example, I would define a specific Report type. > But difficult to appraise all the future use cases. But for me, the = main use of the report type is to differentiate OC-OLR received in the = same message. > And it is the reasons of my recommendation. Actually, the exact = wording will be a "SHOULD" saying that it is recommended but you may = have serious reasons to do otherwise. > =20 > Lionel > =20 > De : Nirav Salot (nsalot) [mailto:nsalot@cisco.com]=20 > Envoy=E9 : jeudi 28 novembre 2013 13:00 > =C0 : MORAND Lionel IMT/OLN > Cc : dime@ietf.org > Objet : RE: DOIC: Multiple instance of OC-OLR AVP (of the same type) = within a response message > =20 > Lionel, >=20 > 3gpp may define an optional avp which can be included by the reporting = node if it wishes to do so. E.g. APN can be additionally included by the = reporting node to indicate APN specific overload within the given = application. > In that case, the reporting node may also want to indicate application = level overload without including the APN (e.g. this overload report is = applicable to all other APNs). >=20 > And hence there is a possibility of including multiple instances of = the overload report. >=20 > I am not suggesting that 3gpp will define APN (or any other avp) = within overload report. But later, if 3gpp need to define the same, then = corresponding handling needs to be defined within IETF now. >=20 > Regards, > Nirav. >=20 > On Nov 28, 2013 3:56 PM, "lionel.morand@orange.com" = wrote: > Hi Nirav, > =20 > Not sure to understand the proposal or question. > The OLR is significant per application (piggybacking principle). So if = the 3GPP decides to add specific AVPs in the OLR (that will be = possible), what would be the need to add the OLR without the specific = 3GPP AVPs as the OLR will be anyway handle by 3GPP aware entities? > =20 > Lionel > =20 > De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot = (nsalot) > Envoy=E9 : jeudi 28 novembre 2013 10:33 > =C0 : dime@ietf.org > Objet : [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same = type) within a response message > =20 > Hi, > =20 > As I understand IETF will define the base overload control solution as = part of DOIC. Then 3GPP would adopt the defined solution for each of its = application. > When that happens, 3GPP might want to add 3GPP specific AVP within = OC-OLR AVP. Based on the current definition of the OC-OLR AVP this = should be allowed since it contains "* [AVP]" in its definition. > e.g. for a given application 3GPP decides to add information into = OC-OLR which changes the scope of the OC-OLR from application level to = the provided information level. > Additionally, the reporting may want to advertise the OC-OLR at the = application level scope =96 i.e. the OC-OLR without any 3GPP specific = info. > =20 > So if the above is allowed, we will have the possibility of the = reporting node wanting to include two instances of OC-OLR with the = Report-Type=3D"host". > And then we need to define the handling of multiple instances of = OC-OLR in the DOIC draft. > =20 > So the questions are, > - Is 3GPP (or any other SDO) allowed to extend the definition = of OC-OLR by adding information into it? > - If no, can we guarantee that application level scope of = OC-OLR (which is what we have defined currently) is sufficient (and not = restricting) to all the applications of 3GPP? > =20 > Regards, > Nirav. > =20 > = __________________________________________________________________________= _______________________________________________ > =20 > 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. > =20 > 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. > = __________________________________________________________________________= _______________________________________________ > =20 > 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. > =20 > 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. > = __________________________________________________________________________= _______________________________________________ >=20 > 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. >=20 > 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. >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From jouni.nospam@gmail.com Tue Dec 3 03:10:06 2013 Return-Path: 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 A905A1AE10A for ; Tue, 3 Dec 2013 03:10:06 -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 0thFlTmHaA0b for ; Tue, 3 Dec 2013 03:10:04 -0800 (PST) Received: from mail-bk0-x231.google.com (mail-bk0-x231.google.com [IPv6:2a00:1450:4008:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 55D131AE08D for ; Tue, 3 Dec 2013 03:10:04 -0800 (PST) Received: by mail-bk0-f49.google.com with SMTP id my13so5903356bkb.22 for ; Tue, 03 Dec 2013 03:10:01 -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=5AU9ybOTh41qGup+Cq9XQHCCadZIfn22t8W8rIhp4T8=; b=jWKb0lipgGDyHcrzj7Yx1KIf8k87HwNL3AbIofV4icaIBgKa7ldQiVaBLDrGzkD1I2 yPBl8dkU1JnQ+0/LAM+M48yLUcmSiV++UFjeJad8/In7cyyAjvhHRx+tUcpQ7jH6G79r qE5/PPXAv2oYhr6yuIWIlgr2QG+DgfIzNegVc5nXmejSla3304hVu+aBcwtMxrc/ZDJT fuuIfCgp7Rv6mQZjQTow2yqf4eWRuTWdRS7tPsdNfk4ANZdPmrIMwEAaVpI1DeCFw8/Y +4BMuJVJyUZwkd60x/ZN+Cnuc0wf8bmwQtq7UsaOdu2xK/c/qgaVNnurH5nJho3VQ1FY 5pOA== X-Received: by 10.204.168.142 with SMTP id u14mr35929bky.187.1386069001068; Tue, 03 Dec 2013 03:10:01 -0800 (PST) Received: from ?IPv6:2001:6e8:480:60:8140:b30:4238:2452? ([2001:6e8:480:60:8140:b30:4238:2452]) by mx.google.com with ESMTPSA id l5sm33078396bko.7.2013.12.03.03.09.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Dec 2013 03:09:58 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <087A34937E64E74E848732CFF8354B920972BE76@ESESSMB101.ericsson.se> Date: Tue, 3 Dec 2013 13:09:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6E1A8DB2-A029-4FEE-ACF4-F5731E3D31EC@gmail.com> References: <087A34937E64E74E848732CFF8354B920972BE0C@ESESSMB101.ericsson.se> <14D4A644-96B1-4B0F-892E-B969922C94D3@gmail.com> <087A34937E64E74E848732CFF8354B920972BE76@ESESSMB101.ericsson.se> To: Maria Cruz Bartolome X-Mailer: Apple Mail (2.1510) Cc: "dime@ietf.org" Subject: Re: [Dime] OLR applicable for any/all applications X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 11:10:06 -0000 We had an attempt to have applications other than the piggybacked from the very beginning. That was also ruled out. What has changed since? - Jouni On Dec 3, 2013, at 11:34 AM, Maria Cruz Bartolome = wrote: > Not exactly. > It was opposition to duplicate information. >=20 > Cheers > /MCruz >=20 > -----Original Message----- > From: Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20 > Sent: martes, 03 de diciembre de 2013 10:26 > To: Maria Cruz Bartolome > Cc: dime@ietf.org > Subject: Re: [Dime] OLR applicable for any/all applications >=20 >=20 > Hmm.. wasn't there just recently rather strong opposition to include = anything beyond "implicit" information into the OLR? >=20 > - Jouni >=20 >=20 > On Dec 3, 2013, at 10:42 AM, Maria Cruz Bartolome = wrote: >=20 >>=20 >> Dear all, >>=20 >> There may be a need by a reporting node to request traffic reduction = for all traffic, application independent, e.g. if an operator's network = becomes severely overloaded, it may be of interest to signal directly = general overload to the client. =20 >>=20 >> In this case, since reacting node obtains affected application from = the application message, we may need to extend OLR. >>=20 >> At least we got following options: >>=20 >>=20 >> A) Define a new optional AVP that could be included into OLR, = like e.g.: >> OC-OLR ::=3D < AVP Header: TBD2 > >> < TimeStamp > >> [ Reduction-Percentage ] >> [ ValidityDuration ] >> [ ReportType ] >> [All applications] >> * [ AVP ] >>=20 >>=20 >> B) Extend ReportTypes like e.g.: >>=20 >> 3 Destination-Host All Applications report. Similar to = Destination-Host report but it would apply to any application regardless = the application message this report is received within. >>=20 >> 4 Realm (aggregated) All Applications report. Similar to Realm = report but it would apply to any application regardless the application = message this report is received within. >>=20 >>=20 >>=20 >> I tend to prefer option A, but let me know your opinions and = preferences. >> Best regards >> /MCruz >>=20 >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From maria.cruz.bartolome@ericsson.com Tue Dec 3 03:19:33 2013 Return-Path: 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 42AC61AE04E for ; Tue, 3 Dec 2013 03:19:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 ZB-WCvX8vmXS for ; Tue, 3 Dec 2013 03:19:29 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 130321AE0A0 for ; Tue, 3 Dec 2013 03:19:27 -0800 (PST) X-AuditID: c1b4fb25-b7eff8e000000eda-67-529dbe3cde7e Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 70.D5.03802.C3EBD925; Tue, 3 Dec 2013 12:19:24 +0100 (CET) Received: from ESESSMB101.ericsson.se ([169.254.1.118]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.02.0347.000; Tue, 3 Dec 2013 12:19:24 +0100 From: Maria Cruz Bartolome To: "dime@ietf.org" Thread-Topic: Ongoing Throttling Information in request messages Thread-Index: Ac7aQPqQ1tyE3SNOTC+vVrUogwBrJQAnWH+wAADoRNAABgE0oAAA57DwAACoAlAAASWEQAAAqKUAACDdWeAAAz9GUAABLecQAA4Qc8ABE6PKsABJVfJQASwtPKACh2J2UA== Date: Tue, 3 Dec 2013 11:19:23 +0000 Message-ID: <087A34937E64E74E848732CFF8354B920972BF81@ESESSMB101.ericsson.se> References: <5BCBA1FC2B7F0B4C9D935572D9000668151918EC@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D900066815192B2B@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D900066815192B90@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D900066815192BF7@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D900066815192CD2@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D900066815192D5F@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681519337D@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D900066815193EFD@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D900066815193EFD@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.19] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGLMWRmVeSWpSXmKPExsUyM+Jvra7NvrlBBudbzS3m9q5gc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxuqvX5gK5h5nrLh6eQ5LA+OPxYxdjJwcEgImEtcu7GWBsMUk Ltxbz9bFyMUhJHCIUaJ71UomCGcxo8Sjrx+YQKrYBOwkLp1+AWRzcIgIKEuc/uUAEhYWsJdY 2n6JGSLsIDF5szJIWERgEqPEku/BIGEWARWJy2vFQUxeAV+JSY/9IIb3cUjMPbIH7BxOgQCJ gwtvgdmMQOd8P7UGbCmzgLjErSfzmSDOFJBYsuc8M4QtKvHy8T9WCFtRov1pAyNEvZ7EjalT 2CBsbYllC1+D1fMKCEqcnPmEZQKj6CwkY2chaZmFpGUWkpYFjCyrGNlzEzNz0suNNjECw/7g lt+qOxjvnBM5xCjNwaIkzvvhrXOQkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBkbd0JzCI0Km /o/zfeMcNpgWmu78vWXa5fDOmeenVp2ca/1r146ca89kz3fW3bm61D1qRqe4/IlE2fe7tLLc GjMkyo8qSi01XquzQuvIkmtnNzFl26kWxzA+cX5duqOuI4Zr7mzZJZosbE3WR3boen0LnbfQ lm/P/Ftsr1fpiv8L4uHI6JeMmafEUpyRaKjFXFScCAD2yxm/SQIAAA== Subject: Re: [Dime] Ongoing Throttling Information in request messages X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 11:19:33 -0000 Hello, See some comments below Best regards /MCruz -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN -= DE/Munich) Sent: mi=E9rcoles, 20 de noviembre de 2013 16:25 To: ext Nirav Salot (nsalot); dime@ietf.org Subject: Re: [Dime] Ongoing Throttling Information in request messages Nirav, thank you for your confirmation. In order to select the best solution let me try to start a comparism: 1) A1 can be compared with B1 as both require to insert an AVP in every mes= sage (answer/request, while overloaded/while performing throttling): A1 add= s (resource consuming) functionality to the (overloaded) server/reporting n= ode while B1 adds to the client/reacting node. Furthermore, the AVP to be i= nserted in A1 (OC-OLR) is the only OC-specific AVP to be inserted to the an= swer whereas the AVP to be inserted in B1 (OC-Ongoing-Throttling-Informatio= n) would be in addition to the OC-Feature-Vector which anyway needs to be a= dded to every request (inserting OC specific info to requests is needed any= way). Furthermore A1 seems to violate REQ 13 from RFC 7068 while B1 does no= t. All this clearly is a pro for option B. 2) A2 can be compared with B2: A2 either requires additional processing at = the server/reporting node or relies on timouts (violating REQ 10) while B2 = does not require any corresponding functionality. This is also a pro for Op= tion B. [MCruz] Violation of REQ10 I think may be subject to interpretation (I woul= d think the requirement text could be improved though...). Then, for this c= omparison I am not sure this is a key factor. 3) A3 can be compared with B3 as both recommend to check the presence of ne= w OC-specific info in all received messages: A3 adds the recommended functi= onality to the (overloaded) server/reporting node while B3 adds to the clie= nt/reacting node. This is a pro for option A. [MCruz] I presume you meant " _B3_ adds the recommended functionality to th= e (overloaded) server/reporting node while _A3_ adds to the client/reacting= node Here we can question whether option B violates REQ13 from RFC7068 while A d= oes not. Then, key question is to compare how much work implies each option= to an overloaded server. Not easy to get a conclusion since it could depen= d a lot on implementation. 4) Option B adds a feedback channel from client to server making the soluti= on more robust.=20 [MCruz] More robust? In which sense? It also allows the server to give some priority to already throttled traffi= c (see REQ 18) and it allows agents to ensure that already throttled traffi= c (by a downstream node) is not throttled again. This is a pro for option B= . [MCruz] In my opinion this is the best advantage of solution B over A. But,= we need to highlight as well that if server needs (e.g.) to throttle traff= ic that is not being throttled, then this helps to fulfill REQ-18, but it i= s against REQ13. Then, if we need to fulfill REQ13 as much as possible, the= n this advantage vanishes. 5) In Option A it is not clear how the client/reacting node should behave w= hen it receives an answer without OC-OLR AVP while performing throttling. T= his is a con for option A. In summary my preference is for option B. Comments are welcome. Ulrich -----Original Message----- From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com]=20 Sent: Thursday, November 14, 2013 3:54 PM To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Ulrich, I confirm the summary below of having two valid options. Just wanted to highlight one aspect, in general. Current definition of the OC-OLR AVP suggest the inclusion of TimeStamp and= ValidityDuration AVPs. And these AVPs are applicable/valid/needed in both = the options below. Additionally, if we decide to go for option B, we would need to define new = AVP OC-Ongoing-Throttling-Information AVP. Regards, Nirav. -----Original Message----- From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 Sent: Wednesday, November 13, 2013 9:03 PM To: Nirav Salot (nsalot); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Nirav, in summary it seems that we have two valid options: Option A:=20 A1: the server (or reporting node), while overloaded must insert the load O= C-OLR AVP in every answer message. A2: the server (or reporting node) after leaving the overload state must co= ntinue inserting the OC-OLR AVP (indicating end of throttling request) for = some time (how long needs to be calculated by the server) or the server mus= t rely on expiry of outdated overload reports. A3: the reacting node must/should check the timeStamp in every OC-OLR AVP r= eceived in answer messages in order not to miss an update. Option B: B1: the reacting node, while performing throttling, must insert the OC-Ongo= ing-Throttling-Information in every request message. B2: void (the reacting node , while no longer throttling, simply does not i= nsert OC-Ongoing-Throttling-Information) B3: the reporting node must/should check OC-Ongoing-Throttling-Information = received in a request in order to decide whether or not OC-OLR must be sent= back.=20 Ulrich -----Original Message----- From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com]=20 Sent: Thursday, November 07, 2013 5:29 PM To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Ulrich, Not sure the significance of REQ 10 here but I do not agree to enforce the = server to include overload-report (indicating non-zero or zero overload con= dition) in every message. Even in your example, the overload condition will end sometime - e.g. after= 1000 sec. and then the server can stop including the overload-report. Besides, I am still not convince that "during the overload condition, using= some logic to avoid inclusion of overload-report is less resource consumin= g than simply including the same overload-report". Yes, the reason behind defining timestamp is to allow the reacting node to = discard the overload-report if the same was already received from the repor= ting node. Regards, Nirav. -----Original Message----- From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 Sent: Thursday, November 07, 2013 3:53 PM To: Nirav Salot (nsalot); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Nirav, please see inline. Best regards Ulrich -----Original Message----- From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Sent: Thursday, November 07, 2013 10:15 AM To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Ulrich, Please read my responses inline. Regards, Nirav. -----Original Message----- From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Sent: Thursday, November 07, 2013 1:54 PM To: Nirav Salot (nsalot); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Nirav, thank you for the explanation. This may be a solution which adds more comp= lexity to the reporting node: The reporting node must remember the maximum = not yet expired fraction of duration values it sent when leaving the overlo= ad state and must continue reporting "end of overload condition" until expi= ry. (there is no corresponding complexity at the reacting node in my propos= al) [Nirav] This is not always true, e.g. as I had indicated if the node ha= s advertised 10% reduction-percentage for 10 sec., it need not bother to ad= vertise no-overload condition since the validity-period was very small. [Ulrich] Also not always true, e.g. if the reporting node has requested at = 20% reduction for 1000sec at t1 and then at t1 + 10sec sends an update to r= equest a 10% reduction for 10 sec. Although the validity-period is small (1= 0 sec) there may still be a reacting node that did not get the update and k= eeps on throttling by 20% until t1 + 1000sec. Furthermore you seem not to t= ake REQ 10 seriously. My understanding was that timeout is last resort, not= the normal way. Another question: While doing a throttling, what is the expected behaviour = of the reacting node when receiving an answer message without OC-OLR AVP? (= stop/continue throttling?) (there is no corresponding question in my propos= al since not sending of OC-Ongoing-Throttling-Information clearly means tha= t throttling is not in place) [Nirav] The reacting node should continue to = apply the earlier received OC-OLR.=20 " (Note: We seem to have consensus that a server MAY repeat OLRs in subsequent messages, but is not required to do so, based on local policy.)" [Ulrich] This needs to be reconsidered. See the following example: Non supporting client C1 sends a request via supporting agent A1 to Server = S. S returns a 10% throttling request.=20 C sends an new request via supporting agent A2 to S.=20 S decides not to repeat the 10% throttling request (hence A2 is not aware o= f the throttling request).=20 C1 sends a new request via A1.=20 S decides to repeat the throttling request (redundant).=20 Supporting client C2 sends a request via A2 to S. S decides not to repeat.... To avoid this mess we either need to mandate sending OC-OLR in every answer= (while in overload) or let the Server keep track which agent and which cli= ent is updated with the newest info. (or consider my proposal). Another question is for the reacting node: What is the expected behaviour w= hen receiving lots of redundant OC-OLR AVPs in answer messages? The reactin= g node needs to check every single OC-OLR AVP in order to find out whether = it contains an update. Is that the correct understanding? (this seems to be= equivalent to checking for redundant OC-Ongoing-Throttling-Information AVP= s in every request by the reporting node in my proposal) [Nirav] Please ref= er to Timestamp AVP within OC-OLR. The TimeStamp AVP indicates when the original OC-OLR AVP with the current content was created. It is possible to replay the same OC- OLR AVP multiple times between the overload endpoints, however, when the OC-OLR AVP content changes or the other information sending endpoint wants the receiving endpoint to update its overload control information, then the TimeStamp AVP MUST contain a new value. [Ulrich] This does not explicitly say that the reacting node must check eve= ry TimeStamp received within OC-OLR AVPs. But I guess this is the consequen= ce. Can you please confirm. Adding dime-list again. Ulrich From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Sent: Wednesday, November 06, 2013 4:58 PM To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org Subject: RE: Ongoing Throttling Information in request messages Ulrich, During "no overload condition", why should reporting node include overload-= information in all the answer messages? e.g. if the reporting node has advertised overload-report with period-of-va= lidity=3D10 sec., it knows that after that period all the reacting node wil= l automatically stop applying any overload mitigation action. And hence it = does not need to explicitly send any overload-report indicating "no overloa= d condition". In general, I assume that overload period of would be much shorter as compa= red to "no overload" period. And hence I do not see reason to always includ= e overload-report. Regards, Nirav. From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Sent: Wednesday, November 06, 2013 9:12 PM To: Nirav Salot (nsalot); doc-dt@ietf.org Subject: RE: Ongoing Throttling Information in request messages Nirav, "During the overload" yes I agree, but "when no longer in overload" all ans= wer messages would contain the information "no longer in overload" while on= ly few request messages would contain the Ongoing-Throttling-Information. Removing dime-list which bounces. Best regards Ulrich From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Sent: Wednesday, November 06, 2013 4:02 PM To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Ulrich, I might be missing something here so please bear with me. Number of answer messages sent by server =3D number of request messages rec= eived by the server. During the overload, the server would receive only those requests which sur= vived throttling. And then the server would send answer messages to only those request messag= es. So "every" and "some" are actually equal in the below equation. No? Regards, Nirav. From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Sent: Wednesday, November 06, 2013 8:24 PM To: Nirav Salot (nsalot); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Nirav, Not quite. The question is: "is sending an overload-report in every answer message that corresponds to = request with OC-Feature-Vector present more resource consuming than receivi= ng Ongoing-Throttling-Information in some request messages (only those that= survived a throttling)?" Best regards Ulrich From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Sent: Wednesday, November 06, 2013 3:15 PM To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Ulrich, Thanks for clarification. Then the question would be "is sending overload-report in every answer message is more resource consum= ing than the solution below - i.e. receiving OC-Ongoing-Throttling-Informat= ion in all request message and analyzing the timestamp and then deciding if= the overload-report should be included or not." I am not sure. Regards, Nirav. From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Sent: Wednesday, November 06, 2013 7:08 PM To: Nirav Salot (nsalot); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Nirav, thank you for your comments. The comparism is between: Current way: "send OC specific information (Feature-Vector) in every reques= t message and in every corresponding answer message" My proposal: "send OC specific information (Feature-Vector and in some case= s Ongoing-Throttling-Info) in every request message and in corresponding an= swer messages only when required". Sending OC specific information =A0is regarded a resource consuming action = and we should not put this action to the (overloaded) server where avoidabl= e. See REQ 13. Best regards Ulrich From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Sent: Wednesday, November 06, 2013 12:04 PM To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Ulrich, Thanks for the detail explanation of your proposal. Just to verify my understanding, Your proposal would allow the reporting node to avoid inclusion of the "sam= e" overload-report in the answer message since the request message indicate= s that the path contains at least one reacting node which already has the l= atest overload-report. In other words, the reporting node need not include overload-report in ever= y message, blindly. To achieve the above objective, the solution below suggest the reacting nod= e to include new AVP OC-Ongoing-Throttling-Information in every request mes= sage, which survives throttling. So the net result is that, the inclusion of the overload-report is prevente= d in every answer message since the OC-Ongoing-Throttling-Information is in= cluded in every request message. [Wiehe, Ulrich (NSN - DE/Munich)] no.=A0 .in every request message that sur= vived a throttling. And hence I am not sure if the solution has sound benefit from the inclusio= n of redundant information point of view. In summary, I think the solution suggested below works as explained. But I fail to see the benefit of using this solution compare to a solution = in which the reporting node includes overload-report in every answer messag= e. Regards, Nirav. From: doc-dt-bounces@ietf.org [mailto:doc-dt-bounces@ietf.org] On Behalf Of= Wiehe, Ulrich (NSN - DE/Munich) Sent: Tuesday, November 05, 2013 9:36 PM To: doc-dt@ietf.org; dime@ietf.org Subject: [doc-dt] Ongoing Throttling Information in request messages Hi, draft-docdt-dime-ovli-01 in Appendix B, Table 1, REQ 13 says: =A0=A0=A0=A0=A0=A0=A0 .. Another way =A0=A0=A0=A0=A0=A0=A0 is to let the request sender (reacting node) insert =A0=A0=A0=A0=A0=A0=A0 information in the request to say whether a =A0=A0=A0=A0=A0=A0=A0 throttling is actually performed.=A0 The reporting no= de =A0=A0=A0=A0=A0=A0=A0 then can base its decision on information received in =A0=A0=A0=A0=A0=A0=A0 the request; no need for keeping state to record who =A0 has received overload reports.=A0=20 =A0 And in Appendix B, Table 1, REQ 18: =A0=A0=A0=A0=A0=A0=A0 There has been a proposal to mark =A0=A0=A0=A0=A0=A0=A0 messages that survived overload throttling as one =A0=A0=A0=A0=A0=A0=A0 method for an overloaded node to address fairness but =A0=A0=A0=A0=A0=A0=A0 this proposal is not yet part of the solution.=A0=20 =A0 I would like to come back to this proposal.=20 A new AVP OC-Ongoing-Throttling-Information inserted in request messages wo= uld indicate that the request message survived a throttling. Furthermore, i= nformation within the AVP indicates the TimeStamp as received in the previo= us OC-OLR AVP, according to which the ongoing throttling (which was survive= d) is performed. =A0 OC-Ongoing-Throttling-Information ::=3D < AVP Header: TBD9 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 < TimeStamp > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * [ AVP ] =A0 Supporting Clients would insert the OC-Ongoing-Throttling-Information AVP= =A0 into request messages that survived a throttling performed at that clie= nt. Supporting Agents when receiving a request message that contains an OC-Ongo= ing-Throttling-Information AVP would not perform an additional throttling (= since the client or a downstream agent already performed the throttling) , = while, when receiving a request that does not contain OC-Ongoing-Throttling= -Information AVP would perform throttling (on behalf of the client) accordi= ng to a previously received and stored OC-OLR, and if that throttling is su= rvived the agent would insert the OC-Ongoing-Throttling-Information AVP in = the request before sending it further upstream. Servers (or in general reporting nodes) would check presence and content of= the OC-Ongoing-Throttling-Information AVP in received request messages and= could detect (together with a check of presence of OC-Feature-Vector AVP) = whether inserting an OC-OLR AVP in the corresponding answer message is need= ed in order to update the reacting node with a new OC-OLR). =A0 This proposal especially addresses use cases like the following: =A0 Architecture: =A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +-------= ---------+ =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | suppor= ting=A0=A0=A0=A0 | =A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 /| agent A1= =A0=A0=A0=A0=A0=A0 |\ =A0 +----------------+ / +----------------+ \ =A0 | non supporting |/=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 \ =A0 | client C=A0=A0=A0=A0=A0=A0 |\=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 \ =A0 +----------------+ \ +----------------+=A0=A0=A0 \ +------------+=A0=A0= =A0 +---------+ =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 \| non supp= orting |=A0=A0=A0=A0 \| supporting | =A0=A0 | Server=A0 | =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 age= nt A2=A0=A0=A0=A0=A0 |------| agent A3=A0=A0 |----|=A0 S=A0=A0=A0=A0=A0 | =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0 +------------= ----+=A0=A0=A0=A0=A0 +------------+=A0=A0=A0 +---------+ =A0 1. A request is sent from C via A2 and A3 to S. A3 recognizes that there is= no reacting node downstream (no OC-Feature-Vector received) and therefore = takes the role of the reacting node and inserts an OC-Feature-Vector AVP. A= 3 has no valid OLR from S stored and therefore does not perform throttling = and does not insert an OC-Throttling-Information AVP. 2. S recognizes that there is a reacting node downstream which is actually = not performing a throttling. S returns a 10% throttling request (TimeStamp= =3Dt1, duration=3Dd) within OC-OLR in the answer which goes back via A3 and= A2 to C. 3. A3 stores the 10% throttling request. 4. A new request is sent from C via A2 and A3 to S. A3 recognizes that ther= e is no reacting node downstream (no OC-Feature-Vector received) and theref= ore takes the role of the reacting node and inserts an OC-Feature-Vector AV= P. A3 has=A0 valid OLR from S stored and performs a 10% throttling. The req= uest survives and A3 inserts an OC-Throttling-Information AVP with timeStam= p=3Dt1. 5. S recognizes that correct throttling (correct time stamp) is in place an= d therefore does not return OC-OLR in the answer. 6. A new request is sent from C via A1 and A3 to S. A1 recognizes that ther= e is no reacting node downstream (no OC-Feature-Vector received) and theref= ore takes the role of the reacting node and inserts an OC-Feature-AVP. A1 h= as no valid OLR from S stored and therefore does not perform throttling and= does not insert an OC-Throttling-Information AVP. A3 recognizes that there= is a reacting node downstream (OC-Feature-Vector received) and therefore d= oes not take the role of the reacting node. 7. S recognizes that there is a reacting node downstream which is actually = not performing a throttling. S returns a 10% throttling request (TimeStamp= =3Dt1, duration=3Dd) within OC-OLR in the answer which goes back via A3 and= A1 to C. 8. A1 stores the 10% throttling request. 9. A new request is sent from C via A1 and A3 to S. A1 recognizes that ther= e is no reacting node downstream (no OC-Feature-Vector received) and theref= ore takes the role of the reacting node and inserts an OC-Feature-AVP. A1 h= as=A0 valid OLR from S stored and therefore performs a 10% throttling. The = request survives and A1 inserts an OC-Throttling-Information AVP with timeS= tamp=3Dt1. A3 recognizes that there is a reacting node downstream (OC-Featu= re-Vector received) and therefore does not take the role of the reacting no= de. 10. S recognizes that correct throttling (correct time stamp) is in place a= nd therefore does not return OC-OLR in the answer. 11. Requests sent from C via A1 and A3 to S undergo a 10% throttling at A1,= requests sent from C via A2 and A3 to S undergo a 10% throttling at A3. 12. Overload situation in S for some reason gets worse, S decides to reques= t 20 % reduction. 13. A new request is sent from C via A1 and A3 to S. A1 recognizes that the= re is no reacting node downstream (no OC-Feature-Vector received) and there= fore takes the role of the reacting node and inserts an OC-Feature-AVP. A1 = has=A0 valid OLR from S stored and therefore performs a 10% throttling. The= request survives and A1 inserts an OC-Throttling-Information AVP with time= Stamp=3Dt1. A3 recognizes that there is a reacting node downstream (OC-Feat= ure-Vector received) and therefore does not take the role of the reacting n= ode. 14. S recognizes that incorrect throttling (wrong time stamp) is in place a= nd therefore S returns a 20% throttling request (TimeStamp=3Dt2, duration= =3Dx) within OC-OLR in the answer which goes back via A3 and A1 to C. 15. A3 (not taking the role of the reactingt node)may, A1 must store the 20= % throttling request (replacing the 10% request). 16. A new request is sent from C via A2 and A3 to S. A3 recognizes that the= re is no reacting node downstream (no OC-Feature-Vector received) and there= fore takes the role of the reacting node and inserts an OC-Feature-Vector A= VP. A3 has=A0 valid OLR from S stored and performs a 10% throttling. The re= quest survives and A3 inserts an OC-Throttling-Information AVP with timeSta= mp=3Dt1. (assuming A3 did not store the 20% request at step 14) 17. S recog= nizes that incorrect throttling (wrong time stamp) is in place and therefor= e S returns a 20% throttling request (TimeStamp=3Dt2, duration=3Dx) within = OC-OLR in the answer which goes back via A3 and A2 to C. 18. A3 stores the 20% throttling request (replacing the 10% request). 19. Requests sent from C via A1 and A3 to S undergo a 20% throttling at A1,= requests sent from C via A2 and A3 to S undergo a 20% throttling at A3. =A0 =A0 Comments are welcome. =A0 Best regards Ulrich =A0 =A0 _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From lionel.morand@orange.com Tue Dec 3 03:20:35 2013 Return-Path: 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 5DB5A1AE0A0 for ; Tue, 3 Dec 2013 03:20:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 8dkEqyywkDNZ for ; Tue, 3 Dec 2013 03:20:30 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id 206781AE100 for ; Tue, 3 Dec 2013 03:20:29 -0800 (PST) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id DC3E53B42E3; Tue, 3 Dec 2013 12:20:26 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id B1EF2158062; Tue, 3 Dec 2013 12:20:26 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0158.001; Tue, 3 Dec 2013 12:20:26 +0100 From: To: "Nirav Salot (nsalot)" , Maria Cruz Bartolome , "dime@ietf.org" Thread-Topic: OLR applicable for any/all applications Thread-Index: Ac7wA2nX03YOMS5NT1qqOpqV4/v8iQAB0nIQAAOh7+A= Date: Tue, 3 Dec 2013 11:20:25 +0000 Message-ID: <23791_1386069626_529DBE7A_23791_980_1_6B7134B31289DC4FAF731D844122B36E312AF4@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <087A34937E64E74E848732CFF8354B920972BE0C@ESESSMB101.ericsson.se> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.5] Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E312AF4PEXCVZYM13corpora_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.19.63615 Subject: Re: [Dime] OLR applicable for any/all applications X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 11:20:35 -0000 --_000_6B7134B31289DC4FAF731D844122B36E312AF4PEXCVZYM13corpora_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Maria-Cruz, I agree with Nirav's comment: No need of such optimization. OLR is per appl= ication and if more than one application is used between nodes, the OLR wil= l be received on the application related answers. Regards, Lionel De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot (nsalot) Envoy=E9 : mardi 3 d=E9cembre 2013 10:41 =C0 : Maria Cruz Bartolome; dime@ietf.org Objet : Re: [Dime] OLR applicable for any/all applications Maria-Cruz, The existing OC-OLR definition (without "All Application" AVP) already addr= esses your use case. E.g. reporting node includes same value of "Reduction= -Percentage" in all the application messages sent by it. So we don't need "= All Application" AVP additionally. Besides, reporting "Reduction-Percentage" of a different application violat= es the basic principle of the piggybacking. Finally, in 3GPP (as far as I remember) we do not have any use case of two = nodes interfacing with each other over more than one application. i.e. we h= ave only one application between any pair of nodes and if that is so then I= fail to see the practicality of the use case you have mentioned below. Regards, Nirav. From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Maria Cruz Bartolome Sent: Tuesday, December 03, 2013 2:13 PM To: dime@ietf.org Subject: [Dime] OLR applicable for any/all applications Dear all, There may be a need by a reporting node to request traffic reduction for al= l traffic, application independent, e.g. if an operator's network becomes s= everely overloaded, it may be of interest to signal directly general overlo= ad to the client. In this case, since reacting node obtains affected application from the app= lication message, we may need to extend OLR. At least we got following options: A) Define a new optional AVP that could be included into OLR, like e.g.: OC-OLR ::=3D < AVP Header: TBD2 > < TimeStamp > [ Reduction-Percentage ] [ ValidityDuration ] [ ReportType ] [All applications] * [ AVP ] B) Extend ReportTypes like e.g.: 3 Destination-Host All Applications report. Similar to Destination-Hos= t report but it would apply to any application regardless the application m= essage this report is received within. 4 Realm (aggregated) All Applications report. Similar to Realm report = but it would apply to any application regardless the application message th= is report is received within. I tend to prefer option A, but let me know your opinions and preferences. Best regards /MCruz ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. --_000_6B7134B31289DC4FAF731D844122B36E312AF4PEXCVZYM13corpora_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Maria-Cruz,

 

I agree= with Nirav's comment: No need of such optimization. OLR is per application= and if more than one application is used between nodes, the OLR will be re= ceived on the application related answers.

&n= bsp;

Regards= ,

&n= bsp;

Lionel<= o:p>

&n= bsp;

De : DiME= [mailto:dime-bounces@ietf.org] De la part de Nirav Salot (nsalot)
Envoy=E9 : mardi 3 d=E9cembre 2013 10:41
=C0 : Maria Cruz Bartolome; dime@ietf.org
Objet : Re: [Dime] OLR applicable for any/all applications=

 

Maria-C= ruz,

&n= bsp;

The exi= sting OC-OLR definition (without "All Application" AVP) already a= ddresses your use case. E.g. reporting  node includes same value of &q= uot;Reduction-Percentage" in all the application messages sent by it. So we don’t need "All Application" AVP additio= nally.

Besides= , reporting "Reduction-Percentage" of a different application vio= lates the basic principle of the piggybacking.

Finally= , in 3GPP (as far as I remember) we do not have any use case of two nodes i= nterfacing with each other over more than one application. i.e. we have onl= y one application between any pair of nodes and if that is so then I fail to see the practicality of the use cas= e you have mentioned below.

&n= bsp;

Regards= ,

Nirav.<= o:p>

&n= bsp;

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Maria Cruz Bartolome
Sent: Tuesday, December 03, 2013 2:13 PM
To: dime@ietf.org
Subject: [Dime] OLR applicable for any/all applications

 

 

Dear all,

 

= There may be a need by a reporting node to request traffic reduction for al= l traffic, application independent, e.g. if an operator’s network bec= omes severely overloaded, it may be of interest to signal directly general overload to the client. 

In this case, since reacting no= de obtains affected application from the application message, we may need t= o extend OLR.

 

At least we got following optio= ns:

 

 

A= )   &= nbsp; Define a new optional AVP that could be included into OLR, like e.g.:

   OC-OLR ::=3D < AVP Header: TBD2 &g=
t;
        &n=
bsp;     < TimeStamp >
        &n=
bsp;     [ Reduction-Percentage ]

        &n=
bsp;     [ ValidityDuration ]


        &n=
bsp;     [ ReportType ]


        &n=
bsp;     [All applications]


        &n=
bsp;   * [ AVP ]


 


 



B=
)   &=
nbsp; 
Extend  ReportTypes like e.g.:


 


   3  Destination-Host
All Applications
report.  Similar to Destination-Host repor=
t but it would apply to any application regardless the application message =
this report is received within.


 


   4  Realm (aggregated)
All Applications repo=
rt.  Similar to Realm report but it would apply to any application
 regardless the application message this report is received within.<=
span lang=3D"EN-US">


 


 


 


I tend to prefer option A, but =
let me know your opinions and preferences.


Best regards<=
/p>

/MCruz


 


 


______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles 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 el=
ectroniques 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 inf=
ormation 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 dele=
te 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.
--_000_6B7134B31289DC4FAF731D844122B36E312AF4PEXCVZYM13corpora_-- From ulrich.wiehe@nsn.com Tue Dec 3 04:21:37 2013 Return-Path: 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 CE61F1ADEA6 for ; Tue, 3 Dec 2013 04:21: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 vC8RbUiHuMop for ; Tue, 3 Dec 2013 04:21:32 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 3E5581AE12D for ; Tue, 3 Dec 2013 04:21:09 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rB3CL3HJ007862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 3 Dec 2013 13:21:03 +0100 Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rB3CL3eA013296 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Dec 2013 13:21:03 +0100 Received: from DEMUHTC011.nsn-intra.net (10.159.42.42) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 3 Dec 2013 13:21:02 +0100 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.152]) by DEMUHTC011.nsn-intra.net ([10.159.42.42]) with mapi id 14.03.0123.003; Tue, 3 Dec 2013 13:21:02 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: ext Maria Cruz Bartolome , "dime@ietf.org" Thread-Topic: Ongoing Throttling Information in request messages Thread-Index: Ac7aQPqQ1tyE3SNOTC+vVrUogwBrJQAnWH+wAADoRNAABgE0oAAA57DwAACoAlAAASWEQAAAqKUAACDdWeAAAz9GUAABLecQAA4Qc8ABE6PKsABJVfJQASwtPKACh2J2UAABYVvw Date: Tue, 3 Dec 2013 12:21:02 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519D35C@DEMUMBX014.nsn-intra.net> References: <5BCBA1FC2B7F0B4C9D935572D9000668151918EC@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D900066815192B2B@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D900066815192B90@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D900066815192BF7@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D900066815192CD2@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D900066815192D5F@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681519337D@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D900066815193EFD@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B920972BF81@ESESSMB101.ericsson.se> In-Reply-To: <087A34937E64E74E848732CFF8354B920972BF81@ESESSMB101.ericsson.se> 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: 26724 X-purgate-ID: 151667::1386073264-000022AE-4B456F14/0-0/0-0 Subject: Re: [Dime] Ongoing Throttling Information in request messages X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 12:21:38 -0000 Hi MCruz, thank you for your comments. What is your interpretation of REQ10? Which interpretation other than "when= overload condition ends at the server, client must be able to detect this"= is reasonable? With regard to robustness (see 4) below): If for any reason (attacker, misconfiguration,...) a wrong throttling is pe= rformed by the client, the server is able to immediately detect and correct= this in option B). With regard to the trade of between REQ18 and REQ13 (see 4) below): Option B allows to leave the decision to implementations (even dynamically)= while option A takes a numb decision against REQ18. Also note that it is n= ot only the (overloaded) server but also the (not at all overloaded) agent = that could fulfill REQ18 without contravening REQ13 in option B. Best regards Ulrich =20 -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto= lome Sent: Tuesday, December 03, 2013 12:19 PM To: dime@ietf.org Subject: Re: [Dime] Ongoing Throttling Information in request messages Hello, See some comments below Best regards /MCruz -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN -= DE/Munich) Sent: mi=E9rcoles, 20 de noviembre de 2013 16:25 To: ext Nirav Salot (nsalot); dime@ietf.org Subject: Re: [Dime] Ongoing Throttling Information in request messages Nirav, thank you for your confirmation. In order to select the best solution let me try to start a comparism: 1) A1 can be compared with B1 as both require to insert an AVP in every mes= sage (answer/request, while overloaded/while performing throttling): A1 add= s (resource consuming) functionality to the (overloaded) server/reporting n= ode while B1 adds to the client/reacting node. Furthermore, the AVP to be i= nserted in A1 (OC-OLR) is the only OC-specific AVP to be inserted to the an= swer whereas the AVP to be inserted in B1 (OC-Ongoing-Throttling-Informatio= n) would be in addition to the OC-Feature-Vector which anyway needs to be a= dded to every request (inserting OC specific info to requests is needed any= way). Furthermore A1 seems to violate REQ 13 from RFC 7068 while B1 does no= t. All this clearly is a pro for option B. 2) A2 can be compared with B2: A2 either requires additional processing at = the server/reporting node or relies on timouts (violating REQ 10) while B2 = does not require any corresponding functionality. This is also a pro for Op= tion B. [MCruz] Violation of REQ10 I think may be subject to interpretation (I woul= d think the requirement text could be improved though...). Then, for this c= omparison I am not sure this is a key factor. 3) A3 can be compared with B3 as both recommend to check the presence of ne= w OC-specific info in all received messages: A3 adds the recommended functi= onality to the (overloaded) server/reporting node while B3 adds to the clie= nt/reacting node. This is a pro for option A. [MCruz] I presume you meant " _B3_ adds the recommended functionality to th= e (overloaded) server/reporting node while _A3_ adds to the client/reacting= node Here we can question whether option B violates REQ13 from RFC7068 while A d= oes not. Then, key question is to compare how much work implies each option= to an overloaded server. Not easy to get a conclusion since it could depen= d a lot on implementation. 4) Option B adds a feedback channel from client to server making the soluti= on more robust.=20 [MCruz] More robust? In which sense? It also allows the server to give some priority to already throttled traffi= c (see REQ 18) and it allows agents to ensure that already throttled traffi= c (by a downstream node) is not throttled again. This is a pro for option B= . [MCruz] In my opinion this is the best advantage of solution B over A. But,= we need to highlight as well that if server needs (e.g.) to throttle traff= ic that is not being throttled, then this helps to fulfill REQ-18, but it i= s against REQ13. Then, if we need to fulfill REQ13 as much as possible, the= n this advantage vanishes. 5) In Option A it is not clear how the client/reacting node should behave w= hen it receives an answer without OC-OLR AVP while performing throttling. T= his is a con for option A. In summary my preference is for option B. Comments are welcome. Ulrich -----Original Message----- From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com]=20 Sent: Thursday, November 14, 2013 3:54 PM To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Ulrich, I confirm the summary below of having two valid options. Just wanted to highlight one aspect, in general. Current definition of the OC-OLR AVP suggest the inclusion of TimeStamp and= ValidityDuration AVPs. And these AVPs are applicable/valid/needed in both = the options below. Additionally, if we decide to go for option B, we would need to define new = AVP OC-Ongoing-Throttling-Information AVP. Regards, Nirav. -----Original Message----- From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 Sent: Wednesday, November 13, 2013 9:03 PM To: Nirav Salot (nsalot); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Nirav, in summary it seems that we have two valid options: Option A:=20 A1: the server (or reporting node), while overloaded must insert the load O= C-OLR AVP in every answer message. A2: the server (or reporting node) after leaving the overload state must co= ntinue inserting the OC-OLR AVP (indicating end of throttling request) for = some time (how long needs to be calculated by the server) or the server mus= t rely on expiry of outdated overload reports. A3: the reacting node must/should check the timeStamp in every OC-OLR AVP r= eceived in answer messages in order not to miss an update. Option B: B1: the reacting node, while performing throttling, must insert the OC-Ongo= ing-Throttling-Information in every request message. B2: void (the reacting node , while no longer throttling, simply does not i= nsert OC-Ongoing-Throttling-Information) B3: the reporting node must/should check OC-Ongoing-Throttling-Information = received in a request in order to decide whether or not OC-OLR must be sent= back.=20 Ulrich -----Original Message----- From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com]=20 Sent: Thursday, November 07, 2013 5:29 PM To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Ulrich, Not sure the significance of REQ 10 here but I do not agree to enforce the = server to include overload-report (indicating non-zero or zero overload con= dition) in every message. Even in your example, the overload condition will end sometime - e.g. after= 1000 sec. and then the server can stop including the overload-report. Besides, I am still not convince that "during the overload condition, using= some logic to avoid inclusion of overload-report is less resource consumin= g than simply including the same overload-report". Yes, the reason behind defining timestamp is to allow the reacting node to = discard the overload-report if the same was already received from the repor= ting node. Regards, Nirav. -----Original Message----- From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 Sent: Thursday, November 07, 2013 3:53 PM To: Nirav Salot (nsalot); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Nirav, please see inline. Best regards Ulrich -----Original Message----- From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Sent: Thursday, November 07, 2013 10:15 AM To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Ulrich, Please read my responses inline. Regards, Nirav. -----Original Message----- From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Sent: Thursday, November 07, 2013 1:54 PM To: Nirav Salot (nsalot); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Nirav, thank you for the explanation. This may be a solution which adds more comp= lexity to the reporting node: The reporting node must remember the maximum = not yet expired fraction of duration values it sent when leaving the overlo= ad state and must continue reporting "end of overload condition" until expi= ry. (there is no corresponding complexity at the reacting node in my propos= al) [Nirav] This is not always true, e.g. as I had indicated if the node ha= s advertised 10% reduction-percentage for 10 sec., it need not bother to ad= vertise no-overload condition since the validity-period was very small. [Ulrich] Also not always true, e.g. if the reporting node has requested at = 20% reduction for 1000sec at t1 and then at t1 + 10sec sends an update to r= equest a 10% reduction for 10 sec. Although the validity-period is small (1= 0 sec) there may still be a reacting node that did not get the update and k= eeps on throttling by 20% until t1 + 1000sec. Furthermore you seem not to t= ake REQ 10 seriously. My understanding was that timeout is last resort, not= the normal way. Another question: While doing a throttling, what is the expected behaviour = of the reacting node when receiving an answer message without OC-OLR AVP? (= stop/continue throttling?) (there is no corresponding question in my propos= al since not sending of OC-Ongoing-Throttling-Information clearly means tha= t throttling is not in place) [Nirav] The reacting node should continue to = apply the earlier received OC-OLR.=20 " (Note: We seem to have consensus that a server MAY repeat OLRs in subsequent messages, but is not required to do so, based on local policy.)" [Ulrich] This needs to be reconsidered. See the following example: Non supporting client C1 sends a request via supporting agent A1 to Server = S. S returns a 10% throttling request.=20 C sends an new request via supporting agent A2 to S.=20 S decides not to repeat the 10% throttling request (hence A2 is not aware o= f the throttling request).=20 C1 sends a new request via A1.=20 S decides to repeat the throttling request (redundant).=20 Supporting client C2 sends a request via A2 to S. S decides not to repeat.... To avoid this mess we either need to mandate sending OC-OLR in every answer= (while in overload) or let the Server keep track which agent and which cli= ent is updated with the newest info. (or consider my proposal). Another question is for the reacting node: What is the expected behaviour w= hen receiving lots of redundant OC-OLR AVPs in answer messages? The reactin= g node needs to check every single OC-OLR AVP in order to find out whether = it contains an update. Is that the correct understanding? (this seems to be= equivalent to checking for redundant OC-Ongoing-Throttling-Information AVP= s in every request by the reporting node in my proposal) [Nirav] Please ref= er to Timestamp AVP within OC-OLR. The TimeStamp AVP indicates when the original OC-OLR AVP with the current content was created. It is possible to replay the same OC- OLR AVP multiple times between the overload endpoints, however, when the OC-OLR AVP content changes or the other information sending endpoint wants the receiving endpoint to update its overload control information, then the TimeStamp AVP MUST contain a new value. [Ulrich] This does not explicitly say that the reacting node must check eve= ry TimeStamp received within OC-OLR AVPs. But I guess this is the consequen= ce. Can you please confirm. Adding dime-list again. Ulrich From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Sent: Wednesday, November 06, 2013 4:58 PM To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org Subject: RE: Ongoing Throttling Information in request messages Ulrich, During "no overload condition", why should reporting node include overload-= information in all the answer messages? e.g. if the reporting node has advertised overload-report with period-of-va= lidity=3D10 sec., it knows that after that period all the reacting node wil= l automatically stop applying any overload mitigation action. And hence it = does not need to explicitly send any overload-report indicating "no overloa= d condition". In general, I assume that overload period of would be much shorter as compa= red to "no overload" period. And hence I do not see reason to always includ= e overload-report. Regards, Nirav. From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Sent: Wednesday, November 06, 2013 9:12 PM To: Nirav Salot (nsalot); doc-dt@ietf.org Subject: RE: Ongoing Throttling Information in request messages Nirav, "During the overload" yes I agree, but "when no longer in overload" all ans= wer messages would contain the information "no longer in overload" while on= ly few request messages would contain the Ongoing-Throttling-Information. Removing dime-list which bounces. Best regards Ulrich From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Sent: Wednesday, November 06, 2013 4:02 PM To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Ulrich, I might be missing something here so please bear with me. Number of answer messages sent by server =3D number of request messages rec= eived by the server. During the overload, the server would receive only those requests which sur= vived throttling. And then the server would send answer messages to only those request messag= es. So "every" and "some" are actually equal in the below equation. No? Regards, Nirav. From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Sent: Wednesday, November 06, 2013 8:24 PM To: Nirav Salot (nsalot); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Nirav, Not quite. The question is: "is sending an overload-report in every answer message that corresponds to = request with OC-Feature-Vector present more resource consuming than receivi= ng Ongoing-Throttling-Information in some request messages (only those that= survived a throttling)?" Best regards Ulrich From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Sent: Wednesday, November 06, 2013 3:15 PM To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Ulrich, Thanks for clarification. Then the question would be "is sending overload-report in every answer message is more resource consum= ing than the solution below - i.e. receiving OC-Ongoing-Throttling-Informat= ion in all request message and analyzing the timestamp and then deciding if= the overload-report should be included or not." I am not sure. Regards, Nirav. From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Sent: Wednesday, November 06, 2013 7:08 PM To: Nirav Salot (nsalot); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Nirav, thank you for your comments. The comparism is between: Current way: "send OC specific information (Feature-Vector) in every reques= t message and in every corresponding answer message" My proposal: "send OC specific information (Feature-Vector and in some case= s Ongoing-Throttling-Info) in every request message and in corresponding an= swer messages only when required". Sending OC specific information =A0is regarded a resource consuming action = and we should not put this action to the (overloaded) server where avoidabl= e. See REQ 13. Best regards Ulrich From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Sent: Wednesday, November 06, 2013 12:04 PM To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Ulrich, Thanks for the detail explanation of your proposal. Just to verify my understanding, Your proposal would allow the reporting node to avoid inclusion of the "sam= e" overload-report in the answer message since the request message indicate= s that the path contains at least one reacting node which already has the l= atest overload-report. In other words, the reporting node need not include overload-report in ever= y message, blindly. To achieve the above objective, the solution below suggest the reacting nod= e to include new AVP OC-Ongoing-Throttling-Information in every request mes= sage, which survives throttling. So the net result is that, the inclusion of the overload-report is prevente= d in every answer message since the OC-Ongoing-Throttling-Information is in= cluded in every request message. [Wiehe, Ulrich (NSN - DE/Munich)] no.=A0 .in every request message that sur= vived a throttling. And hence I am not sure if the solution has sound benefit from the inclusio= n of redundant information point of view. In summary, I think the solution suggested below works as explained. But I fail to see the benefit of using this solution compare to a solution = in which the reporting node includes overload-report in every answer messag= e. Regards, Nirav. From: doc-dt-bounces@ietf.org [mailto:doc-dt-bounces@ietf.org] On Behalf Of= Wiehe, Ulrich (NSN - DE/Munich) Sent: Tuesday, November 05, 2013 9:36 PM To: doc-dt@ietf.org; dime@ietf.org Subject: [doc-dt] Ongoing Throttling Information in request messages Hi, draft-docdt-dime-ovli-01 in Appendix B, Table 1, REQ 13 says: =A0=A0=A0=A0=A0=A0=A0 .. Another way =A0=A0=A0=A0=A0=A0=A0 is to let the request sender (reacting node) insert =A0=A0=A0=A0=A0=A0=A0 information in the request to say whether a =A0=A0=A0=A0=A0=A0=A0 throttling is actually performed.=A0 The reporting no= de =A0=A0=A0=A0=A0=A0=A0 then can base its decision on information received in =A0=A0=A0=A0=A0=A0=A0 the request; no need for keeping state to record who =A0 has received overload reports.=A0=20 =A0 And in Appendix B, Table 1, REQ 18: =A0=A0=A0=A0=A0=A0=A0 There has been a proposal to mark =A0=A0=A0=A0=A0=A0=A0 messages that survived overload throttling as one =A0=A0=A0=A0=A0=A0=A0 method for an overloaded node to address fairness but =A0=A0=A0=A0=A0=A0=A0 this proposal is not yet part of the solution.=A0=20 =A0 I would like to come back to this proposal.=20 A new AVP OC-Ongoing-Throttling-Information inserted in request messages wo= uld indicate that the request message survived a throttling. Furthermore, i= nformation within the AVP indicates the TimeStamp as received in the previo= us OC-OLR AVP, according to which the ongoing throttling (which was survive= d) is performed. =A0 OC-Ongoing-Throttling-Information ::=3D < AVP Header: TBD9 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 < TimeStamp > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * [ AVP ] =A0 Supporting Clients would insert the OC-Ongoing-Throttling-Information AVP= =A0 into request messages that survived a throttling performed at that clie= nt. Supporting Agents when receiving a request message that contains an OC-Ongo= ing-Throttling-Information AVP would not perform an additional throttling (= since the client or a downstream agent already performed the throttling) , = while, when receiving a request that does not contain OC-Ongoing-Throttling= -Information AVP would perform throttling (on behalf of the client) accordi= ng to a previously received and stored OC-OLR, and if that throttling is su= rvived the agent would insert the OC-Ongoing-Throttling-Information AVP in = the request before sending it further upstream. Servers (or in general reporting nodes) would check presence and content of= the OC-Ongoing-Throttling-Information AVP in received request messages and= could detect (together with a check of presence of OC-Feature-Vector AVP) = whether inserting an OC-OLR AVP in the corresponding answer message is need= ed in order to update the reacting node with a new OC-OLR). =A0 This proposal especially addresses use cases like the following: =A0 Architecture: =A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +-------= ---------+ =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | suppor= ting=A0=A0=A0=A0 | =A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 /| agent A1= =A0=A0=A0=A0=A0=A0 |\ =A0 +----------------+ / +----------------+ \ =A0 | non supporting |/=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 \ =A0 | client C=A0=A0=A0=A0=A0=A0 |\=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 \ =A0 +----------------+ \ +----------------+=A0=A0=A0 \ +------------+=A0=A0= =A0 +---------+ =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 \| non supp= orting |=A0=A0=A0=A0 \| supporting | =A0=A0 | Server=A0 | =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 age= nt A2=A0=A0=A0=A0=A0 |------| agent A3=A0=A0 |----|=A0 S=A0=A0=A0=A0=A0 | =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0 +------------= ----+=A0=A0=A0=A0=A0 +------------+=A0=A0=A0 +---------+ =A0 1. A request is sent from C via A2 and A3 to S. A3 recognizes that there is= no reacting node downstream (no OC-Feature-Vector received) and therefore = takes the role of the reacting node and inserts an OC-Feature-Vector AVP. A= 3 has no valid OLR from S stored and therefore does not perform throttling = and does not insert an OC-Throttling-Information AVP. 2. S recognizes that there is a reacting node downstream which is actually = not performing a throttling. S returns a 10% throttling request (TimeStamp= =3Dt1, duration=3Dd) within OC-OLR in the answer which goes back via A3 and= A2 to C. 3. A3 stores the 10% throttling request. 4. A new request is sent from C via A2 and A3 to S. A3 recognizes that ther= e is no reacting node downstream (no OC-Feature-Vector received) and theref= ore takes the role of the reacting node and inserts an OC-Feature-Vector AV= P. A3 has=A0 valid OLR from S stored and performs a 10% throttling. The req= uest survives and A3 inserts an OC-Throttling-Information AVP with timeStam= p=3Dt1. 5. S recognizes that correct throttling (correct time stamp) is in place an= d therefore does not return OC-OLR in the answer. 6. A new request is sent from C via A1 and A3 to S. A1 recognizes that ther= e is no reacting node downstream (no OC-Feature-Vector received) and theref= ore takes the role of the reacting node and inserts an OC-Feature-AVP. A1 h= as no valid OLR from S stored and therefore does not perform throttling and= does not insert an OC-Throttling-Information AVP. A3 recognizes that there= is a reacting node downstream (OC-Feature-Vector received) and therefore d= oes not take the role of the reacting node. 7. S recognizes that there is a reacting node downstream which is actually = not performing a throttling. S returns a 10% throttling request (TimeStamp= =3Dt1, duration=3Dd) within OC-OLR in the answer which goes back via A3 and= A1 to C. 8. A1 stores the 10% throttling request. 9. A new request is sent from C via A1 and A3 to S. A1 recognizes that ther= e is no reacting node downstream (no OC-Feature-Vector received) and theref= ore takes the role of the reacting node and inserts an OC-Feature-AVP. A1 h= as=A0 valid OLR from S stored and therefore performs a 10% throttling. The = request survives and A1 inserts an OC-Throttling-Information AVP with timeS= tamp=3Dt1. A3 recognizes that there is a reacting node downstream (OC-Featu= re-Vector received) and therefore does not take the role of the reacting no= de. 10. S recognizes that correct throttling (correct time stamp) is in place a= nd therefore does not return OC-OLR in the answer. 11. Requests sent from C via A1 and A3 to S undergo a 10% throttling at A1,= requests sent from C via A2 and A3 to S undergo a 10% throttling at A3. 12. Overload situation in S for some reason gets worse, S decides to reques= t 20 % reduction. 13. A new request is sent from C via A1 and A3 to S. A1 recognizes that the= re is no reacting node downstream (no OC-Feature-Vector received) and there= fore takes the role of the reacting node and inserts an OC-Feature-AVP. A1 = has=A0 valid OLR from S stored and therefore performs a 10% throttling. The= request survives and A1 inserts an OC-Throttling-Information AVP with time= Stamp=3Dt1. A3 recognizes that there is a reacting node downstream (OC-Feat= ure-Vector received) and therefore does not take the role of the reacting n= ode. 14. S recognizes that incorrect throttling (wrong time stamp) is in place a= nd therefore S returns a 20% throttling request (TimeStamp=3Dt2, duration= =3Dx) within OC-OLR in the answer which goes back via A3 and A1 to C. 15. A3 (not taking the role of the reactingt node)may, A1 must store the 20= % throttling request (replacing the 10% request). 16. A new request is sent from C via A2 and A3 to S. A3 recognizes that the= re is no reacting node downstream (no OC-Feature-Vector received) and there= fore takes the role of the reacting node and inserts an OC-Feature-Vector A= VP. A3 has=A0 valid OLR from S stored and performs a 10% throttling. The re= quest survives and A3 inserts an OC-Throttling-Information AVP with timeSta= mp=3Dt1. (assuming A3 did not store the 20% request at step 14) 17. S recog= nizes that incorrect throttling (wrong time stamp) is in place and therefor= e S returns a 20% throttling request (TimeStamp=3Dt2, duration=3Dx) within = OC-OLR in the answer which goes back via A3 and A2 to C. 18. A3 stores the 20% throttling request (replacing the 10% request). 19. Requests sent from C via A1 and A3 to S undergo a 20% throttling at A1,= requests sent from C via A2 and A3 to S undergo a 20% throttling at A3. =A0 =A0 Comments are welcome. =A0 Best regards Ulrich =A0 =A0 _______________________________________________ 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 From ulrich.wiehe@nsn.com Tue Dec 3 05:52:34 2013 Return-Path: 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 40DF51ADBD5 for ; Tue, 3 Dec 2013 05:52:34 -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 YZViuG6k5mNB for ; Tue, 3 Dec 2013 05:52:29 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD521A802D for ; Tue, 3 Dec 2013 05:52:28 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rB3DqNQI005589 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 3 Dec 2013 14:52:24 +0100 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 rB3DqNHs031615 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Dec 2013 14:52:23 +0100 Received: from DEMUHTC005.nsn-intra.net (10.159.42.36) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 3 Dec 2013 14:52:23 +0100 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.152]) by DEMUHTC005.nsn-intra.net ([10.159.42.36]) with mapi id 14.03.0123.003; Tue, 3 Dec 2013 14:52:23 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: "ext lionel.morand@orange.com" , "ext Maria Cruz Bartolome" , "dime@ietf.org list" Thread-Topic: [Dime] DOIC: Self-Contained OLRs Thread-Index: AQHO67/t2PaAGa/GgUyaCwjRxXVUh5o5m/0AgAC8o/D///ghgIAAFu+wgAGHVQCAACqasIAAMwWAgANxipCAAKJuAIAATHjQgAAM5ICAABPPEIAAFwqAgAAGBICAAAUigIAAJC3wgAEbsUCAAAYOAIAAGIwQ///0igCAAEGG8A== Date: Tue, 3 Dec 2013 13:52:23 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519D3D9@DEMUMBX014.nsn-intra.net> References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D90006681519BC90@DEMUMBX014.nsn-intra.net> <6390_1385631044_52970D44_6390_18593_1_6B7134B31289DC4FAF731D844122B36E30748E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BD19@DEMUMBX014.nsn-intra.net> <17872_1385720008_529868C8_17872_2613_1_6B7134B31289DC4FAF731D844122B36E3096B8@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BF1B@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681519BFAE@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681519C017@DEMUMBX014.nsn-intra.net> , <5BCBA1FC2B7F0B4C9D935572D90006681519C087@DEMUMBX014.nsn-intra.net> <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> In-Reply-To: <21357_1386067889_529DB7B1_21357_3212_1_6B7134B31289DC4FAF731D844122B36E312A07@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: 31133 X-purgate-ID: 151667::1386078744-000022AE-3AF115FE/0-0/0-0 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 13:52:34 -0000 Hi Lionel, the more OLRs a client must process (in every answer) the more complex is t= he solution. I don't see how it helps that multiple OLRs are not mandated f= or 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]=20 Sent: Tuesday, December 03, 2013 11:51 AM To: Wiehe, Ulrich (NSN - DE/Munich); ext Maria Cruz Bartolome; dime@ietf.or= g list Subject: RE: [Dime] DOIC: Self-Contained OLRs Hi Ulrich, I don't see the complexity if each OLR instance received is clearly disting= uished by the Report-Type.=20 Again, it is not said that it will be mandated for any deployment to rely o= n multiple OLR instances.=20 Regards, Lionel -----Message d'origine----- De=A0: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 Envoy=E9=A0: mardi 3 d=E9cembre 2013 11:46 =C0=A0: MORAND Lionel IMT/OLN; ext Maria Cruz Bartolome; dime@ietf.org list Objet=A0: 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=20 -----Original Message----- From: ext lionel.morand@orange.com [mailto:lionel.morand@orange.com]=20 Sent: Tuesday, December 03, 2013 11:05 AM To: Wiehe, Ulrich (NSN - DE/Munich); ext Maria Cruz Bartolome; dime@ietf.or= g 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 prohib= it 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 an= swer. Regards, Lionel=20 -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN= - DE/Munich) Envoy=E9=A0: mardi 3 d=E9cembre 2013 10:21 =C0=A0: ext Maria Cruz Bartolome; dime@ietf.org list Objet=A0: 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 retu= rns a host-type OLR to C (via A) and there is no need for A to insert a rea= lm-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 Destinat= ion Host in which case any realm-type OLR inserted by A would be useless to= C.=20 Similarly In figure 5 when C sends a request without Destination Host, A ma= y 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 rece= ived 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 Barto= lome 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 no= rmal behavior. But I agree in case the request is towards a Destination Host, receiving th= e 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 no= de 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 t= he 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 o= n the need for the Report-Type. > =20 > 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 De= stination-Host is not in the answer. So receiving a host-based OLR in respo= nse 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 pos= itive 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" of= fered 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 th= e client could include a destination-host or not. So the client needs to kn= ow which reduction to apply from a previous answer. > =20 > 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 co= ntext based on the type of request. > =20 > Regards, > =20 > Lionel > =20 > =20 > De : Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Envoy=E9 : lundi 2=20 > d=E9cembre 2013 14:58 =C0 : Wiehe, Ulrich (NSN - DE/Munich) Cc :=20 > dime@ietf.org list; ext Jouni Korhonen; MORAND Lionel IMT/OLN; Ben=20 > Campbell Objet : RE: [Dime] DOIC: Self-Contained OLRs > =20 > Ulrich, >=20 > 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? >=20 > I would prefer to derive the context of the OLR based on the message whic= h contains the OLR. >=20 > Back to the topic of this thread, I don't think we need to define an "opt= ional" optimization at this stage. Either it is respected by all the nodes = supporting the solution or we drop that optimization. >=20 > Regards, > Nirav. >=20 > On Dec 2, 2013 5:27 PM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: > Nirav, >=20 > If the reacting node sends a request without Destination Host, a realm-ty= pe OLR in the answer would be in-context whereas a host-type OLR in the ans= wer would be out of context. >=20 > Similarly, if the reacting node sends a request containing Destination Ho= st, a realm-type OLR in the answer would be out-of-context and a host-type = OLR in the answer would be in-context. >=20 > Ulrich >=20 >=20 >=20 > -----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=20 > Jouni Korhonen; Ben Campbell > Cc: dime@ietf.org list > Subject: RE: [Dime] DOIC: Self-Contained OLRs >=20 > Ulrich, >=20 > I have a basic question. >=20 > When the reacting node sends realm-routed request and it receives (only o= ne) OLR in the response message (which also contains the origin-host), is t= his OLR applicable for realm or host? > I am trying to understand which is out-of-context OLR here: realm-type or= host-type? >=20 > Regards, > Nirav. >=20 > -----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=20 > Korhonen; Ben Campbell > Cc: dime@ietf.org list > Subject: RE: [Dime] DOIC: Self-Contained OLRs >=20 > Hi Nirav, >=20 > please see inline. >=20 > Regards > Ulrich >=20 > -----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=20 > Jouni Korhonen; Ben Campbell > Cc: dime@ietf.org list > Subject: RE: [Dime] DOIC: Self-Contained OLRs >=20 > Ulrich, >=20 > When the client sends request containing destination-realm (and not conta= ining 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 thi= s response message is not out-of-context information.=20 > [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= =3Dx1, destination realm =3Dx2 application=3D 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, w= hat the type x was. E.g. it deduces from the value of Origin Realm in the a= nswer the value of Destination Realm in the request; it deduces from the va= lue of Report-Type in the answer whether Destination Host was present in th= e request... >=20 > On the other hand, we discussed - as part of Maria Cruz's alternative sol= ution - to define the response message's context based on the request messa= ge. And hence if the request message was sent to destination-realm, the cor= responding 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 unneces= sary complexity.=20 > [Wiehe, Ulrich (NSN - DE/Munich)] I agree. This means: the report-type AV= P is needed to let the client deduce from information received in the answe= r whether the request contained a destination host. It does not mean that w= e need two OLRs in one answer. >=20 > If we strictly want to ensure that the realm-type OLR is not sent=20 > out-of-context [Wiehe, Ulrich (NSN - DE/Munich)] That was not my=20 > proposal. My proposal was to clearly mark out-of-context OLRs in=20 > answer messages (if we allow including out-of-context OLRs) >=20 > , then we should agree to Lionel's alternative solution - to send realm-t= ype OLR only when the destination-realm based request is rejected. So basic= ally, 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 ensu= re the context of the response message and the OLR it contains). >=20 > 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 on= e 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=20 > (NSN - DE/Munich)] only the out-of-context one >=20 > , then what is the point of including two OLRs [Wiehe, Ulrich (NSN - DE/M= unich)] 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 a= s 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 react= ing node (if the reacting node wants to make use of this optimization). >=20 > and what is the point of defining Report-Type AVP? > [Wiehe, Ulrich (NSN - DE/Munich)] to let the reacting node deduce from in= formation received in the answer whether the corresponding request containe= d a destination host (so there is no need to remember). >=20 >=20 > In summary, if we define Report-Type AVP and corresponding handling at th= e reacting node, the reacting node must act accordingly and not ignore it. > [Wiehe, Ulrich (NSN - DE/Munich)] What goes wrong when out-of -context O= LR is ignored? >=20 > 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 i= gnored. > [Wiehe, Ulrich (NSN - DE/Munich)] Not the Report-Type AVP is the optimiza= tion but the incusion of out-of-context OLRs. And I'm ok not to proceed wit= h this optimization as it is not needed. >=20 > Regards, > Nirav. >=20 > -----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=20 > Korhonen; Ben Campbell > Cc: dime@ietf.org list > Subject: RE: [Dime] DOIC: Self-Contained OLRs >=20 > Hi Nirav, >=20 > 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-contex= t. > There is nothing wrong with storing such out-of-context OLRs at the clien= t, but it is simply not needed as the client will learn this OLR from respo= nses received within the context. >=20 > Best regards > Ulrich >=20 >=20 > -----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=20 > Jouni Korhonen; Ben Campbell > Cc: dime@ietf.org list > Subject: RE: [Dime] DOIC: Self-Contained OLRs >=20 > Hi Ulrich, >=20 > If an additional OLR is present with a different ReportType, why it shoul= d be ignored by the reacting node? >=20 > Regards, > Nirav. >=20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich=20 > (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 >=20 > Hi Lionel, >=20 > there is nothing missing exept the clarification that everything works fi= ne 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. >=20 > Ulrich > =20 >=20 > -----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 >=20 > Hi Ulrich, >=20 > Using the Report Type "host report", you know that the OLR applies for su= bsequent 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.=20 >=20 > It is not so important to know what the type of request was and which nod= e 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, f= or instance, future development could allow a distributed server architectu= re to provide the same information. >=20 > I'm not sure of what is missing in this reasoning... >=20 > Lionel >=20 > -----Message d'origine----- > De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 > Envoy=E9 : jeudi 28 novembre 2013 11:30 =C0 : MORAND Lionel IMT/OLN; ext= =20 > Jouni Korhonen; Ben Campbell Cc : dime@ietf.org list Objet : RE:=20 > [Dime] DOIC: Self-Contained OLRs >=20 > Lionel, >=20 > my understanding was that _the_ reporting end point provides _the_ OLR. >=20 > If we go for two OLRs in the answer we should indicate which OLR is the a= ctual OLR created by the reporting end point and which OLR is an additional= OLR created by another node. >=20 > We have two cases: > a) The request sent by the client (reacting end point) contains no Destin= ation 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 OL= R as learned from the selected server. The client may ignore the additiona= l OLR. > b) The request sent by the client (reacting endpoint) contains the Destin= ation Host. The Server (reporting node) returns a host-type OLR as the actu= al reporting-node-created OLR in the answer. The agent may optionally inser= t a realm-type OLR as additional OLR to the answer. The client may ignore t= he additional OLR. >=20 > Ulrich >=20 >=20 >=20 > -----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 >=20 > Hi, >=20 > There is no assumption on which entity is providing the realm overload st= atus. 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 s= ome 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 ser= ver itself, one for the realm for new request sent to the realm with only D= est-Realm AVP. >=20 > Lionel >=20 > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich=20 > (NSN - DE/Munich) Envoy=E9 : jeudi 28 novembre 2013 10:26 =C0 : ext Jouni= =20 > Korhonen; Ben Campbell Cc : dime@ietf.org list Objet : Re: [Dime]=20 > DOIC: Self-Contained OLRs >=20 > Hi, >=20 > 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 i= ndicates 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 indicate= s to the reacting end point that the reporting end point is a server. How c= an the reporting end point be both agent and server? >=20 > Ulrich >=20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Jouni=20 > Korhonen > Sent: Wednesday, November 27, 2013 11:44 PM > To: Ben Campbell > Cc: dime@ietf.org list > Subject: Re: [Dime] DOIC: Self-Contained OLRs >=20 >=20 > On Nov 28, 2013, at 12:27 AM, Ben Campbell wrote: >=20 > > Hi, > >=20 > > I mentioned in another thread that I prefer putting an explicit=20 > > ReportType AVP in an OLR, rather than >=20 > The more I spent time thinking/writing the actual procedures on the endpo= ints, the more it makes sense to me to keep the ReportType in the OC-OLR. E= ven if the baseline does not have agent overload etc, the ReportType fits w= ell 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 pl= ain more clear. >=20 > I skip the rest of the mail.. too much text ;-) >=20 >=20 > - Jouni >=20 >=20 >=20 >=20 >=20 > > making a responding node infer the type or meaning of the OLR from a Di= ameter request that corresponds to the answer containing the OLR. My reason= s for that go beyond just ReportType, so I'm starting a separate thread. > >=20 > > 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 t= hat carries the OLR. For example, the OLR implicitly refers to the applicat= ion identified by the Application-Id field of the enclosing answer, the rea= lm 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 mea= ning in the context of the enclosing answer. If you moved an OLR from one a= nswer to another, it's meaning may change completely. > >=20 > > I think this approach is a mistake. I would greatly prefer that we expl= icitly include such values in the OLR itself, for multiple reasons: > >=20 > > 1) It's more complex to interpret implicit, contextual values than expl= icit values. The consumer cannot simply look at the OLR; it must look in va= rious other AVPs to find all the information it needs. For example, I think= a common software design for overload control processing to be separated f= rom 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 OL= R, 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 "c= ontext" avps that must be interpreted can grow large. This approach is erro= r prone, and will likely encourage brittle, hard-to-maintain code. Self-con= tained OLRs would keep all the information related to overload in one place= . making for simpler implementations. > >=20 > > 2) It's more complex for the reporting node to send implicit values tha= n explicit values. The sender cannot simply set the context to match the OL= R--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 ins= ert OLRs into answers created by other nodes.=20 > >=20 > > If the reporting node screws this up, the meaning of the OLR may change= significantly. So again, implicit meaning gives us error prone implementat= ions. Self-contained OLRs are simpler to create and send. > >=20 > > 3) Implicit values don't work at all for certain problems. For=20 > > example, if an agent needs to originate an OLR, it typically needs=20 > > to insert that OLR into an existing Diameter answer created by a server= . > > It can't create its own answer without affecting the application=20 > > state. If the responding node assumes the OLR comes from or refers=20 > > to the node identified by the Origin-Host AVP in the enclosing=20 > > answer, things break. (For examples of when an agent needs to send=20 > > OLRs that are distinct from those sent by a server, see Steve's=20 > > agent overload draft, or my dh/dr example.) > >=20 > > OTOH, explicit values will work for all cases where we need to associat= e some arbitrary value with an OLR. > >=20 > > 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 ov= erload 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 trans= ported, this won't work. We would have to create a new or significantly mod= ified OLR format if we found a need to transport OLRs in different ways. Se= lf-contained OLRs would allow much greater flexibility. > >=20 > > 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. > >=20 > > Thanks! > >=20 > > Ben. > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime >=20 > _______________________________________________ > 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 >=20 > ______________________________________________________________________ > ___________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc pas etre diffuses, exploites o= u copies sans autorisation. Si vous avez recu ce message par erreur, veuill= ez 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= . >=20 > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; they should not be distributed, us= ed or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 >=20 > ______________________________________________________________________ > ___________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc pas etre diffuses, exploites o= u copies sans autorisation. Si vous avez recu ce message par erreur, veuill= ez 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= . >=20 > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; they should not be distributed, us= ed or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > ______________________________________________________________________ > ___________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not be d= istributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 _______________________________________________ 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 confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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 confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. From maria.cruz.bartolome@ericsson.com Tue Dec 3 05:56:07 2013 Return-Path: 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 B38CD1ADDBD for ; Tue, 3 Dec 2013 05:56:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.239 X-Spam-Level: X-Spam-Status: No, score=-1.239 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 NCisecK7AFDJ for ; Tue, 3 Dec 2013 05:56:05 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 100AD1A802D for ; Tue, 3 Dec 2013 05:56:04 -0800 (PST) X-AuditID: c1b4fb32-b7f388e0000057e0-5a-529de2f14d26 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 6D.4E.22496.1F2ED925; Tue, 3 Dec 2013 14:56:01 +0100 (CET) Received: from ESESSMB101.ericsson.se ([169.254.1.118]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.02.0347.000; Tue, 3 Dec 2013 14:56:01 +0100 From: Maria Cruz Bartolome To: "dime@ietf.org" Thread-Topic: [Dime] OVLI: clarification in 4.2 Thread-Index: Ac7wLSOy5PcGMIF3QXy86CAXysOX/A== Date: Tue, 3 Dec 2013 13:56:00 +0000 Message-ID: <087A34937E64E74E848732CFF8354B920972C119@ESESSMB101.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: multipart/alternative; boundary="_000_087A34937E64E74E848732CFF8354B920972C119ESESSMB101erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBLMWRmVeSWpSXmKPExsUyM+Jvre7HR3ODDLZfNrCY27uCzYHRY8mS n0wBjFFcNimpOZllqUX6dglcGUuftjEX9LtXrJ+4grWB8Y1dFyMnh4SAiUTDojfMELaYxIV7 69m6GLk4hAROMEq0vJ/MDOEsZpRYcf0UC0gVm4CdxKXTL5i6GDk4RASUJU7/cgAJCwtoSZz9 /pgNxBYR0Je40zKDCcLWk1je9ZARxGYRUJE48PkGO4jNK+Ar0fj3FVicEWjx91NrwOqZBcQl bj2ZzwRxkIDEkj3noY4TlXj5+B8rhK0o0f60gRGiPl9i2/HtLBAzBSVOznzCMoFRaBaSUbOQ lM1CUgYR15FYsPsTG4StLbFs4WtmGPvMgcdMyOILGNlXMUoWpxYX56YbGejlpueW6KUWZSYX F+fn6RWnbmIExsbBLb+NdjCe3GN/iFGag0VJnPc6a02QkEB6YklqdmpqQWpRfFFpTmrxIUYm Dk6pBsaeVbLHZusvedy9Nefwxym2Sd0/Te7/OyjA7n/EZZG8qjDHbFlxWbGaZ3pMevP9VB76 l0z+HF/722xa93qWVfH2c8Iv2kcuMJjIdu8+2zsvHqsbpcu/CZQbCwYvymBg2blk3uyeu4/D I6bMXqxdF7RSoCG71Ikh8Ol0vunlR/6orS4SKSp/xarEUpyRaKjFXFScCACh8JkBWwIAAA== Subject: [Dime] OVLI: clarification in 4.2 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 13:56:07 -0000 --_000_087A34937E64E74E848732CFF8354B920972C119ESESSMB101erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I would like to propose a clarification on 4.2 .... The OC-OLR AVP does not contain explicit information to which application it applies to and who inserted the AVP or whom the specific OC-OLR AVP concerns to. Both these information is implicitly learned from the encapsulating Diameter message/command. The application the OC-OLR AVP applies to is the same as the Application-Id found in the Diameter message header. The identity the OC-OLR AVP concerns is determined from the Origin-Host AVP found from the encapsulating Diameter command. My understanding is that "who inserted the AVP" cannot always be learned fr= om the encapsulating Diameter message, since "origin-host" may not always c= ontain the host that inserted the OLR. A part from that, "whom the specific OC-OLR AVP concerns to", could be a bi= t misleading... "whom" may be host, realm, or any other future ReportType, = or even any other "narrowed scope" within the OLR. Last sentence is affecte= d by this ambiguity as well. Some rephrasing may be considered: The OC-OLR AVP does not contain explicit information that may be implicitly learned from the encapsulating Diameter message/command. The application the OC-OLR AVP applies to is the same as the Application-Id found in the Diameter message header. When Report-Type is a Destination-Host, the identity the OC-OLR AVP concerns is determined from the Origin-Host AVP found from the encapsulating Diameter command. Best regards /MCruz --_000_087A34937E64E74E848732CFF8354B920972C119ESESSMB101erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

I would like to propose a clarification on 4.2<= /o:p>

        &nbs= p;       ….

  = ; The OC-OLR AVP does not contain explicit information to which<= /span>

  = ; application it applies to and who inserted the AVP= or whom the

   specific OC-OLR A=
VP concerns to. Both th=
ese information is
   implicitly learned from the encapsulating Diameter m=
essage/command.
   The application the OC-OLR AVP applies to is the sam=
e as the
   Application-Id found in the Diameter message header.=
  The identity
   the OC-OLR AVP concerns is determined from the Origi=
n-Host AVP found
   from the encapsulating Diameter command.<=
/span>

 =

 

My understanding is that “who inserted the AVP= ” cannot always be learned from the encapsulating Diameter message, s= ince “origin-host” may not always contain the host that inserte= d the OLR.

A part from that, “whom the specific OC-OLR AV= P concerns to”, could be a bit misleading… “whom” m= ay be host, realm, or any other future ReportType, or even any other “= ;narrowed scope” within the OLR. Last sentence is affected by this am= biguity as well.

 

Some rephrasing may be considered:

  = ; The OC-OLR AVP does not contain explicit information that may be 

   implicitly learned from the encapsulating Diame=
ter message/command.
   The application the OC-OLR AVP applies to is the same as th=
e
   Application-Id found in the Diameter message header.=
 When Report-Type is 
   a Destination-Host, the identity
   the OC-OLR AVP concerns is determined from the Origi=
n-Host AVP found
   from the encapsulating Diameter command.<=
/span>

 

 

Best regards

/MCruz

 

--_000_087A34937E64E74E848732CFF8354B920972C119ESESSMB101erics_-- From maria.cruz.bartolome@ericsson.com Tue Dec 3 06:30:33 2013 Return-Path: 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 C9DEE1ADBE5 for ; Tue, 3 Dec 2013 06:30:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 EljxC7WWFF79 for ; Tue, 3 Dec 2013 06:30:29 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id A502C1AD9AB for ; Tue, 3 Dec 2013 06:30:28 -0800 (PST) X-AuditID: c1b4fb38-b7f2c8e000006d25-7e-529deb010430 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 83.D8.27941.10BED925; Tue, 3 Dec 2013 15:30:25 +0100 (CET) Received: from ESESSMB101.ericsson.se ([169.254.1.118]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.02.0347.000; Tue, 3 Dec 2013 15:30:24 +0100 From: Maria Cruz Bartolome To: "dime@ietf.org" Thread-Topic: Ongoing Throttling Information in request messages Thread-Index: Ac7aQPqQ1tyE3SNOTC+vVrUogwBrJQAnWH+wAADoRNAABgE0oAAA57DwAACoAlAAASWEQAAAqKUAACDdWeAAAz9GUAABLecQAA4Qc8ABE6PKsABJVfJQASwtPKACh2J2UAABYVvwAAWQLLA= Date: Tue, 3 Dec 2013 14:30:24 +0000 Message-ID: <087A34937E64E74E848732CFF8354B920972C1BB@ESESSMB101.ericsson.se> References: <5BCBA1FC2B7F0B4C9D935572D9000668151918EC@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D900066815192B2B@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D900066815192B90@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D900066815192BF7@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D900066815192CD2@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D900066815192D5F@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681519337D@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D900066815193EFD@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B920972BF81@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D90006681519D35C@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681519D35C@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.19] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBLMWRmVeSWpSXmKPExsUyM+JvrS7j67lBBq/PCFrM7V3B5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujE33NrAWvLvDWPHy8QOWBsZjWxm7GDk4JARMJFau5+ti5AQy xSQu3FvP1sXIxSEkcIRR4s2t46wQzmJGiR13ZrGDVLEJ2ElcOv2CCaRZREBZ4vQvB5CwsIC9 xNL2S8wQYQeJyZuVQVpFBOYxSszsbmICqWERUJHY+Go12BheAV+JE4uXsUPMn8EpMWH3dbBm ToEAiZUzMkFqGIEO+n5qDVgvs4C4xK0n85kgDhWQWLLnPDOELSrx8vE/VghbUaL9aQMjRL2e xI2pU9ggbG2JZQtfM0PsFZQ4OfMJywRG0VlIxs5C0jILScssJC0LGFlWMXIUpxYn5aYbGWxi BIb+wS2/LXYwXv5rc4hRmoNFSZz341vnICGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2Ma3/7 r/9l+WFPjrgxWwzjQe1D/xj9Ej88Lr4cuOln7Daxe4e3+gix9KfyWm+s7zZUmC55rvTN9o37 j/+4rKL4cdm/IzduBnjcalI7d+Tdnonntr5k9u0+ZtkdOmG+XEZbwTTl/KWRWw9qG0683Bar 8HBa6+TUfVc3Km2c9jzlgpfH+4N/eSyqjiuxFGckGmoxFxUnAgC1L3JlSwIAAA== Subject: Re: [Dime] Ongoing Throttling Information in request messages X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 14:30:34 -0000 Hello, See comments below Regards MCruz -----Original Message----- From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 Sent: martes, 03 de diciembre de 2013 13:21 To: Maria Cruz Bartolome; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Hi MCruz, thank you for your comments. What is your interpretation of REQ10? Which interpretation other than "when= overload condition ends at the server, client must be able to detect this"= is reasonable? [MCruz] I already read some other people interpretations... I think "when" = may not be interpreted as an exact point in time, but if could be more loos= ely interpreted as that the client should be able to know whether or not th= e need to continue executing any abatement mechanism. But... I just wanted = to highlight that in my opinion, this is not key for selecting one option o= r another. With regard to robustness (see 4) below): If for any reason (attacker, misconfiguration,...) a wrong throttling is pe= rformed by the client, the server is able to immediately detect and correct= this in option B). [MCruz] But, option A keeps sending OLR with any answer, why do you think o= ption B is more robust than option A? With regard to the trade of between REQ18 and REQ13 (see 4) below): Option B allows to leave the decision to implementations (even dynamically)= =20 [MCruz] I presume you refer to the proposal you made in another mail, but c= ould you confirm? ..................... a) executing some logic (timestamp check) always + sending OLR only in the = very few cases where it is needed is more expensive (in terms or resource c= onsumption contributing to overload) than b) sending OLR always One approach could be to - mandate sending of Ongoing-Throttling-Information(TimeStamp) in request m= essages by acting nodes while performing throttling - reporting nodes that are in overload may either do a) or b) whatever is r= egarded less resource consuming by the implementation - reporting nodes that are not (no longer) overloaded must do a) ......................... while option A takes a numb decision against REQ18. Also note that it is no= t only the (overloaded) server but also the (not at all overloaded) agent t= hat could fulfill REQ18 without contravening REQ13 in option B. Best regards Ulrich =20 -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto= lome Sent: Tuesday, December 03, 2013 12:19 PM To: dime@ietf.org Subject: Re: [Dime] Ongoing Throttling Information in request messages Hello, See some comments below Best regards /MCruz -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN -= DE/Munich) Sent: mi=E9rcoles, 20 de noviembre de 2013 16:25 To: ext Nirav Salot (nsalot); dime@ietf.org Subject: Re: [Dime] Ongoing Throttling Information in request messages Nirav, thank you for your confirmation. In order to select the best solution let me try to start a comparism: 1) A1 can be compared with B1 as both require to insert an AVP in every mes= sage (answer/request, while overloaded/while performing throttling): A1 add= s (resource consuming) functionality to the (overloaded) server/reporting n= ode while B1 adds to the client/reacting node. Furthermore, the AVP to be i= nserted in A1 (OC-OLR) is the only OC-specific AVP to be inserted to the an= swer whereas the AVP to be inserted in B1 (OC-Ongoing-Throttling-Informatio= n) would be in addition to the OC-Feature-Vector which anyway needs to be a= dded to every request (inserting OC specific info to requests is needed any= way). Furthermore A1 seems to violate REQ 13 from RFC 7068 while B1 does no= t. All this clearly is a pro for option B. 2) A2 can be compared with B2: A2 either requires additional processing at = the server/reporting node or relies on timouts (violating REQ 10) while B2 = does not require any corresponding functionality. This is also a pro for Op= tion B. [MCruz] Violation of REQ10 I think may be subject to interpretation (I woul= d think the requirement text could be improved though...). Then, for this c= omparison I am not sure this is a key factor. 3) A3 can be compared with B3 as both recommend to check the presence of ne= w OC-specific info in all received messages: A3 adds the recommended functi= onality to the (overloaded) server/reporting node while B3 adds to the clie= nt/reacting node. This is a pro for option A. [MCruz] I presume you meant " _B3_ adds the recommended functionality to th= e (overloaded) server/reporting node while _A3_ adds to the client/reacting= node Here we can question whether option B violates REQ13 from RFC7068 whi= le A does not. Then, key question is to compare how much work implies each = option to an overloaded server. Not easy to get a conclusion since it could= depend a lot on implementation. 4) Option B adds a feedback channel from client to server making the soluti= on more robust.=20 [MCruz] More robust? In which sense? It also allows the server to give some priority to already throttled traffi= c (see REQ 18) and it allows agents to ensure that already throttled traffi= c (by a downstream node) is not throttled again. This is a pro for option B= . [MCruz] In my opinion this is the best advantage of solution B over A. But,= we need to highlight as well that if server needs (e.g.) to throttle traff= ic that is not being throttled, then this helps to fulfill REQ-18, but it i= s against REQ13. Then, if we need to fulfill REQ13 as much as possible, the= n this advantage vanishes. 5) In Option A it is not clear how the client/reacting node should behave w= hen it receives an answer without OC-OLR AVP while performing throttling. T= his is a con for option A. In summary my preference is for option B. Comments are welcome. Ulrich -----Original Message----- From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Sent: Thursday, November 14, 2013 3:54 PM To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Ulrich, I confirm the summary below of having two valid options. Just wanted to highlight one aspect, in general. Current definition of the OC-OLR AVP suggest the inclusion of TimeStamp and= ValidityDuration AVPs. And these AVPs are applicable/valid/needed in both = the options below. Additionally, if we decide to go for option B, we would need to define new = AVP OC-Ongoing-Throttling-Information AVP. Regards, Nirav. -----Original Message----- From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Sent: Wednesday, November 13, 2013 9:03 PM To: Nirav Salot (nsalot); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Nirav, in summary it seems that we have two valid options: Option A:=20 A1: the server (or reporting node), while overloaded must insert the load O= C-OLR AVP in every answer message. A2: the server (or reporting node) after leaving the overload state must co= ntinue inserting the OC-OLR AVP (indicating end of throttling request) for = some time (how long needs to be calculated by the server) or the server mus= t rely on expiry of outdated overload reports. A3: the reacting node must/should check the timeStamp in every OC-OLR AVP r= eceived in answer messages in order not to miss an update. Option B: B1: the reacting node, while performing throttling, must insert the OC-Ongo= ing-Throttling-Information in every request message. B2: void (the reacting node , while no longer throttling, simply does not i= nsert OC-Ongoing-Throttling-Information) B3: the reporting node must/should check OC-Ongoing-Throttling-Information = received in a request in order to decide whether or not OC-OLR must be sent= back.=20 Ulrich -----Original Message----- From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Sent: Thursday, November 07, 2013 5:29 PM To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Ulrich, Not sure the significance of REQ 10 here but I do not agree to enforce the = server to include overload-report (indicating non-zero or zero overload con= dition) in every message. Even in your example, the overload condition will end sometime - e.g. after= 1000 sec. and then the server can stop including the overload-report. Besides, I am still not convince that "during the overload condition, using= some logic to avoid inclusion of overload-report is less resource consumin= g than simply including the same overload-report". Yes, the reason behind defining timestamp is to allow the reacting node to = discard the overload-report if the same was already received from the repor= ting node. Regards, Nirav. -----Original Message----- From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Sent: Thursday, November 07, 2013 3:53 PM To: Nirav Salot (nsalot); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Nirav, please see inline. Best regards Ulrich -----Original Message----- From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Sent: Thursday, November 07, 2013 10:15 AM To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Ulrich, Please read my responses inline. Regards, Nirav. -----Original Message----- From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Sent: Thursday, November 07, 2013 1:54 PM To: Nirav Salot (nsalot); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Nirav, thank you for the explanation. This may be a solution which adds more comp= lexity to the reporting node: The reporting node must remember the maximum = not yet expired fraction of duration values it sent when leaving the overlo= ad state and must continue reporting "end of overload condition" until expi= ry. (there is no corresponding complexity at the reacting node in my propos= al) [Nirav] This is not always true, e.g. as I had indicated if the node ha= s advertised 10% reduction-percentage for 10 sec., it need not bother to ad= vertise no-overload condition since the validity-period was very small. [Ulrich] Also not always true, e.g. if the reporting node has requested at = 20% reduction for 1000sec at t1 and then at t1 + 10sec sends an update to r= equest a 10% reduction for 10 sec. Although the validity-period is small (1= 0 sec) there may still be a reacting node that did not get the update and k= eeps on throttling by 20% until t1 + 1000sec. Furthermore you seem not to t= ake REQ 10 seriously. My understanding was that timeout is last resort, not= the normal way. Another question: While doing a throttling, what is the expected behaviour = of the reacting node when receiving an answer message without OC-OLR AVP? (= stop/continue throttling?) (there is no corresponding question in my propos= al since not sending of OC-Ongoing-Throttling-Information clearly means tha= t throttling is not in place) [Nirav] The reacting node should continue to = apply the earlier received OC-OLR.=20 " (Note: We seem to have consensus that a server MAY repeat OLRs in subsequent messages, but is not required to do so, based on local policy.)" [Ulrich] This needs to be reconsidered. See the following example: Non supporting client C1 sends a request via supporting agent A1 to Server = S. S returns a 10% throttling request.=20 C sends an new request via supporting agent A2 to S.=20 S decides not to repeat the 10% throttling request (hence A2 is not aware o= f the throttling request).=20 C1 sends a new request via A1.=20 S decides to repeat the throttling request (redundant).=20 Supporting client C2 sends a request via A2 to S. S decides not to repeat.... To avoid this mess we either need to mandate sending OC-OLR in every answer= (while in overload) or let the Server keep track which agent and which cli= ent is updated with the newest info. (or consider my proposal). Another question is for the reacting node: What is the expected behaviour w= hen receiving lots of redundant OC-OLR AVPs in answer messages? The reactin= g node needs to check every single OC-OLR AVP in order to find out whether = it contains an update. Is that the correct understanding? (this seems to be= equivalent to checking for redundant OC-Ongoing-Throttling-Information AVP= s in every request by the reporting node in my proposal) [Nirav] Please ref= er to Timestamp AVP within OC-OLR. The TimeStamp AVP indicates when the original OC-OLR AVP with the current content was created. It is possible to replay the same OC- OLR AVP multiple times between the overload endpoints, however, when the OC-OLR AVP content changes or the other information sending endpoint wants the receiving endpoint to update its overload control information, then the TimeStamp AVP MUST contain a new value. [Ulrich] This does not explicitly say that the reacting node must check eve= ry TimeStamp received within OC-OLR AVPs. But I guess this is the consequen= ce. Can you please confirm. Adding dime-list again. Ulrich From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Sent: Wednesday, November 06, 2013 4:58 PM To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org Subject: RE: Ongoing Throttling Information in request messages Ulrich, During "no overload condition", why should reporting node include overload-= information in all the answer messages? e.g. if the reporting node has advertised overload-report with period-of-va= lidity=3D10 sec., it knows that after that period all the reacting node wil= l automatically stop applying any overload mitigation action. And hence it = does not need to explicitly send any overload-report indicating "no overloa= d condition". In general, I assume that overload period of would be much shorter as compa= red to "no overload" period. And hence I do not see reason to always includ= e overload-report. Regards, Nirav. From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Sent: Wednesday, November 06, 2013 9:12 PM To: Nirav Salot (nsalot); doc-dt@ietf.org Subject: RE: Ongoing Throttling Information in request messages Nirav, "During the overload" yes I agree, but "when no longer in overload" all ans= wer messages would contain the information "no longer in overload" while on= ly few request messages would contain the Ongoing-Throttling-Information. Removing dime-list which bounces. Best regards Ulrich From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Sent: Wednesday, November 06, 2013 4:02 PM To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Ulrich, I might be missing something here so please bear with me. Number of answer messages sent by server =3D number of request messages rec= eived by the server. During the overload, the server would receive only those requests which sur= vived throttling. And then the server would send answer messages to only those request messag= es. So "every" and "some" are actually equal in the below equation. No? Regards, Nirav. From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Sent: Wednesday, November 06, 2013 8:24 PM To: Nirav Salot (nsalot); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Nirav, Not quite. The question is: "is sending an overload-report in every answer message that corresponds to = request with OC-Feature-Vector present more resource consuming than receivi= ng Ongoing-Throttling-Information in some request messages (only those that= survived a throttling)?" Best regards Ulrich From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Sent: Wednesday, November 06, 2013 3:15 PM To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Ulrich, Thanks for clarification. Then the question would be "is sending overload-report in every answer message is more resource consum= ing than the solution below - i.e. receiving OC-Ongoing-Throttling-Informat= ion in all request message and analyzing the timestamp and then deciding if= the overload-report should be included or not." I am not sure. Regards, Nirav. From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Sent: Wednesday, November 06, 2013 7:08 PM To: Nirav Salot (nsalot); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Nirav, thank you for your comments. The comparism is between: Current way: "send OC specific information (Feature-Vector) in every reques= t message and in every corresponding answer message" My proposal: "send OC specific information (Feature-Vector and in some case= s Ongoing-Throttling-Info) in every request message and in corresponding an= swer messages only when required". Sending OC specific information =A0is regarded a resource consuming action = and we should not put this action to the (overloaded) server where avoidabl= e. See REQ 13. Best regards Ulrich From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Sent: Wednesday, November 06, 2013 12:04 PM To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Ulrich, Thanks for the detail explanation of your proposal. Just to verify my understanding, Your proposal would allow the reporting node to avoid inclusion of the "sam= e" overload-report in the answer message since the request message indicate= s that the path contains at least one reacting node which already has the l= atest overload-report. In other words, the reporting node need not include overload-report in ever= y message, blindly. To achieve the above objective, the solution below suggest the reacting nod= e to include new AVP OC-Ongoing-Throttling-Information in every request mes= sage, which survives throttling. So the net result is that, the inclusion of the overload-report is prevente= d in every answer message since the OC-Ongoing-Throttling-Information is in= cluded in every request message. [Wiehe, Ulrich (NSN - DE/Munich)] no.=A0 .in every request message that sur= vived a throttling. And hence I am not sure if the solution has sound benefit from the inclusio= n of redundant information point of view. In summary, I think the solution suggested below works as explained. But I fail to see the benefit of using this solution compare to a solution = in which the reporting node includes overload-report in every answer messag= e. Regards, Nirav. From: doc-dt-bounces@ietf.org [mailto:doc-dt-bounces@ietf.org] On Behalf Of= Wiehe, Ulrich (NSN - DE/Munich) Sent: Tuesday, November 05, 2013 9:36 PM To: doc-dt@ietf.org; dime@ietf.org Subject: [doc-dt] Ongoing Throttling Information in request messages Hi, draft-docdt-dime-ovli-01 in Appendix B, Table 1, REQ 13 says: =A0=A0=A0=A0=A0=A0=A0 .. Another way =A0=A0=A0=A0=A0=A0=A0 is to let the request sender (reacting node) insert =A0=A0=A0=A0=A0=A0=A0 information in the request to say whether a =A0=A0=A0=A0=A0=A0=A0 throttling is actually performed.=A0 The reporting no= de =A0=A0=A0=A0=A0=A0=A0 then can base its decision on information received in =A0=A0=A0=A0=A0=A0=A0 the request; no need for keeping state to record who =A0 has received overload reports.=A0=20 =A0 And in Appendix B, Table 1, REQ 18: =A0=A0=A0=A0=A0=A0=A0 There has been a proposal to mark =A0=A0=A0=A0=A0=A0=A0 messages that survived overload throttling as one =A0=A0=A0=A0=A0=A0=A0 method for an overloaded node to address fairness but =A0=A0=A0=A0=A0=A0=A0 this proposal is not yet part of the solution.=A0=20 =A0 I would like to come back to this proposal.=20 A new AVP OC-Ongoing-Throttling-Information inserted in request messages wo= uld indicate that the request message survived a throttling. Furthermore, i= nformation within the AVP indicates the TimeStamp as received in the previo= us OC-OLR AVP, according to which the ongoing throttling (which was survive= d) is performed. =A0 OC-Ongoing-Throttling-Information ::=3D < AVP Header: TBD9 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 < TimeStamp > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * [ AVP ] =A0 Supporting Clients would insert the OC-Ongoing-Throttling-Information AVP= =A0 into request messages that survived a throttling performed at that clie= nt. Supporting Agents when receiving a request message that contains an OC-Ongo= ing-Throttling-Information AVP would not perform an additional throttling (= since the client or a downstream agent already performed the throttling) , = while, when receiving a request that does not contain OC-Ongoing-Throttling= -Information AVP would perform throttling (on behalf of the client) accordi= ng to a previously received and stored OC-OLR, and if that throttling is su= rvived the agent would insert the OC-Ongoing-Throttling-Information AVP in = the request before sending it further upstream. Servers (or in general reporting nodes) would check presence and content of= the OC-Ongoing-Throttling-Information AVP in received request messages and= could detect (together with a check of presence of OC-Feature-Vector AVP) = whether inserting an OC-OLR AVP in the corresponding answer message is need= ed in order to update the reacting node with a new OC-OLR). =A0 This proposal especially addresses use cases like the following: =A0 Architecture: =A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +-------= ---------+ =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | suppor= ting=A0=A0=A0=A0 | =A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 /| agent A1= =A0=A0=A0=A0=A0=A0 |\ =A0 +----------------+ / +----------------+ \ =A0 | non supporting |/=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 \ =A0 | client C=A0=A0=A0=A0=A0=A0 |\=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 \ =A0 +----------------+ \ +----------------+=A0=A0=A0 \ +------------+=A0=A0= =A0 +---------+ =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 \| non supp= orting |=A0=A0=A0=A0 \| supporting | =A0=A0 | Server=A0 | =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 age= nt A2=A0=A0=A0=A0=A0 |------| agent A3=A0=A0 |----|=A0 S=A0=A0=A0=A0=A0 | =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0 +------------= ----+=A0=A0=A0=A0=A0 +------------+=A0=A0=A0 +---------+ =A0 1. A request is sent from C via A2 and A3 to S. A3 recognizes that there is= no reacting node downstream (no OC-Feature-Vector received) and therefore = takes the role of the reacting node and inserts an OC-Feature-Vector AVP. A= 3 has no valid OLR from S stored and therefore does not perform throttling = and does not insert an OC-Throttling-Information AVP. 2. S recognizes that there is a reacting node downstream which is actually = not performing a throttling. S returns a 10% throttling request (TimeStamp= =3Dt1, duration=3Dd) within OC-OLR in the answer which goes back via A3 and= A2 to C. 3. A3 stores the 10% throttling request. 4. A new request is sent from C via A2 and A3 to S. A3 recognizes that ther= e is no reacting node downstream (no OC-Feature-Vector received) and theref= ore takes the role of the reacting node and inserts an OC-Feature-Vector AV= P. A3 has=A0 valid OLR from S stored and performs a 10% throttling. The req= uest survives and A3 inserts an OC-Throttling-Information AVP with timeStam= p=3Dt1. 5. S recognizes that correct throttling (correct time stamp) is in place an= d therefore does not return OC-OLR in the answer. 6. A new request is sent from C via A1 and A3 to S. A1 recognizes that ther= e is no reacting node downstream (no OC-Feature-Vector received) and theref= ore takes the role of the reacting node and inserts an OC-Feature-AVP. A1 h= as no valid OLR from S stored and therefore does not perform throttling and= does not insert an OC-Throttling-Information AVP. A3 recognizes that there= is a reacting node downstream (OC-Feature-Vector received) and therefore d= oes not take the role of the reacting node. 7. S recognizes that there is a reacting node downstream which is actually = not performing a throttling. S returns a 10% throttling request (TimeStamp= =3Dt1, duration=3Dd) within OC-OLR in the answer which goes back via A3 and= A1 to C. 8. A1 stores the 10% throttling request. 9. A new request is sent from C via A1 and A3 to S. A1 recognizes that ther= e is no reacting node downstream (no OC-Feature-Vector received) and theref= ore takes the role of the reacting node and inserts an OC-Feature-AVP. A1 h= as=A0 valid OLR from S stored and therefore performs a 10% throttling. The = request survives and A1 inserts an OC-Throttling-Information AVP with timeS= tamp=3Dt1. A3 recognizes that there is a reacting node downstream (OC-Featu= re-Vector received) and therefore does not take the role of the reacting no= de. 10. S recognizes that correct throttling (correct time stamp) is in place a= nd therefore does not return OC-OLR in the answer. 11. Requests sent from C via A1 and A3 to S undergo a 10% throttling at A1,= requests sent from C via A2 and A3 to S undergo a 10% throttling at A3. 12. Overload situation in S for some reason gets worse, S decides to reques= t 20 % reduction. 13. A new request is sent from C via A1 and A3 to S. A1 recognizes that the= re is no reacting node downstream (no OC-Feature-Vector received) and there= fore takes the role of the reacting node and inserts an OC-Feature-AVP. A1 = has=A0 valid OLR from S stored and therefore performs a 10% throttling. The= request survives and A1 inserts an OC-Throttling-Information AVP with time= Stamp=3Dt1. A3 recognizes that there is a reacting node downstream (OC-Feat= ure-Vector received) and therefore does not take the role of the reacting n= ode. 14. S recognizes that incorrect throttling (wrong time stamp) is in place a= nd therefore S returns a 20% throttling request (TimeStamp=3Dt2, duration= =3Dx) within OC-OLR in the answer which goes back via A3 and A1 to C. 15. A3 (not taking the role of the reactingt node)may, A1 must store the 20= % throttling request (replacing the 10% request). 16. A new request is sent from C via A2 and A3 to S. A3 recognizes that the= re is no reacting node downstream (no OC-Feature-Vector received) and there= fore takes the role of the reacting node and inserts an OC-Feature-Vector A= VP. A3 has=A0 valid OLR from S stored and performs a 10% throttling. The re= quest survives and A3 inserts an OC-Throttling-Information AVP with timeSta= mp=3Dt1. (assuming A3 did not store the 20% request at step 14) 17. S recog= nizes that incorrect throttling (wrong time stamp) is in place and therefor= e S returns a 20% throttling request (TimeStamp=3Dt2, duration=3Dx) within = OC-OLR in the answer which goes back via A3 and A2 to C. 18. A3 stores the 20% throttling request (replacing the 10% request). 19. Requests sent from C via A1 and A3 to S undergo a 20% throttling at A1,= requests sent from C via A2 and A3 to S undergo a 20% throttling at A3. =A0 =A0 Comments are welcome. =A0 Best regards Ulrich =A0 =A0 _______________________________________________ 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 From ulrich.wiehe@nsn.com Tue Dec 3 07:03:25 2013 Return-Path: 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 494401AE172 for ; Tue, 3 Dec 2013 07:03:25 -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 jfxkXkLZ9Ltr for ; Tue, 3 Dec 2013 07:03:16 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 96EA01AE174 for ; Tue, 3 Dec 2013 07:03:15 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rB3F3BAb016304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 3 Dec 2013 16:03:11 +0100 Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rB3F39aR032144 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Dec 2013 16:03:09 +0100 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.152]) by DEMUHTC003.nsn-intra.net ([10.159.42.34]) with mapi id 14.03.0123.003; Tue, 3 Dec 2013 16:03:09 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: ext Maria Cruz Bartolome , "dime@ietf.org" Thread-Topic: [Dime] OVLI: clarification in 4.2 Thread-Index: Ac7wLSOy5PcGMIF3QXy86CAXysOX/AABwHCQ Date: Tue, 3 Dec 2013 15:03:08 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519D427@DEMUMBX014.nsn-intra.net> References: <087A34937E64E74E848732CFF8354B920972C119@ESESSMB101.ericsson.se> In-Reply-To: <087A34937E64E74E848732CFF8354B920972C119@ESESSMB101.ericsson.se> 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: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D90006681519D427DEMUMBX014nsnin_" 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: 16537 X-purgate-ID: 151667::1386082991-000022AE-865F88FB/0-0/0-0 Subject: Re: [Dime] OVLI: clarification in 4.2 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 15:03:25 -0000 --_000_5BCBA1FC2B7F0B4C9D935572D90006681519D427DEMUMBX014nsnin_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi MCruz, isn't this clause 4.3? I agree that clarification is needed. But isn't it so that the OLR contains some explicit information (e.g. the R= eport-Type) that is not implicitly learned from the encapsulating Diameter = message? My proposal: The OC-OLR AVP does not contain explicitly all information needed by the re= acting node in order to decide whether a subsequent request must undergo a = throttling process with the reported percentage. To take this decision the = reacting node must check a) whether the subsequent request's Application-ID matches the Applica= tion-Id received in the OC-OLR AVP's encapsulating answer command; b) if the Report-Type received in the OC-ORL is "host" b1) whether the subsequent request's Destination Host is present and match= es the Origin Host received in the OC-OLR AVP's encapsulating answer comman= d; if the Report-Type received in the OC-OLR is "realm" b2) whether the subsequent request' Destination Host is absent and the Dest= ination Realm matches the Origin Realm received in the OC-OLR AVP's encaps= ulating answer command; Best regards Ulrich From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto= lome Sent: Tuesday, December 03, 2013 2:56 PM To: dime@ietf.org Subject: [Dime] OVLI: clarification in 4.2 Hello, I would like to propose a clarification on 4.2 .... The OC-OLR AVP does not contain explicit information to which application it applies to and who inserted the AVP or whom the specific OC-OLR AVP concerns to. Both these information is implicitly learned from the encapsulating Diameter message/command. The application the OC-OLR AVP applies to is the same as the Application-Id found in the Diameter message header. The identity the OC-OLR AVP concerns is determined from the Origin-Host AVP found from the encapsulating Diameter command. My understanding is that "who inserted the AVP" cannot always be learned fr= om the encapsulating Diameter message, since "origin-host" may not always c= ontain the host that inserted the OLR. A part from that, "whom the specific OC-OLR AVP concerns to", could be a bi= t misleading... "whom" may be host, realm, or any other future ReportType, = or even any other "narrowed scope" within the OLR. Last sentence is affecte= d by this ambiguity as well. Some rephrasing may be considered: The OC-OLR AVP does not contain explicit information that may be implicitly learned from the encapsulating Diameter message/command. The application the OC-OLR AVP applies to is the same as the Application-Id found in the Diameter message header. When Report-Type is a Destination-Host, the identity the OC-OLR AVP concerns is determined from the Origin-Host AVP found from the encapsulating Diameter command. Best regards /MCruz --_000_5BCBA1FC2B7F0B4C9D935572D90006681519D427DEMUMBX014nsnin_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi MCruz,

 

isn’t this claus= e 4.3?

 

I agree= that clarification is needed.

But isn= ’t it so that the OLR contains some explicit information (e.g. the Re= port-Type) that is not implicitly learned from the encapsulating Diameter m= essage?

&n= bsp;

My prop= osal:

The OC-= OLR AVP does not contain explicitly all information needed by the reacting = node in order to decide whether a subsequent request must undergo a throttl= ing process with the reported percentage. To take this decision the reacting node must check

= a)      whether the subsequent request’s Application-ID matches the Applicat= ion-Id received in the OC-OLR AVP’s encapsulating answer command;

= b)      if the Report-Type received in the OC-ORL is “host”=

b1)  whether the subsequent request’s Dest= ination Host is present and matches the Origin Host received in the OC-OLR = AVP’s encapsulating answer command;

if the Report-Type received in the= OC-OLR is “realm”

b2) whether the subsequent request’ Destination= Host is absent and the Destination Realm matches the Origin Realm received= in the OC-OLR AVP’s  encapsulating answer command;

&n= bsp;

Best re= gards

Ulrich<= o:p>

&n= bsp;

&n= bsp;

&n= bsp;

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Bartolome
Sent: Tuesday, December 03, 2013 2:56 PM
To: dime@ietf.org
Subject: [Dime] OVLI: clarification in 4.2

 

Hello,

 

I would like to propose a clari= fication on 4.2

     &= nbsp;          ….

   The OC-OLR AVP does not contain explicit information to wh= ich

   application it applies to and who inserted the AVP= or whom the

   sp=
ecific OC-OLR AVP concerns to. Both these information is
   implicitly learned from the encapsula=
ting Diameter message/command.
   The application the OC-OLR AVP applie=
s to is the same as the
   Application-Id found in the Diameter =
message header.  The identity
   the OC-OLR AVP concerns is determined=
 from the Origin-Host AVP found
   from the encapsulating Diameter comma=
nd.

 

 

My understanding is that “= ;who inserted the AVP” cannot always be learned from the encapsulatin= g Diameter message, since “origin-host” may not always contain = the host that inserted the OLR.

A part from that, “whom t= he specific OC-OLR AVP concerns to”, could be a bit misleading…= “whom” may be host, realm, or any other future ReportType, or = even any other “narrowed scope” within the OLR. Last sentence i= s affected by this ambiguity as well.

 

Some rephrasing may be consider= ed:

   The OC-OLR AVP does not contain explicit information that may be 

   implicitly learned from the enca=
psulating Diameter message/command.
   The application the OC-OLR AV=
P applies to is the same as the
   Application-Id found in the Diameter =
message header. When Report-Type is 
   a Destination-Host, the identity
   the OC-OLR AVP concerns is determined=
 from the Origin-Host AVP found
   from the encapsulating Diameter comma=
nd.

 

 

Best regards<= /p>

/MCruz

 

--_000_5BCBA1FC2B7F0B4C9D935572D90006681519D427DEMUMBX014nsnin_-- From maria.cruz.bartolome@ericsson.com Tue Dec 3 07:11:40 2013 Return-Path: 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 1EACC1AE135 for ; Tue, 3 Dec 2013 07:11:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, 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 G4cfKg4SUO2p for ; Tue, 3 Dec 2013 07:11:32 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 613461AE157 for ; Tue, 3 Dec 2013 07:11:31 -0800 (PST) X-AuditID: c1b4fb2d-b7f1c8e000005ceb-f7-529df49f1797 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 9A.F8.23787.F94FD925; Tue, 3 Dec 2013 16:11:28 +0100 (CET) Received: from ESESSMB101.ericsson.se ([169.254.1.118]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.02.0347.000; Tue, 3 Dec 2013 16:11:24 +0100 From: Maria Cruz Bartolome To: "dime@ietf.org" Thread-Topic: [Dime] OVLI: clarification in 4.2 Thread-Index: AQHO8DjJXSb826ZS2kaa0cmdua9w95pCkc5w Date: Tue, 3 Dec 2013 15:11:23 +0000 Message-ID: <087A34937E64E74E848732CFF8354B920972C3CE@ESESSMB101.ericsson.se> References: <087A34937E64E74E848732CFF8354B920972C119@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D90006681519D427@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681519D427@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.19] Content-Type: multipart/alternative; boundary="_000_087A34937E64E74E848732CFF8354B920972C3CEESESSMB101erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrILMWRmVeSWpSXmKPExsUyM+Jvre6CL3ODDD6dZ7SY27uCzYHRY8mS n0wBjFFcNimpOZllqUX6dglcGSu3XWMueDyFsWLW3OksDYwPmxm7GDk5JARMJCZsXMMKYYtJ XLi3nq2LkYtDSOAQo8S8m7dYIJzFjBIf/75kBqliE7CTuHT6BVMXIweHiICyxOlfDiBhYQF9 ic0Lr4CViAgYSDxcsJQRwjaSWPvuExOIzSKgInHjyBewZbwCvhJ/lq1mgpg/mVHiwIQesAZO gQCJHzv+soPYjEAXfT+1BqyZWUBc4taT+UwQlwpILNlznhnCFpV4+fgf1AeKEu1PGxgh6vMl Vp6/xQyxTFDi5MwnLBMYRWYhGTULSdksJGUQcR2JBbs/sUHY2hLLFr5mhrHPHHjMhCy+gJF9 FSN7bmJmTnq54SZGYLQc3PJbdwfjqXMihxilOViUxHk/vHUOEhJITyxJzU5NLUgtii8qzUkt PsTIxMEp1cCo/fL5vuhph3onJq50/5rtLhS7pNRbQvaU3j8+z6B7dowy+jseTfbNrlISrp/z se/J/O+WJa+uGzVP6DUuU/NRLp7nY8T/ZXm4fjtzxIRG483uH5y609Z1HzTJXaix9Uk7yw+z OUYLt3zQVmK5fmb2In+ViU6n/zs4l7Jt5ZVYx6xxpDZlf58SS3FGoqEWc1FxIgDts9GbZAIA AA== Subject: Re: [Dime] OVLI: clarification in 4.2 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 15:11:40 -0000 --_000_087A34937E64E74E848732CFF8354B920972C3CEESESSMB101erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Ulrich, You are right, it is 4.3 in version under development: https://github.com/jounikor/draft-docdt-dime-ovli/blob/master/draft-ietf-di= me-ovli-01.txt Your proposal looks fine. Best regards MCruz From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Sent: martes, 03 de diciembre de 2013 16:03 To: Maria Cruz Bartolome; dime@ietf.org Subject: RE: [Dime] OVLI: clarification in 4.2 Hi MCruz, isn't this clause 4.3? I agree that clarification is needed. But isn't it so that the OLR contains some explicit information (e.g. the R= eport-Type) that is not implicitly learned from the encapsulating Diameter = message? My proposal: The OC-OLR AVP does not contain explicitly all information needed by the re= acting node in order to decide whether a subsequent request must undergo a = throttling process with the reported percentage. To take this decision the = reacting node must check a) whether the subsequent request's Application-ID matches the Applica= tion-Id received in the OC-OLR AVP's encapsulating answer command; b) if the Report-Type received in the OC-ORL is "host" b1) whether the subsequent request's Destination Host is present and match= es the Origin Host received in the OC-OLR AVP's encapsulating answer comman= d; if the Report-Type received in the OC-OLR is "realm" b2) whether the subsequent request' Destination Host is absent and the Dest= ination Realm matches the Origin Realm received in the OC-OLR AVP's encaps= ulating answer command; Best regards Ulrich From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto= lome Sent: Tuesday, December 03, 2013 2:56 PM To: dime@ietf.org Subject: [Dime] OVLI: clarification in 4.2 Hello, I would like to propose a clarification on 4.2 .... The OC-OLR AVP does not contain explicit information to which application it applies to and who inserted the AVP or whom the specific OC-OLR AVP concerns to. Both these information is implicitly learned from the encapsulating Diameter message/command. The application the OC-OLR AVP applies to is the same as the Application-Id found in the Diameter message header. The identity the OC-OLR AVP concerns is determined from the Origin-Host AVP found from the encapsulating Diameter command. My understanding is that "who inserted the AVP" cannot always be learned fr= om the encapsulating Diameter message, since "origin-host" may not always c= ontain the host that inserted the OLR. A part from that, "whom the specific OC-OLR AVP concerns to", could be a bi= t misleading... "whom" may be host, realm, or any other future ReportType, = or even any other "narrowed scope" within the OLR. Last sentence is affecte= d by this ambiguity as well. Some rephrasing may be considered: The OC-OLR AVP does not contain explicit information that may be implicitly learned from the encapsulating Diameter message/command. The application the OC-OLR AVP applies to is the same as the Application-Id found in the Diameter message header. When Report-Type is a Destination-Host, the identity the OC-OLR AVP concerns is determined from the Origin-Host AVP found from the encapsulating Diameter command. Best regards /MCruz --_000_087A34937E64E74E848732CFF8354B920972C3CEESESSMB101erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Ulrich,

 

You are right, it is 4= .3 in version under development:

https://github.com/jounikor/draft-docdt-dime-ovli/blob/master/draft= -ietf-dime-ovli-01.txt

Your proposal looks fi= ne.

Best regards

MCruz

 

From: Wiehe, U= lrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
Sent: martes, 03 de diciembre de 2013 16:03
To: Maria Cruz Bartolome; dime@ietf.org
Subject: RE: [Dime] OVLI: clarification in 4.2

 

Hi MCruz,<= o:p>

 = ;

isn’= t this clause 4.3?

 = ;

I agree that clarifica= tion is needed.

But isn’t it so = that the OLR contains some explicit information (e.g. the Report-Type) that= is not implicitly learned from the encapsulating Diameter message?

 

My proposal:

The OC-OLR AVP does no= t contain explicitly all information needed by the reacting node in order t= o decide whether a subsequent request must undergo a throttling process wit= h the reported percentage. To take this decision the reacting node must check

a)&= nbsp;     whether the su= bsequent request’s Application-ID matches the Application-Id received= in the OC-OLR AVP’s encapsulating answer command;<= /p>

b)&= nbsp;     if the Report-= Type received in the OC-ORL is “host”

b1)  whether the subsequent request’s Destination Host is= present and matches the Origin Host received in the OC-OLR AVP’s enc= apsulating answer command;

if the Report-Type received in the OC-OLR is R= 20;realm”

b2) whether the subsequent request’ Destination Host is absent= and the Destination Realm matches the Origin Realm received in the OC-OLR = AVP’s  encapsulating answer command;

 

Best regards

Ulrich

 

 

 

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Bartolome
Sent: Tuesday, December 03, 2013 2:56 PM
To: dime@ietf.org
Subject: [Dime] OVLI: clarification in 4.2

 

Hello,

 

I would like to propose a clarification on 4.2<= /o:p>

        &nbs= p;       ….

   The OC-OLR AVP does not contain explicit information to= which

   application it applies to and who inserted the AVP= or whom the

   specific OC-OLR A=
VP concerns to. Both th=
ese information is
   implicitly learned from the encapsulating Diameter m=
essage/command.
   The application the OC-OLR AVP applies to is the sam=
e as the
   Application-Id found in the Diameter message header.=
  The identity
   the OC-OLR AVP concerns is determined from the Origi=
n-Host AVP found
   from the encapsulating Diameter command.<=
/span>

 

 

My understanding is that “who inserted the AVP= ” cannot always be learned from the encapsulating Diameter message, s= ince “origin-host” may not always contain the host that inserte= d the OLR.

A part from that, “whom the specific OC-OLR AV= P concerns to”, could be a bit misleading… “whom” m= ay be host, realm, or any other future ReportType, or even any other “= ;narrowed scope” within the OLR. Last sentence is affected by this am= biguity as well.

 

Some rephrasing may be considered:

   The OC-OLR AVP does not contain explicit information that may be 

   implicitly learned from the encapsulating Diame=
ter message/command.
   The application the OC-OLR AVP applies to is the same as th=
e
   Application-Id found in the Diameter message header.=
 When Report-Type is 
   a Destination-Host, the identity
   the OC-OLR AVP concerns is determined from the Origi=
n-Host AVP found
   from the encapsulating Diameter command.<=
/span>

 

 

Best regards

/MCruz

 

--_000_087A34937E64E74E848732CFF8354B920972C3CEESESSMB101erics_-- From srdonovan@usdonovans.com Tue Dec 3 07:35:00 2013 Return-Path: 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 9D7F01AE13A for ; Tue, 3 Dec 2013 07:35:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no 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 JVb9xchy5vOk for ; Tue, 3 Dec 2013 07:34:52 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id BC8231AE08C for ; Tue, 3 Dec 2013 07:34:52 -0800 (PST) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:50131 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1Vnrzr-0008Fw-D0 for dime@ietf.org; Tue, 03 Dec 2013 07:34:49 -0800 Message-ID: <529DFA17.1090507@usdonovans.com> Date: Tue, 03 Dec 2013 09:34:47 -0600 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: dime@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------060200020206020203010408" X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same type) within a response message X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 15:35:00 -0000 This is a multi-part message in MIME format. --------------060200020206020203010408 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Nirav, If we allow AVPs to be added without a new report type then where will the behavior associated with the presence of that AVP be documented? Requiring the definition of a new registered report type insures that implementers have a well defined place to go to find out how to deal with the presence of that AVP. Steve On 12/3/13 3:25 AM, Nirav Salot (nsalot) wrote: > > Maria-Cruz, > > > > >we may think that we need two different OLRs with ReportType=host, and > one of them includes the extra info (AVPs) required for that application > > Yes. The above is my concern. I tried giving APN as one example AVP > which we may want to include in OC-OLR. Let me give another possible > example. > > As of now, the OC-OLR can indicate application + host/realm level > "required-reduction-percentage". > > However, for the given application (e.g. Gx) we may want to define a > narrower scope with "session-type = {M2M, Others}" AVP. So basically, > the Gx nodes can advertise different "required-reduction-percentage" > for M2M sessions v/s other type of sessions for the same application > Gx and for the same destination-host. > > > > So in general, if any application needs to define a different (i.e. > narrower) scope than application + host/realm, it can do so by adding > a new AVP in OC-OLR. > > And then we might have two instances of OC-OLR from the same host. > > > > We could achieve the above by defining new Report-Type for each new > AVP added by each application. But would this scale or is this a > reasonable approach? > > I am not sure and you have already identified one of my concerns below > > >if we extend ReportType, does it need to be done by IETF, or could it > be done per application by 3GPP? > > > > In summary, in my view, we need to define the handling of multiple > instances with the same Report-Type as part of the DOIC draft. Or we > say that multiple instances with the same Report-Type is not allowed > -- this seems unnecessary restriction to me. > > Otherwise, if later, we realize the need to do so then we may not be > able to do so since the handling is not defined in the base solution. > > > > Regards, > > Nirav. > > > > *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *Maria Cruz > Bartolome > *Sent:* Tuesday, December 03, 2013 1:57 PM > *To:* dime@ietf.org > *Subject:* Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the > same type) within a response message > > > > Nirav, > > > > I think I understand your concern. It may occur that we need that a > reacting node should apply two different OLR when sending a request > towards one specific host. > > Then, we may think that we need two different OLRs with > ReportType=host, and one of them includes the extra info (AVPs) > required for that application, I think this is your interpretation, > but... we can as well consider a new ReportType=applicX_ReportY, that > may apply e.g. for any request send to this application, or just for > this application+host, and then Host could be another AVP to be > included in the OLR, or we could define expected behaviour when > defining this new ReportType. > > > > Would this cover your concerns? If not, could you try to provide an > example that requires two OLR with ReportType=host? > > > > A part from that, a question for all, if we extend ReportType, does it > need to be done by IETF, or could it be done per application by 3GPP? > > > > Thanks > > /MCruz > > > > *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *Nirav Salot > (nsalot) > *Sent:* jueves, 28 de noviembre de 2013 17:11 > *To:* lionel.morand@orange.com > *Cc:* dime@ietf.org > *Subject:* Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the > same type) within a response message > > > > Hi Lionel, > > > > I am not sure if defining new ReportType for every new AVP 3GPP would > add for a specific application would be a good solution. > > I thought ReportType would indicate if the corresponding OC-OLR should > be used while sending the traffic towards the host or towards the realm. > > So from that point of view, all the OC-OLR generated by the server > should have ReportType=host. i.e. when the reacting node sends the > traffic towards that host, it should make use of the corresponding > OC-OLR. Now, this OC-OLR may contain the AVPs defined by DOIC draft as > well as 3GPP application specific AVPs. > > > > In general, I was just thinking that it may be good idea to define > some of the principles such as > > - More than one instances of OC-OLR with ReportType=host may > be present in the answer message if the OC-OLR definition is extended > by the application using the same. In that case, it is the > responsibility of the application to define the valid combination of > OC-OLR instances in a given message > > - If the reporting node includes more than one instance of > OC-OLR, the reporting node shall always include all the active > instances of OC-OLR in a response message. > > - When the reacting node receives one or more instances of > OC-OLR with the given ReportType and with new timestamp value, it > should overwrite all the existing OC-OLR of the same ReportType. > > > > Regards, > > Nirav. > > > > *From:*lionel.morand@orange.com > [mailto:lionel.morand@orange.com] > *Sent:* Thursday, November 28, 2013 7:39 PM > *To:* Nirav Salot (nsalot) > *Cc:* dime@ietf.org > *Subject:* RE: DOIC: Multiple instance of OC-OLR AVP (of the same > type) within a response message > > > > Hi Nirav, > > > > The Report Type should be able to differentiate such cases. In your > example, I would define a specific Report type. > > But difficult to appraise all the future use cases. But for me, the > main use of the report type is to differentiate OC-OLR received in the > same message. > > And it is the reasons of my recommendation. Actually, the exact > wording will be a "SHOULD" saying that it is recommended but you may > have serious reasons to do otherwise. > > > > Lionel > > > > *De :*Nirav Salot (nsalot) [mailto:nsalot@cisco.com] > *Envoyé :* jeudi 28 novembre 2013 13:00 > *À :* MORAND Lionel IMT/OLN > *Cc :* dime@ietf.org > *Objet :* RE: DOIC: Multiple instance of OC-OLR AVP (of the same type) > within a response message > > > > Lionel, > > 3gpp may define an optional avp which can be included by the reporting > node if it wishes to do so. E.g. APN can be additionally included by > the reporting node to indicate APN specific overload within the given > application. > In that case, the reporting node may also want to indicate application > level overload without including the APN (e.g. this overload report is > applicable to all other APNs). > > And hence there is a possibility of including multiple instances of > the overload report. > > I am not suggesting that 3gpp will define APN (or any other avp) > within overload report. But later, if 3gpp need to define the same, > then corresponding handling needs to be defined within IETF now. > > Regards, > Nirav. > > On Nov 28, 2013 3:56 PM, "lionel.morand@orange.com > " > wrote: > > Hi Nirav, > > > > Not sure to understand the proposal or question. > > The OLR is significant per application (piggybacking principle). So if > the 3GPP decides to add specific AVPs in the OLR (that will be > possible), what would be the need to add the OLR without the specific > 3GPP AVPs as the OLR will be anyway handle by 3GPP aware entities? > > > > Lionel > > > > *De :*DiME [mailto:dime-bounces@ietf.org] *De la part de* Nirav Salot > (nsalot) > *Envoyé :* jeudi 28 novembre 2013 10:33 > *À :* dime@ietf.org > *Objet :* [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same > type) within a response message > > > > Hi, > > > > As I understand IETF will define the base overload control solution as > part of DOIC. Then 3GPP would adopt the defined solution for each of > its application. > > When that happens, 3GPP might want to add 3GPP specific AVP within > OC-OLR AVP. Based on the current definition of the OC-OLR AVP this > should be allowed since it contains "* [AVP]" in its definition. > > e.g. for a given application 3GPP decides to add information into > OC-OLR which changes the scope of the OC-OLR from application level to > the provided information level. > > Additionally, the reporting may want to advertise the OC-OLR at the > application level scope -- i.e. the OC-OLR without any 3GPP specific info. > > > > So if the above is allowed, we will have the possibility of the > reporting node wanting to include two instances of OC-OLR with the > Report-Type="host". > > And then we need to define the handling of multiple instances of > OC-OLR in the DOIC draft. > > > > So the questions are, > > - Is 3GPP (or any other SDO) allowed to extend the definition > of OC-OLR by adding information into it? > > - If no, can we guarantee that application level scope of > OC-OLR (which is what we have defined currently) is sufficient (and > not restricting) to all the applications of 3GPP? > > > > Regards, > > Nirav. > > > > _________________________________________________________________________________________________________________________ > > 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 --------------060200020206020203010408 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Nirav,

If we allow AVPs to be added without a new report type then where will the behavior associated with the presence of that AVP be documented?

Requiring the definition of a new registered report type insures that implementers have a well defined place to go to find out how to deal with the presence of that AVP.

Steve
On 12/3/13 3:25 AM, Nirav Salot (nsalot) wrote:

Maria-Cruz,

 

> we may think that we need two different OLRs with ReportType=host, and one of them includes the extra info (AVPs) required for that application

Yes. The above is my concern. I tried giving APN as one example AVP which we may want to include in OC-OLR. Let me give another possible example.

As of now, the OC-OLR can indicate application + host/realm level "required-reduction-percentage".

However, for the given application (e.g. Gx) we may want to define a narrower scope with "session-type = {M2M, Others}" AVP. So basically, the Gx nodes can advertise different "required-reduction-percentage" for M2M sessions v/s other type of sessions for the same application Gx and for the same destination-host.

 

So in general, if any application needs to define a different (i.e. narrower) scope than application + host/realm, it can do so by adding a new AVP in OC-OLR.

And then we might have two instances of OC-OLR from the same host.

 

We could achieve the above by defining new Report-Type for each new AVP added by each application. But would this scale or is this a reasonable approach?

I am not sure and you have already identified one of my concerns below

> if we extend ReportType, does it need to be done by IETF, or could it be done per application by 3GPP?

 

In summary, in my view, we need to define the handling of multiple instances with the same Report-Type as part of the DOIC draft. Or we say that multiple instances with the same Report-Type is not allowed – this seems unnecessary restriction to me.

Otherwise, if later, we realize the need to do so then we may not be able to do so since the handling is not defined in the base solution.

 

Regards,

Nirav.

 

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Maria Cruz Bartolome
Sent: Tuesday, December 03, 2013 1:57 PM
To: dime@ietf.org
Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same type) within a response message

 

Nirav,

 

I think I understand your concern. It may occur that we need that a reacting node should apply two different OLR when sending a request towards one specific host.

Then, we may think that we need two different OLRs with ReportType=host, and one of them includes the extra info (AVPs) required for that application, I think this is your interpretation, but… we can as well consider a new ReportType=applicX_ReportY, that may apply e.g. for any request send to this application, or just for this application+host, and then Host could be another AVP to be included in the OLR, or we could define expected behaviour when defining this new ReportType.

 

Would this cover your concerns? If not, could you try to provide an example that requires two OLR with ReportType=host?

 

A part from that, a question for all, if we extend ReportType, does it need to be done by IETF, or could it be done per application by 3GPP?

 

Thanks

/MCruz

 

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Nirav Salot (nsalot)
Sent: jueves, 28 de noviembre de 2013 17:11
To: lionel.morand@orange.com
Cc: dime@ietf.org
Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same type) within a response message

 

Hi Lionel,

 

I am not sure if defining new ReportType for every new AVP 3GPP would add for a specific application would be a good solution.

I thought ReportType would indicate if the corresponding OC-OLR should be used while sending the traffic towards the host or towards the realm.

So from that point of view, all the OC-OLR generated by the server should have ReportType=host. i.e. when the reacting node sends the traffic towards that host, it should make use of the corresponding OC-OLR. Now, this OC-OLR may contain the AVPs defined by DOIC draft as well as 3GPP application specific AVPs.

 

In general, I was just thinking that it may be good idea to define some of the principles such as

-          More than one instances of OC-OLR with ReportType=host may be present in the answer message if the OC-OLR definition is extended by the application using the same. In that case, it is the responsibility of the application to define the valid combination of OC-OLR instances in a given message

-          If the reporting node includes more than one instance of OC-OLR, the reporting node shall always include all the active instances of OC-OLR in a response message.

-          When the reacting node receives one or more instances of OC-OLR with the given ReportType and with new timestamp value, it should overwrite all the existing OC-OLR of the same ReportType.

 

Regards,

Nirav.

 

From: lionel.morand@orange.com [mailto:lionel.morand@orange.com]
Sent: Thursday, November 28, 2013 7:39 PM
To: Nirav Salot (nsalot)
Cc: dime@ietf.org
Subject: RE: DOIC: Multiple instance of OC-OLR AVP (of the same type) within a response message

 

Hi Nirav,

 

The Report Type should be able to differentiate such cases. In your example, I would define a specific Report type.

But difficult to appraise all the future use cases. But for me, the main use of the report type is to differentiate OC-OLR received in the same message.

And it is the reasons of my recommendation. Actually, the exact wording will be a "SHOULD" saying that it is recommended but you may have serious reasons to do otherwise.

 

Lionel

 

De : Nirav Salot (nsalot) [mailto:nsalot@cisco.com]
Envoyé : jeudi 28 novembre 2013 13:00
À : MORAND Lionel IMT/OLN
Cc : dime@ietf.org
Objet : RE: DOIC: Multiple instance of OC-OLR AVP (of the same type) within a response message

 

Lionel,

3gpp may define an optional avp which can be included by the reporting node if it wishes to do so. E.g. APN can be additionally included by the reporting node to indicate APN specific overload within the given application.
In that case, the reporting node may also want to indicate application level overload without including the APN (e.g. this overload report is applicable to all other APNs).

And hence there is a possibility of including multiple instances of the overload report.

I am not suggesting that 3gpp will define APN (or any other avp) within overload report. But later, if 3gpp need to define the same, then corresponding handling needs to be defined within IETF now.

Regards,
Nirav.

On Nov 28, 2013 3:56 PM, "lionel.morand@orange.com" <lionel.morand@orange.com> wrote:

Hi Nirav,

 

Not sure to understand the proposal or question.

The OLR is significant per application (piggybacking principle). So if the 3GPP decides to add specific AVPs in the OLR (that will be possible), what would be the need to add the OLR without the specific 3GPP AVPs as the OLR will be anyway handle by 3GPP aware entities?

 

Lionel

 

De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot (nsalot)
Envoyé : jeudi 28 novembre 2013 10:33
À : dime@ietf.org
Objet : [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same type) within a response message

 

Hi,

 

As I understand IETF will define the base overload control solution as part of DOIC. Then 3GPP would adopt the defined solution for each of its application.

When that happens, 3GPP might want to add 3GPP specific AVP within OC-OLR AVP. Based on the current definition of the OC-OLR AVP this should be allowed since it contains "* [AVP]" in its definition.

e.g. for a given application 3GPP decides to add information into OC-OLR which changes the scope of the OC-OLR from application level to the provided information level.

Additionally, the reporting may want to advertise the OC-OLR at the application level scope – i.e. the OC-OLR without any 3GPP specific info.

 

So if the above is allowed, we will have the possibility of the reporting node wanting to include two instances of OC-OLR with the Report-Type="host".

And then we need to define the handling of multiple instances of OC-OLR in the DOIC draft.

 

So the questions are,

-          Is 3GPP (or any other SDO) allowed to extend the definition of OC-OLR by adding information into it?

-          If no, can we guarantee that application level scope of OC-OLR (which is what we have defined currently) is sufficient (and not restricting) to all the applications of 3GPP?

 

Regards,

Nirav.

 

_________________________________________________________________________________________________________________________
 
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

--------------060200020206020203010408-- From ulrich.wiehe@nsn.com Tue Dec 3 07:35:27 2013 Return-Path: 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 81DBB1AE168 for ; Tue, 3 Dec 2013 07:35:27 -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 yNSV_adU9dy2 for ; Tue, 3 Dec 2013 07:35:22 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 3B36B1ADFE6 for ; Tue, 3 Dec 2013 07:35:21 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rB3FZG3k022767 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 3 Dec 2013 16:35:16 +0100 Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rB3FZG5k007727 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Dec 2013 16:35:16 +0100 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.123.3; Tue, 3 Dec 2013 16:35:16 +0100 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.152]) by DEMUHTC013.nsn-intra.net ([10.159.42.44]) with mapi id 14.03.0123.003; Tue, 3 Dec 2013 16:35:15 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: ext Maria Cruz Bartolome , "dime@ietf.org" Thread-Topic: Ongoing Throttling Information in request messages Thread-Index: Ac7aQPqQ1tyE3SNOTC+vVrUogwBrJQAnWH+wAADoRNAABgE0oAAA57DwAACoAlAAASWEQAAAqKUAACDdWeAAAz9GUAABLecQAA4Qc8ABE6PKsABJVfJQASwtPKACh2J2UAABYVvwAAWQLLAAAbm+kA== Date: Tue, 3 Dec 2013 15:35:14 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519D459@DEMUMBX014.nsn-intra.net> References: <5BCBA1FC2B7F0B4C9D935572D9000668151918EC@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D900066815192B2B@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D900066815192B90@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D900066815192BF7@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D900066815192CD2@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D900066815192D5F@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681519337D@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D900066815193EFD@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B920972BF81@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D90006681519D35C@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B920972C1BB@ESESSMB101.ericsson.se> In-Reply-To: <087A34937E64E74E848732CFF8354B920972C1BB@ESESSMB101.ericsson.se> 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: 29666 X-purgate-ID: 151667::1386084916-00006154-BABC2FBA/0-0/0-0 Subject: Re: [Dime] Ongoing Throttling Information in request messages X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 15:35:27 -0000 Hi, thank you again. See answers below Regards Ulrich -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto= lome Sent: Tuesday, December 03, 2013 3:30 PM To: dime@ietf.org Subject: Re: [Dime] Ongoing Throttling Information in request messages Hello, See comments below Regards MCruz -----Original Message----- From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 Sent: martes, 03 de diciembre de 2013 13:21 To: Maria Cruz Bartolome; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Hi MCruz, thank you for your comments. What is your interpretation of REQ10? Which interpretation other than "when= overload condition ends at the server, client must be able to detect this"= is reasonable? [MCruz] I already read some other people interpretations... I think "when" = may not be interpreted as an exact point in time, but if could be more loos= ely interpreted as that the client should be able to know whether or not th= e need to continue executing any abatement mechanism. But... I just wanted = to highlight that in my opinion, this is not key for selecting one option o= r another. With regard to robustness (see 4) below): If for any reason (attacker, misconfiguration,...) a wrong throttling is pe= rformed by the client, the server is able to immediately detect and correct= this in option B). [MCruz] But, option A keeps sending OLR with any answer, why do you think o= ption B is more robust than option A? [Wiehe, Ulrich (NSN - DE/Munich)] In option A lets assume a client receives= an (correct) OLR1 with timestamp =3D t0 requesting a 10% reduction. After = that the client receives an (incorrect) OLR2 (from attacker or misconfigure= d source, or whatever..) with timestamp =3D t0+x requesting a 80% reduction= . The client would override OLR1 with OLR2. After that the client receives = the (correct replayed) OLR1 again with timestamp t1 and 10%. Wouldn't the c= lient have to ignore the replayed OLR1 as the timestamp is older than the t= imestamp in the stored OLR2? With regard to the trade of between REQ18 and REQ13 (see 4) below): Option B allows to leave the decision to implementations (even dynamically)= =20 [MCruz] I presume you refer to the proposal you made in another mail, but c= ould you confirm? [Wiehe, Ulrich (NSN - DE/Munich)] not exactly, but this is similar: In option B) - reporting nodes that are in overload may either=20 a) honor REQ18 and treat non throttled traffic differently than throttled t= raffic or b) do no treat throttled traffic and non throttled traffic differently (if = this is regarded too costly) In option A) there is no choice but only b). ..................... a) executing some logic (timestamp check) always + sending OLR only in the = very few cases where it is needed is more expensive (in terms or resource c= onsumption contributing to overload) than b) sending OLR always One approach could be to - mandate sending of Ongoing-Throttling-Information(TimeStamp) in request m= essages by acting nodes while performing throttling - reporting nodes that are in overload may either do a) or b) whatever is r= egarded less resource consuming by the implementation - reporting nodes that are not (no longer) overloaded must do a) ......................... while option A takes a numb decision against REQ18. Also note that it is no= t only the (overloaded) server but also the (not at all overloaded) agent t= hat could fulfill REQ18 without contravening REQ13 in option B. Best regards Ulrich =20 -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto= lome Sent: Tuesday, December 03, 2013 12:19 PM To: dime@ietf.org Subject: Re: [Dime] Ongoing Throttling Information in request messages Hello, See some comments below Best regards /MCruz -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN -= DE/Munich) Sent: mi=E9rcoles, 20 de noviembre de 2013 16:25 To: ext Nirav Salot (nsalot); dime@ietf.org Subject: Re: [Dime] Ongoing Throttling Information in request messages Nirav, thank you for your confirmation. In order to select the best solution let me try to start a comparism: 1) A1 can be compared with B1 as both require to insert an AVP in every mes= sage (answer/request, while overloaded/while performing throttling): A1 add= s (resource consuming) functionality to the (overloaded) server/reporting n= ode while B1 adds to the client/reacting node. Furthermore, the AVP to be i= nserted in A1 (OC-OLR) is the only OC-specific AVP to be inserted to the an= swer whereas the AVP to be inserted in B1 (OC-Ongoing-Throttling-Informatio= n) would be in addition to the OC-Feature-Vector which anyway needs to be a= dded to every request (inserting OC specific info to requests is needed any= way). Furthermore A1 seems to violate REQ 13 from RFC 7068 while B1 does no= t. All this clearly is a pro for option B. 2) A2 can be compared with B2: A2 either requires additional processing at = the server/reporting node or relies on timouts (violating REQ 10) while B2 = does not require any corresponding functionality. This is also a pro for Op= tion B. [MCruz] Violation of REQ10 I think may be subject to interpretation (I woul= d think the requirement text could be improved though...). Then, for this c= omparison I am not sure this is a key factor. 3) A3 can be compared with B3 as both recommend to check the presence of ne= w OC-specific info in all received messages: A3 adds the recommended functi= onality to the (overloaded) server/reporting node while B3 adds to the clie= nt/reacting node. This is a pro for option A. [MCruz] I presume you meant " _B3_ adds the recommended functionality to th= e (overloaded) server/reporting node while _A3_ adds to the client/reacting= node Here we can question whether option B violates REQ13 from RFC7068 whi= le A does not. Then, key question is to compare how much work implies each = option to an overloaded server. Not easy to get a conclusion since it could= depend a lot on implementation. 4) Option B adds a feedback channel from client to server making the soluti= on more robust.=20 [MCruz] More robust? In which sense? It also allows the server to give some priority to already throttled traffi= c (see REQ 18) and it allows agents to ensure that already throttled traffi= c (by a downstream node) is not throttled again. This is a pro for option B= . [MCruz] In my opinion this is the best advantage of solution B over A. But,= we need to highlight as well that if server needs (e.g.) to throttle traff= ic that is not being throttled, then this helps to fulfill REQ-18, but it i= s against REQ13. Then, if we need to fulfill REQ13 as much as possible, the= n this advantage vanishes. 5) In Option A it is not clear how the client/reacting node should behave w= hen it receives an answer without OC-OLR AVP while performing throttling. T= his is a con for option A. In summary my preference is for option B. Comments are welcome. Ulrich -----Original Message----- From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Sent: Thursday, November 14, 2013 3:54 PM To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Ulrich, I confirm the summary below of having two valid options. Just wanted to highlight one aspect, in general. Current definition of the OC-OLR AVP suggest the inclusion of TimeStamp and= ValidityDuration AVPs. And these AVPs are applicable/valid/needed in both = the options below. Additionally, if we decide to go for option B, we would need to define new = AVP OC-Ongoing-Throttling-Information AVP. Regards, Nirav. -----Original Message----- From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Sent: Wednesday, November 13, 2013 9:03 PM To: Nirav Salot (nsalot); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Nirav, in summary it seems that we have two valid options: Option A:=20 A1: the server (or reporting node), while overloaded must insert the load O= C-OLR AVP in every answer message. A2: the server (or reporting node) after leaving the overload state must co= ntinue inserting the OC-OLR AVP (indicating end of throttling request) for = some time (how long needs to be calculated by the server) or the server mus= t rely on expiry of outdated overload reports. A3: the reacting node must/should check the timeStamp in every OC-OLR AVP r= eceived in answer messages in order not to miss an update. Option B: B1: the reacting node, while performing throttling, must insert the OC-Ongo= ing-Throttling-Information in every request message. B2: void (the reacting node , while no longer throttling, simply does not i= nsert OC-Ongoing-Throttling-Information) B3: the reporting node must/should check OC-Ongoing-Throttling-Information = received in a request in order to decide whether or not OC-OLR must be sent= back.=20 Ulrich -----Original Message----- From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Sent: Thursday, November 07, 2013 5:29 PM To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Ulrich, Not sure the significance of REQ 10 here but I do not agree to enforce the = server to include overload-report (indicating non-zero or zero overload con= dition) in every message. Even in your example, the overload condition will end sometime - e.g. after= 1000 sec. and then the server can stop including the overload-report. Besides, I am still not convince that "during the overload condition, using= some logic to avoid inclusion of overload-report is less resource consumin= g than simply including the same overload-report". Yes, the reason behind defining timestamp is to allow the reacting node to = discard the overload-report if the same was already received from the repor= ting node. Regards, Nirav. -----Original Message----- From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Sent: Thursday, November 07, 2013 3:53 PM To: Nirav Salot (nsalot); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Nirav, please see inline. Best regards Ulrich -----Original Message----- From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Sent: Thursday, November 07, 2013 10:15 AM To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Ulrich, Please read my responses inline. Regards, Nirav. -----Original Message----- From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Sent: Thursday, November 07, 2013 1:54 PM To: Nirav Salot (nsalot); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Nirav, thank you for the explanation. This may be a solution which adds more comp= lexity to the reporting node: The reporting node must remember the maximum = not yet expired fraction of duration values it sent when leaving the overlo= ad state and must continue reporting "end of overload condition" until expi= ry. (there is no corresponding complexity at the reacting node in my propos= al) [Nirav] This is not always true, e.g. as I had indicated if the node ha= s advertised 10% reduction-percentage for 10 sec., it need not bother to ad= vertise no-overload condition since the validity-period was very small. [Ulrich] Also not always true, e.g. if the reporting node has requested at = 20% reduction for 1000sec at t1 and then at t1 + 10sec sends an update to r= equest a 10% reduction for 10 sec. Although the validity-period is small (1= 0 sec) there may still be a reacting node that did not get the update and k= eeps on throttling by 20% until t1 + 1000sec. Furthermore you seem not to t= ake REQ 10 seriously. My understanding was that timeout is last resort, not= the normal way. Another question: While doing a throttling, what is the expected behaviour = of the reacting node when receiving an answer message without OC-OLR AVP? (= stop/continue throttling?) (there is no corresponding question in my propos= al since not sending of OC-Ongoing-Throttling-Information clearly means tha= t throttling is not in place) [Nirav] The reacting node should continue to = apply the earlier received OC-OLR.=20 " (Note: We seem to have consensus that a server MAY repeat OLRs in subsequent messages, but is not required to do so, based on local policy.)" [Ulrich] This needs to be reconsidered. See the following example: Non supporting client C1 sends a request via supporting agent A1 to Server = S. S returns a 10% throttling request.=20 C sends an new request via supporting agent A2 to S.=20 S decides not to repeat the 10% throttling request (hence A2 is not aware o= f the throttling request).=20 C1 sends a new request via A1.=20 S decides to repeat the throttling request (redundant).=20 Supporting client C2 sends a request via A2 to S. S decides not to repeat.... To avoid this mess we either need to mandate sending OC-OLR in every answer= (while in overload) or let the Server keep track which agent and which cli= ent is updated with the newest info. (or consider my proposal). Another question is for the reacting node: What is the expected behaviour w= hen receiving lots of redundant OC-OLR AVPs in answer messages? The reactin= g node needs to check every single OC-OLR AVP in order to find out whether = it contains an update. Is that the correct understanding? (this seems to be= equivalent to checking for redundant OC-Ongoing-Throttling-Information AVP= s in every request by the reporting node in my proposal) [Nirav] Please ref= er to Timestamp AVP within OC-OLR. The TimeStamp AVP indicates when the original OC-OLR AVP with the current content was created. It is possible to replay the same OC- OLR AVP multiple times between the overload endpoints, however, when the OC-OLR AVP content changes or the other information sending endpoint wants the receiving endpoint to update its overload control information, then the TimeStamp AVP MUST contain a new value. [Ulrich] This does not explicitly say that the reacting node must check eve= ry TimeStamp received within OC-OLR AVPs. But I guess this is the consequen= ce. Can you please confirm. Adding dime-list again. Ulrich From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Sent: Wednesday, November 06, 2013 4:58 PM To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org Subject: RE: Ongoing Throttling Information in request messages Ulrich, During "no overload condition", why should reporting node include overload-= information in all the answer messages? e.g. if the reporting node has advertised overload-report with period-of-va= lidity=3D10 sec., it knows that after that period all the reacting node wil= l automatically stop applying any overload mitigation action. And hence it = does not need to explicitly send any overload-report indicating "no overloa= d condition". In general, I assume that overload period of would be much shorter as compa= red to "no overload" period. And hence I do not see reason to always includ= e overload-report. Regards, Nirav. From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Sent: Wednesday, November 06, 2013 9:12 PM To: Nirav Salot (nsalot); doc-dt@ietf.org Subject: RE: Ongoing Throttling Information in request messages Nirav, "During the overload" yes I agree, but "when no longer in overload" all ans= wer messages would contain the information "no longer in overload" while on= ly few request messages would contain the Ongoing-Throttling-Information. Removing dime-list which bounces. Best regards Ulrich From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Sent: Wednesday, November 06, 2013 4:02 PM To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Ulrich, I might be missing something here so please bear with me. Number of answer messages sent by server =3D number of request messages rec= eived by the server. During the overload, the server would receive only those requests which sur= vived throttling. And then the server would send answer messages to only those request messag= es. So "every" and "some" are actually equal in the below equation. No? Regards, Nirav. From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Sent: Wednesday, November 06, 2013 8:24 PM To: Nirav Salot (nsalot); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Nirav, Not quite. The question is: "is sending an overload-report in every answer message that corresponds to = request with OC-Feature-Vector present more resource consuming than receivi= ng Ongoing-Throttling-Information in some request messages (only those that= survived a throttling)?" Best regards Ulrich From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Sent: Wednesday, November 06, 2013 3:15 PM To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Ulrich, Thanks for clarification. Then the question would be "is sending overload-report in every answer message is more resource consum= ing than the solution below - i.e. receiving OC-Ongoing-Throttling-Informat= ion in all request message and analyzing the timestamp and then deciding if= the overload-report should be included or not." I am not sure. Regards, Nirav. From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Sent: Wednesday, November 06, 2013 7:08 PM To: Nirav Salot (nsalot); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Nirav, thank you for your comments. The comparism is between: Current way: "send OC specific information (Feature-Vector) in every reques= t message and in every corresponding answer message" My proposal: "send OC specific information (Feature-Vector and in some case= s Ongoing-Throttling-Info) in every request message and in corresponding an= swer messages only when required". Sending OC specific information =A0is regarded a resource consuming action = and we should not put this action to the (overloaded) server where avoidabl= e. See REQ 13. Best regards Ulrich From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Sent: Wednesday, November 06, 2013 12:04 PM To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Ulrich, Thanks for the detail explanation of your proposal. Just to verify my understanding, Your proposal would allow the reporting node to avoid inclusion of the "sam= e" overload-report in the answer message since the request message indicate= s that the path contains at least one reacting node which already has the l= atest overload-report. In other words, the reporting node need not include overload-report in ever= y message, blindly. To achieve the above objective, the solution below suggest the reacting nod= e to include new AVP OC-Ongoing-Throttling-Information in every request mes= sage, which survives throttling. So the net result is that, the inclusion of the overload-report is prevente= d in every answer message since the OC-Ongoing-Throttling-Information is in= cluded in every request message. [Wiehe, Ulrich (NSN - DE/Munich)] no.=A0 .in every request message that sur= vived a throttling. And hence I am not sure if the solution has sound benefit from the inclusio= n of redundant information point of view. In summary, I think the solution suggested below works as explained. But I fail to see the benefit of using this solution compare to a solution = in which the reporting node includes overload-report in every answer messag= e. Regards, Nirav. From: doc-dt-bounces@ietf.org [mailto:doc-dt-bounces@ietf.org] On Behalf Of= Wiehe, Ulrich (NSN - DE/Munich) Sent: Tuesday, November 05, 2013 9:36 PM To: doc-dt@ietf.org; dime@ietf.org Subject: [doc-dt] Ongoing Throttling Information in request messages Hi, draft-docdt-dime-ovli-01 in Appendix B, Table 1, REQ 13 says: =A0=A0=A0=A0=A0=A0=A0 .. Another way =A0=A0=A0=A0=A0=A0=A0 is to let the request sender (reacting node) insert =A0=A0=A0=A0=A0=A0=A0 information in the request to say whether a =A0=A0=A0=A0=A0=A0=A0 throttling is actually performed.=A0 The reporting no= de =A0=A0=A0=A0=A0=A0=A0 then can base its decision on information received in =A0=A0=A0=A0=A0=A0=A0 the request; no need for keeping state to record who =A0 has received overload reports.=A0=20 =A0 And in Appendix B, Table 1, REQ 18: =A0=A0=A0=A0=A0=A0=A0 There has been a proposal to mark =A0=A0=A0=A0=A0=A0=A0 messages that survived overload throttling as one =A0=A0=A0=A0=A0=A0=A0 method for an overloaded node to address fairness but =A0=A0=A0=A0=A0=A0=A0 this proposal is not yet part of the solution.=A0=20 =A0 I would like to come back to this proposal.=20 A new AVP OC-Ongoing-Throttling-Information inserted in request messages wo= uld indicate that the request message survived a throttling. Furthermore, i= nformation within the AVP indicates the TimeStamp as received in the previo= us OC-OLR AVP, according to which the ongoing throttling (which was survive= d) is performed. =A0 OC-Ongoing-Throttling-Information ::=3D < AVP Header: TBD9 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 < TimeStamp > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * [ AVP ] =A0 Supporting Clients would insert the OC-Ongoing-Throttling-Information AVP= =A0 into request messages that survived a throttling performed at that clie= nt. Supporting Agents when receiving a request message that contains an OC-Ongo= ing-Throttling-Information AVP would not perform an additional throttling (= since the client or a downstream agent already performed the throttling) , = while, when receiving a request that does not contain OC-Ongoing-Throttling= -Information AVP would perform throttling (on behalf of the client) accordi= ng to a previously received and stored OC-OLR, and if that throttling is su= rvived the agent would insert the OC-Ongoing-Throttling-Information AVP in = the request before sending it further upstream. Servers (or in general reporting nodes) would check presence and content of= the OC-Ongoing-Throttling-Information AVP in received request messages and= could detect (together with a check of presence of OC-Feature-Vector AVP) = whether inserting an OC-OLR AVP in the corresponding answer message is need= ed in order to update the reacting node with a new OC-OLR). =A0 This proposal especially addresses use cases like the following: =A0 Architecture: =A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +-------= ---------+ =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | suppor= ting=A0=A0=A0=A0 | =A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 /| agent A1= =A0=A0=A0=A0=A0=A0 |\ =A0 +----------------+ / +----------------+ \ =A0 | non supporting |/=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 \ =A0 | client C=A0=A0=A0=A0=A0=A0 |\=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 \ =A0 +----------------+ \ +----------------+=A0=A0=A0 \ +------------+=A0=A0= =A0 +---------+ =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 \| non supp= orting |=A0=A0=A0=A0 \| supporting | =A0=A0 | Server=A0 | =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 age= nt A2=A0=A0=A0=A0=A0 |------| agent A3=A0=A0 |----|=A0 S=A0=A0=A0=A0=A0 | =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0 +------------= ----+=A0=A0=A0=A0=A0 +------------+=A0=A0=A0 +---------+ =A0 1. A request is sent from C via A2 and A3 to S. A3 recognizes that there is= no reacting node downstream (no OC-Feature-Vector received) and therefore = takes the role of the reacting node and inserts an OC-Feature-Vector AVP. A= 3 has no valid OLR from S stored and therefore does not perform throttling = and does not insert an OC-Throttling-Information AVP. 2. S recognizes that there is a reacting node downstream which is actually = not performing a throttling. S returns a 10% throttling request (TimeStamp= =3Dt1, duration=3Dd) within OC-OLR in the answer which goes back via A3 and= A2 to C. 3. A3 stores the 10% throttling request. 4. A new request is sent from C via A2 and A3 to S. A3 recognizes that ther= e is no reacting node downstream (no OC-Feature-Vector received) and theref= ore takes the role of the reacting node and inserts an OC-Feature-Vector AV= P. A3 has=A0 valid OLR from S stored and performs a 10% throttling. The req= uest survives and A3 inserts an OC-Throttling-Information AVP with timeStam= p=3Dt1. 5. S recognizes that correct throttling (correct time stamp) is in place an= d therefore does not return OC-OLR in the answer. 6. A new request is sent from C via A1 and A3 to S. A1 recognizes that ther= e is no reacting node downstream (no OC-Feature-Vector received) and theref= ore takes the role of the reacting node and inserts an OC-Feature-AVP. A1 h= as no valid OLR from S stored and therefore does not perform throttling and= does not insert an OC-Throttling-Information AVP. A3 recognizes that there= is a reacting node downstream (OC-Feature-Vector received) and therefore d= oes not take the role of the reacting node. 7. S recognizes that there is a reacting node downstream which is actually = not performing a throttling. S returns a 10% throttling request (TimeStamp= =3Dt1, duration=3Dd) within OC-OLR in the answer which goes back via A3 and= A1 to C. 8. A1 stores the 10% throttling request. 9. A new request is sent from C via A1 and A3 to S. A1 recognizes that ther= e is no reacting node downstream (no OC-Feature-Vector received) and theref= ore takes the role of the reacting node and inserts an OC-Feature-AVP. A1 h= as=A0 valid OLR from S stored and therefore performs a 10% throttling. The = request survives and A1 inserts an OC-Throttling-Information AVP with timeS= tamp=3Dt1. A3 recognizes that there is a reacting node downstream (OC-Featu= re-Vector received) and therefore does not take the role of the reacting no= de. 10. S recognizes that correct throttling (correct time stamp) is in place a= nd therefore does not return OC-OLR in the answer. 11. Requests sent from C via A1 and A3 to S undergo a 10% throttling at A1,= requests sent from C via A2 and A3 to S undergo a 10% throttling at A3. 12. Overload situation in S for some reason gets worse, S decides to reques= t 20 % reduction. 13. A new request is sent from C via A1 and A3 to S. A1 recognizes that the= re is no reacting node downstream (no OC-Feature-Vector received) and there= fore takes the role of the reacting node and inserts an OC-Feature-AVP. A1 = has=A0 valid OLR from S stored and therefore performs a 10% throttling. The= request survives and A1 inserts an OC-Throttling-Information AVP with time= Stamp=3Dt1. A3 recognizes that there is a reacting node downstream (OC-Feat= ure-Vector received) and therefore does not take the role of the reacting n= ode. 14. S recognizes that incorrect throttling (wrong time stamp) is in place a= nd therefore S returns a 20% throttling request (TimeStamp=3Dt2, duration= =3Dx) within OC-OLR in the answer which goes back via A3 and A1 to C. 15. A3 (not taking the role of the reactingt node)may, A1 must store the 20= % throttling request (replacing the 10% request). 16. A new request is sent from C via A2 and A3 to S. A3 recognizes that the= re is no reacting node downstream (no OC-Feature-Vector received) and there= fore takes the role of the reacting node and inserts an OC-Feature-Vector A= VP. A3 has=A0 valid OLR from S stored and performs a 10% throttling. The re= quest survives and A3 inserts an OC-Throttling-Information AVP with timeSta= mp=3Dt1. (assuming A3 did not store the 20% request at step 14) 17. S recog= nizes that incorrect throttling (wrong time stamp) is in place and therefor= e S returns a 20% throttling request (TimeStamp=3Dt2, duration=3Dx) within = OC-OLR in the answer which goes back via A3 and A2 to C. 18. A3 stores the 20% throttling request (replacing the 10% request). 19. Requests sent from C via A1 and A3 to S undergo a 20% throttling at A1,= requests sent from C via A2 and A3 to S undergo a 20% throttling at A3. =A0 =A0 Comments are welcome. =A0 Best regards Ulrich =A0 =A0 _______________________________________________ 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 From srdonovan@usdonovans.com Tue Dec 3 07:39:48 2013 Return-Path: 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 ED5511AE19A for ; Tue, 3 Dec 2013 07:39:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no 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 RSNsVamNxfja for ; Tue, 3 Dec 2013 07:39:46 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 6931B1AE187 for ; Tue, 3 Dec 2013 07:39:46 -0800 (PST) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:50135 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1Vns4Z-00064i-8u for dime@ietf.org; Tue, 03 Dec 2013 07:39:43 -0800 Message-ID: <529DFB3B.3080109@usdonovans.com> Date: Tue, 03 Dec 2013 09:39:39 -0600 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: dime@ietf.org References: <087A34937E64E74E848732CFF8354B920972BE0C@ESESSMB101.ericsson.se> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080302000405000505090503" X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com Subject: Re: [Dime] OLR applicable for any/all applications X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 15:39:49 -0000 This is a multi-part message in MIME format. --------------080302000405000505090503 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Nirav, Agents handle multiple applications over a single connection. It is also possible that implementations can support multiple 3GPP functions in a single node. For instance, someone might decide to implement a combined HSS and EIR, causing the MME to communicate S6a and S13 over the same connection. Steve On 12/3/13 3:41 AM, Nirav Salot (nsalot) wrote: > > Maria-Cruz, > > > > The existing OC-OLR definition (without "All Application" AVP) already > addresses your use case. E.g. reporting node includes same value of > "Reduction-Percentage" in all the application messages sent by it. So > we don't need "All Application" AVP additionally. > > Besides, reporting "Reduction-Percentage" of a different application > violates the basic principle of the piggybacking. > > Finally, in 3GPP (as far as I remember) we do not have any use case of > two nodes interfacing with each other over more than one application. > i.e. we have only one application between any pair of nodes and if > that is so then I fail to see the practicality of the use case you > have mentioned below. > > > > Regards, > > Nirav. > > > > *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *Maria Cruz > Bartolome > *Sent:* Tuesday, December 03, 2013 2:13 PM > *To:* dime@ietf.org > *Subject:* [Dime] OLR applicable for any/all applications > > > > > > Dear all, > > > > There may be a need by a reporting node to request traffic reduction > for all traffic, application independent, e.g. if an operator's > network becomes severely overloaded, it may be of interest to signal > directly general overload to the client. > > In this case, since reacting node obtains affected application from > the application message, we may need to extend OLR. > > > > At least we got following options: > > > > > > A) Define a new optional AVP that could be included into OLR, like > e.g.: > > OC-OLR ::= < AVP Header: TBD2 > > < TimeStamp > > [ Reduction-Percentage ] > [ ValidityDuration ] > [ ReportType ] > [All applications] > * [ AVP ] > > > > > > B) Extend ReportTypes like e.g.: > > > > 3 Destination-Host All Applications report. Similar to > Destination-Host report but it would apply to any application > regardless the application message this report is received within. > > > > 4 Realm (aggregated) All Applicationsreport. Similar to Realm > report but it would apply to any application regardless the > application message this report is received within. > > > > > > > > I tend to prefer option A, but let me know your opinions and preferences. > > Best regards > > /MCruz > > > > > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime --------------080302000405000505090503 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Nirav,

Agents handle multiple applications over a single connection.

It is also possible that implementations can support multiple 3GPP functions in a single node.  For instance, someone might decide to implement a combined HSS and EIR, causing the MME to communicate S6a and S13 over the same connection.

Steve
On 12/3/13 3:41 AM, Nirav Salot (nsalot) wrote:

Maria-Cruz,

 

The existing OC-OLR definition (without "All Application" AVP) already addresses your use case. E.g. reporting  node includes same value of "Reduction-Percentage" in all the application messages sent by it. So we don’t need "All Application" AVP additionally.

Besides, reporting "Reduction-Percentage" of a different application violates the basic principle of the piggybacking.

Finally, in 3GPP (as far as I remember) we do not have any use case of two nodes interfacing with each other over more than one application. i.e. we have only one application between any pair of nodes and if that is so then I fail to see the practicality of the use case you have mentioned below.

 

Regards,

Nirav.

 

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Maria Cruz Bartolome
Sent: Tuesday, December 03, 2013 2:13 PM
To: dime@ietf.org
Subject: [Dime] OLR applicable for any/all applications

 

 

Dear all,

 

There may be a need by a reporting node to request traffic reduction for all traffic, application independent, e.g. if an operator’s network becomes severely overloaded, it may be of interest to signal directly general overload to the client. 

In this case, since reacting node obtains affected application from the application message, we may need to extend OLR.

 

At least we got following options:

 

 

A)     Define a new optional AVP that could be included into OLR, like e.g.:

   OC-OLR ::= < AVP Header: TBD2 >
              < TimeStamp >
              [ Reduction-Percentage ]
              [ ValidityDuration ]
              [ ReportType ]
              [All applications]
            * [ AVP ]

 

 

B)      Extend  ReportTypes like e.g.:

 

   3  Destination-Host All Applications report.  Similar to Destination-Host report but it would apply to any application regardless the application message this report is received within.

 

   4  Realm (aggregated) All Applications report.  Similar to Realm report but it would apply to any application regardless the application message this report is received within.

 

 

 

I tend to prefer option A, but let me know your opinions and preferences.

Best regards

/MCruz

 

 



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

--------------080302000405000505090503-- From srdonovan@usdonovans.com Tue Dec 3 07:43:20 2013 Return-Path: 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 458A51AE120 for ; Tue, 3 Dec 2013 07:43:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no 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 MHzT9AatXAEi for ; Tue, 3 Dec 2013 07:43:16 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 236871AE078 for ; Tue, 3 Dec 2013 07:43:16 -0800 (PST) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:50138 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1Vns7v-0001oj-Ma for dime@ietf.org; Tue, 03 Dec 2013 07:43:13 -0800 Message-ID: <529DFC0A.4000705@usdonovans.com> Date: Tue, 03 Dec 2013 09:43:06 -0600 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: dime@ietf.org References: <087A34937E64E74E848732CFF8354B920972BE0C@ESESSMB101.ericsson.se> <23791_1386069626_529DBE7A_23791_980_1_6B7134B31289DC4FAF731D844122B36E312AF4@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <23791_1386069626_529DBE7A_23791_980_1_6B7134B31289DC4FAF731D844122B36E312AF4@PEXCVZYM13.corporate.adroot.infra.ftgroup> Content-Type: multipart/alternative; boundary="------------090704040507020507010408" X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com Subject: Re: [Dime] OLR applicable for any/all applications X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 15:43:20 -0000 This is a multi-part message in MIME format. --------------090704040507020507010408 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Personally I like Maria-Cruz's suggestion. But I am also on the side of including the application-id in the overload report in the first place. On a related note, the agent overload extension will likely default to being all applications. We will need to decide if we allow for getting more specific by allowing the agent to include a list of impacted applications. Steve On 12/3/13 5:20 AM, lionel.morand@orange.com wrote: > > Hi Maria-Cruz, > > > > I agree with Nirav's comment: No need of such optimization. OLR is per > application and if more than one application is used between nodes, > the OLR will be received on the application related answers. > > > > Regards, > > > > Lionel > > > > *De :*DiME [mailto:dime-bounces@ietf.org] *De la part de* Nirav Salot > (nsalot) > *Envoyé :* mardi 3 décembre 2013 10:41 > *À :* Maria Cruz Bartolome; dime@ietf.org > *Objet :* Re: [Dime] OLR applicable for any/all applications > > > > Maria-Cruz, > > > > The existing OC-OLR definition (without "All Application" AVP) already > addresses your use case. E.g. reporting node includes same value of > "Reduction-Percentage" in all the application messages sent by it. So > we don't need "All Application" AVP additionally. > > Besides, reporting "Reduction-Percentage" of a different application > violates the basic principle of the piggybacking. > > Finally, in 3GPP (as far as I remember) we do not have any use case of > two nodes interfacing with each other over more than one application. > i.e. we have only one application between any pair of nodes and if > that is so then I fail to see the practicality of the use case you > have mentioned below. > > > > Regards, > > Nirav. > > > > *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *Maria Cruz > Bartolome > *Sent:* Tuesday, December 03, 2013 2:13 PM > *To:* dime@ietf.org > *Subject:* [Dime] OLR applicable for any/all applications > > > > > > Dear all, > > > > There may be a need by a reporting node to request traffic reduction > for all traffic, application independent, e.g. if an operator's > network becomes severely overloaded, it may be of interest to signal > directly general overload to the client. > > In this case, since reacting node obtains affected application from > the application message, we may need to extend OLR. > > > > At least we got following options: > > > > > > A) Define a new optional AVP that could be included into OLR, like > e.g.: > > OC-OLR ::= < AVP Header: TBD2 > > < TimeStamp > > [ Reduction-Percentage ] > [ ValidityDuration ] > [ ReportType ] > [All applications] > * [ AVP ] > > > > > > B) Extend ReportTypes like e.g.: > > > > 3 Destination-Host All Applications report. Similar to > Destination-Host report but it would apply to any application > regardless the application message this report is received within. > > > > 4 Realm (aggregated) All Applicationsreport. Similar to Realm > report but it would apply to any application regardless the > application message this report is received within. > > > > > > > > I tend to prefer option A, but let me know your opinions and preferences. > > Best regards > > /MCruz > > > > > > _________________________________________________________________________________________________________________________ > > 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 --------------090704040507020507010408 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Personally I like Maria-Cruz's suggestion.  But I am also on the side of including the application-id in the overload report in the first place.

On a related note, the agent overload extension will likely default to being all applications.  We will need to decide if we allow for getting more specific by allowing the agent to include a list of impacted applications.

Steve

On 12/3/13 5:20 AM, lionel.morand@orange.com wrote:

Hi Maria-Cruz,

 

I agree with Nirav's comment: No need of such optimization. OLR is per application and if more than one application is used between nodes, the OLR will be received on the application related answers.

 

Regards,

 

Lionel

 

De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot (nsalot)
Envoyé : mardi 3 décembre 2013 10:41
À : Maria Cruz Bartolome; dime@ietf.org
Objet : Re: [Dime] OLR applicable for any/all applications

 

Maria-Cruz,

 

The existing OC-OLR definition (without "All Application" AVP) already addresses your use case. E.g. reporting  node includes same value of "Reduction-Percentage" in all the application messages sent by it. So we don’t need "All Application" AVP additionally.

Besides, reporting "Reduction-Percentage" of a different application violates the basic principle of the piggybacking.

Finally, in 3GPP (as far as I remember) we do not have any use case of two nodes interfacing with each other over more than one application. i.e. we have only one application between any pair of nodes and if that is so then I fail to see the practicality of the use case you have mentioned below.

 

Regards,

Nirav.

 

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Maria Cruz Bartolome
Sent: Tuesday, December 03, 2013 2:13 PM
To: dime@ietf.org
Subject: [Dime] OLR applicable for any/all applications

 

 

Dear all,

 

There may be a need by a reporting node to request traffic reduction for all traffic, application independent, e.g. if an operator’s network becomes severely overloaded, it may be of interest to signal directly general overload to the client. 

In this case, since reacting node obtains affected application from the application message, we may need to extend OLR.

 

At least we got following options:

 

 

A)     Define a new optional AVP that could be included into OLR, like e.g.:

   OC-OLR ::= < AVP Header: TBD2 >
              < TimeStamp >
              [ Reduction-Percentage ]
              [ ValidityDuration ]
              [ ReportType ]
              [All applications]
            * [ AVP ]

 

 

B)      Extend  ReportTypes like e.g.:

 

   3  Destination-Host All Applications report.  Similar to Destination-Host report but it would apply to any application regardless the application message this report is received within.

 

   4  Realm (aggregated) All Applications report.  Similar to Realm report but it would apply to any application regardless the application message this report is received within.

 

 

 

I tend to prefer option A, but let me know your opinions and preferences.

Best regards

/MCruz

 

 

_________________________________________________________________________________________________________________________

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

--------------090704040507020507010408-- From srdonovan@usdonovans.com Tue Dec 3 07:47:39 2013 Return-Path: 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 5F4A11A1F4C for ; Tue, 3 Dec 2013 07:47:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no 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 0uKs2Q97X14V for ; Tue, 3 Dec 2013 07:47:32 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 73B041ADFE6 for ; Tue, 3 Dec 2013 07:47:32 -0800 (PST) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:50142 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1VnsC2-0007HM-AX for dime@ietf.org; Tue, 03 Dec 2013 07:47:29 -0800 Message-ID: <529DFD0A.9050308@usdonovans.com> Date: Tue, 03 Dec 2013 09:47:22 -0600 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: dime@ietf.org References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> , <5BCBA1FC2B7F0B4C9D935572D90006681519C087@DEMUMBX014.nsn-intra.net> <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> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681519D3D9@DEMUMBX014.nsn-intra.net> Content-Type: multipart/alternative; boundary="------------020706030503020002080600" X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 15:47:39 -0000 This is a multi-part message in MIME format. --------------020706030503020002080600 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit 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)" 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 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 > --------------020706030503020002080600 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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

--------------020706030503020002080600-- From ulrich.wiehe@nsn.com Tue Dec 3 07:56:45 2013 Return-Path: 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 F0C8D1AE149 for ; Tue, 3 Dec 2013 07:56:44 -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 xF7o54ci-9pE for ; Tue, 3 Dec 2013 07:56:31 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 977AF1A1F4C for ; Tue, 3 Dec 2013 07:56:30 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rB3FuQ18029125 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 3 Dec 2013 16:56:26 +0100 Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rB3FuPZA017955 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Dec 2013 16:56:25 +0100 Received: from DEMUHTC010.nsn-intra.net (10.159.42.41) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 3 Dec 2013 16:56:25 +0100 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.152]) by DEMUHTC010.nsn-intra.net ([10.159.42.41]) with mapi id 14.03.0123.003; Tue, 3 Dec 2013 16:56:25 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: ext Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] DOIC: Self-Contained OLRs Thread-Index: AQHO67/t2PaAGa/GgUyaCwjRxXVUh5o5m/0AgAC8o/D///ghgIAAFu+wgAGHVQCAACqasIAAMwWAgANxipCAAKJuAIAATHjQgAAM5ICAABPPEIAAFwqAgAAGBICAAAUigIAAJC3wgAEbsUCAAAYOAIAAGIwQ///0igCAAEGG8IAAESYAgAARq0A= Date: Tue, 3 Dec 2013 15:56:24 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519D493@DEMUMBX014.nsn-intra.net> References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> , <5BCBA1FC2B7F0B4C9D935572D90006681519C087@DEMUMBX014.nsn-intra.net> <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> In-Reply-To: <529DFD0A.9050308@usdonovans.com> 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: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D90006681519D493DEMUMBX014nsnin_" 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: 84342 X-purgate-ID: 151667::1386086186-00006154-B9D156D6/0-0/0-0 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 15:56:45 -0000 --_000_5BCBA1FC2B7F0B4C9D935572D90006681519D493DEMUMBX014nsnin_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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 exte= nsion (like agent overload) must not be forced to process more than one OLR= per answer. 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 t= he solution. I don't see how it helps that multiple OLRs are not mandated f= or 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.or= g list Subject: RE: [Dime] DOIC: Self-Contained OLRs Hi Ulrich, I don't see the complexity if each OLR instance received is clearly disting= uished by the Report-Type. Again, it is not said that it will be mandated for any deployment to rely o= n multiple OLR instances. Regards, Lionel -----Message d'origine----- De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Envoy=E9 : mardi 3 d=E9cembre 2013 11:46 =C0 : 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.or= g 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 prohib= it 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 an= swer. Regards, Lionel -----Message d'origine----- De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN -= DE/Munich) Envoy=E9 : mardi 3 d=E9cembre 2013 10:21 =C0 : 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 retu= rns a host-type OLR to C (via A) and there is no need for A to insert a rea= lm-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 Destinat= ion 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 ma= y 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 rece= ived 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 Barto= lome 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 no= rmal behavior. But I agree in case the request is towards a Destination Host, receiving th= e 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 no= de 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 t= he 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 m= atter of interpretation. When sending a request, a client is always targeting a server, even if Dest= ination-Host is not in the answer. So receiving a host-based OLR in respons= e 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 posit= ive 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" offe= red by the use of the Report-Type. But there is nothing wrong. It is only t= o 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 Re= port-type. And having the report type avoids the client to "guess" the cont= ext based on the type of request. Regards, Lionel De : Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Envoy=E9 : lundi 2 d=E9cembre 2013 14:58 =C0 : 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 "optio= nal" optimization at this stage. Either it is respected by all the nodes su= pporting the solution or we drop that optimization. Regards, Nirav. On Dec 2, 2013 5:27 PM, "Wiehe, Ulrich (NSN - DE/Munich)" 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 answe= r 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 OL= R 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 thi= s OLR applicable for realm or host? I am trying to understand which is out-of-context OLR here: realm-type or h= ost-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 contain= ing destination-host), it gets back answer containing origin-host (set by t= he 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 me= ssage perspective. The client sends a request of type x (destination host = =3Dx1, destination realm =3Dx2 application=3D x3) and gets back an OLR in t= he answer which says "please throttle request of the type you just sent". T= he client either remembers, or deduces from info received in the answer, wh= at the type x was. E.g. it deduces from the value of Origin Realm in the an= swer the value of Destination Realm in the request; it deduces from the val= ue 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 solut= ion - to define the response message's context based on the request message= . And hence if the request message was sent to destination-realm, the corre= sponding response message can only contain realm-type OLR. But this requires the client to remember the context of the request while p= rocessing the response and hence it was considered as introducing unnecessa= ry 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-typ= e OLR only when the destination-realm based request is rejected. So basical= ly, realm-type OLR is never included in a response message which contains o= rigin-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-ty= pe 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/Mun= ich)] 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 a= gent wants to offer this optimization), and may be processed by the reactin= g 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 info= rmation 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 ign= ored. [Wiehe, Ulrich (NSN - DE/Munich)] Not the Report-Type AVP is the optimizati= on 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 O= LR is out-of-context. Similary, when the client sends a request containing destination host and g= ets 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 respons= es 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 Joun= i 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 i= n the answer and additional OLRs (not created by the reporting endpoint) ma= y just be present as an optional optimization i.e. optionally inserted by t= he 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 subs= equent request towards the origin-host of the answer containing the OLR. Us= ing 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=E9 : jeudi 28 novembre 2013 11:30 =C0 : 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 act= ual OLR created by the reporting end point and which OLR is an additional O= LR created by another node. We have two cases: a) The request sent by the client (reacting end point) contains no Destinat= ion Host. The agent (reporting node) (after forwarding the request to the s= elected server and receiving the answer) returns a realm-type OLR as the ac= tual 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 Destinat= ion 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 stat= us. It could be provided an agent inserting this info in answers received f= rom a server behind but also from a server that would know this info by som= e internal magic. But in any case, if we assume that the client will received a successful an= swer from the server for an initial request with only Dest-Realm AVP, it sh= ould be possible to have both report types in the answer: one for the serve= r itself, one for the realm for new request sent to the realm with only Des= t-Realm AVP. Lionel -----Message d'origine----- De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN - DE/Munich) Envoy=E9 : jeudi 28 novembre 2013 10:26 =C0 : 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 a= ligned with the "endpoint principle". If the ReportType is "realm" this ind= icates 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 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 endpoin= ts, the more it makes sense to me to keep the ReportType in the OC-OLR. Eve= n if the baseline does not have agent overload etc, the ReportType fits wel= l to the "endpoint principle" we have in the draft. It indeed gives more to= ols to make a host vs. realm base decision on the reacting node and is plai= n 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 Diamet= er request that corresponds to the answer containing the OLR. My reasons fo= r 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 i= dentified by Origin-Realm, and so on. This means that the "meaning" of an O= LR 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 answe= r to another, it's meaning may change completely. I think this approach is a mistake. I would greatly prefer that we explicit= ly 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 variou= s other AVPs to find all the information it needs. For example, I think a c= ommon software design for overload control processing to be separated from = application processing. The consumer cannot simply hand the OLR to that mod= ule and expect things to work. The OC module must not only parse the OLR, b= ut parse any other AVPs that are relevant. As OLR contents get extended (as= sumedly following the same strategy as the base spec), the number of "conte= xt" avps that must be interpreted can grow large. This approach is error pr= one, and will likely encourage brittle, hard-to-maintain code. Self-contain= ed OLRs would keep all the information related to overload in one place. ma= king for simpler implementations. 2) It's more complex for the reporting node to send implicit values than ex= plicit values. The sender cannot simply set the context to match the OLR--a= ll those other AVPs have application or protocol layer meanings. Once a rep= orting node realizes that it is overloade, it has to wait for the right ans= wer that contains the right context before it can send the OLR. This is par= ticularly 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 sig= nificantly. 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 so= me 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 overlo= ad reports were self-contained, one could just reuse the report format we s= pecify here. But if the meaning of an OLR depends on the way it's transport= ed, this won't work. We would have to create a new or significantly modifie= d OLR format if we found a need to transport OLRs in different ways. Self-c= ontained OLRs would allow much greater flexibility. So, in summary, I think that self-contained OLRs would lead to simpler impl= ementations, less brittle deployments, and more flexibility for future evol= ution 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 confiden= tielles 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. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation 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 dele= te 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 confiden= tielles 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. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation 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 dele= te 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 le= s pieces jointes. Les messages electroniques etant susceptibles d'alteratio= n, 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 dis= tributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te 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 confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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 confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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 --_000_5BCBA1FC2B7F0B4C9D935572D90006681519D493DEMUMBX014nsnin_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Steve,

 = ;

I didnR= 17;t say that there can never be more than one OLR.

My point i= s that a reacting node that does not indicate support of any extension (lik= e agent overload) must not be forced to process more than one OLR per answer.

 = ;

Ulrich

 = ;

From:= DiME [mailto:dime-b= ounces@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 agen= t 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 manda=
ted for the reporting node; the reacting node would still be required to pr=
ocess all received OLRs.
 
Best regards
Ulrich
 
-----Original Message-----
From: ext lionel.morand@or=
ange.com [mailto:lionel.mor=
and@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 di=
stinguished by the Report-Type. 
Again, it is not said that it will be mandated for any deployment to r=
ely on multiple OLR instances. 
 
Regards,
 
Lionel
 
-----Message d'origine-----
De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] 
Envoy=E9 : mardi 3 d=E9cembre 2013 11:46
=C0 : 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@or=
ange.com [mailto:lionel.mor=
and@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 p=
rohibit this way of doing. The consequence for the client is that it will n=
ever 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 sa=
me answer.


 


Regards,


 


Lionel 


 


-----Message d'origine-----


De : DiME [mailto:dime-b=
ounces@ietf.org] De la part de Wiehe, Ulrich (NSN - DE/Munich)


Envoy=E9 : mardi 3 d=E9cembre 2013 10:21


=C0 : 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 a=
nd A in this case).


Note: it may well be that C never sends a request not containing a Des=
tination Host in which case any realm-type OLR inserted by A would be usele=
ss 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 req=
uest. 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 betwe=
en C and S in this case).


Note: it may well be that C never sends a request containing a Destina=
tion 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.<=
/o:p>


 


Ulrich


 


 


 


 


-----Original Message-----


From: DiME [mailto:dime-bounc=
es@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 b=
elow.


 


For a request towards a realm (without Destination Host), in case ther=
e is not an intermediate agent, receiving a host-based OLR may be in fact t=
he normal behavior.


But I agree in case the request is towards a Destination Host, receivi=
ng the realm-based OLR could be considered an optimization, and I would agr=
ee 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 reacti=
ng node does not take this into account when (potentially) sending a reques=
t 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-bounc=
es@ietf.org] On Behalf Of Jouni Korhonen


Sent: lunes, 02 de diciembre de 2013 15:38


To: lionel.morand@orange.c=
om


Cc: Ben Campbell; dime@ietf.org l=
ist


Subject: Re: [Dime] DOIC: Self-Contained OLRs


 


 


My understanding (and current editing) has already been towards what L=
ionel 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 positio=
n on the need for the Report-Type.


 


Ulrich, I think that what you are considering as out of context is jus=
t 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 re=
sponse 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 optimiza=
tion" offered by the use of the Report-Type. But there is nothing wron=
g. It is only to comply with the Diameter routing principle: subsequent req=
uests from the client could include a destination-host or not. So the clien=
t needs to know which reduction to apply from a previous answer.=



 


In any case, the client needs to store the OLR received according to t=
he 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=E9 : lundi 2 


d=E9cembre 2013 14:58 =C0 : Wiehe, Ulrich (NSN - DE/Munich) Cc : =



dime@ietf.org list; ext Jouni Kor=
honen; 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 h=
as to remember what was sent in the request while processing the response?<=
o:p>


 


I would prefer to derive the context of the OLR based on the message w=
hich contains the OLR.


 


Back to the topic of this thread, I don't think we need to define an &=
quot;optional" optimization at this stage. Either it is respected by a=
ll 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> wrot=
e:


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-ty=
pe OLR in the answer would be in-context.


 


Ulrich


 


 


 


-----Original Message-----


From: ext Nirav Salot (nsalot) [ma=
ilto: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 (onl=
y one) OLR in the response message (which also contains the origin-host), i=
s 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) [ma=
ilto: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 co=
ntaining 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 respon=
se message perspective. The client sends a request of type x (destination h=
ost =3Dx1, destination realm =3Dx2 application=3D 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 R=
ealm in the answer the value of Destination Realm in the request; it deduce=
s 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 me=
ssage. And hence if the request message was sent to destination-realm, the =
corresponding response message can only contain realm-type OLR.<=
/pre>

But this requires the client to remember the context of the request wh=
ile processing the response and hence it was considered as introducing unne=
cessary 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 an=
swer whether the request contained a destination host. It does not mean tha=
t 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 real=
m-type OLR only when the destination-realm based request is rejected. So ba=
sically, realm-type OLR is never included in a response message which conta=
ins origin-host AVP. (And I am ready to reconsider the same if we want to e=
nsure 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 - D=
E/Munich)] The in-context-OLR must be included by the reporting node and mu=
st be processed by the reacting node; the out-of-context OLR may be include=
d 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 re=
acting node (if the reacting node wants to make use of this optimization).<=
o:p>


 


 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 conta=
ined 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 i=
t.


[Wiehe, Ulrich (NSN - DE/Munich)]  What goes wrong when out-of -c=
ontext OLR is ignored?


 


Otherwise, if we argue that the Report-Type AVP is just an optimizatio=
n (to allow the inclusion of realm-type OLR) and the reacting node can igno=
re it, then lets not define this optimization since it has no value if it i=
s ignored.


[Wiehe, Ulrich (NSN - DE/Munich)] Not the Report-Type AVP is the optim=
ization 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 b=
ut no destination host an gets back an answer containing a host-type OLR, t=
his 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-con=
text.


There is nothing wrong with storing such out-of-context OLRs at the cl=
ient, but it is simply not needed as the client will learn this OLR from re=
sponses received within the context.


 


Best regards


Ulrich


 


 


-----Original Message-----


From: ext Nirav Salot (nsalot) [ma=
ilto: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 sh=
ould be ignored by the reacting node?


 


Regards,


Nirav.


 


-----Original Message-----


From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of Wiehe, Ulrich 


(NSN - DE/Munich)


Sent: Friday, November 29, 2013 5:36 PM


To: ext lionel.morand@oran=
ge.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 pres=
ent in the answer and additional OLRs (not created by the reporting endpoin=
t) 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@or=
ange.com [mailto:lionel.mor=
and@orange.com]


Sent: Friday, November 29, 2013 11:13 AM


To: Wiehe, Ulrich (NSN - DE/Munich); ext Jouni Korhonen; Ben Campbell<=
o:p>


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 a=
pplies for subsequent request towards the origin-host of the answer contain=
ing 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 destin=
ation-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 knowled=
ge of the realm overload status. An agent in the path could be this one but=
, for instance, future development could allow a distributed server archite=
cture 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=E9 : jeudi 28 novembre 2013 11:30 =C0 : MORAND Lionel IMT/OLN; e=
xt 


Jouni Korhonen; Ben Campbell Cc : dim=
e@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 th=
e actual OLR created by the reporting end point and which OLR is an additio=
nal OLR created by another node.


 


We have two cases:


a) The request sent by the client (reacting end point) contains no Des=
tination Host. The agent (reporting node) (after forwarding the request to =
the selected server and receiving the answer) returns a realm-type OLR as t=
he actual reporting-node-created OLR and optionally in addition a host-type=
 OLR as learned from the selected server.  The client may ignore the a=
dditional OLR.


b) The request sent by the client (reacting endpoint) contains the Des=
tination Host. The Server (reporting node) returns a host-type OLR as the a=
ctual reporting-node-created OLR in the answer. The agent may optionally in=
sert a realm-type OLR as additional OLR to the answer. The client may ignor=
e the additional OLR.


 


Ulrich


 


 


 


-----Original Message-----


From: ext lionel.morand@or=
ange.com [mailto:lionel.mor=
and@orange.com]


Sent: Thursday, November 28, 2013 10:31 AM


To: Wiehe, Ulrich (NSN - DE/Munich); ext Jouni Korhonen; Ben Campbell<=
o:p>


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 recei=
ved from a server behind but also from a server that would know this info b=
y some internal magic.


But in any case, if we assume that the client will received a successf=
ul 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 onl=
y Dest-Realm AVP.


 


Lionel


 


-----Message d'origine-----


De : DiME [mailto:dime-bounce=
s@ietf.org] De la part de Wiehe, Ulrich 


(NSN - DE/Munich) Envoy=E9 : jeudi 28 novembre 2013 10:26 =C0 : ext Jo=
uni 


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 &=
quot;realm" this indicates to the reacting end point that the reportin=
g 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 repor=
ting end point is a server. How can the reporting end point be both agent a=
nd server?


 


Ulrich


 


-----Original Message-----


From: DiME [mailto:dime-bounc=
es@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 <=
/o:p>


ReportType AVP in an OLR, rather than




 


The more I spent time thinking/writing the actual procedures on the en=
dpoints, 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 fit=
s well to the "endpoint principle" we have in the draft. It indee=
d gives more tools to make a host vs. realm base decision on the reacting n=
ode 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 D=
iameter request that corresponds to the answer containing the OLR. My reaso=
ns 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 applica=
tion identified by the Application-Id field of the enclosing answer, the re=
alm identified by Origin-Realm, and so on. This means that the "meanin=
g" of an OLR cannot be determined from the OLR contents alone; OLRs on=
ly 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 exp=
licitly include such values in the OLR itself, for multiple reasons:


 


1) It's more complex to interpret implicit, contextual values than exp=
licit values. The consumer cannot simply look at the OLR; it must look in v=
arious other AVPs to find all the information it needs. For example, I thin=
k a common software design for overload control processing to be separated =
from application processing. The consumer cannot simply hand the OLR to tha=
t module and expect things to work. The OC module must not only parse the O=
LR, but parse any other AVPs that are relevant. As OLR contents get extende=
d (assumedly following the same strategy as the base spec), the number of &=
quot;context" avps that must be interpreted can grow large. This appro=
ach is error prone, and will likely encourage brittle, hard-to-maintain cod=
e. Self-contained OLRs would keep all the information related to overload i=
n one place. making for simpler implementations.


 


2) It's more complex for the reporting node to send implicit values th=
an explicit values. The sender cannot simply set the context to match the O=
LR--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 righ=
t answer that contains the right context before it can send the OLR. This i=
s particularly troublesome for agents, since they will typically have to in=
sert OLRs into answers created by other nodes. 


 


If the reporting node screws this up, the meaning of the OLR may chang=
e significantly. So again, implicit meaning gives us error prone implementa=
tions. 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 serve=
r.


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 <=
/o:p>


agent overload draft, or my dh/dr example.)


 


OTOH, explicit values will work for all cases where we need to associa=
te some arbitrary value with an OLR.


 


4) Implicit values seriously constrain the future evolution of Diamete=
r OC standards. For example, lets say we find a good reason to allow OLRs t=
o be sent out of band, or be sent in a dedicated Diameter application. If o=
verload 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 tran=
sported, this won't work. We would have to create a new or significantly mo=
dified OLR format if we found a need to transport OLRs in different ways. S=
elf-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.iet=
f.org/mailman/listinfo/dime




 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 


______________________________________________________________________=



___________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploite=
s ou copies sans autorisation. Si vous avez recu ce message par erreur, veu=
illez le signaler a l'expediteur et le detruire ainsi que les pieces jointe=
s. Les messages electroniques etant susceptibles d'alteration, Orange decli=
ne toute responsabilite si ce message a ete altere, deforme ou falsifie. Me=
rci.


 


This message and its attachments may contain confidential or privilege=
d 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 con=
fidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploite=
s ou copies sans autorisation. Si vous avez recu ce message par erreur, veu=
illez le signaler a l'expediteur et le detruire ainsi que les pieces jointe=
s. Les messages electroniques etant susceptibles d'alteration, Orange decli=
ne toute responsabilite si ce message a ete altere, deforme ou falsifie. Me=
rci.


 


This message and its attachments may contain confidential or privilege=
d 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.iet=
f.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 q=
ue les pieces jointes. Les messages electroniques etant susceptibles d'alte=
ration, Orange decline toute responsabilite si ce message a ete altere, def=
orme ou falsifie. Merci.


 


This message and its attachments may contain confidential or 


privileged information that may be protected by law; they should not b=
e 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.iet=
f.org/mailman/listinfo/dime


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 


______________________________________________________________________=
___________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


 


This message and its attachments may contain confidential or privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
o:p>


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 con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


 


This message and its attachments may contain confidential or privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
o:p>


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.iet=
f.org/mailman/listinfo/dime


 

 

--_000_5BCBA1FC2B7F0B4C9D935572D90006681519D493DEMUMBX014nsnin_-- From srdonovan@usdonovans.com Tue Dec 3 07:59:11 2013 Return-Path: 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 E69AE1AE154 for ; Tue, 3 Dec 2013 07:59:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no 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 vSHv8gEMeEHN for ; Tue, 3 Dec 2013 07:58:57 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 7F0101AE167 for ; Tue, 3 Dec 2013 07:58:57 -0800 (PST) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:50172 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1VnsN7-0006IT-GU; Tue, 03 Dec 2013 07:58:54 -0800 Message-ID: <529DFFB5.3030200@usdonovans.com> Date: Tue, 03 Dec 2013 09:58:45 -0600 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "Wiehe, Ulrich (NSN - DE/Munich)" , "dime@ietf.org" References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D90006681519C087@DEMUMBX014.nsn-intra.net> <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> <5BCBA1FC2B7F0B4C9D935572D90006681519D493@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681519D493@DEMUMBX014.nsn-intra.net> Content-Type: multipart/alternative; boundary="------------090009020708010409050402" X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 15:59:11 -0000 This is a multi-part message in MIME format. --------------090009020708010409050402 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Ulrich, Thanks for your clarification. Steve On 12/3/13 9:56 AM, Wiehe, Ulrich (NSN - DE/Munich) 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. > > > > 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)" 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 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 > > > > > --------------090009020708010409050402 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Ulrich,

Thanks for your clarification.

Steve
On 12/3/13 9:56 AM, Wiehe, Ulrich (NSN - DE/Munich) 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.

 

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
 

 


--------------090009020708010409050402-- From david.black@emc.com Mon Dec 2 16:59:16 2013 Return-Path: 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 961201ADFEE; Mon, 2 Dec 2013 16:59:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 BIjGFZNeEt-8; Mon, 2 Dec 2013 16:59:14 -0800 (PST) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 8F5A31ADFF2; Mon, 2 Dec 2013 16:59:13 -0800 (PST) Received: from maildlpprd04.lss.emc.com (maildlpprd04.lss.emc.com [10.253.24.36]) by mailuogwprd01.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rB30x7C3007123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Dec 2013 19:59:07 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com rB30x7C3007123 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1386032348; bh=4jjfq1A0EIkaDjk77dsC6jk5Wt4=; h=From:To:CC:Date:Subject:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=APNJ0/SjJBtYESpQ2LBQlCNIINsJgiHhvBWZOZ7z9PJ+jdlb1eTkFegfOeX0JUogz Hy3bsEZI7Bf5b95ZrW3Cv3bJBrhnEN4W85ECDwc6jhLZiiYDF1alDQG/eyMFykdow4 W22OxW2Df90dF6HCG/U637XTKKrH8MzLufadj/FU= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com rB30x7C3007123 Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com [10.106.48.24]) by maildlpprd04.lss.emc.com (RSA Interceptor); Mon, 2 Dec 2013 16:58:50 -0800 Received: from mxhub35.corp.emc.com (mxhub35.corp.emc.com [10.254.93.83]) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rB30wn2N028367 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 2 Dec 2013 19:58:49 -0500 Received: from mx15a.corp.emc.com ([169.254.1.239]) by mxhub35.corp.emc.com ([::1]) with mapi; Mon, 2 Dec 2013 19:58:49 -0500 From: "Black, David" To: "glenzorn@gmail.com" , "lionel.morand@orange.com" , "gen-art@ietf.org" Date: Mon, 2 Dec 2013 19:58:48 -0500 Thread-Topic: Gen-ART review of draft-ietf-dime-rfc4005bis-14 Thread-Index: Ac7vwtMcr6PoiKsVTtusEDHn3V9Ylw== Message-ID: <8D3D17ACE214DC429325B2B98F3AE712026ADFB0E7@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd51.lss.emc.com X-RSA-Classifications: DLM_1, public X-Mailman-Approved-At: Tue, 03 Dec 2013 08:49:00 -0800 Cc: "ietf@ietf.org" , "draft-ietf-dime-rfc4005bis@tools.ietf.org" , "Black, David" , "dime@ietf.org" , "dime-chairs@tools.ietf.org" Subject: [Dime] Gen-ART review of draft-ietf-dime-rfc4005bis-14 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 00:59:16 -0000 Going back to the original Gen-ART review of the -11 version of this draft, all of the major and minor issues in that review have now been addressed. The Unicode situation is not as clean and neat as one might like, courtesy of the need to accommodate deployed implementations ("running code"), but the new Unicode text in Section 6 should suffice ... confession: I wrote that text, Glen pasted it into the draft, and I just hope the IESG thinks the text is reasonable in light of the "running code". OTOH, idnits found this slightly embarrassing nit: =3D=3D Missing Reference: 'RFC4005' is mentioned on line 2805, but not de= fined An RFC Editor Note will suffice to correct that. Thanks, --David > -----Original Message----- > From: Black, David > Sent: Monday, September 17, 2012 7:53 PM > To: glenzorn@gmail.com; lionel.morand@orange.com; gen-art@ietf.org > Cc: dime-chairs@tools.ietf.org; draft-ietf-dime-rfc4005bis@tools.ietf.org= ; > Black, David; ietf@ietf.org; dime@ietf.org; Benoit Claise > Subject: Gen-ART review of draft-ietf-dime-rfc4005bis-11 >=20 > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > . >=20 > Please resolve these comments along with any other Last Call comments > you may receive. >=20 > Document: draft-ietf-dime-rfc4005bis-11 > Reviewer: David L. Black > Review Date: September 17, 2012 > IETF LC End Date: September 18, 2012 > IESG Telechat date: (if known) >=20 > Summary: >=20 > This draft is on the right track but has open issues, described in the re= view. >=20 > This draft is part of a set of drafts that updates the DIAMETER protocol; > this draft specifies the application of DIAMETER to AAA for network acces= s. > The draft is heavily based on RFC 4005, which it obsoletes, and requires > significant DIAMETER familiarity (including familiarity with its companio= n > drafts, starting with the rfc3588bis draft) for complete understanding. >=20 > The draft is in good shape and reads well. I found one major open issue, > a few minor issues, and several nits. >=20 > Major issues: >=20 > This draft makes significant use of UTF-8 in its formats (some subsection= s > of sections 4.2, 4.4 and 4.5) for strings that are intended to be compare= d > for equality or processed by protocol participants, but does not contain > considerations for Unicode processing that are sufficient to support this > usage. Examples of UTF-8 usage in this draft include: >=20 > - 4.2.5 and 4.2.6: The NAS server may perform authorization based on the > Called-Station-Id and Calling-Station-Id AVPs under some > circumstances. > - 4.4.3: The Callback-Id AVP is intended to be interpreted by the NAS. >=20 > All use of UTF-8 in this draft relies upon the specification of the > UTF8String format in the rfc3588bis draft. That specification is > insufficient to support the usage in the above examples, and there are > no Unicode considerations in this draft. Even binary comparison of > Unicode strings for equality generally requires specification of > string preparation (e.g., normalization) in order for string comparison > to work as expected. >=20 > The variety of Unicode strings in this draft makes it important to lay > out the Unicode requirements and considerations for each AVP. I see > at least 5 classes of possible Unicode requirements/considerations: >=20 > 1) String preparation so that tests for equality work as expected. > This may suffice for the Called-Station-ID AVP (4.2.5) and > Calling-Station-ID AVP (4.2.6) if the internal structure of > those strings is not used in authorization. > 2) Detailed string format for a string that is processed by a protocol > participant, e.g., the Callback-ID AVP (4.4.3). > 3) Restriction of the string to ASCII-only, e.g., as already stated > for the Framed-Route AVP (4.4.10.5.3). > 4) Specification that the string is for display to human users only, > e.g., as already stated for the Reply-Message AVP (4.2.9). > 5) Statement that the string contains an FQDN, as stated for one > case of the Tunnel-Client-Endpoint AVP in 4.5.4. That specific > statement is incomplete, as it needs to be accompanied by a > normative reference to a document that specifies the format > of internationalized domain names, and probably needs to also > state which types of labels (e.g., A-label, U-label) are allowed. >=20 > Every use of UTF8String in this draft needs to be checked, and most of > them are likely to need some attention. The ongoing work in the precis > WG may help with some of this, and I would suggest talking to the APP > ADs, especially Pete Resnick (hi Pete) before embarking on significant > work in this area in order to avoid wasted or duplicated efforts. >=20 > Minor Issues: >=20 > [1] End of Section 2 on p.8: >=20 > As a result, > service cannot be started as a result of a response to an > authorization-only request without introducing a significant security > vulnerability. >=20 > Please explain what to do about this - a simple rewrite with a > "SHOULD NOT" would suffice, e.g.: >=20 > As a result, > service SHOULD NOT be started as a result of a response to an > authorization-only request because that may introduce a significant > security vulnerability. >=20 > This should also be noted in the Security Considerations section. >=20 > [2] In the message formats in Section 3, QoS-Filter-Rule is inconsistentl= y > capitalized. Also the use of QoSFilterRule as the format for the > QoS-Filter-Rule AVP in Section 4.1.1 is potentially confusing. Please > add a sentence in 4.1.1 to say that QoSFilterRule is the format for the > QoS-Filter-Rule AVP. >=20 > [3] Section 4.2.1. In this and the other AVP Flag Rules tables, please > explain what the values in the MUST and MUST NOT columns mean. >=20 > [4] Based on this text in 4.4.9: >=20 > The use of this AVP is NOT RECOMMENDED; the AVPs defined by Korhonen, > et al. [RFC5777] SHOULD be used instead. >=20 > I would have expected RFC5777 to be a Normative Reference, not an > Informative Reference. >=20 > Nits/editorial comments: >=20 > After the command table in Section 3 and other similar tables, please add= a > sentence to say that the -Request and -Answer commands in each similarly-= named > command pair are distinguished by the value of the 'R' bit in the Command > Flags field of the command. This is already stated in the command > definitions, > but the sentence should be added after the table for clarity because each > command > pair shares a Command Code. >=20 > idnits 2.12.13 found a few potential nits: >=20 > =3D=3D There are 7 instances of lines with non-RFC5735-compliant IPv4 a= ddresses > in the document. If these are example addresses, they should be cha= nged. >=20 > That can probably be ignored, as these instances are likely generated by > text such as cross-references to Section 4.4.10.1 >=20 > =3D=3D Missing Reference: 'BASE' is mentioned on line 219, but not defi= ned >=20 > That's definitely a problem. Was [I-D.ietf-dime-rfc3588bis] intended? >=20 > -- Possible downref: Non-RFC (?) normative reference: ref. 'ANITypes' >=20 > That reference would be: >=20 > [ANITypes] NANPA Number Resource Info, "ANI > Assignments", number_resource_info/ > ani_ii_assignments.html>. >=20 > Is that reference sufficiently stable (e.g., IANA-class or better managem= ent)? > My guess is that it is sufficiently stable, but I'm not the expert. >=20 > -- Obsolete informational reference (is this intentional?): RFC 1334 > (Obsoleted by RFC 1994) >=20 > That reference may be intentional, as it's cited exactly once: >=20 > 263 PAP (Password Authentication Protocol) > 264 A deprecated PPP authentication process, but often used for > 265 backward compatibility [RFC1334]. >=20 >=20 > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 > +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-7= 786 > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 > ---------------------------------------------------- >=20 From lionel.morand@orange.com Tue Dec 3 09:00:36 2013 Return-Path: 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 B04F21A82E2 for ; Tue, 3 Dec 2013 09:00:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 K0bwsJAp9rHW for ; Tue, 3 Dec 2013 09:00:32 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id A38981AC499 for ; Tue, 3 Dec 2013 09:00:31 -0800 (PST) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id D5A92C0271; Tue, 3 Dec 2013 18:00:27 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id BAC67384057; Tue, 3 Dec 2013 18:00:27 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0158.001; Tue, 3 Dec 2013 18:00:27 +0100 From: To: Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] OLR applicable for any/all applications Thread-Index: AQHO8D3n4RUq1f+l+0exGxJ/KEhpNJpCsK1g Date: Tue, 3 Dec 2013 17:00:26 +0000 Message-ID: <19814_1386090027_529E0E2B_19814_15820_1_6B7134B31289DC4FAF731D844122B36E31353F@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <087A34937E64E74E848732CFF8354B920972BE0C@ESESSMB101.ericsson.se> <529DFB3B.3080109@usdonovans.com> In-Reply-To: <529DFB3B.3080109@usdonovans.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.5] Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E31353FPEXCVZYM13corpora_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.12.2.94815 Subject: Re: [Dime] OLR applicable for any/all applications X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 17:00:36 -0000 --_000_6B7134B31289DC4FAF731D844122B36E31353FPEXCVZYM13corpora_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Steve, The collocation of multiple functions in the same node does not imply inter= action between these functions. And because it is implementation-dependent,= it was considered that such use cases should be left out for further inves= tigations. Regards, Lionel De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan Envoy=E9 : mardi 3 d=E9cembre 2013 16:40 =C0 : dime@ietf.org Objet : Re: [Dime] OLR applicable for any/all applications Nirav, Agents handle multiple applications over a single connection. It is also possible that implementations can support multiple 3GPP function= s in a single node. For instance, someone might decide to implement a comb= ined HSS and EIR, causing the MME to communicate S6a and S13 over the same = connection. Steve On 12/3/13 3:41 AM, Nirav Salot (nsalot) wrote: Maria-Cruz, The existing OC-OLR definition (without "All Application" AVP) already addr= esses your use case. E.g. reporting node includes same value of "Reduction= -Percentage" in all the application messages sent by it. So we don't need "= All Application" AVP additionally. Besides, reporting "Reduction-Percentage" of a different application violat= es the basic principle of the piggybacking. Finally, in 3GPP (as far as I remember) we do not have any use case of two = nodes interfacing with each other over more than one application. i.e. we h= ave only one application between any pair of nodes and if that is so then I= fail to see the practicality of the use case you have mentioned below. Regards, Nirav. From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Maria Cruz Bartolome Sent: Tuesday, December 03, 2013 2:13 PM To: dime@ietf.org Subject: [Dime] OLR applicable for any/all applications Dear all, There may be a need by a reporting node to request traffic reduction for al= l traffic, application independent, e.g. if an operator's network becomes s= everely overloaded, it may be of interest to signal directly general overlo= ad to the client. In this case, since reacting node obtains affected application from the app= lication message, we may need to extend OLR. At least we got following options: A) Define a new optional AVP that could be included into OLR, like e.g.: OC-OLR ::=3D < AVP Header: TBD2 > < TimeStamp > [ Reduction-Percentage ] [ ValidityDuration ] [ ReportType ] [All applications] * [ AVP ] B) Extend ReportTypes like e.g.: 3 Destination-Host All Applications report. Similar to Destination-Hos= t report but it would apply to any application regardless the application m= essage this report is received within. 4 Realm (aggregated) All Applications report. Similar to Realm report = but it would apply to any application regardless the application message th= is report is received within. I tend to prefer option A, but let me know your opinions and preferences. Best regards /MCruz _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. --_000_6B7134B31289DC4FAF731D844122B36E31353FPEXCVZYM13corpora_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Stev= e,

&n= bsp;

The col= location of multiple functions in the same node does not imply interaction = between these functions. And because it is implementation-dependent, it was= considered that such use cases should be left out for further investigations.

&n= bsp;

Regards= ,

&n= bsp;

Lionel<= o:p>

&n= bsp;

De := DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9 : mardi 3 d=E9cembre 2013 16:40
=C0 : dime@ietf.org
Objet : Re: [Dime] OLR applicable for any/all applications=

 

Nirav,

Agents handle multiple applications over a single connection.

It is also possible that implementations can support multiple 3GPP function= s in a single node.  For instance, someone might decide to implement a= combined HSS and EIR, causing the MME to communicate S6a and S13 over the = same connection.

Steve

On 12/3/13 3:41 AM, Nirav Salot (nsalot) wrote:=

Maria-Cruz,

 

The existing OC-OLR de= finition (without "All Application" AVP) already addresses your u= se case. E.g. reporting  node includes same value of "Reduction-P= ercentage" in all the application messages sent by it. So we don’t need "All Application" AVP additionally.

Besides, reporting &qu= ot;Reduction-Percentage" of a different application violates the basic= principle of the piggybacking.

Finally, in 3GPP (as f= ar as I remember) we do not have any use case of two nodes interfacing with= each other over more than one application. i.e. we have only one applicati= on between any pair of nodes and if that is so then I fail to see the practicality of the use case you have me= ntioned below.

 

Regards,

Nirav.

 

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Maria Cruz Bartolome
Sent: Tuesday, December 03, 2013 2:13 PM
To: dime@ietf.org
Subject: [Dime] OLR applicable for any/all applications<= /o:p>

 

 

Dear all,

 

There may be a need b= y a reporting node to request traffic reduction for all traffic, applicatio= n independent, e.g. if an operator’s network becomes severely overloa= ded, it may be of interest to signal directly general overload to the client. 

In this case, since reacting node obtains affected a= pplication from the application message, we may need to extend OLR.

 

At least we got following options:

 

 

A)     Define a new optional AVP = that could be included into OLR, like e.g.:

&n=
bsp;  OC-OLR ::=3D < AVP Header: TBD2 >
&n=
bsp;            =
; < TimeStamp >
&n=
bsp;            =
; [ Reduction-Percentage ]
&n=
bsp;            =
; [ ValidityDuration ]
&n=
bsp;            =
; [ ReportType ]
&n=
bsp;             [All applications]
&n=
bsp;           * [ AVP ]<=
/span>

 

 

B)      Extend  ReportTypes l= ike e.g.:

 

   3  Destination-Host All Applications report.  Similar to Destination-Host r= eport but it would apply to any application regardless the application mess= age this report is received within.

 

   4  Realm (aggregated) All Applications report.  Similar to Realm report but it would apply to any applica= tion regardless the application message this report is received within.<= /p>

 

 

 

I tend to prefer option A, but let me know your opin= ions and preferences.

Best regards

/MCruz

 

 




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

 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles 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 el=
ectroniques 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 inf=
ormation 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 dele=
te 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.
--_000_6B7134B31289DC4FAF731D844122B36E31353FPEXCVZYM13corpora_-- From lionel.morand@orange.com Tue Dec 3 09:26:12 2013 Return-Path: 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 3F7381ABD2A for ; Tue, 3 Dec 2013 09:26:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 5PHOKOXSt4dl for ; Tue, 3 Dec 2013 09:26:07 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 912BA1AD6BF for ; Tue, 3 Dec 2013 09:26:06 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 178E52DC1D0; Tue, 3 Dec 2013 18:26:03 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id E7C6D27C059; Tue, 3 Dec 2013 18:26:02 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0158.001; Tue, 3 Dec 2013 18:26:02 +0100 From: To: Maria Cruz Bartolome , "dime@ietf.org" Thread-Topic: [Dime] OVLI: clarification in 4.2 Thread-Index: Ac7wLSOy5PcGMIF3QXy86CAXysOX/AABwHCQ///6zID//9CjIA== Date: Tue, 3 Dec 2013 17:26:02 +0000 Message-ID: <26806_1386091563_529E142A_26806_2128_1_6B7134B31289DC4FAF731D844122B36E313AC8@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <087A34937E64E74E848732CFF8354B920972C119@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D90006681519D427@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B920972C3CE@ESESSMB101.ericsson.se> In-Reply-To: <087A34937E64E74E848732CFF8354B920972C3CE@ESESSMB101.ericsson.se> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.5] Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E313AC8PEXCVZYM13corpora_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.12.3.151814 Subject: Re: [Dime] OVLI: clarification in 4.2 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 17:26:12 -0000 --_000_6B7134B31289DC4FAF731D844122B36E313AC8PEXCVZYM13corpora_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The clarification is welcome but I think that we don't have to state what i= s missing in the OLR (because a lot of things could be added to the list) b= ut what we can do with the OLR as defined in this document. We could have something as simple as: As defined in this document, the overload report contained in the OC-OLR AVP applies to the application identified by the application-id used in the Dia= meter header of the Diameter message. The value of the Report-Type AVP indicates the sco= pe of applicability of this overload report for this application, as described in= section 4.6. No need for extra info here as we have more details in section 4.6 e.g. "Th= e reacting node learns the "host" implicitly from the Origin-Host AVP of th= e received message that contained the OC-OLR AVP" Regards, Lionel De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome Envoy=E9 : mardi 3 d=E9cembre 2013 16:11 =C0 : dime@ietf.org Objet : Re: [Dime] OVLI: clarification in 4.2 Hello Ulrich, You are right, it is 4.3 in version under development: https://github.com/jounikor/draft-docdt-dime-ovli/blob/master/draft-ietf-di= me-ovli-01.txt Your proposal looks fine. Best regards MCruz From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Sent: martes, 03 de diciembre de 2013 16:03 To: Maria Cruz Bartolome; dime@ietf.org Subject: RE: [Dime] OVLI: clarification in 4.2 Hi MCruz, isn't this clause 4.3? I agree that clarification is needed. But isn't it so that the OLR contains some explicit information (e.g. the R= eport-Type) that is not implicitly learned from the encapsulating Diameter = message? My proposal: The OC-OLR AVP does not contain explicitly all information needed by the re= acting node in order to decide whether a subsequent request must undergo a = throttling process with the reported percentage. To take this decision the = reacting node must check a) whether the subsequent request's Application-ID matches the Applica= tion-Id received in the OC-OLR AVP's encapsulating answer command; b) if the Report-Type received in the OC-ORL is "host" b1) whether the subsequent request's Destination Host is present and match= es the Origin Host received in the OC-OLR AVP's encapsulating answer comman= d; if the Report-Type received in the OC-OLR is "realm" b2) whether the subsequent request' Destination Host is absent and the Dest= ination Realm matches the Origin Realm received in the OC-OLR AVP's encaps= ulating answer command; Best regards Ulrich From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto= lome Sent: Tuesday, December 03, 2013 2:56 PM To: dime@ietf.org Subject: [Dime] OVLI: clarification in 4.2 Hello, I would like to propose a clarification on 4.2 .... The OC-OLR AVP does not contain explicit information to which application it applies to and who inserted the AVP or whom the specific OC-OLR AVP concerns to. Both these information is implicitly learned from the encapsulating Diameter message/command. The application the OC-OLR AVP applies to is the same as the Application-Id found in the Diameter message header. The identity the OC-OLR AVP concerns is determined from the Origin-Host AVP found from the encapsulating Diameter command. My understanding is that "who inserted the AVP" cannot always be learned fr= om the encapsulating Diameter message, since "origin-host" may not always c= ontain the host that inserted the OLR. A part from that, "whom the specific OC-OLR AVP concerns to", could be a bi= t misleading... "whom" may be host, realm, or any other future ReportType, = or even any other "narrowed scope" within the OLR. Last sentence is affecte= d by this ambiguity as well. Some rephrasing may be considered: The OC-OLR AVP does not contain explicit information that may be implicitly learned from the encapsulating Diameter message/command. The application the OC-OLR AVP applies to is the same as the Application-Id found in the Diameter message header. When Report-Type is a Destination-Host, the identity the OC-OLR AVP concerns is determined from the Origin-Host AVP found from the encapsulating Diameter command. Best regards /MCruz ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. --_000_6B7134B31289DC4FAF731D844122B36E313AC8PEXCVZYM13corpora_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

The cla= rification is welcome but I think that we don't have to state what is missi= ng in the OLR (because a lot of things could be added to the list) but what= we can do with the OLR as defined in this document.

&n= bsp;

We coul= d have something as simple as:

&n= bsp;

As defined in this document, the overload report cont= ained in the OC-OLR AVP

applies to the application identified by the applicat= ion-id used in the Diameter header

of the Diameter message. The value of the Report-Type= AVP indicates the scope of

applicability of this overload report for this applic= ation, as described in section 4.6.

&n= bsp;

No need= for extra info here as we have more details in section 4.6 e.g. "The = reacting node learns the "host" implicitly from the Origin-Host A= VP of the received message that contained the OC-OLR AVP"

&n= bsp;

Regards= ,

&n= bsp;

Lionel =

&n= bsp;

De : DiME= [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome
Envoy=E9 : mardi 3 d=E9cembre 2013 16:11
=C0 : dime@ietf.org
Objet : Re: [Dime] OVLI: clarification in 4.2=

 

Hello U= lrich,

&n= bsp;

You are= right, it is 4.3 in version under development:

https://github.com/jo= unikor/draft-docdt-dime-ovli/blob/master/draft-ietf-dime-ovli-01.txt

Your pr= oposal looks fine.

Best re= gards

MCruz

&n= bsp;

From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@= nsn.com]
Sent: martes, 03 de diciembre de 2013 16:03
To: Maria Cruz Bartolome; dime@ietf.org
Subject: RE: [Dime] OVLI: clarification in 4.2

 

Hi MCruz,<= o:p>

 = ;

isn’= t this clause 4.3?

 = ;

I agree= that clarification is needed.

But isn= ’t it so that the OLR contains some explicit information (e.g. the Re= port-Type) that is not implicitly learned from the encapsulating Diameter m= essage?

&n= bsp;

My prop= osal:

The OC-= OLR AVP does not contain explicitly all information needed by the reacting = node in order to decide whether a subsequent request must undergo a throttl= ing process with the reported percentage. To take this decision the reacting node must check

= a)      whether the subsequent request’s Applicatio= n-ID matches the Application-Id received in the OC-OLR AVP’s encapsul= ating answer command;

= b)      if the Report-Type received in the OC-ORL is R= 20;host”

b1)  whether the subsequent request’s Dest= ination Host is present and matches the Origin Host received in the OC-OLR = AVP’s encapsulating answer command;

if the Report-Type received in the= OC-OLR is “realm”

b2) whether the subsequent request’ Destination= Host is absent and the Destination Realm matches the Origin Realm received= in the OC-OLR AVP’s  encapsulating answer command;

&n= bsp;

Best re= gards

Ulrich<= o:p>

&n= bsp;

&n= bsp;

&n= bsp;

From: DiME [mailto= :dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Bartolome
Sent: Tuesday, December 03, 2013 2:56 PM
To: dime@ietf.org
Subject: [Dime] OVLI: clarification in 4.2

 

Hello,

 

I would like to propose a clari= fication on 4.2

     &= nbsp;          ….

   The OC-OLR AVP does not contain explicit information to wh= ich

   application it applies to and who inserted the AVP= or whom the

   sp=
ecific OC-OLR AVP concerns to. Both these information is
   implicitly learned from the encapsula=
ting Diameter message/command.
   The application the OC-OLR AVP applie=
s to is the same as the
   Application-Id found in the Diameter =
message header.  The identity
   the OC-OLR AVP concerns is determined=
 from the Origin-Host AVP found
   from the encapsulating Diameter comma=
nd.

 

 

My understanding is that “= ;who inserted the AVP” cannot always be learned from the encapsulatin= g Diameter message, since “origin-host” may not always contain = the host that inserted the OLR.

A part from that, “whom t= he specific OC-OLR AVP concerns to”, could be a bit misleading…= “whom” may be host, realm, or any other future ReportType, or = even any other “narrowed scope” within the OLR. Last sentence i= s affected by this ambiguity as well.

 

Some rephrasing may be consider= ed:

   The OC-OLR AVP does not contain explicit information that may be 

   implicitly learned from the enca=
psulating Diameter message/command.
   The application the OC-OLR AV=
P applies to is the same as the
   Application-Id found in the Diameter =
message header. When Report-Type is 
   a Destination-Host, the identity
   the OC-OLR AVP concerns is determined=
 from the Origin-Host AVP found
   from the encapsulating Diameter comma=
nd.

 

 

Best regards<= /p>

/MCruz

 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles 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 el=
ectroniques 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 inf=
ormation 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 dele=
te 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.
--_000_6B7134B31289DC4FAF731D844122B36E313AC8PEXCVZYM13corpora_-- From lionel.morand@orange.com Tue Dec 3 09:35:58 2013 Return-Path: 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 30DF51AE11D for ; Tue, 3 Dec 2013 09:35:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 hM5UiH9_QmOM for ; Tue, 3 Dec 2013 09:35:56 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 0079C1AD8F4 for ; Tue, 3 Dec 2013 09:35:54 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 2066426439A for ; Tue, 3 Dec 2013 18:35:52 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 05CEF27C053 for ; Tue, 3 Dec 2013 18:35:52 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0158.001; Tue, 3 Dec 2013 18:35:51 +0100 From: To: "dime@ietf.org" Thread-Topic: OVLI: Clarification on the format of the OC-Report-Type AVP Thread-Index: Ac7wThugO0QKyqubRY2CKRSpVtZHGQ== Date: Tue, 3 Dec 2013 17:35:50 +0000 Message-ID: <26806_1386092152_529E1678_26806_2515_1_6B7134B31289DC4FAF731D844122B36E313B4B@PEXCVZYM13.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.5] Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E313B4BPEXCVZYM13corpora_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.12.3.151814 Subject: [Dime] OVLI: Clarification on the format of the OC-Report-Type AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 17:35:58 -0000 --_000_6B7134B31289DC4FAF731D844122B36E313B4BPEXCVZYM13corpora_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, The proposed format for OC-Report-Type AVP is Enumerated. This would lead to extensibility issue as discussed several times. I would propose to define the OC-Report-Type AVP as Unsigned64 and create s= pecific values. The same registry can be used to add values but we would ge= t rid of the problem with Enumerated AVP. Comment? Lionel ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. --_000_6B7134B31289DC4FAF731D844122B36E313B4BPEXCVZYM13corpora_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

The proposed format for OC-Repo= rt-Type AVP is Enumerated.

This would lead to extensibilit= y issue as discussed several times.

 

I would propose to define the O= C-Report-Type AVP as Unsigned64 and create specific values. The same regist= ry can be used to add values but we would get rid of the problem with Enume= rated AVP.

 

Comment?

 

Lionel

 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles 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 el=
ectroniques 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 inf=
ormation 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 dele=
te 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.
--_000_6B7134B31289DC4FAF731D844122B36E313B4BPEXCVZYM13corpora_-- From lionel.morand@orange.com Tue Dec 3 09:52:40 2013 Return-Path: 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 65EBB1AE151 for ; Tue, 3 Dec 2013 09:52:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 C6Bf_IumH6nG for ; Tue, 3 Dec 2013 09:52:38 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id 2ECC51AC3DD for ; Tue, 3 Dec 2013 09:52:38 -0800 (PST) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id F31293744AF for ; Tue, 3 Dec 2013 18:52:34 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id DD0EB384057 for ; Tue, 3 Dec 2013 18:52:34 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0158.001; Tue, 3 Dec 2013 18:52:34 +0100 From: To: "dime@ietf.org" Thread-Topic: Diameter Guidelines: additional info on alternative to the use of Enumerated Thread-Index: Ac7wUHEP29W63MqjRTmivdiSFEco5g== Date: Tue, 3 Dec 2013 17:52:33 +0000 Message-ID: <4328_1386093154_529E1A62_4328_16367_1_6B7134B31289DC4FAF731D844122B36E313BEA@PEXCVZYM13.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.12.2.94815 Subject: [Dime] Diameter Guidelines: additional info on alternative to the use of Enumerated X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 17:52:40 -0000 Hi, A late comment made me realize that one guideline was missing in http://too= ls.ietf.org/html/draft-ietf-dime-app-design-guide-20 about the possible alt= ernative to Enumerated values when additional values might be defined after= the definition of the AVP. As discussed, one alternative is to use Unsigned32/Unsigned64 AVP instead a= nd to define specific values. I will update the section 5.6 accordingly. Regards, Lionel=20 PS: for information, the proposed text is described below.=20 ************************************ 5.6. Use of Enumerated Type AVPs The type Enumerated was initially defined to provide a list of valid values for an AVP with their respective interpretation described in the specification. For instance, AVPs of type Enumerated can be used to provide further information on the reason for the termination of a session or a specific action to perform upon the reception of the request. As described in the section 4.4.2 above, defining an AVP of type Enumerated presents some limitations in term of extensibility and reusability. Indeed, the finite set of valid values defined at the definition of the AVP of type Enumerated cannot be modified in practice without causing backward compatibility issues with existing implementations. As a consequence, AVPs of Type Enumerated cannot be extended by adding new values to support new capabilities. Diameter protocol designers are then strongly advised to carefully consider before defining an Enumerated AVP whether the set of values will remain unchanged or new values may be required in a near future. If such extension is foreseen or cannot be avoided, it is recommended to rather define AVPs of type Unsigned32 or Unsigned64 in which the data field would contain an address space representing "values" that would have the same use of Enumerated values. For instance, an AVP describing possible access networks would be defined as follow: Access-Network-Type AVP (XXX) is of type Unsigned32 and contains an 32-bit address space representing types of access networks. This application defines the following classes of access networks, all identified by the thousands digit in the decimal notation: o 1xxx (Mobile Access Networks) o 2xxx (Fixed Access Network) o 3xxx (Wireless Access Networks) Values that fall within the Mobile Access Networks category are used to inform a peer that a request has been sent for a user attached to a mobile access networks. The following values are defined in this application: 1001: 3GPP-GERAN TBD. 1002: 3GPP-UTRAN-FDD TBD. Unlike Enumerated AVP, any new value can be added in the address space defined by this Unsigned32 AVP without modifying the definition of the AVP. There is therefore no risk of backward compatibility issue, especially when intermediate nodes may be present between Diameter endpoints. In the same line, AVPs of type Enumerated are too often used as a simple Boolean flag, indicating for instance a specific permission or capability, and therefore only two values are defined, e.g., TRUE/ FALSE, AUTORIZED/UNAUTHORIZED or SUPPORTED/UNSUPPORTED. This is a sub-optimal design since it limits the extensibility of the application: any new capability/permission would have to be supported by a new AVP or new Enumerated value of the already defined AVP, with the backward compatibility issues described above. Instead of using an Enumerated AVP for a Boolean flag, protocol designers are again encouraged to use AVPs of type Unsigned32 or Unsigned64 AVP in which the data field would be defined as bit mask whose bit settings are described in the relevant Diameter application specification. Such AVPs can be reused and extended without major impact on the Diameter application. The bit mask should leave room for future additions. Examples of AVPs that use bit masks are the Session- Binding AVP defined in [RFC6733] and the MIP6-Feature-Vector AVP defined in [RFC5447]. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. From srdonovan@usdonovans.com Tue Dec 3 10:00:22 2013 Return-Path: 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 D39981ABD2A for ; Tue, 3 Dec 2013 10:00:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no 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 4p654ewvm6D3 for ; Tue, 3 Dec 2013 10:00:19 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 6C4A01A1F1A for ; Tue, 3 Dec 2013 10:00:19 -0800 (PST) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:50457 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1VnuGc-0001il-Nz; Tue, 03 Dec 2013 10:00:16 -0800 Message-ID: <529E1C2D.5070707@usdonovans.com> Date: Tue, 03 Dec 2013 12:00:13 -0600 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: lionel.morand@orange.com, "dime@ietf.org" References: <087A34937E64E74E848732CFF8354B920972BE0C@ESESSMB101.ericsson.se> <529DFB3B.3080109@usdonovans.com> <19814_1386090027_529E0E2B_19814_15820_1_6B7134B31289DC4FAF731D844122B36E31353F@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <19814_1386090027_529E0E2B_19814_15820_1_6B7134B31289DC4FAF731D844122B36E31353F@PEXCVZYM13.corporate.adroot.infra.ftgroup> Content-Type: multipart/alternative; boundary="------------040703020802000704050908" X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com Subject: Re: [Dime] OLR applicable for any/all applications X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 18:00:23 -0000 This is a multi-part message in MIME format. --------------040703020802000704050908 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Lionel, I'm just pointing out that it is not a valid assumption that only a single application will be carried across a connection. We should not ignore that fact. Steve On 12/3/13 11:00 AM, lionel.morand@orange.com wrote: > > Hi Steve, > > > > The collocation of multiple functions in the same node does not imply > interaction between these functions. And because it is > implementation-dependent, it was considered that such use cases should > be left out for further investigations. > > > > Regards, > > > > Lionel > > > > *De :*DiME [mailto:dime-bounces@ietf.org] *De la part de* Steve Donovan > *Envoyé :* mardi 3 décembre 2013 16:40 > *À :* dime@ietf.org > *Objet :* Re: [Dime] OLR applicable for any/all applications > > > > Nirav, > > Agents handle multiple applications over a single connection. > > It is also possible that implementations can support multiple 3GPP > functions in a single node. For instance, someone might decide to > implement a combined HSS and EIR, causing the MME to communicate S6a > and S13 over the same connection. > > Steve > > On 12/3/13 3:41 AM, Nirav Salot (nsalot) wrote: > > Maria-Cruz, > > > > The existing OC-OLR definition (without "All Application" AVP) > already addresses your use case. E.g. reporting node includes > same value of "Reduction-Percentage" in all the application > messages sent by it. So we don't need "All Application" AVP > additionally. > > Besides, reporting "Reduction-Percentage" of a different > application violates the basic principle of the piggybacking. > > Finally, in 3GPP (as far as I remember) we do not have any use > case of two nodes interfacing with each other over more than one > application. i.e. we have only one application between any pair of > nodes and if that is so then I fail to see the practicality of the > use case you have mentioned below. > > > > Regards, > > Nirav. > > > > *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *Maria > Cruz Bartolome > *Sent:* Tuesday, December 03, 2013 2:13 PM > *To:* dime@ietf.org > *Subject:* [Dime] OLR applicable for any/all applications > > > > > > Dear all, > > > > There may be a need by a reporting node to request traffic > reduction for all traffic, application independent, e.g. if an > operator's network becomes severely overloaded, it may be of > interest to signal directly general overload to the client. > > In this case, since reacting node obtains affected application > from the application message, we may need to extend OLR. > > > > At least we got following options: > > > > > > A) Define a new optional AVP that could be included into OLR, > like e.g.: > > OC-OLR ::= < AVP Header: TBD2 > > > < TimeStamp > > > [ Reduction-Percentage ] > > [ ValidityDuration ] > > [ ReportType ] > > [All applications] > > * [ AVP ] > > > > > > B) Extend ReportTypes like e.g.: > > > > 3 Destination-Host All Applications report. Similar to > Destination-Host report but it would apply to any application > regardless the application message this report is received within. > > > > 4 Realm (aggregated) All Applicationsreport. Similar to Realm > report but it would apply to any application regardless the > application message this report is received within. > > > > > > > > I tend to prefer option A, but let me know your opinions and > preferences. > > Best regards > > /MCruz > > > > > > > > > _______________________________________________ > > 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. --------------040703020802000704050908 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Lionel,

I'm just pointing out that it is not a valid assumption that only a single application will be carried across a connection.  We should not ignore that fact.

Steve
On 12/3/13 11:00 AM, lionel.morand@orange.com wrote:

Hi Steve,

 

The collocation of multiple functions in the same node does not imply interaction between these functions. And because it is implementation-dependent, it was considered that such use cases should be left out for further investigations.

 

Regards,

 

Lionel

 

De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoyé : mardi 3 décembre 2013 16:40
À : dime@ietf.org
Objet : Re: [Dime] OLR applicable for any/all applications

 

Nirav,

Agents handle multiple applications over a single connection.

It is also possible that implementations can support multiple 3GPP functions in a single node.  For instance, someone might decide to implement a combined HSS and EIR, causing the MME to communicate S6a and S13 over the same connection.

Steve

On 12/3/13 3:41 AM, Nirav Salot (nsalot) wrote:

Maria-Cruz,

 

The existing OC-OLR definition (without "All Application" AVP) already addresses your use case. E.g. reporting  node includes same value of "Reduction-Percentage" in all the application messages sent by it. So we don’t need "All Application" AVP additionally.

Besides, reporting "Reduction-Percentage" of a different application violates the basic principle of the piggybacking.

Finally, in 3GPP (as far as I remember) we do not have any use case of two nodes interfacing with each other over more than one application. i.e. we have only one application between any pair of nodes and if that is so then I fail to see the practicality of the use case you have mentioned below.

 

Regards,

Nirav.

 

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Maria Cruz Bartolome
Sent: Tuesday, December 03, 2013 2:13 PM
To: dime@ietf.org
Subject: [Dime] OLR applicable for any/all applications

 

 

Dear all,

 

There may be a need by a reporting node to request traffic reduction for all traffic, application independent, e.g. if an operator’s network becomes severely overloaded, it may be of interest to signal directly general overload to the client. 

In this case, since reacting node obtains affected application from the application message, we may need to extend OLR.

 

At least we got following options:

 

 

A)     Define a new optional AVP that could be included into OLR, like e.g.:

   OC-OLR ::= < AVP Header: TBD2 >
              < TimeStamp >
              [ Reduction-Percentage ]
              [ ValidityDuration ]
              [ ReportType ]
              [All applications]
            * [ AVP ]

 

 

B)      Extend  ReportTypes like e.g.:

 

   3  Destination-Host All Applications report.  Similar to Destination-Host report but it would apply to any application regardless the application message this report is received within.

 

   4  Realm (aggregated) All Applications report.  Similar to Realm report but it would apply to any application regardless the application message this report is received within.

 

 

 

I tend to prefer option A, but let me know your opinions and preferences.

Best regards

/MCruz

 

 




_______________________________________________
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.

--------------040703020802000704050908-- From jouni.nospam@gmail.com Tue Dec 3 10:15:06 2013 Return-Path: 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 EF4F21AE145 for ; Tue, 3 Dec 2013 10:15:05 -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 igDLnDNHG2HQ for ; Tue, 3 Dec 2013 10:15:04 -0800 (PST) Received: from mail-bk0-x231.google.com (mail-bk0-x231.google.com [IPv6:2a00:1450:4008:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id C8A331AD791 for ; Tue, 3 Dec 2013 10:15:03 -0800 (PST) Received: by mail-bk0-f49.google.com with SMTP id my13so6043940bkb.8 for ; Tue, 03 Dec 2013 10:15:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HDSnMfL+5zeYdoRepjpU6TzTIgACtZcyGZDEOe7chc0=; b=sQkOsKqLP4Xrp2yhRkh7oy0TQmyQmbixICfFisuJGGcYuKJ0QwO8H83wWmEFT3Krsc eUdu9wRvohNsXlSZ2XFfhdWEuqlTgkqS5QMPJ8sgPgugrD6Xy9x0OFSyqQv2onqZDLeR jodzT8/wPnMTokbZUUkYxmJZEw5YadHwzGkIh+xkkXsw2xLCKBFJYLOtu3yvX9J5gnKe EayZfyMPLr7YTdxgPjr8FVaDU+TPsRerIXyGfAIYcxbd+eE4pHE9a01Udf2UbU5OEy5X +2eOue4/XVreY/5ahbjnvdTtKZRPs6O3iL+Cn+LFJTldP3Gq8Mk1OwtR4DZAd7t43hza 2N8A== X-Received: by 10.204.229.139 with SMTP id ji11mr33411840bkb.4.1386094500472; Tue, 03 Dec 2013 10:15:00 -0800 (PST) Received: from ?IPv6:2001:1bc8:101:f101:b5b2:8e61:f64:bc2a? ([2001:1bc8:101:f101:b5b2:8e61:f64:bc2a]) by mx.google.com with ESMTPSA id t2sm79024276bkh.3.2013.12.03.10.14.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Dec 2013 10:14:59 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Jouni In-Reply-To: <26806_1386092152_529E1678_26806_2515_1_6B7134B31289DC4FAF731D844122B36E313B4B@PEXCVZYM13.corporate.adroot.infra.ftgroup> Date: Tue, 3 Dec 2013 20:14:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <26806_1386092152_529E1678_26806_2515_1_6B7134B31289DC4FAF731D844122B36E313B4B@PEXCVZYM13.corporate.adroot.infra.ftgroup> To: X-Mailer: Apple Mail (2.1283) Cc: "dime@ietf.org" Subject: Re: [Dime] OVLI: Clarification on the format of the OC-Report-Type AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 18:15:06 -0000 On Dec 3, 2013, at 7:35 PM, = wrote: > Hi, > =20 > The proposed format for OC-Report-Type AVP is Enumerated. > This would lead to extensibility issue as discussed several times. I know what you refer to but I think it is a non-issue since the AVP is optional and we can define the default behavior when the content is not understood. - Jouni > =20 > I would propose to define the OC-Report-Type AVP as Unsigned64 and = create specific values. The same registry can be used to add values but = we would get rid of the problem with Enumerated AVP. > =20 > Comment? > =20 > Lionel > =20 > = __________________________________________________________________________= _______________________________________________ >=20 > 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. >=20 > 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. >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From ben@nostrum.com Tue Dec 3 13:35:24 2013 Return-Path: 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 B30C71AE11D for ; Tue, 3 Dec 2013 13:35:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no 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 rQvCVB9gdbCw for ; Tue, 3 Dec 2013 13:35:23 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 606571ADFD9 for ; Tue, 3 Dec 2013 13:35:23 -0800 (PST) Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rB3LZ7Cf038389 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Dec 2013 15:35:09 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ben Campbell In-Reply-To: <82C71989-401F-4972-8878-7D2B1052CCA0@gmail.com> Date: Tue, 3 Dec 2013 15:35:07 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <94F425B4-9027-4934-A20A-890691A6C562@nostrum.com> References: <82C71989-401F-4972-8878-7D2B1052CCA0@gmail.com> To: Jouni Korhonen X-Mailer: Apple Mail (2.1822) Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism) Cc: "dime@ietf.org list" Subject: Re: [Dime] DOIC and terminology X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 21:35:24 -0000 IMHO, the term "server farm" is useful, but the term SFE is not. In = fact, I suspect that people will read more into SFE than intended, and = think it means something special, or that we are defining a new = architectural element. On Nov 28, 2013, at 3:51 AM, Jouni Korhonen = wrote: > Folks, >=20 > In the terminology there is an open issue: >=20 > [OpenIssue: We used the concept of a server farm and SFE for > internal discussions. Do we still need those concepts to = explain the > mechanism? It doesn't seem like we use them much.] >=20 > The terms server farm and SFE are mainly used within the terminology > section itself. If we were to remove e.g. SFE only, then the following = are > also in the list for removal: >=20 > Load Management: >=20 > This functionality ensures that the consolidated load state for > the server farm is collected, and processed. The exact algorithm > for computing the load at the SFE is implementation specific but > enough semantic of the conveyed load information needs to be > specified so that deterministic behavior can be ensured. >=20 > Overload Management: >=20 > The SFE is the entity that understands the consolidated overload > state for the server farm. Just as it is outside the scope of > this document to specify how a Diameter server calculates its > overload state, it is also outside the scope of this document to > specify how an SFE calculates the overload state for the set of > servers. This document describes how the SFE communicates > Overload information to Diameter Clients. >=20 > Server Farm Identity Management: >=20 > Server Farm Identity Management (SFIM) is a mechanism that can be > used by the SFE to present a single Diameter identity that can be > used by clients to send Diameter requests to the server farm. > This requires that the SFE modifies Origin-Host information in > answers coming from servers in the server farm. An agent that > performs SFIM appears as a server from the client's perspective. >=20 >=20 > There are also other impacts but those can be reworded with a minor = effort. >=20 >=20 > Opinions? >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From ben@nostrum.com Tue Dec 3 13:45:48 2013 Return-Path: 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 3AA781ADF48 for ; Tue, 3 Dec 2013 13:45:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no 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 rUMRP1-Vdr78 for ; Tue, 3 Dec 2013 13:45:47 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 192251AD9B8 for ; Tue, 3 Dec 2013 13:45:47 -0800 (PST) Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rB3LjgLW038812 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Dec 2013 15:45:43 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ben Campbell In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681519BD77@DEMUMBX014.nsn-intra.net> Date: Tue, 3 Dec 2013 15:45:42 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5BCBA1FC2B7F0B4C9D935572D90006681519BD77@DEMUMBX014.nsn-intra.net> To: "Wiehe, Ulrich (NSN - DE/Munich)" X-Mailer: Apple Mail (2.1822) Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism) Cc: "dime@ietf.org" Subject: Re: [Dime] endpoint determination X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 21:45:48 -0000 On Nov 28, 2013, at 6:21 AM, Wiehe, Ulrich (NSN - DE/Munich) = wrote: > Hi, >=20 > draft-ietf-dime-ovli-00 in Clause 5.1 says: >=20 > How the endpoints are determined is specific to a deployment, a = Diameter node role in that deployment and local configuration. >=20 >=20 > In order to better address REQ 6 of RFC 7068 I would like to propose = some principles that should be taken into account: >=20 > 1. A client that supports the Diameter Overload Control Mechanism must = (offer to) take the role of a reacting endpoint and hence includes the = OC-Feature-Vector AVP when sending requests. > 2. An Agent that - based on local configuration - takes the role of a = reporting endpoint (towards the downstream reacting endpoint) must also = (offer to) take the role of a reacting endpoint towards the server and = hence replace the received OC-Feature-Vector AVP with its own = OC-Featur-Vector AVP. I agree with the concepts in 1 and 2, but not as written (assuming you = intend the use of must to be normative.) I think this is better written = in terms of a definition of what reporting node and reacting node means, = then mention that a supporting client is normally a reacting node, a = supporting server is normally a reporting node, and an agent can be = both. > 3. An agent that supports the Diameter Overload Control Mechanism and = that - based on absence of local configuration - does not take the role = of a reporting endpoint must be able to detect whether a downstream = agent or client already takes the role of the reacting endpoint (e.g. = by checking the presence of an OC-Feature-Vector AVP in the received = request). If it detects that no downstream node took the role of the = reacting endpoint, the agent must take the role of the reacting = endpoint and hence insert an OC-Feature AVP to the request. I.e. = determination of the reporting endpoint is done dynamically and does not = rely on local configuration. I read that to mean you expect an agent to "take over" as the reacting = node even if the administrator has completely turned off OC? If so, I = don't agree, at least not as a normative requirement. Implementors can = choose to create such a mode if they want to, but we don't need to = require it. From ben@nostrum.com Tue Dec 3 13:49:00 2013 Return-Path: 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 8D7A11ADEBF for ; Tue, 3 Dec 2013 13:49:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no 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 0lFtpEqTcNKZ for ; Tue, 3 Dec 2013 13:48:59 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8B8B51A8032 for ; Tue, 3 Dec 2013 13:48:59 -0800 (PST) Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rB3LmlPr038868 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Dec 2013 15:48:48 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ben Campbell In-Reply-To: Date: Tue, 3 Dec 2013 15:48:47 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <3EA2D87D-9E72-47ED-B079-D24526E5C4FE@nostrum.com> References: To: Jouni Korhonen X-Mailer: Apple Mail (2.1822) Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism) Cc: "dime@ietf.org list" Subject: Re: [Dime] draft-ietf-dime-ovli-01 comment #3 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 21:49:00 -0000 I concur with adding it back. We might consider naming it something more = descriptive; that is, it's more important that it's the "loss" algorithm = than that it's the default algorithm. On Dec 2, 2013, at 6:27 AM, Jouni Korhonen = wrote: >=20 > I brought back the initial features flag for the default abatement > algorithm. It was pointed out to me that just the absence of the > OC-Feature-Vector AVP is not adequate enough in a case multiple > supported abatement algorithms get announced and something specific > is needed to be said about the default algorithm (like the other end > specifically does not want to use it). >=20 > - Jouni >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From ben@nostrum.com Tue Dec 3 13:51:33 2013 Return-Path: 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 A28371ADEBF for ; Tue, 3 Dec 2013 13:51:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no 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 YaunBu4Ub5S4 for ; Tue, 3 Dec 2013 13:51:32 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0E4DC1ADE8A for ; Tue, 3 Dec 2013 13:51:32 -0800 (PST) Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rB3LpRlv039041 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Dec 2013 15:51:28 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ben Campbell In-Reply-To: <529CA996.4020208@usdonovans.com> Date: Tue, 3 Dec 2013 15:51:27 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <6A3207D0-BA9B-4659-B975-6D9DD30B85EB@nostrum.com> References: <2D60D862-45C5-4B13-96E6-F9621AF33759@gmail.com> <19936_1385975192_529C4D98_19936_10950_1_6B7134B31289DC4FAF731D844122B36E30F190@PEXCVZYM13.corporate.adroot.infra.ftgroup> <529CA996.4020208@usdonovans.com> To: Steve Donovan X-Mailer: Apple Mail (2.1822) Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism) Cc: "dime@ietf.org list" Subject: Re: [Dime] draft-ietf-dime-ovli-01 questions #2 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 21:51:33 -0000 On Dec 2, 2013, at 9:39 AM, Steve Donovan = wrote: > I would phrase it as application specific. +1. > It is completely possible that the IETF could define an application = that used pseudo sessions as well. =20 >=20 I hope we don't :-) Creating implicit session state while intentionally = not using the built in mechanism for session state seems a questionable = design choice. > Steve > On 12/2/13 3:06 AM, lionel.morand@orange.com wrote: >> Hi, >>=20 >> Not sure that it is so "SDO" specific. But it is true that we should = clarify that this concept is not clearly described in RFC6733 and it is = up to the application to define the specific session states when not = relying on the session-id and the session state machine defined in = RFC6733. >>=20 >> Lionel >>=20 >> -----Message d'origine----- >> De : DiME [ >> mailto:dime-bounces@ietf.org >> ] De la part de Jouni >> Envoy=E9 : lundi 2 d=E9cembre 2013 09:25 >> =C0 :=20 >> DiME@ietf.org >>=20 >> Objet : [Dime] draft-ietf-dime-ovli-01 questions #2 >>=20 >> In Section 3.1.1 where pseudo-session applications are discussed = shouldn't >> we also state that the pseudo-session application is somewhat a SDO = specific >> jewel? IMHO it is not really what RFC6733 session-less application = is, >> although from the base protocol point of view it is compliant. >>=20 >> - Jouni >> _______________________________________________ >> DiME mailing list >>=20 >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >>=20 >>=20 >> = __________________________________________________________________________= _______________________________________________ >>=20 >> 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. >>=20 >> 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. >>=20 >> _______________________________________________ >> DiME mailing list >>=20 >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >>=20 >>=20 >>=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From ben@nostrum.com Tue Dec 3 13:54:51 2013 Return-Path: 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 0243A1ADEBF for ; Tue, 3 Dec 2013 13:54:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no 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 FT5AwEhGVhw5 for ; Tue, 3 Dec 2013 13:54:49 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 34D2A1ADE8A for ; Tue, 3 Dec 2013 13:54:49 -0800 (PST) Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rB3LsgCV039094 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Dec 2013 15:54:43 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ben Campbell In-Reply-To: <3468_1385718494_529862DE_3468_4222_1_6B7134B31289DC4FAF731D844122B36E309600@PEXCVZYM13.corporate.adroot.infra.ftgroup> Date: Tue, 3 Dec 2013 15:54:42 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <3015E787-881A-468B-9127-895C2946D726@nostrum.com> References: <5E28C8B7-2E5E-41E8-9592-24A19AD76826@gmail.com> <9889_1385714340_529852A4_9889_16410_1_6B7134B31289DC4FAF731D844122B36E3093B0@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52EDD6D4-71CD-439F-9D2D-439CC656C3CC@gmail.com> <3468_1385718494_529862DE_3468_4222_1_6B7134B31289DC4FAF731D844122B36E309600@PEXCVZYM13.corporate.adroot.infra.ftgroup> To: "ext lionel.morand@orange.com" X-Mailer: Apple Mail (2.1822) Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism) Cc: "dime@ietf.org list" Subject: Re: [Dime] open issues #1 in DOIC X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 21:54:51 -0000 On Nov 29, 2013, at 3:48 AM, lionel.morand@orange.com wrote: > Actually, I realized that we are redefining something somehow already = in use in RFC 6733: >=20 > 9.6. Correlation of Accounting Records >=20 >=20 > If an application uses accounting messages, it can correlate > accounting records with a specific application session by using the > Session-Id of the particular application session in the accounting > messages. Accounting messages MAY also use a different Session-Id > from that of the application sessions, in which case, other session- > related information is needed to perform correlation. >=20 > We could maybe reuse the same type of wording to simplify the = definition: >=20 > Pseudo-session applications are applications that > do not rely on the Session-Id AVP for correlation=20 > of application messages related to the same session > but use another session-related information for this > purpose. The 3GPP defined Cx application [3GPP.29.229] > is an example of a pseudo-session application. >=20 > OK? >=20 I think that's generally okay, but it might be useful to be explicit on = the answer to the original question, that is, whether we assume all = requests in a pseudo-session go to the same server.=20 > Regards, >=20 > Lionel >=20 > -----Message d'origine----- > De : Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20 > Envoy=E9 : vendredi 29 novembre 2013 10:01 > =C0 : MORAND Lionel IMT/OLN > Cc : dime@ietf.org list > Objet : Re: [Dime] open issues #1 in DOIC >=20 >=20 > Pseudo-session applications: >=20 > While this class of application does not use the Diameter > Session-ID AVP to correlate requests, there is an implied = ordering > of transactions defined by the application and except for the > Session-ID differences pseudo-session based applications are > generally assumed to behave like session-based application. The > 3GPP defined Cx application [3GPP.29.229] is an example of a > pseudo-session application. >=20 >=20 > Would this suffice? >=20 > - Jouni >=20 >=20 >=20 > On Nov 29, 2013, at 10:38 AM, lionel.morand@orange.com wrote: >=20 >> Hi, >>=20 >> For me, "pseudo-session" refers to session-based oriented = applications that do not rely on the session-id for message correlations = but on something else e.g. user-name. So it is implied that the same = server is contacted by the client managing the session. In the Cx = example, the same origin-host will be used in the client-initiated = requests after the initial exchange and the server discovery phase. >>=20 >> Regards, >>=20 >> Lionel=20 >>=20 >> -----Message d'origine----- >> De : DiME [mailto:dime-bounces@ietf.org] De la part de Jouni Korhonen >> Envoy=E9 : vendredi 29 novembre 2013 09:30 >> =C0 : dime@ietf.org list >> Objet : [Dime] open issues #1 in DOIC >>=20 >> Folks, >>=20 >> [OpenIssue: Do we assume that all requests in a = pseudo-session >> typically need to go to the same server?] >>=20 >>=20 >> The example here is in context of Cx. Not that I am expert on Cx (or = anything) >> but based on the CCF the requests _may_ have destination-host. Thus, = I assume >> that it is an implementation issue whether pseudo-sessions need to go = to the >> same server.. I guess we cannot have such firm requirement. Correct? >>=20 >> - Jouni >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >>=20 >> = __________________________________________________________________________= _______________________________________________ >>=20 >> 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. >>=20 >> 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. >>=20 >=20 >=20 > = __________________________________________________________________________= _______________________________________________ >=20 > 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. >=20 > 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. >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From ben@nostrum.com Tue Dec 3 13:56:25 2013 Return-Path: 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 382C01AD8DA for ; Tue, 3 Dec 2013 13:56:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no 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 Sdk4DgSCgFHk for ; Tue, 3 Dec 2013 13:56:24 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 879281AC7EE for ; Tue, 3 Dec 2013 13:56:24 -0800 (PST) Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rB3LuGk1039254 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Dec 2013 15:56:17 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ben Campbell In-Reply-To: <3558_1386001910_529CB5F6_3558_6116_1_6B7134B31289DC4FAF731D844122B36E3110E6@PEXCVZYM13.corporate.adroot.infra.ftgroup> Date: Tue, 3 Dec 2013 15:56:16 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <487F94B4-F695-42B7-887B-0EBCDC5FF0C2@nostrum.com> References: <16E13E52-0DB9-4E72-964A-FE658536155B@gmail.com> <10629_1385971488_529C3F20_10629_5138_1_emlwd34vyt318xrd8i01xiee.1385971482719@email.android.com> <529CAA39.6050809@usdonovans.com> <3558_1386001910_529CB5F6_3558_6116_1_6B7134B31289DC4FAF731D844122B36E3110E6@PEXCVZYM13.corporate.adroot.infra.ftgroup> To: "ext lionel.morand@orange.com" X-Mailer: Apple Mail (2.1822) Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism) Cc: "dime@ietf.org" Subject: Re: [Dime] draft-ietf-dime-ovli-01 questions #1 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 21:56:25 -0000 On Dec 2, 2013, at 10:31 AM, lionel.morand@orange.com wrote: > RFC5729 is another example. Maybe can we be more generic saying that = enhanced routing decisions can be performed at the application level = based on specific info e.g. NAI and add some examples. +1. We don't need to be exhaustive. From ben@nostrum.com Tue Dec 3 13:58:57 2013 Return-Path: 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 5C3A91ADD9D for ; Tue, 3 Dec 2013 13:58:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no 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 SgwHiOADE-dJ for ; Tue, 3 Dec 2013 13:58:56 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 562E71AC7EE for ; Tue, 3 Dec 2013 13:58:56 -0800 (PST) Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rB3LwqUM039298 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Dec 2013 15:58:53 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ben Campbell In-Reply-To: <529CAE2D.8020600@usdonovans.com> Date: Tue, 3 Dec 2013 15:58:52 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <1288D590-986D-4752-8FC4-B52F912C2BDB@nostrum.com> References: <50C72080-905C-4B1D-BAD8-C0026791BA6E@gmail.com> <6390_1385631299_52970E43_6390_18869_1_6B7134B31289DC4FAF731D844122B36E3074FC@PEXCVZYM13.corporate.adroot.infra.ftgroup> <529CAE2D.8020600@usdonovans.com> To: Steve Donovan X-Mailer: Apple Mail (2.1822) Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism) Cc: "dime@ietf.org list" Subject: Re: [Dime] DOIC document size and placeholders X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 21:58:57 -0000 On Dec 2, 2013, at 9:58 AM, Steve Donovan = wrote: > I would prefer to wait to drop the conformance section. Either that = or keep it updated as a separate draft/document to keep us focused on = the requirements. I agree we should keep this section, and perhaps mark it as "to be = removed by the RFC editor". While it's not really useful for the RFC, = it's extremely useful for the work-in-process draft. >=20 > I agree on the S6a and PCC examples. Much of that information in = already contained in either the requirements RFC or 3GGP DOC document. Agreed. If we decide it's important, we can publish it as a separate = informational RFC.= From ben@nostrum.com Tue Dec 3 14:05:52 2013 Return-Path: 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 47CBB1AE16B for ; Tue, 3 Dec 2013 14:05:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no 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 2OlKD8CjPSo0 for ; Tue, 3 Dec 2013 14:05:51 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7A23D1ADD9D for ; Tue, 3 Dec 2013 14:05:51 -0800 (PST) Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rB3M5g5T039642 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Dec 2013 16:05:43 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ben Campbell In-Reply-To: <18796_1385626955_5296FD4B_18796_11001_1_6B7134B31289DC4FAF731D844122B36E3071A0@PEXCVZYM13.corporate.adroot.infra.ftgroup> Date: Tue, 3 Dec 2013 16:05:41 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <78E23951-EE6E-4295-BBE3-FDC37C5E362D@nostrum.com> References: <66DEB166-8DEB-42CA-A46E-8128F0D0900B@nostrum.com> <4CFE9D80-E25A-4B8F-96D1-EB7C21F2F11A@nostrum.com> <9AC5C876-99AD-4C43-9B13-3288C76459FB@gmail.com> <18796_1385626955_5296FD4B_18796_11001_1_6B7134B31289DC4FAF731D844122B36E3071A0@PEXCVZYM13.corporate.adroot.infra.ftgroup> To: "ext lionel.morand@orange.com" X-Mailer: Apple Mail (2.1822) Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism) Cc: "dime@ietf.org" Subject: Re: [Dime] Proposed Example Text for draft-docdt-dime-ovli-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 22:05:52 -0000 On Nov 28, 2013, at 2:22 AM, lionel.morand@orange.com wrote: > I could discuss the need for the report type for a longtime... > But I can live with the following approach: >=20 > - Keep the report type AVP > - Keep the Report type as optional in the OC-OLR > - Clarify that the OC-OLR applies to the Origin-Host of the Answer = when the report type is absent > - Multiple OLRs can be found in the answer only if the OLRs have = different Report types e.g. response to an initial request (with only = dest-Realm AVP) may contain overload status of the node and of the realm > - Remove "aggregated" >=20 > Is it OK for everyone? What does it mean for the report type to be optional? More to the point, = do we expect all reacting nodes to support ReportType? If not, what = behavior do we expect from a node that doesn't understand ReportType, = and gets a report that includes it? The answer can't be to ignore the = presence of ReportType, because that is likely to cause incorrect = action. From ben@nostrum.com Tue Dec 3 14:16:12 2013 Return-Path: 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 B8AD01ADF71 for ; Tue, 3 Dec 2013 14:16:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no 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 ntSX0objnYkL for ; Tue, 3 Dec 2013 14:16:10 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0D3641ADF69 for ; Tue, 3 Dec 2013 14:16:09 -0800 (PST) Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rB3MG02G040060 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Dec 2013 16:16:01 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ben Campbell In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681519C296@DEMUMBX014.nsn-intra.net> Date: Tue, 3 Dec 2013 16:16:00 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <4244E2A6-F8E6-4CE5-B377-B42E99107C33@nostrum.com> References: <5BCBA1FC2B7F0B4C9D935572D90006681519C296@DEMUMBX014.nsn-intra.net> To: "Wiehe, Ulrich (NSN - DE/Munich)" X-Mailer: Apple Mail (2.1822) Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism) Cc: "dime@ietf.org" Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same type) within a response message X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 22:16:12 -0000 On Dec 3, 2013, at 3:48 AM, Wiehe, Ulrich (NSN - DE/Munich) = wrote: > Nirav, > =20 > I still do not see the need for more than one OLR in an answer. > =20 > More than one OLR means more complexity. Let=92s try to avoid that. I agree it adds complexity for the reacting node. As I outlined in my = original email on the mixed dh/dr example, I think _not_ allowing it = adds more complexity for the reporting node, since it may need to send = more reports than it has answers to put them in. I think it's reasonable to transfer complexity from the reporting node = to the reacting node, since the reporting node is often the overloaded = entity. > =20 > The server gets a request that either is or is not in the narrower = scope. If it is not, why shoud the server return an OLR for the narrower = scope? It can do so when it gets a request within the narrower scope = (which possibly never happens). > =20 > Ulrich > =20 > =20 > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Nirav Salot = (nsalot) > Sent: Tuesday, December 03, 2013 10:26 AM > To: Maria Cruz Bartolome; dime@ietf.org > Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same = type) within a response message > =20 > Maria-Cruz, > =20 > > we may think that we need two different OLRs with ReportType=3Dhost, = and one of them includes the extra info (AVPs) required for that = application > Yes. The above is my concern. I tried giving APN as one example AVP = which we may want to include in OC-OLR. Let me give another possible = example. > As of now, the OC-OLR can indicate application + host/realm level = "required-reduction-percentage". > However, for the given application (e.g. Gx) we may want to define a = narrower scope with "session-type =3D {M2M, Others}" AVP. So basically, = the Gx nodes can advertise different "required-reduction-percentage" for = M2M sessions v/s other type of sessions for the same application Gx and = for the same destination-host. > =20 > So in general, if any application needs to define a different (i.e. = narrower) scope than application + host/realm, it can do so by adding a = new AVP in OC-OLR. > And then we might have two instances of OC-OLR from the same host. > =20 > We could achieve the above by defining new Report-Type for each new = AVP added by each application. But would this scale or is this a = reasonable approach? > I am not sure and you have already identified one of my concerns below > > if we extend ReportType, does it need to be done by IETF, or could = it be done per application by 3GPP? > =20 > In summary, in my view, we need to define the handling of multiple = instances with the same Report-Type as part of the DOIC draft. Or we say = that multiple instances with the same Report-Type is not allowed =96 = this seems unnecessary restriction to me. > Otherwise, if later, we realize the need to do so then we may not be = able to do so since the handling is not defined in the base solution. > =20 > Regards, > Nirav. > =20 > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Maria Cruz = Bartolome > Sent: Tuesday, December 03, 2013 1:57 PM > To: dime@ietf.org > Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same = type) within a response message > =20 > Nirav, > =20 > I think I understand your concern. It may occur that we need that a = reacting node should apply two different OLR when sending a request = towards one specific host. > Then, we may think that we need two different OLRs with = ReportType=3Dhost, and one of them includes the extra info (AVPs) = required for that application, I think this is your interpretation, but=85= we can as well consider a new ReportType=3DapplicX_ReportY, that may = apply e.g. for any request send to this application, or just for this = application+host, and then Host could be another AVP to be included in = the OLR, or we could define expected behaviour when defining this new = ReportType. > =20 > Would this cover your concerns? If not, could you try to provide an = example that requires two OLR with ReportType=3Dhost? > =20 > A part from that, a question for all, if we extend ReportType, does it = need to be done by IETF, or could it be done per application by 3GPP? > =20 > Thanks > /MCruz > =20 > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Nirav Salot = (nsalot) > Sent: jueves, 28 de noviembre de 2013 17:11 > To: lionel.morand@orange.com > Cc: dime@ietf.org > Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same = type) within a response message > =20 > Hi Lionel, > =20 > I am not sure if defining new ReportType for every new AVP 3GPP would = add for a specific application would be a good solution. > I thought ReportType would indicate if the corresponding OC-OLR should = be used while sending the traffic towards the host or towards the realm. > So from that point of view, all the OC-OLR generated by the server = should have ReportType=3Dhost. i.e. when the reacting node sends the = traffic towards that host, it should make use of the corresponding = OC-OLR. Now, this OC-OLR may contain the AVPs defined by DOIC draft as = well as 3GPP application specific AVPs. > =20 > In general, I was just thinking that it may be good idea to define = some of the principles such as > - More than one instances of OC-OLR with ReportType=3Dhost = may be present in the answer message if the OC-OLR definition is = extended by the application using the same. In that case, it is the = responsibility of the application to define the valid combination of = OC-OLR instances in a given message > - If the reporting node includes more than one instance of = OC-OLR, the reporting node shall always include all the active instances = of OC-OLR in a response message. > - When the reacting node receives one or more instances of = OC-OLR with the given ReportType and with new timestamp value, it should = overwrite all the existing OC-OLR of the same ReportType. > =20 > Regards, > Nirav. > =20 > From: lionel.morand@orange.com [mailto:lionel.morand@orange.com]=20 > Sent: Thursday, November 28, 2013 7:39 PM > To: Nirav Salot (nsalot) > Cc: dime@ietf.org > Subject: RE: DOIC: Multiple instance of OC-OLR AVP (of the same type) = within a response message > =20 > Hi Nirav, > =20 > The Report Type should be able to differentiate such cases. In your = example, I would define a specific Report type. > But difficult to appraise all the future use cases. But for me, the = main use of the report type is to differentiate OC-OLR received in the = same message. > And it is the reasons of my recommendation. Actually, the exact = wording will be a "SHOULD" saying that it is recommended but you may = have serious reasons to do otherwise. > =20 > Lionel > =20 > De : Nirav Salot (nsalot) [mailto:nsalot@cisco.com]=20 > Envoy=E9 : jeudi 28 novembre 2013 13:00 > =C0 : MORAND Lionel IMT/OLN > Cc : dime@ietf.org > Objet : RE: DOIC: Multiple instance of OC-OLR AVP (of the same type) = within a response message > =20 > Lionel, >=20 > 3gpp may define an optional avp which can be included by the reporting = node if it wishes to do so. E.g. APN can be additionally included by the = reporting node to indicate APN specific overload within the given = application. > In that case, the reporting node may also want to indicate application = level overload without including the APN (e.g. this overload report is = applicable to all other APNs). >=20 > And hence there is a possibility of including multiple instances of = the overload report. >=20 > I am not suggesting that 3gpp will define APN (or any other avp) = within overload report. But later, if 3gpp need to define the same, then = corresponding handling needs to be defined within IETF now. >=20 > Regards, > Nirav. >=20 > On Nov 28, 2013 3:56 PM, "lionel.morand@orange.com" = wrote: > Hi Nirav, > =20 > Not sure to understand the proposal or question. > The OLR is significant per application (piggybacking principle). So if = the 3GPP decides to add specific AVPs in the OLR (that will be = possible), what would be the need to add the OLR without the specific = 3GPP AVPs as the OLR will be anyway handle by 3GPP aware entities? > =20 > Lionel > =20 > De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot = (nsalot) > Envoy=E9 : jeudi 28 novembre 2013 10:33 > =C0 : dime@ietf.org > Objet : [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same = type) within a response message > =20 > Hi, > =20 > As I understand IETF will define the base overload control solution as = part of DOIC. Then 3GPP would adopt the defined solution for each of its = application. > When that happens, 3GPP might want to add 3GPP specific AVP within = OC-OLR AVP. Based on the current definition of the OC-OLR AVP this = should be allowed since it contains "* [AVP]" in its definition. > e.g. for a given application 3GPP decides to add information into = OC-OLR which changes the scope of the OC-OLR from application level to = the provided information level. > Additionally, the reporting may want to advertise the OC-OLR at the = application level scope =96 i.e. the OC-OLR without any 3GPP specific = info. > =20 > So if the above is allowed, we will have the possibility of the = reporting node wanting to include two instances of OC-OLR with the = Report-Type=3D"host". > And then we need to define the handling of multiple instances of = OC-OLR in the DOIC draft. > =20 > So the questions are, > - Is 3GPP (or any other SDO) allowed to extend the definition = of OC-OLR by adding information into it? > - If no, can we guarantee that application level scope of = OC-OLR (which is what we have defined currently) is sufficient (and not = restricting) to all the applications of 3GPP? > =20 > Regards, > Nirav. > =20 > = __________________________________________________________________________= _______________________________________________ > =20 > 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. > =20 > 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. > = __________________________________________________________________________= _______________________________________________ > =20 > 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. > =20 > 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 From ben@nostrum.com Tue Dec 3 14:23:35 2013 Return-Path: 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 F1C7E1AE195 for ; Tue, 3 Dec 2013 14:23:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no 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 m_3hcTfG04Kv for ; Tue, 3 Dec 2013 14:23:34 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF791AE190 for ; Tue, 3 Dec 2013 14:23:34 -0800 (PST) Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rB3MNU5m040297 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Dec 2013 16:23:31 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ben Campbell In-Reply-To: <529DFA17.1090507@usdonovans.com> Date: Tue, 3 Dec 2013 16:23:30 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <529DFA17.1090507@usdonovans.com> To: Steve Donovan X-Mailer: Apple Mail (2.1822) Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism) Cc: "dime@ietf.org list" Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same type) within a response message X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 22:23:35 -0000 On Dec 3, 2013, at 9:34 AM, Steve Donovan = wrote: > Nirav, >=20 > If we allow AVPs to be added without a new report type then where will = the behavior associated with the presence of that AVP be documented? >=20 > Requiring the definition of a new registered report type insures that = implementers have a well defined place to go to find out how to deal = with the presence of that AVP. >=20 The big issue is that we don't have conflicting reports in an answer. It seems like requiring a new report type for a new "kind" of report is = simpler than allowing any random new AVP to discriminate among types. It = also gives better backwards compatibility, since a node that doesn't = understand some new AVP will not know that it indicates a different = scope. So I concur with Steve. From ben@nostrum.com Tue Dec 3 14:30:43 2013 Return-Path: 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 80B581AE1A6 for ; Tue, 3 Dec 2013 14:30:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no 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 6qum9G2Fxf1Z for ; Tue, 3 Dec 2013 14:30:42 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 847451ADDA0 for ; Tue, 3 Dec 2013 14:30:42 -0800 (PST) Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rB3MUbfp040632 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Dec 2013 16:30:38 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ben Campbell In-Reply-To: <26806_1386092152_529E1678_26806_2515_1_6B7134B31289DC4FAF731D844122B36E313B4B@PEXCVZYM13.corporate.adroot.infra.ftgroup> Date: Tue, 3 Dec 2013 16:30:37 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <3D2B4DEE-B8FF-4221-B719-5D8012277AB4@nostrum.com> References: <26806_1386092152_529E1678_26806_2515_1_6B7134B31289DC4FAF731D844122B36E313B4B@PEXCVZYM13.corporate.adroot.infra.ftgroup> To: "ext lionel.morand@orange.com" X-Mailer: Apple Mail (2.1822) Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism) Cc: "dime@ietf.org" Subject: Re: [Dime] OVLI: Clarification on the format of the OC-Report-Type AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 22:30:43 -0000 On Dec 3, 2013, at 11:35 AM, lionel.morand@orange.com wrote: > Hi, > =20 > The proposed format for OC-Report-Type AVP is Enumerated. > This would lead to extensibility issue as discussed several times. > =20 > I would propose to define the OC-Report-Type AVP as Unsigned64 and = create specific values. The same registry can be used to add values but = we would get rid of the problem with Enumerated AVP. > =20 > Comment? > =20 I'm missing something--what's the problem with extending Enumerated AVPs = in this context? I recognize that we don't want new applications to change the set of = values in Enumerated AVPs defined by another application. But that's not = what we're talking about here. Why couldn't we, for example, create an = Enumeration for DOIC that is intended to be extensible, and maybe even = has an IANA registry? (But for the record, I'm fine with Unsigned64). > Lionel > =20 > = __________________________________________________________________________= _______________________________________________ >=20 > 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. >=20 > 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. >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From ben@nostrum.com Tue Dec 3 14:37:00 2013 Return-Path: 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 9C7041ADFB1 for ; Tue, 3 Dec 2013 14:37:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no 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 WEw5LpdGnXt9 for ; Tue, 3 Dec 2013 14:37:00 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id D14D81ADFA6 for ; Tue, 3 Dec 2013 14:36:59 -0800 (PST) Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rB3MatST040870 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Dec 2013 16:36:56 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ben Campbell In-Reply-To: <529CA930.4030006@usdonovans.com> Date: Tue, 3 Dec 2013 16:36:55 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D90006681519BC90@DEMUMBX014.nsn-intra.net> <6390_1385631044_52970D44_6390_18593_1_6B7134B31289DC4FAF731D844122B36E30748E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BD31@DEMUMBX014.nsn-intra.net> <47383DC2-1A1B-4D1A-ADD5-9E3CE60B06C8@gmail.com> <8467_1385735507_5298A553_8467_17054_3_6B7134B31289DC4FAF731D844122B36E309D0D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <529CA930.4030006@usdonovans.com> To: Steve Donovan X-Mailer: Apple Mail (2.1822) Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism) Cc: "dime@ietf.org list" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 22:37:00 -0000 On Dec 2, 2013, at 9:37 AM, Steve Donovan = wrote: > I don't believe that Ben's proposal was to change the piggybacking = assumption in the baseline mechanism. Ben's proposal is to design the = solution in such a way that it is not dependent on the piggybacking = transport mechanism. =20 I also note that people seem to have defined "piggybacking" in ways that = seem odd to me. For the record, the roach draft had both "piggybacking" = and "self-contained OLRs".=20= From ben@nostrum.com Tue Dec 3 14:44:16 2013 Return-Path: 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 CA9941AE1A7 for ; Tue, 3 Dec 2013 14:44:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no 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 LM3K6GA86Cvv for ; Tue, 3 Dec 2013 14:44:14 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9E7E31AE1A1 for ; Tue, 3 Dec 2013 14:44:09 -0800 (PST) Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rB3Mi2U4041109 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Dec 2013 16:44:03 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ben Campbell In-Reply-To: <087A34937E64E74E848732CFF8354B920972B9BE@ESESSMB101.ericsson.se> Date: Tue, 3 Dec 2013 16:44:03 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D90006681519BC90@DEMUMBX014.nsn-intra.net> <6390_1385631044_52970D44_6390_18593_1_6B7134B31289DC4FAF731D844122B36E30748E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BD31@DEMUMBX014.nsn-intra.net> <47383DC2-1A1B-4D1A-ADD5-9E3CE60B06C8@gmail.com> <8467_1385735507_5298A553_8467_17054_3_6B7134B31289DC4FAF731D844122B36E309D0D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B920972B9BE@ESESSMB101.ericsson.se> To: Maria Cruz Bartolome X-Mailer: Apple Mail (2.1822) Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism) Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 22:44:16 -0000 On Dec 2, 2013, at 9:57 AM, Maria Cruz Bartolome = wrote: > Dear all, >=20 > About self-contained OLRs, I agree with Nirav, Lionel and JJ. > Duplication of information should be avoided, once we have considered = piggybacking as the overload info conveyance mechanism. It's not duplication. It's decoupling. In many cases, that sort of = decoupling can greatly simplify the solution. For example, let's say I save an OLR in a log. With self-contained OLRs, = I can just save the OLR. Otherwise, I have to save some or all of the = answer with it. This is true of _any_ interpretation and creation of the = OLR. Self-contained OLRs are less work to create, less work to insert in = the request, and less work to interpret. This is true even for a purely = piggybacked solution. But more importantly, self-contained OLRs allow for much more = extensibility and reuse. For example, if we find a need to create a = dedicated overload application, we can do so without creating a new = format. If we want to extend the solution later to allow sending OLRs in = requests, we can do so, again without a new format. The same is true if = we later decide to extend the solution to allow OLRs in watchdog = messages. I can also imagine very useful ways to exchange OLRs out-of-band. >=20 > Best regards > /MCruz >=20 >=20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, = JEAN-JACQUES (JEAN-JACQUES) > Sent: viernes, 29 de noviembre de 2013 16:05 > To: dime@ietf.org > Subject: Re: [Dime] DOIC: Self-Contained OLRs >=20 > Dear all >=20 > In the baseline mechanism as currently defined in the draft, the OLR = content is simple, and is related to the message conveying it in = particular application origin host/realm and destination to which the = OLR is sent back. As Lionel indicated, it is not so important to know = which node inserts the OLR or to have other information. >=20 > There is a performance aspect to consider: the OLRs defined in the = baseline may be frequently sent (in particular to compensate possible = message losses and to manage the loopback to the reporting node ensuring = the quick convergence towards the optimal throughput). So we have to = minimize the processing of these OLRs. As OLRs are piggybacked in the = relevant messages, they may be simply forwarded in the same message by = the DAs on the path except if there are particular reasons a DA to act = on them. =20 >=20 > I am cautious about duplication of information, it always means = additional checks to ensure consistency. If the OLR has an application = id and origin host different from the message conveying it, what to do = with this OLR, is it an error case? or should it be put in another = message in the path? Our current piggybacking mechanism allows the OLR = to remain in the same message from the reporting node to the reacting = node.=20 >=20 > An important point is extensibility, as we may have to introduce = other type of OLRs, additional AVPs, more sophisticated processing, but = these extensions should not impact the baseline mechanism by making the = baseline more complex. the current draft allows extensions without = impacting the baseline. >=20 > Currently I do not see drawbacks on the OLRs defined for the baseline = mechanism. So my comments join the Nirav and Lionel's ones. >=20 > Best regards=20 >=20 > JJacques=20 >=20 >=20 > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de = lionel.morand@orange.com Envoy=E9 : vendredi 29 novembre 2013 15:32 =C0 = : Nirav Salot (nsalot); Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); = dime@ietf.org list Cc : Ben Campbell Objet : Re: [Dime] DOIC: = Self-Contained OLRs >=20 > I totally agree with Nirav. No need to revert at this stage the = working assumption on piggybacking of OLR in application answer = messages, especially when the aim is to define a basic mechanism called = "reduction". >=20 > Anyone would be able to further add extra info for optimization if = needed but there is no need at all for the basic mechanism. >=20 > Regards, >=20 > Lionel >=20 > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot = (nsalot) Envoy=E9 : vendredi 29 novembre 2013 12:24 =C0 : Jouni = Korhonen; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list Cc : Ben = Campbell Objet : Re: [Dime] DOIC: Self-Contained OLRs >=20 > Jouni, Ben, >=20 > I am totally against the idea of self-contained OC-OLR specifically = since we have adopted the principles of piggybacking the OC-OLR over = existing application message. > Self-contained OC-OLR - which means adding all the information which = defines the scope of the OC-OLR into the OC-OLR - does not make sense in = the piggybacking approach. In fact, it is adding lot of information, = which is anyway available within the message containing the OC-OLR, into = the OC-OLR. So it is adding lot of redundant information in a message = which increases the processing requirement for the sender as well as the = receiver. (And this is un-optimization, in my view). >=20 > Besides, I am not convinced with the other reasons provided here: > - One software module within a node can provide OC-OLR to another = software module in the same node without passing other related info > Within a node, based on the design, lots of information may need to = be passed between two software modules and we cannot optimize those = aspects by replicating unnecessary information in a protocol message. > In summary, it is node's internal software design issue and we need = not optimize that at protocol level. >=20 > - Once the reporting node realizes that it is overloaded, it has to = wait for right answer to send OC-OLR > What is the point of sending OC-OLR for a context for which there is = no messaging? Why should the reacting node care if it never sends a = message for a context for which the reporting node is overloaded? > So this waiting is justified since it ensures that the overload is = reported only when necessary and only to the applicable reacting node. = Not to all the nodes in the network. >=20 > - The agent needs to wait for the answer generated by the server and = the right context > The same argument as applicable for the server applies here. The = agent need not send out-of-context overload info to a node. > Why should reacting node receive/process/store the overload info for = the scope for which it is not sending any messages. >=20 > - For sending OC-OLR in dedicated Diameter application??? > Piggybacking was the first basic principle we agreed before putting = other principles in place. So we may want to go back the drawing board = if we decide to change this principle. >=20 > Regards, > Nirav. >=20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen > Sent: Friday, November 29, 2013 2:50 PM > To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list > Cc: Ben Campbell > Subject: Re: [Dime] DOIC: Self-Contained OLRs >=20 >=20 >=20 > So, are we reaching any level of consensus here? >=20 > - JOuni >=20 > (as a note.. that we are converging back to where we started with OLRs = ;) >=20 >=20 >=20 > On Nov 28, 2013, at 12:40 PM, "Wiehe, Ulrich (NSN - DE/Munich)" = wrote: >=20 >> Hi, >>=20 >> another question: >>=20 >> If we go for explicit self contained OLRs, why would we then need the = ReportType? >>=20 >> The realm-type OLR would explicitly contain application-Id, Realm, = but no Host whereas the host-type OLR would explicitly contain = application-Id, Host, but probably (I'm not sure) no Realm. >>=20 >> Ulrich >>=20 >>=20 >>=20 >> -----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 >>=20 >> Hi, >>=20 >> 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. >>=20 >> Lionel >>=20 >> -----Message d'origine----- >> De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich=20= >> (NSN - DE/Munich) Envoy=E9 : jeudi 28 novembre 2013 10:26 =C0 : ext = Jouni=20 >> Korhonen; Ben Campbell Cc : dime@ietf.org list Objet : Re: [Dime] >> DOIC: Self-Contained OLRs >>=20 >> Hi, >>=20 >> 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? >>=20 >> Ulrich >>=20 >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Jouni=20 >> Korhonen >> Sent: Wednesday, November 27, 2013 11:44 PM >> To: Ben Campbell >> Cc: dime@ietf.org list >> Subject: Re: [Dime] DOIC: Self-Contained OLRs >>=20 >>=20 >> On Nov 28, 2013, at 12:27 AM, Ben Campbell wrote: >>=20 >>> Hi, >>>=20 >>> I mentioned in another thread that I prefer putting an explicit=20 >>> ReportType AVP in an OLR, rather than >>=20 >> The more I spent time thinking/writing the actual procedures on the=20= >> endpoints, the more it makes sense to me to keep the ReportType in = the=20 >> OC-OLR. Even if the baseline does not have agent overload etc, the=20 >> 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. >>=20 >> I skip the rest of the mail.. too much text ;-) >>=20 >>=20 >> - Jouni >>=20 >>=20 >>=20 >>=20 >>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> I think this approach is a mistake. I would greatly prefer that we = explicitly include such values in the OLR itself, for multiple reasons: >>>=20 >>> 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. >>>=20 >>> 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.=20= >>>=20 >>> 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. >>>=20 >>> 3) Implicit values don't work at all for certain problems. For=20 >>> example, if an agent needs to originate an OLR, it typically needs = to=20 >>> insert that OLR into an existing Diameter answer created by a = server. >>> It can't create its own answer without affecting the application=20 >>> state. If the responding node assumes the OLR comes from or refers = to=20 >>> the node identified by the Origin-Host AVP in the enclosing answer,=20= >>> things break. (For examples of when an agent needs to send OLRs that=20= >>> are distinct from those sent by a server, see Steve's agent overload=20= >>> draft, or my dh/dr example.) >>>=20 >>> OTOH, explicit values will work for all cases where we need to = associate some arbitrary value with an OLR. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> Thanks! >>>=20 >>> Ben. >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>=20 >> _______________________________________________ >> 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 >>=20 >> = ______________________________________________________________________ >> ___________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations=20 >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20= >> exploites ou copies sans autorisation. Si vous avez recu ce message=20= >> 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. >>=20 >> This message and its attachments may contain confidential or=20 >> 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. >>=20 >=20 > _______________________________________________ > 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 >=20 > = __________________________________________________________________________= _______________________________________________ >=20 > 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. >=20 > 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. >=20 > _______________________________________________ > 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 From lionel.morand@orange.com Tue Dec 3 14:50:39 2013 Return-Path: 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 88FAC1AE192 for ; Tue, 3 Dec 2013 14:50:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.899 X-Spam-Level: X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no 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 EyBX6HN68osn for ; Tue, 3 Dec 2013 14:50:38 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id D8D141AE198 for ; Tue, 3 Dec 2013 14:50:37 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id E9F2E32455F; Tue, 3 Dec 2013 23:50:33 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id D00C335C045; Tue, 3 Dec 2013 23:50:33 +0100 (CET) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0158.001; Tue, 3 Dec 2013 23:50:33 +0100 From: To: Jouni Thread-Topic: [Dime] OVLI: Clarification on the format of the OC-Report-Type AVP Thread-Index: Ac7wThugO0QKyqubRY2CKRSpVtZHGf//+iqA//+kHRA= Date: Tue, 3 Dec 2013 22:50:32 +0000 Message-ID: <960_1386111033_529E6039_960_7297_1_6B7134B31289DC4FAF731D844122B36E3196C3@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <26806_1386092152_529E1678_26806_2515_1_6B7134B31289DC4FAF731D844122B36E313B4B@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.12.3.160315 Cc: "dime@ietf.org" Subject: Re: [Dime] OVLI: Clarification on the format of the OC-Report-Type AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 22:50:39 -0000 Hi Jouni, The setting of the M-bit will be decided per application and not by this do= cument. Obviously, when reused in existing applications, it will be purely optional= . But designers may decide to include this AVP as mandatory AVP to understa= nd in a new application and then the issues regarding Enumerated AVP will c= ome back, no? Lionel -----Message d'origine----- De=A0: Jouni [mailto:jouni.nospam@gmail.com]=20 Envoy=E9=A0: mardi 3 d=E9cembre 2013 19:15 =C0=A0: MORAND Lionel IMT/OLN Cc=A0: dime@ietf.org Objet=A0: Re: [Dime] OVLI: Clarification on the format of the OC-Report-Typ= e AVP On Dec 3, 2013, at 7:35 PM, wrote: > Hi, >=20=20 > The proposed format for OC-Report-Type AVP is Enumerated. > This would lead to extensibility issue as discussed several times. I know what you refer to but I think it is a non-issue since the AVP is optional and we can define the default behavior when the content is not understood. - Jouni >=20=20 > I would propose to define the OC-Report-Type AVP as Unsigned64 and create= specific values. The same registry can be used to add values but we would = get rid of the problem with Enumerated AVP. >=20=20 > Comment? >=20=20 > Lionel >=20=20 > _________________________________________________________________________= ________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu 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 o= u falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged i= nformation 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 de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. From ben@nostrum.com Tue Dec 3 14:51:12 2013 Return-Path: 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 3DD2B1AE192 for ; Tue, 3 Dec 2013 14:51:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no 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 77mDd6lhw5iH for ; Tue, 3 Dec 2013 14:51:08 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 634D01AE164 for ; Tue, 3 Dec 2013 14:51:08 -0800 (PST) Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rB3Mp3ew041472 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Dec 2013 16:51:04 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ben Campbell In-Reply-To: <529DFD0A.9050308@usdonovans.com> Date: Tue, 3 Dec 2013 16:51:04 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> , <5BCBA1FC2B7F0B4C9D935572D90006681519C087@DEMUMBX014.nsn-intra.net> <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> To: Steve Donovan X-Mailer: Apple Mail (2.1822) Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism) Cc: "dime@ietf.org list" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 22:51:12 -0000 I agree with Steve. Further, contrary to Ulrich's earlier assertion, I = think a prohibition against multiple OLRs in a single answer adds a = _lot_ more complexity than it would save. On Dec 3, 2013, at 9:47 AM, Steve Donovan = wrote: > 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. >=20 > It also makes it more difficult to achieve the more granular = differentiated overload report types that Nirav is suggesting. >=20 > Steve >=20 > On 12/3/13 7:52 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >> Hi Lionel, >>=20 >> 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. >>=20 >> Best regards >> Ulrich >>=20 >> -----Original Message----- >> From: ext=20 >> lionel.morand@orange.com [mailto:lionel.morand@orange.com >> ]=20 >> Sent: Tuesday, December 03, 2013 11:51 AM >> To: Wiehe, Ulrich (NSN - DE/Munich); ext Maria Cruz Bartolome;=20 >> dime@ietf.org >> list >> Subject: RE: [Dime] DOIC: Self-Contained OLRs >>=20 >> Hi Ulrich, >>=20 >> I don't see the complexity if each OLR instance received is clearly = distinguished by the Report-Type.=20 >> Again, it is not said that it will be mandated for any deployment to = rely on multiple OLR instances.=20 >>=20 >> Regards, >>=20 >> Lionel >>=20 >> -----Message d'origine----- >> De : Wiehe, Ulrich (NSN - DE/Munich) [ >> mailto:ulrich.wiehe@nsn.com >> ]=20 >> Envoy=E9 : mardi 3 d=E9cembre 2013 11:46 >> =C0 : MORAND Lionel IMT/OLN; ext Maria Cruz Bartolome;=20 >> dime@ietf.org >> list >> Objet : RE: [Dime] DOIC: Self-Contained OLRs >>=20 >> Hi Lionel, >>=20 >> my point is simple: >>=20 >> 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. >>=20 >> Ulrich=20 >>=20 >> -----Original Message----- >> From: ext=20 >> lionel.morand@orange.com [mailto:lionel.morand@orange.com >> ]=20 >> Sent: Tuesday, December 03, 2013 11:05 AM >> To: Wiehe, Ulrich (NSN - DE/Munich); ext Maria Cruz Bartolome;=20 >> dime@ietf.org >> list >> Subject: RE: [Dime] DOIC: Self-Contained OLRs >>=20 >> Hi Ulrich, >>=20 >> 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. >>=20 >> Regards, >>=20 >> Lionel=20 >>=20 >> -----Message d'origine----- >> De : DiME [ >> mailto:dime-bounces@ietf.org >> ] De la part de Wiehe, Ulrich (NSN - DE/Munich) >> Envoy=E9 : mardi 3 d=E9cembre 2013 10:21 >> =C0 : ext Maria Cruz Bartolome;=20 >> dime@ietf.org >> list >> Objet : Re: [Dime] DOIC: Self-Contained OLRs >>=20 >> Dear MCruz, >> thank you for your support. >>=20 >> 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.=20 >>=20 >> 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. >>=20 >> In any case there is no need for more than one OLR in an answer. >>=20 >> Ulrich >>=20 >>=20 >>=20 >>=20 >> -----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:=20 >> dime@ietf.org >> list >> Subject: Re: [Dime] DOIC: Self-Contained OLRs >>=20 >> Dear all, >>=20 >> My interpretation is as well in line to what is summarized by Lionel = below. >>=20 >> 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. >>=20 >> Best regards >> /MCruz >>=20 >> -----Original Message----- >> From: DiME [ >> mailto:dime-bounces@ietf.org >> ] On Behalf Of Jouni Korhonen >> Sent: lunes, 02 de diciembre de 2013 15:38 >> To:=20 >> lionel.morand@orange.com >>=20 >> Cc: Ben Campbell;=20 >> dime@ietf.org >> list >> Subject: Re: [Dime] DOIC: Self-Contained OLRs >>=20 >>=20 >> My understanding (and current editing) has already been towards what = Lionel said below. >>=20 >> - Jouni >>=20 >>=20 >> On Dec 2, 2013, at 4:19 PM,=20 >> lionel.morand@orange.com >> wrote: >>=20 >>=20 >>> I agree with last part. It was the reason I've reconsidered my = position on the need for the Report-Type. >>> =20 >>> 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. >>> =20 >>> 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. >>> =20 >>> Regards, >>> =20 >>> Lionel >>> =20 >>> =20 >>> De : Nirav Salot (nsalot) [ >>> mailto:nsalot@cisco.com >>> ] Envoy=E9 : lundi 2=20 >>> d=E9cembre 2013 14:58 =C0 : Wiehe, Ulrich (NSN - DE/Munich) Cc :=20 >>>=20 >>> dime@ietf.org >>> list; ext Jouni Korhonen; MORAND Lionel IMT/OLN; Ben=20 >>> Campbell Objet : RE: [Dime] DOIC: Self-Contained OLRs >>> =20 >>> Ulrich, >>>=20 >>> 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? >>>=20 >>> I would prefer to derive the context of the OLR based on the message = which contains the OLR. >>>=20 >>> 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. >>>=20 >>> Regards, >>> Nirav. >>>=20 >>> On Dec 2, 2013 5:27 PM, "Wiehe, Ulrich (NSN - DE/Munich)"=20 >>> >>> wrote: >>> Nirav, >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> Ulrich >>>=20 >>>=20 >>>=20 >>> -----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=20 >>> lionel.morand@orange.com >>> ; ext=20 >>> Jouni Korhonen; Ben Campbell >>> Cc:=20 >>> dime@ietf.org >>> list >>> Subject: RE: [Dime] DOIC: Self-Contained OLRs >>>=20 >>> Ulrich, >>>=20 >>> I have a basic question. >>>=20 >>> 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? >>>=20 >>> Regards, >>> Nirav. >>>=20 >>> -----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=20 >>> lionel.morand@orange.com >>> ; ext Jouni=20 >>> Korhonen; Ben Campbell >>> Cc:=20 >>> dime@ietf.org >>> list >>> Subject: RE: [Dime] DOIC: Self-Contained OLRs >>>=20 >>> Hi Nirav, >>>=20 >>> please see inline. >>>=20 >>> Regards >>> Ulrich >>>=20 >>> -----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=20 >>> lionel.morand@orange.com >>> ; ext=20 >>> Jouni Korhonen; Ben Campbell >>> Cc:=20 >>> dime@ietf.org >>> list >>> Subject: RE: [Dime] DOIC: Self-Contained OLRs >>>=20 >>> Ulrich, >>>=20 >>> 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.=20 >>> [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 =3Dx1, destination realm =3Dx2 application=3D 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... >>>=20 >>> 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.=20 >>> [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. >>>=20 >>> If we strictly want to ensure that the realm-type OLR is not sent=20 >>> out-of-context [Wiehe, Ulrich (NSN - DE/Munich)] That was not my=20 >>> proposal. My proposal was to clearly mark out-of-context OLRs in=20 >>> answer messages (if we allow including out-of-context OLRs) >>>=20 >>> , 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). >>>=20 >>> 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=20= >>> (NSN - DE/Munich)] only the out-of-context one >>>=20 >>> , 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). >>>=20 >>> 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). >>>=20 >>>=20 >>> 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? >>>=20 >>> 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. >>>=20 >>> Regards, >>> Nirav. >>>=20 >>> -----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=20 >>> lionel.morand@orange.com >>> ; ext Jouni=20 >>> Korhonen; Ben Campbell >>> Cc:=20 >>> dime@ietf.org >>> list >>> Subject: RE: [Dime] DOIC: Self-Contained OLRs >>>=20 >>> Hi Nirav, >>>=20 >>> 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. >>>=20 >>> Best regards >>> Ulrich >>>=20 >>>=20 >>> -----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=20 >>> lionel.morand@orange.com >>> ; ext=20 >>> Jouni Korhonen; Ben Campbell >>> Cc:=20 >>> dime@ietf.org >>> list >>> Subject: RE: [Dime] DOIC: Self-Contained OLRs >>>=20 >>> Hi Ulrich, >>>=20 >>> If an additional OLR is present with a different ReportType, why it = should be ignored by the reacting node? >>>=20 >>> Regards, >>> Nirav. >>>=20 >>> -----Original Message----- >>> From: DiME [ >>> mailto:dime-bounces@ietf.org >>> ] On Behalf Of Wiehe, Ulrich=20 >>> (NSN - DE/Munich) >>> Sent: Friday, November 29, 2013 5:36 PM >>> To: ext=20 >>> lionel.morand@orange.com >>> ; ext Jouni Korhonen; Ben Campbell >>> Cc:=20 >>> dime@ietf.org >>> list >>> Subject: Re: [Dime] DOIC: Self-Contained OLRs >>>=20 >>> Hi Lionel, >>>=20 >>> 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. >>>=20 >>> Ulrich >>> =20 >>>=20 >>> -----Original Message----- >>> From: ext=20 >>> 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:=20 >>> dime@ietf.org >>> list >>> Subject: RE: [Dime] DOIC: Self-Contained OLRs >>>=20 >>> Hi Ulrich, >>>=20 >>> 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.=20 >>>=20 >>> 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. >>>=20 >>> I'm not sure of what is missing in this reasoning... >>>=20 >>> Lionel >>>=20 >>> -----Message d'origine----- >>> De : Wiehe, Ulrich (NSN - DE/Munich) [ >>> mailto:ulrich.wiehe@nsn.com >>> ]=20 >>> Envoy=E9 : jeudi 28 novembre 2013 11:30 =C0 : MORAND Lionel IMT/OLN; = ext=20 >>> Jouni Korhonen; Ben Campbell Cc :=20 >>> dime@ietf.org >>> list Objet : RE:=20 >>> [Dime] DOIC: Self-Contained OLRs >>>=20 >>> Lionel, >>>=20 >>> my understanding was that _the_ reporting end point provides _the_ = OLR. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> Ulrich >>>=20 >>>=20 >>>=20 >>> -----Original Message----- >>> From: ext=20 >>> 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:=20 >>> dime@ietf.org >>> list >>> Subject: RE: [Dime] DOIC: Self-Contained OLRs >>>=20 >>> Hi, >>>=20 >>> 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. >>>=20 >>> Lionel >>>=20 >>> -----Message d'origine----- >>> De : DiME [ >>> mailto:dime-bounces@ietf.org >>> ] De la part de Wiehe, Ulrich=20 >>> (NSN - DE/Munich) Envoy=E9 : jeudi 28 novembre 2013 10:26 =C0 : ext = Jouni=20 >>> Korhonen; Ben Campbell Cc :=20 >>> dime@ietf.org >>> list Objet : Re: [Dime]=20 >>> DOIC: Self-Contained OLRs >>>=20 >>> Hi, >>>=20 >>> 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? >>>=20 >>> Ulrich >>>=20 >>> -----Original Message----- >>> From: DiME [ >>> mailto:dime-bounces@ietf.org >>> ] On Behalf Of ext Jouni=20 >>> Korhonen >>> Sent: Wednesday, November 27, 2013 11:44 PM >>> To: Ben Campbell >>> Cc:=20 >>> dime@ietf.org >>> list >>> Subject: Re: [Dime] DOIC: Self-Contained OLRs >>>=20 >>>=20 >>> On Nov 28, 2013, at 12:27 AM, Ben Campbell=20 >>> >>> wrote: >>>=20 >>>=20 >>>> Hi, >>>>=20 >>>> I mentioned in another thread that I prefer putting an explicit=20 >>>> ReportType AVP in an OLR, rather than >>>>=20 >>> 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. >>>=20 >>> I skip the rest of the mail.. too much text ;-) >>>=20 >>>=20 >>> - Jouni >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>> 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. >>>>=20 >>>> 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. >>>>=20 >>>> I think this approach is a mistake. I would greatly prefer that we = explicitly include such values in the OLR itself, for multiple reasons: >>>>=20 >>>> 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. >>>>=20 >>>> 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.=20= >>>>=20 >>>> 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. >>>>=20 >>>> 3) Implicit values don't work at all for certain problems. For=20 >>>> example, if an agent needs to originate an OLR, it typically needs=20= >>>> to insert that OLR into an existing Diameter answer created by a = server. >>>> It can't create its own answer without affecting the application=20 >>>> state. If the responding node assumes the OLR comes from or refers=20= >>>> to the node identified by the Origin-Host AVP in the enclosing=20 >>>> answer, things break. (For examples of when an agent needs to send=20= >>>> OLRs that are distinct from those sent by a server, see Steve's=20 >>>> agent overload draft, or my dh/dr example.) >>>>=20 >>>> OTOH, explicit values will work for all cases where we need to = associate some arbitrary value with an OLR. >>>>=20 >>>> 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. >>>>=20 >>>> 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. >>>>=20 >>>> Thanks! >>>>=20 >>>> Ben. >>>> _______________________________________________ >>>> DiME mailing list >>>>=20 >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >>> _______________________________________________ >>> DiME mailing list >>>=20 >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>>=20 >>> _______________________________________________ >>> DiME mailing list >>>=20 >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>>=20 >>>=20 >>> = ______________________________________________________________________ >>> ___________________________________________________ >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>>=20 >>> = ______________________________________________________________________ >>> ___________________________________________________ >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> _______________________________________________ >>> DiME mailing list >>>=20 >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>>=20 >>> = ______________________________________________________________________ >>> ___________________________________________________ >>>=20 >>> Ce message et ses pieces jointes peuvent contenir des informations=20= >>> confidentielles ou privilegiees et ne doivent donc pas etre = diffuses,=20 >>> exploites ou copies sans autorisation. Si vous avez recu ce message=20= >>> 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. >>>=20 >>> This message and its attachments may contain confidential or=20 >>> 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. >>>=20 >>>=20 >> _______________________________________________ >> DiME mailing list >>=20 >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >>=20 >> _______________________________________________ >> DiME mailing list >>=20 >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >>=20 >> _______________________________________________ >> DiME mailing list >>=20 >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >>=20 >>=20 >> = __________________________________________________________________________= _______________________________________________ >>=20 >> 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. >>=20 >> 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. >>=20 >>=20 >> = __________________________________________________________________________= _______________________________________________ >>=20 >> 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. >>=20 >> 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. >>=20 >> _______________________________________________ >> DiME mailing list >>=20 >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >>=20 >>=20 >>=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From ben@nostrum.com Tue Dec 3 14:52:42 2013 Return-Path: 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 5D2BE1AE19F for ; Tue, 3 Dec 2013 14:52:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no 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 LHxTI5rMUmEY for ; Tue, 3 Dec 2013 14:52:39 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id D1C591ADED9 for ; Tue, 3 Dec 2013 14:52:38 -0800 (PST) Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rB3MqX9U041511 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Dec 2013 16:52:35 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ben Campbell In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681519D493@DEMUMBX014.nsn-intra.net> Date: Tue, 3 Dec 2013 16:52:34 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> , <5BCBA1FC2B7F0B4C9D935572D90006681519C087@DEMUMBX014.nsn-intra.net> <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> To: "Wiehe, Ulrich (NSN - DE/Munich)" X-Mailer: Apple Mail (2.1822) Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism) Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 22:52:42 -0000 On Dec 3, 2013, at 9:56 AM, Wiehe, Ulrich (NSN - DE/Munich) = wrote: > Steve, > =20 > I didn=92t 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. > =20 Can we restate the "not forced to process" to say "not be forced to = choose between ambiguous" OLRs? > Ulrich > =20 > 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 > =20 > 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. >=20 > It also makes it more difficult to achieve the more granular = differentiated overload report types that Nirav is suggesting. >=20 > Steve >=20 > On 12/3/13 7:52 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: > Hi Lionel, > =20 > 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. > =20 > Best regards > Ulrich > =20 > -----Original Message----- > From: ext lionel.morand@orange.com [mailto:lionel.morand@orange.com]=20= > 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 > =20 > Hi Ulrich, > =20 > I don't see the complexity if each OLR instance received is clearly = distinguished by the Report-Type.=20 > Again, it is not said that it will be mandated for any deployment to = rely on multiple OLR instances.=20 > =20 > Regards, > =20 > Lionel > =20 > -----Message d'origine----- > De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 > Envoy=E9 : mardi 3 d=E9cembre 2013 11:46 > =C0 : MORAND Lionel IMT/OLN; ext Maria Cruz Bartolome; dime@ietf.org = list > Objet : RE: [Dime] DOIC: Self-Contained OLRs > =20 > Hi Lionel, > =20 > my point is simple: > =20 > 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. > =20 > Ulrich=20 > =20 > -----Original Message----- > From: ext lionel.morand@orange.com [mailto:lionel.morand@orange.com]=20= > 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 > =20 > Hi Ulrich, > =20 > 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. > =20 > Regards, > =20 > Lionel=20 > =20 > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich = (NSN - DE/Munich) > Envoy=E9 : mardi 3 d=E9cembre 2013 10:21 > =C0 : ext Maria Cruz Bartolome; dime@ietf.org list > Objet : Re: [Dime] DOIC: Self-Contained OLRs > =20 > Dear MCruz, > thank you for your support. > =20 > 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.=20 > =20 > 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. > =20 > In any case there is no need for more than one OLR in an answer. > =20 > Ulrich > =20 > =20 > =20 > =20 > -----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 > =20 > Dear all, > =20 > My interpretation is as well in line to what is summarized by Lionel = below. > =20 > 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. > =20 > Best regards > /MCruz > =20 > -----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 > =20 > =20 > My understanding (and current editing) has already been towards what = Lionel said below. > =20 > - Jouni > =20 > =20 > On Dec 2, 2013, at 4:19 PM, lionel.morand@orange.com wrote: > =20 > I agree with last part. It was the reason I've reconsidered my = position on the need for the Report-Type. > =20 > 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. > =20 > 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. > =20 > Regards, > =20 > Lionel > =20 > =20 > De : Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Envoy=E9 : lundi 2=20= > d=E9cembre 2013 14:58 =C0 : Wiehe, Ulrich (NSN - DE/Munich) Cc :=20 > dime@ietf.org list; ext Jouni Korhonen; MORAND Lionel IMT/OLN; Ben=20 > Campbell Objet : RE: [Dime] DOIC: Self-Contained OLRs > =20 > Ulrich, > =20 > 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? > =20 > I would prefer to derive the context of the OLR based on the message = which contains the OLR. > =20 > 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. > =20 > Regards, > Nirav. > =20 > On Dec 2, 2013 5:27 PM, "Wiehe, Ulrich (NSN - DE/Munich)" = wrote: > Nirav, > =20 > 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. > =20 > 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. > =20 > Ulrich > =20 > =20 > =20 > -----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=20= > Jouni Korhonen; Ben Campbell > Cc: dime@ietf.org list > Subject: RE: [Dime] DOIC: Self-Contained OLRs > =20 > Ulrich, > =20 > I have a basic question. > =20 > 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? > =20 > Regards, > Nirav. > =20 > -----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=20 > Korhonen; Ben Campbell > Cc: dime@ietf.org list > Subject: RE: [Dime] DOIC: Self-Contained OLRs > =20 > Hi Nirav, > =20 > please see inline. > =20 > Regards > Ulrich > =20 > -----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=20= > Jouni Korhonen; Ben Campbell > Cc: dime@ietf.org list > Subject: RE: [Dime] DOIC: Self-Contained OLRs > =20 > Ulrich, > =20 > 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.=20 > [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 =3Dx1, destination realm =3Dx2 application=3D 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... > =20 > 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.=20 > [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. > =20 > If we strictly want to ensure that the realm-type OLR is not sent=20 > out-of-context [Wiehe, Ulrich (NSN - DE/Munich)] That was not my=20 > proposal. My proposal was to clearly mark out-of-context OLRs in=20 > answer messages (if we allow including out-of-context OLRs) > =20 > , 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). > =20 > 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=20 > (NSN - DE/Munich)] only the out-of-context one > =20 > , 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). > =20 > 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). > =20 > =20 > 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? > =20 > 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. > =20 > Regards, > Nirav. > =20 > -----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=20 > Korhonen; Ben Campbell > Cc: dime@ietf.org list > Subject: RE: [Dime] DOIC: Self-Contained OLRs > =20 > Hi Nirav, > =20 > 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. > =20 > Best regards > Ulrich > =20 > =20 > -----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=20= > Jouni Korhonen; Ben Campbell > Cc: dime@ietf.org list > Subject: RE: [Dime] DOIC: Self-Contained OLRs > =20 > Hi Ulrich, > =20 > If an additional OLR is present with a different ReportType, why it = should be ignored by the reacting node? > =20 > Regards, > Nirav. > =20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich=20= > (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 > =20 > Hi Lionel, > =20 > 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. > =20 > Ulrich > =20 > =20 > -----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 > =20 > Hi Ulrich, > =20 > 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.=20= > =20 > 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. > =20 > I'm not sure of what is missing in this reasoning... > =20 > Lionel > =20 > -----Message d'origine----- > De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 > Envoy=E9 : jeudi 28 novembre 2013 11:30 =C0 : MORAND Lionel IMT/OLN; = ext=20 > Jouni Korhonen; Ben Campbell Cc : dime@ietf.org list Objet : RE:=20 > [Dime] DOIC: Self-Contained OLRs > =20 > Lionel, > =20 > my understanding was that _the_ reporting end point provides _the_ = OLR. > =20 > 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. > =20 > 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. > =20 > Ulrich > =20 > =20 > =20 > -----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 > =20 > Hi, > =20 > 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. > =20 > Lionel > =20 > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich=20= > (NSN - DE/Munich) Envoy=E9 : jeudi 28 novembre 2013 10:26 =C0 : ext = Jouni=20 > Korhonen; Ben Campbell Cc : dime@ietf.org list Objet : Re: [Dime]=20 > DOIC: Self-Contained OLRs > =20 > Hi, > =20 > 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? > =20 > Ulrich > =20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Jouni=20 > Korhonen > Sent: Wednesday, November 27, 2013 11:44 PM > To: Ben Campbell > Cc: dime@ietf.org list > Subject: Re: [Dime] DOIC: Self-Contained OLRs > =20 > =20 > On Nov 28, 2013, at 12:27 AM, Ben Campbell wrote: > =20 > Hi, > =20 > I mentioned in another thread that I prefer putting an explicit=20 > ReportType AVP in an OLR, rather than > =20 > 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. > =20 > I skip the rest of the mail.. too much text ;-) > =20 > =20 > - Jouni > =20 > =20 > =20 > =20 > =20 > 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. > =20 > 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. > =20 > I think this approach is a mistake. I would greatly prefer that we = explicitly include such values in the OLR itself, for multiple reasons: > =20 > 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. > =20 > 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.=20= > =20 > 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. > =20 > 3) Implicit values don't work at all for certain problems. For=20 > example, if an agent needs to originate an OLR, it typically needs=20 > to insert that OLR into an existing Diameter answer created by a = server. > It can't create its own answer without affecting the application=20 > state. If the responding node assumes the OLR comes from or refers=20 > to the node identified by the Origin-Host AVP in the enclosing=20 > answer, things break. (For examples of when an agent needs to send=20 > OLRs that are distinct from those sent by a server, see Steve's=20 > agent overload draft, or my dh/dr example.) > =20 > OTOH, explicit values will work for all cases where we need to = associate some arbitrary value with an OLR. > =20 > 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. > =20 > 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. > =20 > Thanks! > =20 > Ben. > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > =20 > _______________________________________________ > 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 > =20 > ______________________________________________________________________ > ___________________________________________________ > =20 > 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. > =20 > 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. > =20 > =20 > ______________________________________________________________________ > ___________________________________________________ > =20 > 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. > =20 > 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. > =20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > ______________________________________________________________________ > ___________________________________________________ > =20 > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20= > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > 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. > =20 > This message and its attachments may contain confidential or=20 > 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. > =20 > =20 > _______________________________________________ > 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 > =20 > = __________________________________________________________________________= _______________________________________________ > =20 > 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. > =20 > 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. > =20 > =20 > = __________________________________________________________________________= _______________________________________________ > =20 > 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. > =20 > 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. > =20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > =20 > =20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From ben@nostrum.com Tue Dec 3 14:56:11 2013 Return-Path: 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 5836E1ADF22 for ; Tue, 3 Dec 2013 14:56:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no 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 RS0Nm20OmCNd for ; Tue, 3 Dec 2013 14:56:09 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id C21551ADED9 for ; Tue, 3 Dec 2013 14:56:08 -0800 (PST) Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rB3Mu4AZ041703 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Dec 2013 16:56:05 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ben Campbell In-Reply-To: <13482_1386001111_529CB2D7_13482_11387_1_6B7134B31289DC4FAF731D844122B36E311068@PEXCVZYM13.corporate.adroot.infra.ftgroup> Date: Tue, 3 Dec 2013 16:56:04 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <2AB88923-E019-4EAF-9512-E677D5798DB3@nostrum.com> References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D90006681519BC90@DEMUMBX014.nsn-intra.net> <6390_1385631044_52970D44_6390_18593_1_6B7134B31289DC4FAF731D844122B36E30748E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BD31@DEMUMBX014.nsn-intra.net> <47383DC2-1A1B-4D1A-ADD5-9E3CE60B06C8@gmail.com> <8467_1385735507_5298A553_8467_17054_3_6B7134B31289DC4FAF731D844122B36E309D0D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <529CA930.4030006@usdonovans.com> <13482_1386001111_529CB2D7_13482_11387_1_6B7134B31289DC4FAF731D844122B36E311068@PEXCVZYM13.corporate.adroot.infra.ftgroup> To: "ext lionel.morand@orange.com" X-Mailer: Apple Mail (2.1822) Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism) Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 22:56:11 -0000 On Dec 2, 2013, at 10:18 AM, lionel.morand@orange.com wrote: > Hi Steve, > =20 > I think that is not only about few bytes in the answer. It is also = about the solution principles agreed so far: > =B7 the current need is for an OLR bound to the application in = use > =B7 the OLR is received from the node targeted in the request. > =B7 the OLR is defined per application I don't think those principles have been well tested. I don't recall any = discussion of their benefits. What benefits do you see they have over = self-contained OLRs? All I see from these are restrictions in the flexibility of the = solution, with very little in return. > So all the implicit information (application, origin-host, = origin-realm) are meaningful in this context. > And the actual solution is designed based on these assumptions. The = extensibility of the solution will allow extra info if required in other = use cases but it was agreed to go with a straightforward solution that = will satisfy most of us. > =20 > Regards, > =20 > Lionel > =20 > De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan > Envoy=E9 : lundi 2 d=E9cembre 2013 16:37 > =C0 : dime@ietf.org > Objet : Re: [Dime] DOIC: Self-Contained OLRs > =20 > I don't believe that Ben's proposal was to change the piggybacking = assumption in the baseline mechanism. Ben's proposal is to design the = solution in such a way that it is not dependent on the piggybacking = transport mechanism. =20 >=20 > I share Ben's concern that we have over optimized the content of the = overload report in a way that makes implementations brittle, = interoperability more difficult to achieve and extensibility more = complex. And what do we gain from this optimization? A few bites in = answer messages. >=20 > Self contained overload reports, transported using the piggybacking = mechanism, is a cleaner solution. >=20 > Steve >=20 > On 11/29/13 8:31 AM, lionel.morand@orange.com wrote: > I totally agree with Nirav. No need to revert at this stage the = working assumption on piggybacking of OLR in application answer = messages, especially when the aim is to define a basic mechanism called = "reduction". > =20 > Anyone would be able to further add extra info for optimization if = needed but there is no need at all for the basic mechanism. > =20 > Regards, > =20 > Lionel > =20 > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot = (nsalot) > Envoy=E9 : vendredi 29 novembre 2013 12:24 > =C0 : Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org = list > Cc : Ben Campbell > Objet : Re: [Dime] DOIC: Self-Contained OLRs > =20 > Jouni, Ben, > =20 > I am totally against the idea of self-contained OC-OLR specifically = since we have adopted the principles of piggybacking the OC-OLR over = existing application message. > Self-contained OC-OLR - which means adding all the information which = defines the scope of the OC-OLR into the OC-OLR - does not make sense in = the piggybacking approach. In fact, it is adding lot of information, = which is anyway available within the message containing the OC-OLR, into = the OC-OLR. So it is adding lot of redundant information in a message = which increases the processing requirement for the sender as well as the = receiver. (And this is un-optimization, in my view). > =20 > Besides, I am not convinced with the other reasons provided here: > - One software module within a node can provide OC-OLR to another = software module in the same node without passing other related info > Within a node, based on the design, lots of information may need to = be passed between two software modules and we cannot optimize those = aspects by replicating unnecessary information in a protocol message. > In summary, it is node's internal software design issue and we need = not optimize that at protocol level. > =20 > - Once the reporting node realizes that it is overloaded, it has to = wait for right answer to send OC-OLR > What is the point of sending OC-OLR for a context for which there is = no messaging? Why should the reacting node care if it never sends a = message for a context for which the reporting node is overloaded? > So this waiting is justified since it ensures that the overload is = reported only when necessary and only to the applicable reacting node. = Not to all the nodes in the network. > =20 > - The agent needs to wait for the answer generated by the server and = the right context > The same argument as applicable for the server applies here. The = agent need not send out-of-context overload info to a node. > Why should reacting node receive/process/store the overload info = for the scope for which it is not sending any messages. > =20 > - For sending OC-OLR in dedicated Diameter application??? > Piggybacking was the first basic principle we agreed before putting = other principles in place. So we may want to go back the drawing board = if we decide to change this principle. > =20 > Regards, > Nirav. > =20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen > Sent: Friday, November 29, 2013 2:50 PM > To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list > Cc: Ben Campbell > Subject: Re: [Dime] DOIC: Self-Contained OLRs > =20 > =20 > =20 > So, are we reaching any level of consensus here? > =20 > - JOuni > =20 > (as a note.. that we are converging back to where we started with OLRs = ;) > =20 > =20 > =20 > On Nov 28, 2013, at 12:40 PM, "Wiehe, Ulrich (NSN - DE/Munich)" = wrote: > =20 > Hi, > =20 > another question: > =20 > If we go for explicit self contained OLRs, why would we then need the = ReportType? > =20 > The realm-type OLR would explicitly contain application-Id, Realm, but = no Host whereas the host-type OLR would explicitly contain = application-Id, Host, but probably (I'm not sure) no Realm. > =20 > Ulrich > =20 > =20 > =20 > -----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 > =20 > Hi, > =20 > 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. > =20 > Lionel > =20 > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich=20= > (NSN - DE/Munich) Envoy=E9 : jeudi 28 novembre 2013 10:26 =C0 : ext = Jouni=20 > Korhonen; Ben Campbell Cc : dime@ietf.org list Objet : Re: [Dime]=20 > DOIC: Self-Contained OLRs > =20 > Hi, > =20 > 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? > =20 > Ulrich > =20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Jouni=20 > Korhonen > Sent: Wednesday, November 27, 2013 11:44 PM > To: Ben Campbell > Cc: dime@ietf.org list > Subject: Re: [Dime] DOIC: Self-Contained OLRs > =20 > =20 > On Nov 28, 2013, at 12:27 AM, Ben Campbell wrote: > =20 > Hi, > =20 > I mentioned in another thread that I prefer putting an explicit=20 > ReportType AVP in an OLR, rather than > =20 > The more I spent time thinking/writing the actual procedures on the=20 > endpoints, the more it makes sense to me to keep the ReportType in the=20= > OC-OLR. Even if the baseline does not have agent overload etc, the=20 > ReportType fits well to the "endpoint principle" we have in the draft.=20= > It indeed gives more tools to make a host vs. realm base decision on = the reacting node and is plain more clear. > =20 > I skip the rest of the mail.. too much text ;-) > =20 > =20 > - Jouni > =20 > =20 > =20 > =20 > =20 > 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. > =20 > 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. > =20 > I think this approach is a mistake. I would greatly prefer that we = explicitly include such values in the OLR itself, for multiple reasons: > =20 > 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. > =20 > 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.=20= > =20 > 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. > =20 > 3) Implicit values don't work at all for certain problems. For=20 > example, if an agent needs to originate an OLR, it typically needs to=20= > insert that OLR into an existing Diameter answer created by a server.=20= > It can't create its own answer without affecting the application=20 > state. If the responding node assumes the OLR comes from or refers to=20= > the node identified by the Origin-Host AVP in the enclosing answer,=20 > things break. (For examples of when an agent needs to send OLRs that=20= > are distinct from those sent by a server, see Steve's agent overload=20= > draft, or my dh/dr example.) > =20 > OTOH, explicit values will work for all cases where we need to = associate some arbitrary value with an OLR. > =20 > 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. > =20 > 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. > =20 > Thanks! > =20 > Ben. > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > =20 > _______________________________________________ > 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 > =20 > ______________________________________________________________________ > ___________________________________________________ > =20 > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20= > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > 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. > =20 > This message and its attachments may contain confidential or=20 > 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. > =20 > =20 > _______________________________________________ > 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 > =20 > = __________________________________________________________________________= _______________________________________________ > =20 > 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. > =20 > 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. > =20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > =20 > =20 > = __________________________________________________________________________= _______________________________________________ >=20 > 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. >=20 > 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. >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From ben@nostrum.com Tue Dec 3 15:00:18 2013 Return-Path: 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 87F6E1AE1C0 for ; Tue, 3 Dec 2013 15:00:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no 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 jEbf0tocNVrP for ; Tue, 3 Dec 2013 15:00:16 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1D5AA1AE1BC for ; Tue, 3 Dec 2013 15:00:16 -0800 (PST) Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rB3N09wK041832 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Dec 2013 17:00:10 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ben Campbell In-Reply-To: <529CA616.2040205@usdonovans.com> Date: Tue, 3 Dec 2013 17:00:10 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D90006681519BC90@DEMUMBX014.nsn-intra.net> <6390_1385631044_52970D44_6390_18593_1_6B7134B31289DC4FAF731D844122B36E30748E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BD19@DEMUMBX014.nsn-intra.net> <17872_1385720008_529868C8_17872_2613_1_6B7134B31289DC4FAF731D844122B36E3096B8@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BF1B@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681519BFAE@DEMUMBX014.nsn-intra.net> <529CA616.2040205@usdonovans.com> To: Steve Donovan X-Mailer: Apple Mail (2.1822) Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism) Cc: "dime@ietf.org list" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 23:00:18 -0000 On Dec 2, 2013, at 9:24 AM, Steve Donovan = wrote: > Ulrich, >=20 > Designing an overload solution that allows a reacting node to ignore = an overload report seems strange to me. The system is under stress. = Overload reports should be reacted to as quickly as possible, = independent of how the overload report is received by the reacting node. >=20 While I don't agree with the "out-of-context" concern, I can see saying = that a reacting node ignore an OLR if it does not understand the = ReportType. Otherwise, it doesn't understand the meaning of the report, = and is likely to do the wrong thing. An alternative might be to say the = reacting node should treat anything it doesn't understand as "Realm". > Steve >=20 > On 12/1/13 1:38 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >> Hi Nirav, >>=20 >> 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. >>=20 >> Best regards >> Ulrich=20 >>=20 >>=20 >> -----Original Message----- >> From: ext Nirav Salot (nsalot) [ >> mailto:nsalot@cisco.com >> ]=20 >> Sent: Friday, November 29, 2013 4:49 PM >> To: Wiehe, Ulrich (NSN - DE/Munich); ext=20 >> lionel.morand@orange.com >> ; ext Jouni Korhonen; Ben Campbell >> Cc:=20 >> dime@ietf.org >> list >> Subject: RE: [Dime] DOIC: Self-Contained OLRs >>=20 >> Hi Ulrich, >>=20 >> If an additional OLR is present with a different ReportType, why it = should be ignored by the reacting node? >>=20 >> Regards, >> Nirav. >>=20 >> -----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=20 >> lionel.morand@orange.com >> ; ext Jouni Korhonen; Ben Campbell >> Cc:=20 >> dime@ietf.org >> list >> Subject: Re: [Dime] DOIC: Self-Contained OLRs >>=20 >> Hi Lionel, >>=20 >> 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. >>=20 >> Ulrich >> =20 >>=20 >> -----Original Message----- >> From: ext=20 >> 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:=20 >> dime@ietf.org >> list >> Subject: RE: [Dime] DOIC: Self-Contained OLRs >>=20 >> Hi Ulrich, >>=20 >> 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.=20 >>=20 >> 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. >>=20 >> I'm not sure of what is missing in this reasoning... >>=20 >> Lionel >>=20 >> -----Message d'origine----- >> De : Wiehe, Ulrich (NSN - DE/Munich) [ >> mailto:ulrich.wiehe@nsn.com] Envoy=E9 : jeudi 28 novembre 2013 11:30 = =C0 : MORAND Lionel IMT/OLN; ext Jouni Korhonen; Ben Campbell Cc : = dime@ietf.org >> list Objet : RE: [Dime] DOIC: Self-Contained OLRs >>=20 >> Lionel, >>=20 >> my understanding was that _the_ reporting end point provides _the_ = OLR. >>=20 >> 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. >>=20 >> 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. >>=20 >> Ulrich >>=20 >>=20 >>=20 >> -----Original Message----- >> From: ext=20 >> 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:=20 >> dime@ietf.org >> list >> Subject: RE: [Dime] DOIC: Self-Contained OLRs >>=20 >> Hi, >>=20 >> 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. >>=20 >> Lionel >>=20 >> -----Message d'origine----- >> De : DiME [ >> mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN - = DE/Munich) Envoy=E9 : jeudi 28 novembre 2013 10:26 =C0 : ext Jouni = Korhonen; Ben Campbell Cc : dime@ietf.org >> list Objet : Re: [Dime] DOIC: Self-Contained OLRs >>=20 >> Hi, >>=20 >> 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? >>=20 >> Ulrich >>=20 >> -----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:=20 >> dime@ietf.org >> list >> Subject: Re: [Dime] DOIC: Self-Contained OLRs >>=20 >>=20 >> On Nov 28, 2013, at 12:27 AM, Ben Campbell=20 >> >> wrote: >>=20 >>=20 >>> Hi, >>>=20 >>> I mentioned in another thread that I prefer putting an explicit=20 >>> ReportType AVP in an OLR, rather than >>>=20 >> 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. >>=20 >> I skip the rest of the mail.. too much text ;-) >>=20 >>=20 >> - Jouni >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> I think this approach is a mistake. I would greatly prefer that we = explicitly include such values in the OLR itself, for multiple reasons: >>>=20 >>> 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. >>>=20 >>> 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.=20= >>>=20 >>> 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. >>>=20 >>> 3) Implicit values don't work at all for certain problems. For=20 >>> example, if an agent needs to originate an OLR, it typically needs = to=20 >>> insert that OLR into an existing Diameter answer created by a = server.=20 >>> It can't create its own answer without affecting the application=20 >>> state. If the responding node assumes the OLR comes from or refers = to=20 >>> the node identified by the Origin-Host AVP in the enclosing answer,=20= >>> things break. (For examples of when an agent needs to send OLRs that=20= >>> are distinct from those sent by a server, see Steve's agent overload=20= >>> draft, or my dh/dr example.) >>>=20 >>> OTOH, explicit values will work for all cases where we need to = associate some arbitrary value with an OLR. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> Thanks! >>>=20 >>> Ben. >>> _______________________________________________ >>> DiME mailing list >>>=20 >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >> _______________________________________________ >> DiME mailing list >>=20 >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >>=20 >> _______________________________________________ >> DiME mailing list >>=20 >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >>=20 >>=20 >> = __________________________________________________________________________= _______________________________________________ >>=20 >> 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. >>=20 >> 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. >>=20 >>=20 >> = __________________________________________________________________________= _______________________________________________ >>=20 >> 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. >>=20 >> 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. >>=20 >> _______________________________________________ >> DiME mailing list >>=20 >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >>=20 >> _______________________________________________ >> DiME mailing list >>=20 >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >>=20 >>=20 >>=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From ben@nostrum.com Tue Dec 3 15:02:04 2013 Return-Path: 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 B58AD1ADF59 for ; Tue, 3 Dec 2013 15:02:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no 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 srMvcF59jFYo for ; Tue, 3 Dec 2013 15:02:02 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id DB5851AE1BC for ; Tue, 3 Dec 2013 15:02:01 -0800 (PST) Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rB3N1qmN041911 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Dec 2013 17:01:53 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ben Campbell In-Reply-To: Date: Tue, 3 Dec 2013 17:01:52 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D90006681519BC90@DEMUMBX014.nsn-intra.net> <6390_1385631044_52970D44_6390_18593_1_6B7134B31289DC4FAF731D844122B36E30748E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BD31@DEMUMBX014.nsn-intra.net> <47383DC2-1A1B-4D1A-ADD5-9E3CE60B06C8@gmail.com> To: "Nirav Salot (nsalot)" X-Mailer: Apple Mail (2.1822) Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism) Cc: "dime@ietf.org list" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 23:02:04 -0000 On Nov 29, 2013, at 5:24 AM, Nirav Salot (nsalot) = wrote: > Jouni, Ben, >=20 > I am totally against the idea of self-contained OC-OLR specifically = since we have adopted the principles of piggybacking the OC-OLR over = existing application message. > Self-contained OC-OLR - which means adding all the information which = defines the scope of the OC-OLR into the OC-OLR - does not make sense in = the piggybacking approach. In fact, it is adding lot of information, = which is anyway available within the message containing the OC-OLR, into = the OC-OLR. So it is adding lot of redundant information in a message = which increases the processing requirement for the sender as well as the = receiver. (And this is un-optimization, in my view). I do not really understand why the idea of "piggybacking" need force any = particular connection between the OLR and the enclosing message, other = than as a transport. >=20 > Besides, I am not convinced with the other reasons provided here: > - One software module within a node can provide OC-OLR to another = software module in the same node without passing other related info > Within a node, based on the design, lots of information may need to = be passed between two software modules and we cannot optimize those = aspects by replicating unnecessary information in a protocol message. > In summary, it is node's internal software design issue and we need = not optimize that at protocol level. >=20 > - Once the reporting node realizes that it is overloaded, it has to = wait for right answer to send OC-OLR > What is the point of sending OC-OLR for a context for which there is = no messaging? Why should the reacting node care if it never sends a = message for a context for which the reporting node is overloaded? > So this waiting is justified since it ensures that the overload is = reported only when necessary and only to the applicable reacting node. = Not to all the nodes in the network. >=20 > - The agent needs to wait for the answer generated by the server and = the right context > The same argument as applicable for the server applies here. The = agent need not send out-of-context overload info to a node. > Why should reacting node receive/process/store the overload info for = the scope for which it is not sending any messages. >=20 > - For sending OC-OLR in dedicated Diameter application??? > Piggybacking was the first basic principle we agreed before putting = other principles in place. So we may want to go back the drawing board = if we decide to change this principle. >=20 > Regards, > Nirav. >=20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen > Sent: Friday, November 29, 2013 2:50 PM > To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list > Cc: Ben Campbell > Subject: Re: [Dime] DOIC: Self-Contained OLRs >=20 >=20 >=20 > So, are we reaching any level of consensus here? >=20 > - JOuni >=20 > (as a note.. that we are converging back to where we started with OLRs = ;) >=20 >=20 >=20 > On Nov 28, 2013, at 12:40 PM, "Wiehe, Ulrich (NSN - DE/Munich)" = wrote: >=20 >> Hi, >>=20 >> another question: >>=20 >> If we go for explicit self contained OLRs, why would we then need the = ReportType? >>=20 >> The realm-type OLR would explicitly contain application-Id, Realm, = but no Host whereas the host-type OLR would explicitly contain = application-Id, Host, but probably (I'm not sure) no Realm. >>=20 >> Ulrich >>=20 >>=20 >>=20 >> -----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 >>=20 >> Hi, >>=20 >> 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. >>=20 >> Lionel >>=20 >> -----Message d'origine----- >> De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich=20= >> (NSN - DE/Munich) Envoy=E9 : jeudi 28 novembre 2013 10:26 =C0 : ext = Jouni=20 >> Korhonen; Ben Campbell Cc : dime@ietf.org list Objet : Re: [Dime]=20 >> DOIC: Self-Contained OLRs >>=20 >> Hi, >>=20 >> 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? >>=20 >> Ulrich >>=20 >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Jouni=20 >> Korhonen >> Sent: Wednesday, November 27, 2013 11:44 PM >> To: Ben Campbell >> Cc: dime@ietf.org list >> Subject: Re: [Dime] DOIC: Self-Contained OLRs >>=20 >>=20 >> On Nov 28, 2013, at 12:27 AM, Ben Campbell wrote: >>=20 >>> Hi, >>>=20 >>> I mentioned in another thread that I prefer putting an explicit=20 >>> ReportType AVP in an OLR, rather than >>=20 >> The more I spent time thinking/writing the actual procedures on the=20= >> endpoints, the more it makes sense to me to keep the ReportType in = the=20 >> OC-OLR. Even if the baseline does not have agent overload etc, the=20 >> ReportType fits well to the "endpoint principle" we have in the = draft.=20 >> It indeed gives more tools to make a host vs. realm base decision on = the reacting node and is plain more clear. >>=20 >> I skip the rest of the mail.. too much text ;-) >>=20 >>=20 >> - Jouni >>=20 >>=20 >>=20 >>=20 >>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> I think this approach is a mistake. I would greatly prefer that we = explicitly include such values in the OLR itself, for multiple reasons: >>>=20 >>> 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. >>>=20 >>> 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.=20= >>>=20 >>> 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. >>>=20 >>> 3) Implicit values don't work at all for certain problems. For=20 >>> example, if an agent needs to originate an OLR, it typically needs = to=20 >>> insert that OLR into an existing Diameter answer created by a = server.=20 >>> It can't create its own answer without affecting the application=20 >>> state. If the responding node assumes the OLR comes from or refers = to=20 >>> the node identified by the Origin-Host AVP in the enclosing answer,=20= >>> things break. (For examples of when an agent needs to send OLRs that=20= >>> are distinct from those sent by a server, see Steve's agent overload=20= >>> draft, or my dh/dr example.) >>>=20 >>> OTOH, explicit values will work for all cases where we need to = associate some arbitrary value with an OLR. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> Thanks! >>>=20 >>> Ben. >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>=20 >> _______________________________________________ >> 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 >>=20 >> = ______________________________________________________________________ >> ___________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations=20 >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20= >> exploites ou copies sans autorisation. Si vous avez recu ce message=20= >> 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. >>=20 >> This message and its attachments may contain confidential or=20 >> 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. >>=20 >=20 > _______________________________________________ > 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 From ben@nostrum.com Tue Dec 3 15:15:21 2013 Return-Path: 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 1E6231AE1C2 for ; Tue, 3 Dec 2013 15:15:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no 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 CWWjFnJ3ZA9s for ; Tue, 3 Dec 2013 15:15:18 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4A3261AE1C0 for ; Tue, 3 Dec 2013 15:15:18 -0800 (PST) Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rB3NF84x042427 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Dec 2013 17:15:09 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ben Campbell In-Reply-To: Date: Tue, 3 Dec 2013 17:15:08 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <0E3F4DF0-0C5F-482D-8CA4-F77B5B2A5F09@nostrum.com> References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D90006681519BC90@DEMUMBX014.nsn-intra.net> <6390_1385631044_52970D44_6390_18593_1_6B7134B31289DC4FAF731D844122B36E30748E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BD31@DEMUMBX014.nsn-intra.net> <47383DC2-1A1B-4D1A-ADD5-9E3CE60B06C8@gmail.com> To: "Nirav Salot (nsalot)" X-Mailer: Apple Mail (2.1822) Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism) Cc: "dime@ietf.org list" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 23:15:21 -0000 (oops, sorry, I sent my previous response before I was finished. On Nov 29, 2013, at 5:24 AM, Nirav Salot (nsalot) = wrote: > Jouni, Ben, >=20 > I am totally against the idea of self-contained OC-OLR specifically = since we have adopted the principles of piggybacking the OC-OLR over = existing application message. > Self-contained OC-OLR - which means adding all the information which = defines the scope of the OC-OLR into the OC-OLR - does not make sense in = the piggybacking approach. In fact, it is adding lot of information, = which is anyway available within the message containing the OC-OLR, into = the OC-OLR. So it is adding lot of redundant information in a message = which increases the processing requirement for the sender as well as the = receiver. (And this is un-optimization, in my view). It's not clear to me that piggybacking implies any particular = relationship between an OLR and the enclosing message, other than = transport. >=20 > Besides, I am not convinced with the other reasons provided here: > - One software module within a node can provide OC-OLR to another = software module in the same node without passing other related info > Within a node, based on the design, lots of information may need to = be passed between two software modules and we cannot optimize those = aspects by replicating unnecessary information in a protocol message. > In summary, it is node's internal software design issue and we need = not optimize that at protocol level. We should absolutely not ignore implementation concerns. I think that = overload control should be considered a separate layer than the Diameter = application. The whole point of layering is about reducing = implementation complexity. In fact, I think this whole disagreement comes from different = assumptions about layering. Part of why I've brought this up is, I have = talked to implementors who think that we've made life hard for them by = tying OLRs to tightly to the application. This is particularly hard for = anything that wants to handle OLC for arbitrary applications in an = application-independent way. (Which, by the way, is required by the = requirements RFC). >=20 > - Once the reporting node realizes that it is overloaded, it has to = wait for right answer to send OC-OLR > What is the point of sending OC-OLR for a context for which there is = no messaging? Why should the reacting node care if it never sends a = message for a context for which the reporting node is overloaded? I didn't say that no messages existed that could carry the report. The = issue is, there may be a lot of other messages that _cannot_ carry it. = So the sender has to sort through all the messages to find the ones that = can work. > So this waiting is justified since it ensures that the overload is = reported only when necessary and only to the applicable reacting node. = Not to all the nodes in the network. With self-contained OLRs, you don't have to worry about an inappropriate = node getting the request. Sure you can choose to send OLRs only to = appropriate reacting nodes, but that becomes an implementation decision = rather than a protocol requirement. >=20 > - The agent needs to wait for the answer generated by the server and = the right context > The same argument as applicable for the server applies here. The = agent need not send out-of-context overload info to a node. > Why should reacting node receive/process/store the overload info for = the scope for which it is not sending any messages. If it's not sending (or going to send) any messages for the scope, it = can ignore the OLR. >=20 > - For sending OC-OLR in dedicated Diameter application??? > Piggybacking was the first basic principle we agreed before putting = other principles in place. So we may want to go back the drawing board = if we decide to change this principle. Piggybacking does not conflict with self-contained OLRs. The roach draft = was piggybacked, and still used self-contained OLRs. All we have to do = to use self-contained OLRs is add the necessary AVPs to the OLR format, = and possibly remove a bunch of restrictions on how you can use them. If = we need other transport designs (i.e. dedicated applications), we can = add those later. I'd like to remind people that the original mandate given to the design = team at the Berlin DIME meeting was to define a format and semantics, = not define how we move reports around. We went way beyond that. I don't = object to that fact, but I think we should avoid too many limitations in = the format and semantics that prevent other ways of moving the reports = around. >=20 > Regards, > Nirav. >=20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen > Sent: Friday, November 29, 2013 2:50 PM > To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list > Cc: Ben Campbell > Subject: Re: [Dime] DOIC: Self-Contained OLRs >=20 >=20 >=20 > So, are we reaching any level of consensus here? >=20 > - JOuni >=20 > (as a note.. that we are converging back to where we started with OLRs = ;) >=20 >=20 >=20 > On Nov 28, 2013, at 12:40 PM, "Wiehe, Ulrich (NSN - DE/Munich)" = wrote: >=20 >> Hi, >>=20 >> another question: >>=20 >> If we go for explicit self contained OLRs, why would we then need the = ReportType? >>=20 >> The realm-type OLR would explicitly contain application-Id, Realm, = but no Host whereas the host-type OLR would explicitly contain = application-Id, Host, but probably (I'm not sure) no Realm. >>=20 >> Ulrich >>=20 >>=20 >>=20 >> -----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 >>=20 >> Hi, >>=20 >> 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. >>=20 >> Lionel >>=20 >> -----Message d'origine----- >> De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich=20= >> (NSN - DE/Munich) Envoy=E9 : jeudi 28 novembre 2013 10:26 =C0 : ext = Jouni=20 >> Korhonen; Ben Campbell Cc : dime@ietf.org list Objet : Re: [Dime]=20 >> DOIC: Self-Contained OLRs >>=20 >> Hi, >>=20 >> 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? >>=20 >> Ulrich >>=20 >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Jouni=20 >> Korhonen >> Sent: Wednesday, November 27, 2013 11:44 PM >> To: Ben Campbell >> Cc: dime@ietf.org list >> Subject: Re: [Dime] DOIC: Self-Contained OLRs >>=20 >>=20 >> On Nov 28, 2013, at 12:27 AM, Ben Campbell wrote: >>=20 >>> Hi, >>>=20 >>> I mentioned in another thread that I prefer putting an explicit=20 >>> ReportType AVP in an OLR, rather than >>=20 >> The more I spent time thinking/writing the actual procedures on the=20= >> endpoints, the more it makes sense to me to keep the ReportType in = the=20 >> OC-OLR. Even if the baseline does not have agent overload etc, the=20 >> ReportType fits well to the "endpoint principle" we have in the = draft.=20 >> It indeed gives more tools to make a host vs. realm base decision on = the reacting node and is plain more clear. >>=20 >> I skip the rest of the mail.. too much text ;-) >>=20 >>=20 >> - Jouni >>=20 >>=20 >>=20 >>=20 >>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> I think this approach is a mistake. I would greatly prefer that we = explicitly include such values in the OLR itself, for multiple reasons: >>>=20 >>> 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. >>>=20 >>> 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.=20= >>>=20 >>> 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. >>>=20 >>> 3) Implicit values don't work at all for certain problems. For=20 >>> example, if an agent needs to originate an OLR, it typically needs = to=20 >>> insert that OLR into an existing Diameter answer created by a = server.=20 >>> It can't create its own answer without affecting the application=20 >>> state. If the responding node assumes the OLR comes from or refers = to=20 >>> the node identified by the Origin-Host AVP in the enclosing answer,=20= >>> things break. (For examples of when an agent needs to send OLRs that=20= >>> are distinct from those sent by a server, see Steve's agent overload=20= >>> draft, or my dh/dr example.) >>>=20 >>> OTOH, explicit values will work for all cases where we need to = associate some arbitrary value with an OLR. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> Thanks! >>>=20 >>> Ben. >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>=20 >> _______________________________________________ >> 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 >>=20 >> = ______________________________________________________________________ >> ___________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations=20 >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20= >> exploites ou copies sans autorisation. Si vous avez recu ce message=20= >> 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. >>=20 >> This message and its attachments may contain confidential or=20 >> 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. >>=20 >=20 > _______________________________________________ > 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 From lionel.morand@orange.com Tue Dec 3 15:18:08 2013 Return-Path: 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 1CDBF1AE1DA for ; Tue, 3 Dec 2013 15:18:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 iEuWwLdjqafl for ; Tue, 3 Dec 2013 15:18:04 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id 1850C1AE1D7 for ; Tue, 3 Dec 2013 15:18:03 -0800 (PST) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id C3F202AC639; Wed, 4 Dec 2013 00:17:59 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id A2483158052; Wed, 4 Dec 2013 00:17:59 +0100 (CET) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0158.001; Wed, 4 Dec 2013 00:17:59 +0100 From: To: Ben Campbell Thread-Topic: [Dime] DOIC: Self-Contained OLRs Thread-Index: AQHO8HrXo7y6FFeeaEmQ38aKczpYQJpDF2Xg Date: Tue, 3 Dec 2013 23:17:57 +0000 Message-ID: <17146_1386112679_529E66A7_17146_16391_1_6B7134B31289DC4FAF731D844122B36E31A900@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D90006681519BC90@DEMUMBX014.nsn-intra.net> <6390_1385631044_52970D44_6390_18593_1_6B7134B31289DC4FAF731D844122B36E30748E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BD31@DEMUMBX014.nsn-intra.net> <47383DC2-1A1B-4D1A-ADD5-9E3CE60B06C8@gmail.com> <8467_1385735507_5298A553_8467_17054_3_6B7134B31289DC4FAF731D844122B36E309D0D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <529CA930.4030006@usdonovans.com> <13482_1386001111_529CB2D7_13482_11387_1_6B7134B31289DC4FAF731D844122B36E311068@PEXCVZYM13.corporate.adroot.infra.ftgroup> <2AB88923-E019-4EAF-9512-E677D5798DB3@nostrum.com> In-Reply-To: <2AB88923-E019-4EAF-9512-E677D5798DB3@nostrum.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.12.3.224215 Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 23:18:08 -0000 Hi Ben, I may be wrong somewhere in my summary but I think that it was the result o= f the discussions and agreements reached regarding existing requirements, a= t least from 3GPP point of view, compared to possible optimizations for fut= ure optimizations not so obvious. And because the solution offers extensibility via the definition of new alg= o, new report type and addition of any new AVP in the existing Grouped OLR,= the "limitations" of the proposed solution might be removed by someone if = really required according to new requirements. Regards, Lionel -----Message d'origine----- De=A0: Ben Campbell [mailto:ben@nostrum.com]=20 Envoy=E9=A0: mardi 3 d=E9cembre 2013 23:56 =C0=A0: MORAND Lionel IMT/OLN Cc=A0: Steve Donovan; dime@ietf.org Objet=A0: Re: [Dime] DOIC: Self-Contained OLRs On Dec 2, 2013, at 10:18 AM, lionel.morand@orange.com wrote: > Hi Steve, >=20=20 > I think that is not only about few bytes in the answer. It is also about = the solution principles agreed so far: > =B7 the current need is for an OLR bound to the application in use > =B7 the OLR is received from the node targeted in the request. > =B7 the OLR is defined per application I don't think those principles have been well tested. I don't recall any di= scussion of their benefits. What benefits do you see they have over self-co= ntained OLRs? All I see from these are restrictions in the flexibility of the solution, w= ith very little in return. > So all the implicit information (application, origin-host, origin-realm) = are meaningful in this context. > And the actual solution is designed based on these assumptions. The exten= sibility of the solution will allow extra info if required in other use cas= es but it was agreed to go with a straightforward solution that will satisf= y most of us. >=20=20 > Regards, >=20=20 > Lionel >=20=20 > De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan > Envoy=E9 : lundi 2 d=E9cembre 2013 16:37 > =C0 : dime@ietf.org > Objet : Re: [Dime] DOIC: Self-Contained OLRs >=20=20 > I don't believe that Ben's proposal was to change the piggybacking assump= tion in the baseline mechanism. Ben's proposal is to design the solution i= n such a way that it is not dependent on the piggybacking transport mechani= sm.=20=20 >=20 > I share Ben's concern that we have over optimized the content of the over= load report in a way that makes implementations brittle, interoperability m= ore difficult to achieve and extensibility more complex. And what do we ga= in from this optimization? A few bites in answer messages. >=20 > Self contained overload reports, transported using the piggybacking mecha= nism, is a cleaner solution. >=20 > Steve >=20 > On 11/29/13 8:31 AM, lionel.morand@orange.com wrote: > I totally agree with Nirav. No need to revert at this stage the working a= ssumption on piggybacking of OLR in application answer messages, especially= when the aim is to define a basic mechanism called "reduction". >=20=20 > Anyone would be able to further add extra info for optimization if needed= but there is no need at all for the basic mechanism. >=20=20 > Regards, >=20=20 > Lionel >=20=20 > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot (nsalo= t) > Envoy=E9 : vendredi 29 novembre 2013 12:24 > =C0 : Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list > Cc : Ben Campbell > Objet : Re: [Dime] DOIC: Self-Contained OLRs >=20=20 > Jouni, Ben, >=20=20 > I am totally against the idea of self-contained OC-OLR specifically since= we have adopted the principles of piggybacking the OC-OLR over existing ap= plication message. > Self-contained OC-OLR - which means adding all the information which defi= nes the scope of the OC-OLR into the OC-OLR - does not make sense in the pi= ggybacking approach. In fact, it is adding lot of information, which is any= way available within the message containing the OC-OLR, into the OC-OLR. So= it is adding lot of redundant information in a message which increases the= processing requirement for the sender as well as the receiver. (And this i= s un-optimization, in my view). >=20=20 > Besides, I am not convinced with the other reasons provided here: > - One software module within a node can provide OC-OLR to another softwar= e module in the same node without passing other related info > Within a node, based on the design, lots of information may need to be= passed between two software modules and we cannot optimize those aspects b= y replicating unnecessary information in a protocol message. > In summary, it is node's internal software design issue and we need no= t optimize that at protocol level. >=20=20 > - Once the reporting node realizes that it is overloaded, it has to wait = for right answer to send OC-OLR > What is the point of sending OC-OLR for a context for which there is no= messaging? Why should the reacting node care if it never sends a message f= or a context for which the reporting node is overloaded? > So this waiting is justified since it ensures that the overload is repo= rted only when necessary and only to the applicable reacting node. Not to a= ll the nodes in the network. >=20=20 > - The agent needs to wait for the answer generated by the server and the = right context > The same argument as applicable for the server applies here. The agent= need not send out-of-context overload info to a node. > Why should reacting node receive/process/store the overload info for t= he scope for which it is not sending any messages. >=20=20 > - For sending OC-OLR in dedicated Diameter application??? > Piggybacking was the first basic principle we agreed before putting oth= er principles in place. So we may want to go back the drawing board if we d= ecide to change this principle. >=20=20 > Regards, > Nirav. >=20=20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen > Sent: Friday, November 29, 2013 2:50 PM > To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list > Cc: Ben Campbell > Subject: Re: [Dime] DOIC: Self-Contained OLRs >=20=20 >=20=20 >=20=20 > So, are we reaching any level of consensus here? >=20=20 > - JOuni >=20=20 > (as a note.. that we are converging back to where we started with OLRs ;) >=20=20 >=20=20 >=20=20 > On Nov 28, 2013, at 12:40 PM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: >=20=20 > Hi, >=20=20 > another question: >=20=20 > If we go for explicit self contained OLRs, why would we then need the Rep= ortType? >=20=20 > The realm-type OLR would explicitly contain application-Id, Realm, but no= Host whereas the host-type OLR would explicitly contain application-Id, Ho= st, but probably (I'm not sure) no Realm. >=20=20 > Ulrich >=20=20 >=20=20 >=20=20 > -----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 >=20=20 > Hi, >=20=20 > There is no assumption on which entity is providing the realm overload st= atus. 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 s= ome 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 ser= ver itself, one for the realm for new request sent to the realm with only D= est-Realm AVP. >=20=20 > Lionel >=20=20 > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich=20 > (NSN - DE/Munich) Envoy=E9 : jeudi 28 novembre 2013 10:26 =C0 : ext Jouni= =20 > Korhonen; Ben Campbell Cc : dime@ietf.org list Objet : Re: [Dime]=20 > DOIC: Self-Contained OLRs >=20=20 > Hi, >=20=20 > 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 i= ndicates 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 indicate= s to the reacting end point that the reporting end point is a server. How c= an the reporting end point be both agent and server? >=20=20 > Ulrich >=20=20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Jouni=20 > Korhonen > Sent: Wednesday, November 27, 2013 11:44 PM > To: Ben Campbell > Cc: dime@ietf.org list > Subject: Re: [Dime] DOIC: Self-Contained OLRs >=20=20 >=20=20 > On Nov 28, 2013, at 12:27 AM, Ben Campbell wrote: >=20=20 > Hi, >=20=20 > I mentioned in another thread that I prefer putting an explicit=20 > ReportType AVP in an OLR, rather than >=20=20 > The more I spent time thinking/writing the actual procedures on the=20 > endpoints, the more it makes sense to me to keep the ReportType in the=20 > OC-OLR. Even if the baseline does not have agent overload etc, the=20 > ReportType fits well to the "endpoint principle" we have in the draft.=20 > It indeed gives more tools to make a host vs. realm base decision on the = reacting node and is plain more clear. >=20=20 > I skip the rest of the mail.. too much text ;-) >=20=20 >=20=20 > - Jouni >=20=20 >=20=20 >=20=20 >=20=20 >=20=20 > making a responding node infer the type or meaning of the OLR from a Diam= eter request that corresponds to the answer containing the OLR. My reasons = for that go beyond just ReportType, so I'm starting a separate thread. >=20=20 > As currently described, a consumer of an OLR must infer several things fr= om other context. In most cases, that context is in the Diameter answer tha= t carries the OLR. For example, the OLR implicitly refers to the applicatio= n 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 meani= ng in the context of the enclosing answer. If you moved an OLR from one ans= wer to another, it's meaning may change completely. >=20=20 > I think this approach is a mistake. I would greatly prefer that we explic= itly include such values in the OLR itself, for multiple reasons: >=20=20 > 1) It's more complex to interpret implicit, contextual values than explic= it values. The consumer cannot simply look at the OLR; it must look in vari= ous other AVPs to find all the information it needs. For example, I think a= common software design for overload control processing to be separated fro= m application processing. The consumer cannot simply hand the OLR to that m= odule 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 "con= text" avps that must be interpreted can grow large. This approach is error = prone, and will likely encourage brittle, hard-to-maintain code. Self-conta= ined OLRs would keep all the information related to overload in one place. = making for simpler implementations. >=20=20 > 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 r= eporting node realizes that it is overloade, it has to wait for the right a= nswer that contains the right context before it can send the OLR. This is p= articularly troublesome for agents, since they will typically have to inser= t OLRs into answers created by other nodes.=20 >=20=20 > If the reporting node screws this up, the meaning of the OLR may change s= ignificantly. So again, implicit meaning gives us error prone implementatio= ns. Self-contained OLRs are simpler to create and send. >=20=20 > 3) Implicit values don't work at all for certain problems. For=20 > example, if an agent needs to originate an OLR, it typically needs to=20 > insert that OLR into an existing Diameter answer created by a server.=20 > It can't create its own answer without affecting the application=20 > state. If the responding node assumes the OLR comes from or refers to=20 > the node identified by the Origin-Host AVP in the enclosing answer,=20 > things break. (For examples of when an agent needs to send OLRs that=20 > are distinct from those sent by a server, see Steve's agent overload=20 > draft, or my dh/dr example.) >=20=20 > OTOH, explicit values will work for all cases where we need to associate = some arbitrary value with an OLR. >=20=20 > 4) Implicit values seriously constrain the future evolution of Diameter O= C standards. For example, lets say we find a good reason to allow OLRs to b= e sent out of band, or be sent in a dedicated Diameter application. If over= load 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 transpo= rted, this won't work. We would have to create a new or significantly modif= ied OLR format if we found a need to transport OLRs in different ways. Self= -contained OLRs would allow much greater flexibility. >=20=20 > So, in summary, I think that self-contained OLRs would lead to simpler im= plementations, less brittle deployments, and more flexibility for future ev= olution of standards. >=20=20 > Thanks! >=20=20 > Ben. > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime >=20=20 > _______________________________________________ > 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 >=20=20 > ______________________________________________________________________ > ___________________________________________________ >=20=20 > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci. >=20=20 > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not be d= istributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20=20 >=20=20 > _______________________________________________ > 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 >=20=20 > _________________________________________________________________________= ________________________________________________ >=20=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu 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 o= u falsifie. Merci. >=20=20 > This message and its attachments may contain confidential or privileged i= nformation 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 de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime >=20=20 >=20=20 > _________________________________________________________________________= ________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu 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 o= u falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged i= nformation 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 de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. From ben@nostrum.com Tue Dec 3 15:21:01 2013 Return-Path: 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 A759D1ADFBD for ; Tue, 3 Dec 2013 15:21:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no 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 4Y3dEd8jh6UE for ; Tue, 3 Dec 2013 15:21:00 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB7B1ADF28 for ; Tue, 3 Dec 2013 15:21:00 -0800 (PST) Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rB3NKr7R042677 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Dec 2013 17:20:54 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ben Campbell In-Reply-To: <087A34937E64E74E848732CFF8354B920972BE0C@ESESSMB101.ericsson.se> Date: Tue, 3 Dec 2013 17:20:54 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <087A34937E64E74E848732CFF8354B920972BE0C@ESESSMB101.ericsson.se> To: Maria Cruz Bartolome X-Mailer: Apple Mail (2.1822) Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism) Cc: "dime@ietf.org" Subject: Re: [Dime] OLR applicable for any/all applications X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 23:21:01 -0000 I do not object. I used this as an argument in the past that we should = label the OLR with the application ID, but people thought it was okay to = require the overloaded node to send a separate OLR for each application. = (I don't agree with that, by the way, I just gave up the argument for = the moment.) But I can't help but noting that this would be automatically handled = with self-contained OLRs :-) That is, by defining that the absence of = an application-ID, or possibly some wildcard value, as meaning "all = applications". On Dec 3, 2013, at 2:42 AM, Maria Cruz Bartolome = wrote: > =20 > Dear all, > =20 > There may be a need by a reporting node to request traffic reduction = for all traffic, application independent, e.g. if an operator=92s = network becomes severely overloaded, it may be of interest to signal = directly general overload to the client. =20 >=20 > In this case, since reacting node obtains affected application from = the application message, we may need to extend OLR. > =20 > At least we got following options: > =20 > =20 > A) Define a new optional AVP that could be included into OLR, like = e.g.: > OC-OLR ::=3D < AVP Header: TBD2 > > < TimeStamp > > [ Reduction-Percentage ] > [ ValidityDuration ] > [ ReportType ] > [All applications] > * [ AVP ] > =20 > =20 > B) Extend ReportTypes like e.g.: > =20 > 3 Destination-Host All Applications report. Similar to = Destination-Host report but it would apply to any application regardless = the application message this report is received within. > =20 > 4 Realm (aggregated) All Applications report. Similar to Realm = report but it would apply to any application regardless the application = message this report is received within. > =20 > =20 > =20 > I tend to prefer option A, but let me know your opinions and = preferences. > Best regards > /MCruz > =20 > =20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From lionel.morand@orange.com Tue Dec 3 15:50:25 2013 Return-Path: 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 A9EAB1AE1E7 for ; Tue, 3 Dec 2013 15:50:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 gspiuv_BfLR6 for ; Tue, 3 Dec 2013 15:50:20 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by ietfa.amsl.com (Postfix) with ESMTP id 25D071AE1E6 for ; Tue, 3 Dec 2013 15:50:20 -0800 (PST) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id 7B1243B4605; Wed, 4 Dec 2013 00:50:16 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 61C1B38403C; Wed, 4 Dec 2013 00:50:16 +0100 (CET) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0158.001; Wed, 4 Dec 2013 00:50:16 +0100 From: To: Ben Campbell Thread-Topic: [Dime] DOIC: Self-Contained OLRs Thread-Index: AQHO8HrXo7y6FFeeaEmQ38aKczpYQJpDF2XggAAGiCA= Date: Tue, 3 Dec 2013 23:50:15 +0000 Message-ID: <14257_1386114616_529E6E38_14257_8534_1_6B7134B31289DC4FAF731D844122B36E31AA09@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D90006681519BC90@DEMUMBX014.nsn-intra.net> <6390_1385631044_52970D44_6390_18593_1_6B7134B31289DC4FAF731D844122B36E30748E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BD31@DEMUMBX014.nsn-intra.net> <47383DC2-1A1B-4D1A-ADD5-9E3CE60B06C8@gmail.com> <8467_1385735507_5298A553_8467_17054_3_6B7134B31289DC4FAF731D844122B36E309D0D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <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> In-Reply-To: <17146_1386112679_529E66A7_17146_16391_1_6B7134B31289DC4FAF731D844122B36E31A900@PEXCVZYM11.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.12.3.224215 Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 23:50:25 -0000 In addition, if a totally application-independent solution to convey any ty= pe of overload report for any application, the more straightforward solutio= n would have been the definition of a new application. I think that we have to be pragmatic. A lot of meeting time and email discu= ssions have been spent on this topic since more than one year and we are ab= out to miss the deadline for a stable document that could be used as refere= nce for protocol work in 3GPP. The existing content of the draft was based = on working assumptions for a basic solution for overload agreed between key= participants on the topic and extensibility of the solution was carefully = addressed to allow further development. Of course, the discussion is still open and I can't/don't want to close it.= But it will be soon time to decide what to do with the proposed solution i= n order to let 3GPP know what to do. Regards, Lionel -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de lionel.morand@oran= ge.com Envoy=E9=A0: mercredi 4 d=E9cembre 2013 00:18 =C0=A0: Ben Campbell Cc=A0: dime@ietf.org Objet=A0: Re: [Dime] DOIC: Self-Contained OLRs Hi Ben, I may be wrong somewhere in my summary but I think that it was the result o= f the discussions and agreements reached regarding existing requirements, a= t least from 3GPP point of view, compared to possible optimizations for fut= ure optimizations not so obvious. And because the solution offers extensibility via the definition of new alg= o, new report type and addition of any new AVP in the existing Grouped OLR,= the "limitations" of the proposed solution might be removed by someone if = really required according to new requirements. Regards, Lionel -----Message d'origine----- De=A0: Ben Campbell [mailto:ben@nostrum.com]=20 Envoy=E9=A0: mardi 3 d=E9cembre 2013 23:56 =C0=A0: MORAND Lionel IMT/OLN Cc=A0: Steve Donovan; dime@ietf.org Objet=A0: Re: [Dime] DOIC: Self-Contained OLRs On Dec 2, 2013, at 10:18 AM, lionel.morand@orange.com wrote: > Hi Steve, >=20=20 > I think that is not only about few bytes in the answer. It is also about = the solution principles agreed so far: > =B7 the current need is for an OLR bound to the application in use > =B7 the OLR is received from the node targeted in the request. > =B7 the OLR is defined per application I don't think those principles have been well tested. I don't recall any di= scussion of their benefits. What benefits do you see they have over self-co= ntained OLRs? All I see from these are restrictions in the flexibility of the solution, w= ith very little in return. > So all the implicit information (application, origin-host, origin-realm) = are meaningful in this context. > And the actual solution is designed based on these assumptions. The exten= sibility of the solution will allow extra info if required in other use cas= es but it was agreed to go with a straightforward solution that will satisf= y most of us. >=20=20 > Regards, >=20=20 > Lionel >=20=20 > De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan > Envoy=E9 : lundi 2 d=E9cembre 2013 16:37 > =C0 : dime@ietf.org > Objet : Re: [Dime] DOIC: Self-Contained OLRs >=20=20 > I don't believe that Ben's proposal was to change the piggybacking assump= tion in the baseline mechanism. Ben's proposal is to design the solution i= n such a way that it is not dependent on the piggybacking transport mechani= sm.=20=20 >=20 > I share Ben's concern that we have over optimized the content of the over= load report in a way that makes implementations brittle, interoperability m= ore difficult to achieve and extensibility more complex. And what do we ga= in from this optimization? A few bites in answer messages. >=20 > Self contained overload reports, transported using the piggybacking mecha= nism, is a cleaner solution. >=20 > Steve >=20 > On 11/29/13 8:31 AM, lionel.morand@orange.com wrote: > I totally agree with Nirav. No need to revert at this stage the working a= ssumption on piggybacking of OLR in application answer messages, especially= when the aim is to define a basic mechanism called "reduction". >=20=20 > Anyone would be able to further add extra info for optimization if needed= but there is no need at all for the basic mechanism. >=20=20 > Regards, >=20=20 > Lionel >=20=20 > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot (nsalo= t) > Envoy=E9 : vendredi 29 novembre 2013 12:24 > =C0 : Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list > Cc : Ben Campbell > Objet : Re: [Dime] DOIC: Self-Contained OLRs >=20=20 > Jouni, Ben, >=20=20 > I am totally against the idea of self-contained OC-OLR specifically since= we have adopted the principles of piggybacking the OC-OLR over existing ap= plication message. > Self-contained OC-OLR - which means adding all the information which defi= nes the scope of the OC-OLR into the OC-OLR - does not make sense in the pi= ggybacking approach. In fact, it is adding lot of information, which is any= way available within the message containing the OC-OLR, into the OC-OLR. So= it is adding lot of redundant information in a message which increases the= processing requirement for the sender as well as the receiver. (And this i= s un-optimization, in my view). >=20=20 > Besides, I am not convinced with the other reasons provided here: > - One software module within a node can provide OC-OLR to another softwar= e module in the same node without passing other related info > Within a node, based on the design, lots of information may need to be= passed between two software modules and we cannot optimize those aspects b= y replicating unnecessary information in a protocol message. > In summary, it is node's internal software design issue and we need no= t optimize that at protocol level. >=20=20 > - Once the reporting node realizes that it is overloaded, it has to wait = for right answer to send OC-OLR > What is the point of sending OC-OLR for a context for which there is no= messaging? Why should the reacting node care if it never sends a message f= or a context for which the reporting node is overloaded? > So this waiting is justified since it ensures that the overload is repo= rted only when necessary and only to the applicable reacting node. Not to a= ll the nodes in the network. >=20=20 > - The agent needs to wait for the answer generated by the server and the = right context > The same argument as applicable for the server applies here. The agent= need not send out-of-context overload info to a node. > Why should reacting node receive/process/store the overload info for t= he scope for which it is not sending any messages. >=20=20 > - For sending OC-OLR in dedicated Diameter application??? > Piggybacking was the first basic principle we agreed before putting oth= er principles in place. So we may want to go back the drawing board if we d= ecide to change this principle. >=20=20 > Regards, > Nirav. >=20=20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen > Sent: Friday, November 29, 2013 2:50 PM > To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list > Cc: Ben Campbell > Subject: Re: [Dime] DOIC: Self-Contained OLRs >=20=20 >=20=20 >=20=20 > So, are we reaching any level of consensus here? >=20=20 > - JOuni >=20=20 > (as a note.. that we are converging back to where we started with OLRs ;) >=20=20 >=20=20 >=20=20 > On Nov 28, 2013, at 12:40 PM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: >=20=20 > Hi, >=20=20 > another question: >=20=20 > If we go for explicit self contained OLRs, why would we then need the Rep= ortType? >=20=20 > The realm-type OLR would explicitly contain application-Id, Realm, but no= Host whereas the host-type OLR would explicitly contain application-Id, Ho= st, but probably (I'm not sure) no Realm. >=20=20 > Ulrich >=20=20 >=20=20 >=20=20 > -----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 >=20=20 > Hi, >=20=20 > There is no assumption on which entity is providing the realm overload st= atus. 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 s= ome 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 ser= ver itself, one for the realm for new request sent to the realm with only D= est-Realm AVP. >=20=20 > Lionel >=20=20 > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich=20 > (NSN - DE/Munich) Envoy=E9 : jeudi 28 novembre 2013 10:26 =C0 : ext Jouni= =20 > Korhonen; Ben Campbell Cc : dime@ietf.org list Objet : Re: [Dime]=20 > DOIC: Self-Contained OLRs >=20=20 > Hi, >=20=20 > 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 i= ndicates 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 indicate= s to the reacting end point that the reporting end point is a server. How c= an the reporting end point be both agent and server? >=20=20 > Ulrich >=20=20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Jouni=20 > Korhonen > Sent: Wednesday, November 27, 2013 11:44 PM > To: Ben Campbell > Cc: dime@ietf.org list > Subject: Re: [Dime] DOIC: Self-Contained OLRs >=20=20 >=20=20 > On Nov 28, 2013, at 12:27 AM, Ben Campbell wrote: >=20=20 > Hi, >=20=20 > I mentioned in another thread that I prefer putting an explicit=20 > ReportType AVP in an OLR, rather than >=20=20 > The more I spent time thinking/writing the actual procedures on the=20 > endpoints, the more it makes sense to me to keep the ReportType in the=20 > OC-OLR. Even if the baseline does not have agent overload etc, the=20 > ReportType fits well to the "endpoint principle" we have in the draft.=20 > It indeed gives more tools to make a host vs. realm base decision on the = reacting node and is plain more clear. >=20=20 > I skip the rest of the mail.. too much text ;-) >=20=20 >=20=20 > - Jouni >=20=20 >=20=20 >=20=20 >=20=20 >=20=20 > making a responding node infer the type or meaning of the OLR from a Diam= eter request that corresponds to the answer containing the OLR. My reasons = for that go beyond just ReportType, so I'm starting a separate thread. >=20=20 > As currently described, a consumer of an OLR must infer several things fr= om other context. In most cases, that context is in the Diameter answer tha= t carries the OLR. For example, the OLR implicitly refers to the applicatio= n 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 meani= ng in the context of the enclosing answer. If you moved an OLR from one ans= wer to another, it's meaning may change completely. >=20=20 > I think this approach is a mistake. I would greatly prefer that we explic= itly include such values in the OLR itself, for multiple reasons: >=20=20 > 1) It's more complex to interpret implicit, contextual values than explic= it values. The consumer cannot simply look at the OLR; it must look in vari= ous other AVPs to find all the information it needs. For example, I think a= common software design for overload control processing to be separated fro= m application processing. The consumer cannot simply hand the OLR to that m= odule 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 "con= text" avps that must be interpreted can grow large. This approach is error = prone, and will likely encourage brittle, hard-to-maintain code. Self-conta= ined OLRs would keep all the information related to overload in one place. = making for simpler implementations. >=20=20 > 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 r= eporting node realizes that it is overloade, it has to wait for the right a= nswer that contains the right context before it can send the OLR. This is p= articularly troublesome for agents, since they will typically have to inser= t OLRs into answers created by other nodes.=20 >=20=20 > If the reporting node screws this up, the meaning of the OLR may change s= ignificantly. So again, implicit meaning gives us error prone implementatio= ns. Self-contained OLRs are simpler to create and send. >=20=20 > 3) Implicit values don't work at all for certain problems. For=20 > example, if an agent needs to originate an OLR, it typically needs to=20 > insert that OLR into an existing Diameter answer created by a server.=20 > It can't create its own answer without affecting the application=20 > state. If the responding node assumes the OLR comes from or refers to=20 > the node identified by the Origin-Host AVP in the enclosing answer,=20 > things break. (For examples of when an agent needs to send OLRs that=20 > are distinct from those sent by a server, see Steve's agent overload=20 > draft, or my dh/dr example.) >=20=20 > OTOH, explicit values will work for all cases where we need to associate = some arbitrary value with an OLR. >=20=20 > 4) Implicit values seriously constrain the future evolution of Diameter O= C standards. For example, lets say we find a good reason to allow OLRs to b= e sent out of band, or be sent in a dedicated Diameter application. If over= load 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 transpo= rted, this won't work. We would have to create a new or significantly modif= ied OLR format if we found a need to transport OLRs in different ways. Self= -contained OLRs would allow much greater flexibility. >=20=20 > So, in summary, I think that self-contained OLRs would lead to simpler im= plementations, less brittle deployments, and more flexibility for future ev= olution of standards. >=20=20 > Thanks! >=20=20 > Ben. > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime >=20=20 > _______________________________________________ > 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 >=20=20 > ______________________________________________________________________ > ___________________________________________________ >=20=20 > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci. >=20=20 > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not be d= istributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20=20 >=20=20 > _______________________________________________ > 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 >=20=20 > _________________________________________________________________________= ________________________________________________ >=20=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu 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 o= u falsifie. Merci. >=20=20 > This message and its attachments may contain confidential or privileged i= nformation 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 de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime >=20=20 >=20=20 > _________________________________________________________________________= ________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu 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 o= u falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged i= nformation 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 de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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 confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. From ulrich.wiehe@nsn.com Wed Dec 4 00:23:34 2013 Return-Path: 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 683791AE0C9 for ; Wed, 4 Dec 2013 00:23:34 -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 rVmluvg4QmhN for ; Wed, 4 Dec 2013 00:23:27 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 0F3FF1AE086 for ; Wed, 4 Dec 2013 00:23:25 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rB48NKGO014602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 4 Dec 2013 09:23:20 +0100 Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rB48NJNS026266 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Dec 2013 09:23:19 +0100 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.152]) by DEMUHTC004.nsn-intra.net ([10.159.42.35]) with mapi id 14.03.0123.003; Wed, 4 Dec 2013 09:23:18 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: ext Ben Campbell Thread-Topic: [Dime] DOIC: Self-Contained OLRs Thread-Index: AQHO67/t2PaAGa/GgUyaCwjRxXVUh5o5m/0AgAC8o/D///ghgIAAFu+wgAGHVQCAACqasIAAMwWAgANxipCAAKJuAIAATHjQgAAM5ICAABPPEIAAFwqAgAAGBICAAAUigIAAJC3wgAEbsUCAAAYOAIAAGIwQ///0igCAAEGG8IAAESYAgAARq0CAAGUiAIAAraWg Date: Wed, 4 Dec 2013 08:23:18 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519D57E@DEMUMBX014.nsn-intra.net> References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> , <5BCBA1FC2B7F0B4C9D935572D90006681519C087@DEMUMBX014.nsn-intra.net> <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> In-Reply-To: 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: 33434 X-purgate-ID: 151667::1386145401-00006154-A5C2BF62/0-0/0-0 Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 08:23:34 -0000 Ben, No. One OLR per answer (if no extension is supported). What is an ambiguous OLR? What should the client do when receiving 5 OLRs in one answer three of whic= h are ambiguous? Let's try to avoid complexity. Ulrich=20 -----Original Message----- From: ext Ben Campbell [mailto:ben@nostrum.com]=20 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) wrote: > Steve, > =20 > 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 ex= tension (like agent overload) must not be forced to process more than one O= LR per answer. > =20 Can we restate the "not forced to process" to say "not be forced to choose = between ambiguous" OLRs? > Ulrich > =20 > 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 > =20 > I am strongly against saying that there can never be more than one overlo= ad report in a message. This makes it impossible to extend the base protoc= ol to support agent overload. >=20 > It also makes it more difficult to achieve the more granular differentiat= ed overload report types that Nirav is suggesting. >=20 > Steve >=20 > On 12/3/13 7:52 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: > Hi Lionel, > =20 > 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 proce= ss all received OLRs. > =20 > Best regards > Ulrich > =20 > -----Original Message----- > From: ext lionel.morand@orange.com [mailto:lionel.morand@orange.com]=20 > 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 > =20 > Hi Ulrich, > =20 > I don't see the complexity if each OLR instance received is clearly disti= nguished by the Report-Type.=20 > Again, it is not said that it will be mandated for any deployment to rely= on multiple OLR instances.=20 > =20 > Regards, > =20 > Lionel > =20 > -----Message d'origine----- > De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 > Envoy=E9 : mardi 3 d=E9cembre 2013 11:46 > =C0 : MORAND Lionel IMT/OLN; ext Maria Cruz Bartolome; dime@ietf.org list > Objet : RE: [Dime] DOIC: Self-Contained OLRs > =20 > Hi Lionel, > =20 > my point is simple: > =20 > 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 th= em. > Clients must not be forced to process additional OLRs. > =20 > Ulrich=20 > =20 > -----Original Message----- > From: ext lionel.morand@orange.com [mailto:lionel.morand@orange.com]=20 > 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 > =20 > Hi Ulrich, > =20 > Honestly, I don't get your point. > It could be done as you've described below and there is no reason to proh= ibit this way of doing. The consequence for the client is that it will neve= r receive more than one OLR. I think it was never mandated that an agent MU= ST insert a realm-based OLR. > But there is no reason to prohibit the presence of both OLRs in the same = answer. > =20 > Regards, > =20 > Lionel=20 > =20 > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN= - DE/Munich) > Envoy=E9 : mardi 3 d=E9cembre 2013 10:21 > =C0 : ext Maria Cruz Bartolome; dime@ietf.org list > Objet : Re: [Dime] DOIC: Self-Contained OLRs > =20 > Dear MCruz, > thank you for your support. > =20 > 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 re= turns a host-type OLR to C (via A) and there is no need for A to insert a r= ealm-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 Destin= ation Host in which case any realm-type OLR inserted by A would be useless = to C.=20 > =20 > 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 reques= t. S then returns a host-type OLR to A, and A replaces the host-type OLR re= ceived from S with a realm-type OLR. There is no need that the host-type OL= R 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 Destinatio= n Host in which case any host-type OLR conveyed to C would be useless to C. > =20 > In any case there is no need for more than one OLR in an answer. > =20 > Ulrich > =20 > =20 > =20 > =20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Bar= tolome > Sent: Monday, December 02, 2013 4:55 PM > To: dime@ietf.org list > Subject: Re: [Dime] DOIC: Self-Contained OLRs > =20 > Dear all, > =20 > My interpretation is as well in line to what is summarized by Lionel belo= w. > =20 > For a request towards a realm (without Destination Host), in case there i= s 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, an= d 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 t= o a realm (with no destination host), it will get back fresh information on= the realm overload status in the corresponding answer, if required. > =20 > Best regards > /MCruz > =20 > -----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 > =20 > =20 > My understanding (and current editing) has already been towards what Lion= el said below. > =20 > - Jouni > =20 > =20 > On Dec 2, 2013, at 4:19 PM, lionel.morand@orange.com wrote: > =20 > I agree with last part. It was the reason I've reconsidered my position o= n the need for the Report-Type. > =20 > 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 De= stination-Host is not in the answer. So receiving a host-based OLR in respo= nse 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 pos= itive 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" of= fered 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 th= e client could include a destination-host or not. So the client needs to kn= ow which reduction to apply from a previous answer. > =20 > 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 co= ntext based on the type of request. > =20 > Regards, > =20 > Lionel > =20 > =20 > De : Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Envoy=E9 : lundi 2=20 > d=E9cembre 2013 14:58 =C0 : Wiehe, Ulrich (NSN - DE/Munich) Cc :=20 > dime@ietf.org list; ext Jouni Korhonen; MORAND Lionel IMT/OLN; Ben=20 > Campbell Objet : RE: [Dime] DOIC: Self-Contained OLRs > =20 > Ulrich, > =20 > 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? > =20 > I would prefer to derive the context of the OLR based on the message whic= h contains the OLR. > =20 > Back to the topic of this thread, I don't think we need to define an "opt= ional" optimization at this stage. Either it is respected by all the nodes = supporting the solution or we drop that optimization. > =20 > Regards, > Nirav. > =20 > On Dec 2, 2013 5:27 PM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: > Nirav, > =20 > If the reacting node sends a request without Destination Host, a realm-ty= pe OLR in the answer would be in-context whereas a host-type OLR in the ans= wer would be out of context. > =20 > Similarly, if the reacting node sends a request containing Destination Ho= st, a realm-type OLR in the answer would be out-of-context and a host-type = OLR in the answer would be in-context. > =20 > Ulrich > =20 > =20 > =20 > -----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=20 > Jouni Korhonen; Ben Campbell > Cc: dime@ietf.org list > Subject: RE: [Dime] DOIC: Self-Contained OLRs > =20 > Ulrich, > =20 > I have a basic question. > =20 > When the reacting node sends realm-routed request and it receives (only o= ne) OLR in the response message (which also contains the origin-host), is t= his OLR applicable for realm or host? > I am trying to understand which is out-of-context OLR here: realm-type or= host-type? > =20 > Regards, > Nirav. > =20 > -----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=20 > Korhonen; Ben Campbell > Cc: dime@ietf.org list > Subject: RE: [Dime] DOIC: Self-Contained OLRs > =20 > Hi Nirav, > =20 > please see inline. > =20 > Regards > Ulrich > =20 > -----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=20 > Jouni Korhonen; Ben Campbell > Cc: dime@ietf.org list > Subject: RE: [Dime] DOIC: Self-Contained OLRs > =20 > Ulrich, > =20 > When the client sends request containing destination-realm (and not conta= ining 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 thi= s response message is not out-of-context information.=20 > [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= =3Dx1, destination realm =3Dx2 application=3D 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, w= hat the type x was. E.g. it deduces from the value of Origin Realm in the a= nswer the value of Destination Realm in the request; it deduces from the va= lue of Report-Type in the answer whether Destination Host was present in th= e request... > =20 > On the other hand, we discussed - as part of Maria Cruz's alternative sol= ution - to define the response message's context based on the request messa= ge. And hence if the request message was sent to destination-realm, the cor= responding 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 unneces= sary complexity.=20 > [Wiehe, Ulrich (NSN - DE/Munich)] I agree. This means: the report-type AV= P is needed to let the client deduce from information received in the answe= r whether the request contained a destination host. It does not mean that w= e need two OLRs in one answer. > =20 > If we strictly want to ensure that the realm-type OLR is not sent=20 > out-of-context [Wiehe, Ulrich (NSN - DE/Munich)] That was not my=20 > proposal. My proposal was to clearly mark out-of-context OLRs in=20 > answer messages (if we allow including out-of-context OLRs) > =20 > , then we should agree to Lionel's alternative solution - to send realm-t= ype OLR only when the destination-realm based request is rejected. So basic= ally, 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 ensu= re the context of the response message and the OLR it contains). > =20 > 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 on= e 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=20 > (NSN - DE/Munich)] only the out-of-context one > =20 > , then what is the point of including two OLRs [Wiehe, Ulrich (NSN - DE/M= unich)] 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 a= s 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 react= ing node (if the reacting node wants to make use of this optimization). > =20 > and what is the point of defining Report-Type AVP? > [Wiehe, Ulrich (NSN - DE/Munich)] to let the reacting node deduce from in= formation received in the answer whether the corresponding request containe= d a destination host (so there is no need to remember). > =20 > =20 > In summary, if we define Report-Type AVP and corresponding handling at th= e reacting node, the reacting node must act accordingly and not ignore it. > [Wiehe, Ulrich (NSN - DE/Munich)] What goes wrong when out-of -context O= LR is ignored? > =20 > 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 i= gnored. > [Wiehe, Ulrich (NSN - DE/Munich)] Not the Report-Type AVP is the optimiza= tion but the incusion of out-of-context OLRs. And I'm ok not to proceed wit= h this optimization as it is not needed. > =20 > Regards, > Nirav. > =20 > -----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=20 > Korhonen; Ben Campbell > Cc: dime@ietf.org list > Subject: RE: [Dime] DOIC: Self-Contained OLRs > =20 > Hi Nirav, > =20 > 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-contex= t. > There is nothing wrong with storing such out-of-context OLRs at the clien= t, but it is simply not needed as the client will learn this OLR from respo= nses received within the context. > =20 > Best regards > Ulrich > =20 > =20 > -----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=20 > Jouni Korhonen; Ben Campbell > Cc: dime@ietf.org list > Subject: RE: [Dime] DOIC: Self-Contained OLRs > =20 > Hi Ulrich, > =20 > If an additional OLR is present with a different ReportType, why it shoul= d be ignored by the reacting node? > =20 > Regards, > Nirav. > =20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich=20 > (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 > =20 > Hi Lionel, > =20 > there is nothing missing exept the clarification that everything works fi= ne 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. > =20 > Ulrich > =20 > =20 > -----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 > =20 > Hi Ulrich, > =20 > Using the Report Type "host report", you know that the OLR applies for su= bsequent 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.=20 > =20 > It is not so important to know what the type of request was and which nod= e 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, f= or instance, future development could allow a distributed server architectu= re to provide the same information. > =20 > I'm not sure of what is missing in this reasoning... > =20 > Lionel > =20 > -----Message d'origine----- > De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 > Envoy=E9 : jeudi 28 novembre 2013 11:30 =C0 : MORAND Lionel IMT/OLN; ext= =20 > Jouni Korhonen; Ben Campbell Cc : dime@ietf.org list Objet : RE:=20 > [Dime] DOIC: Self-Contained OLRs > =20 > Lionel, > =20 > my understanding was that _the_ reporting end point provides _the_ OLR. > =20 > If we go for two OLRs in the answer we should indicate which OLR is the a= ctual OLR created by the reporting end point and which OLR is an additional= OLR created by another node. > =20 > We have two cases: > a) The request sent by the client (reacting end point) contains no Destin= ation 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 OL= R as learned from the selected server. The client may ignore the additiona= l OLR. > b) The request sent by the client (reacting endpoint) contains the Destin= ation Host. The Server (reporting node) returns a host-type OLR as the actu= al reporting-node-created OLR in the answer. The agent may optionally inser= t a realm-type OLR as additional OLR to the answer. The client may ignore t= he additional OLR. > =20 > Ulrich > =20 > =20 > =20 > -----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 > =20 > Hi, > =20 > There is no assumption on which entity is providing the realm overload st= atus. 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 s= ome 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 ser= ver itself, one for the realm for new request sent to the realm with only D= est-Realm AVP. > =20 > Lionel > =20 > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich=20 > (NSN - DE/Munich) Envoy=E9 : jeudi 28 novembre 2013 10:26 =C0 : ext Jouni= =20 > Korhonen; Ben Campbell Cc : dime@ietf.org list Objet : Re: [Dime]=20 > DOIC: Self-Contained OLRs > =20 > Hi, > =20 > 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 i= ndicates 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 indicate= s to the reacting end point that the reporting end point is a server. How c= an the reporting end point be both agent and server? > =20 > Ulrich > =20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Jouni=20 > Korhonen > Sent: Wednesday, November 27, 2013 11:44 PM > To: Ben Campbell > Cc: dime@ietf.org list > Subject: Re: [Dime] DOIC: Self-Contained OLRs > =20 > =20 > On Nov 28, 2013, at 12:27 AM, Ben Campbell wrote: > =20 > Hi, > =20 > I mentioned in another thread that I prefer putting an explicit=20 > ReportType AVP in an OLR, rather than > =20 > The more I spent time thinking/writing the actual procedures on the endpo= ints, the more it makes sense to me to keep the ReportType in the OC-OLR. E= ven if the baseline does not have agent overload etc, the ReportType fits w= ell 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 pl= ain more clear. > =20 > I skip the rest of the mail.. too much text ;-) > =20 > =20 > - Jouni > =20 > =20 > =20 > =20 > =20 > making a responding node infer the type or meaning of the OLR from a Diam= eter request that corresponds to the answer containing the OLR. My reasons = for that go beyond just ReportType, so I'm starting a separate thread. > =20 > As currently described, a consumer of an OLR must infer several things fr= om other context. In most cases, that context is in the Diameter answer tha= t carries the OLR. For example, the OLR implicitly refers to the applicatio= n 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 meani= ng in the context of the enclosing answer. If you moved an OLR from one ans= wer to another, it's meaning may change completely. > =20 > I think this approach is a mistake. I would greatly prefer that we explic= itly include such values in the OLR itself, for multiple reasons: > =20 > 1) It's more complex to interpret implicit, contextual values than explic= it values. The consumer cannot simply look at the OLR; it must look in vari= ous other AVPs to find all the information it needs. For example, I think a= common software design for overload control processing to be separated fro= m application processing. The consumer cannot simply hand the OLR to that m= odule 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 "con= text" avps that must be interpreted can grow large. This approach is error = prone, and will likely encourage brittle, hard-to-maintain code. Self-conta= ined OLRs would keep all the information related to overload in one place. = making for simpler implementations. > =20 > 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 r= eporting node realizes that it is overloade, it has to wait for the right a= nswer that contains the right context before it can send the OLR. This is p= articularly troublesome for agents, since they will typically have to inser= t OLRs into answers created by other nodes.=20 > =20 > If the reporting node screws this up, the meaning of the OLR may change s= ignificantly. So again, implicit meaning gives us error prone implementatio= ns. Self-contained OLRs are simpler to create and send. > =20 > 3) Implicit values don't work at all for certain problems. For=20 > example, if an agent needs to originate an OLR, it typically needs=20 > to insert that OLR into an existing Diameter answer created by a server. > It can't create its own answer without affecting the application=20 > state. If the responding node assumes the OLR comes from or refers=20 > to the node identified by the Origin-Host AVP in the enclosing=20 > answer, things break. (For examples of when an agent needs to send=20 > OLRs that are distinct from those sent by a server, see Steve's=20 > agent overload draft, or my dh/dr example.) > =20 > OTOH, explicit values will work for all cases where we need to associate = some arbitrary value with an OLR. > =20 > 4) Implicit values seriously constrain the future evolution of Diameter O= C standards. For example, lets say we find a good reason to allow OLRs to b= e sent out of band, or be sent in a dedicated Diameter application. If over= load 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 transpo= rted, this won't work. We would have to create a new or significantly modif= ied OLR format if we found a need to transport OLRs in different ways. Self= -contained OLRs would allow much greater flexibility. > =20 > So, in summary, I think that self-contained OLRs would lead to simpler im= plementations, less brittle deployments, and more flexibility for future ev= olution of standards. > =20 > Thanks! > =20 > Ben. > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > =20 > _______________________________________________ > 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 > =20 > ______________________________________________________________________ > ___________________________________________________ > =20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc pas etre diffuses, exploites o= u copies sans autorisation. Si vous avez recu ce message par erreur, veuill= ez 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= . > =20 > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; they should not be distributed, us= ed or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > =20 > =20 > ______________________________________________________________________ > ___________________________________________________ > =20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc pas etre diffuses, exploites o= u copies sans autorisation. Si vous avez recu ce message par erreur, veuill= ez 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= . > =20 > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; they should not be distributed, us= ed or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > =20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > ______________________________________________________________________ > ___________________________________________________ > =20 > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci. > =20 > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not be d= istributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > =20 > =20 > _______________________________________________ > 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 > =20 > _________________________________________________________________________= ________________________________________________ > =20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu 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 o= u falsifie. Merci. > =20 > This message and its attachments may contain confidential or privileged i= nformation 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 de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > =20 > =20 > _________________________________________________________________________= ________________________________________________ > =20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu 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 o= u falsifie. Merci. > =20 > This message and its attachments may contain confidential or privileged i= nformation 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 de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > =20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > =20 > =20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From ulrich.wiehe@nsn.com Wed Dec 4 00:40:43 2013 Return-Path: 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 70FFB1AE098 for ; Wed, 4 Dec 2013 00:40:43 -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 88sclyvfdrYn for ; Wed, 4 Dec 2013 00:40:39 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id E92321AE089 for ; Wed, 4 Dec 2013 00:40:38 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rB48eYLY025741 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 4 Dec 2013 09:40:34 +0100 Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rB48eWvl009105 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Dec 2013 09:40:33 +0100 Received: from DEMUHTC013.nsn-intra.net (10.159.42.44) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 4 Dec 2013 09:40:32 +0100 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.152]) by DEMUHTC013.nsn-intra.net ([10.159.42.44]) with mapi id 14.03.0123.003; Wed, 4 Dec 2013 09:40:32 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: ext Ben Campbell , Steve Donovan Thread-Topic: [Dime] DOIC: Self-Contained OLRs Thread-Index: AQHO67/t2PaAGa/GgUyaCwjRxXVUh5o5m/0AgAC8o/D///ghgIAAFu+wgAGHVQCAACqasIAAMwWAgANxipCAA2E2ooAAnXQA Date: Wed, 4 Dec 2013 08:40:31 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519D59C@DEMUMBX014.nsn-intra.net> References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D90006681519BC90@DEMUMBX014.nsn-intra.net> <6390_1385631044_52970D44_6390_18593_1_6B7134B31289DC4FAF731D844122B36E30748E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BD19@DEMUMBX014.nsn-intra.net> <17872_1385720008_529868C8_17872_2613_1_6B7134B31289DC4FAF731D844122B36E3096B8@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BF1B@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681519BFAE@DEMUMBX014.nsn-intra.net> <529CA616.2040205@usdonovans.com> In-Reply-To: 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: 16020 X-purgate-ID: 151667::1386146434-00006154-D0CEC740/0-0/0-0 Cc: "dime@ietf.org list" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 08:40:43 -0000 Ben, we have this feature negotiation/adverisement mechanism that allows the rep= orting endpoint to understand what is supported by the reacting endpoint. T= he reporting endpoint should not send in OLRs not supported by the reacting= node. Ulrich -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Ben Campbell Sent: Wednesday, December 04, 2013 12:00 AM To: Steve Donovan Cc: dime@ietf.org list Subject: Re: [Dime] DOIC: Self-Contained OLRs On Dec 2, 2013, at 9:24 AM, Steve Donovan wrote: > Ulrich, >=20 > Designing an overload solution that allows a reacting node to ignore an o= verload report seems strange to me. The system is under stress. Overload = reports should be reacted to as quickly as possible, independent of how the= overload report is received by the reacting node. >=20 While I don't agree with the "out-of-context" concern, I can see saying tha= t a reacting node ignore an OLR if it does not understand the ReportType. O= therwise, it doesn't understand the meaning of the report, and is likely to= do the wrong thing. An alternative might be to say the reacting node shou= ld treat anything it doesn't understand as "Realm". > Steve >=20 > On 12/1/13 1:38 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >> Hi Nirav, >>=20 >> 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, thi= s OLR is out-of-context. >> Similary, when the client sends a request containing destination host an= d gets back an answer containing a realm-type OLR, this OLR is out-of-conte= xt. >> There is nothing wrong with storing such out-of-context OLRs at the clie= nt, but it is simply not needed as the client will learn this OLR from resp= onses received within the context. >>=20 >> Best regards >> Ulrich=20 >>=20 >>=20 >> -----Original Message----- >> From: ext Nirav Salot (nsalot) [ >> mailto:nsalot@cisco.com >> ]=20 >> Sent: Friday, November 29, 2013 4:49 PM >> To: Wiehe, Ulrich (NSN - DE/Munich); ext=20 >> lionel.morand@orange.com >> ; ext Jouni Korhonen; Ben Campbell >> Cc:=20 >> dime@ietf.org >> list >> Subject: RE: [Dime] DOIC: Self-Contained OLRs >>=20 >> Hi Ulrich, >>=20 >> If an additional OLR is present with a different ReportType, why it shou= ld be ignored by the reacting node? >>=20 >> Regards, >> Nirav. >>=20 >> -----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=20 >> lionel.morand@orange.com >> ; ext Jouni Korhonen; Ben Campbell >> Cc:=20 >> dime@ietf.org >> list >> Subject: Re: [Dime] DOIC: Self-Contained OLRs >>=20 >> Hi Lionel, >>=20 >> there is nothing missing exept the clarification that everything works f= ine when only one OLR (the OLR created by the reporting endpoint) is presen= t in the answer and additional OLRs (not created by the reporting endpoint)= may just be present as an optional optimization i.e. optionally inserted b= y the reporting endpoint and optionally ignored by the reacting endpoint. >>=20 >> Ulrich >> =20 >>=20 >> -----Original Message----- >> From: ext=20 >> 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:=20 >> dime@ietf.org >> list >> Subject: RE: [Dime] DOIC: Self-Contained OLRs >>=20 >> Hi Ulrich, >>=20 >> Using the Report Type "host report", you know that the OLR applies for s= ubsequent 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.=20 >>=20 >> It is not so important to know what the type of request was and which no= de 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 architect= ure to provide the same information. >>=20 >> I'm not sure of what is missing in this reasoning... >>=20 >> Lionel >>=20 >> -----Message d'origine----- >> De : Wiehe, Ulrich (NSN - DE/Munich) [ >> mailto:ulrich.wiehe@nsn.com] Envoy=E9 : jeudi 28 novembre 2013 11:30 =C0= : MORAND Lionel IMT/OLN; ext Jouni Korhonen; Ben Campbell Cc : dime@ietf.o= rg >> list Objet : RE: [Dime] DOIC: Self-Contained OLRs >>=20 >> Lionel, >>=20 >> my understanding was that _the_ reporting end point provides _the_ OLR. >>=20 >> 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 additiona= l OLR created by another node. >>=20 >> We have two cases: >> a) The request sent by the client (reacting end point) contains no Desti= nation Host. The agent (reporting node) (after forwarding the request to th= e 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 O= LR as learned from the selected server. The client may ignore the addition= al OLR. >> b) The request sent by the client (reacting endpoint) contains the Desti= nation Host. The Server (reporting node) returns a host-type OLR as the act= ual reporting-node-created OLR in the answer. The agent may optionally inse= rt a realm-type OLR as additional OLR to the answer. The client may ignore = the additional OLR. >>=20 >> Ulrich >>=20 >>=20 >>=20 >> -----Original Message----- >> From: ext=20 >> 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:=20 >> dime@ietf.org >> list >> Subject: RE: [Dime] DOIC: Self-Contained OLRs >>=20 >> Hi, >>=20 >> There is no assumption on which entity is providing the realm overload s= tatus. It could be provided an agent inserting this info in answers receive= d 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 se= rver itself, one for the realm for new request sent to the realm with only = Dest-Realm AVP. >>=20 >> Lionel >>=20 >> -----Message d'origine----- >> De : DiME [ >> mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN - DE/Muni= ch) Envoy=E9 : jeudi 28 novembre 2013 10:26 =C0 : ext Jouni Korhonen; Ben C= ampbell Cc : dime@ietf.org >> list Objet : Re: [Dime] DOIC: Self-Contained OLRs >>=20 >> Hi, >>=20 >> I don't see how the possibility to send more than one OLR in an answer i= s aligned with the "endpoint principle". If the ReportType is "realm" this = indicates to the reacting end point that the reporting end point is an agen= t (e.g. SFE) rather than a server. If the ReportType is "host" this indicat= es to the reacting end point that the reporting end point is a server. How = can the reporting end point be both agent and server? >>=20 >> Ulrich >>=20 >> -----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:=20 >> dime@ietf.org >> list >> Subject: Re: [Dime] DOIC: Self-Contained OLRs >>=20 >>=20 >> On Nov 28, 2013, at 12:27 AM, Ben Campbell=20 >> >> wrote: >>=20 >>=20 >>> Hi, >>>=20 >>> I mentioned in another thread that I prefer putting an explicit=20 >>> ReportType AVP in an OLR, rather than >>>=20 >> The more I spent time thinking/writing the actual procedures on the endp= oints, 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 p= lain more clear. >>=20 >> I skip the rest of the mail.. too much text ;-) >>=20 >>=20 >> - Jouni >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>> making a responding node infer the type or meaning of the OLR from a Di= ameter request that corresponds to the answer containing the OLR. My reason= s for that go beyond just ReportType, so I'm starting a separate thread. >>>=20 >>> 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 t= hat carries the OLR. For example, the OLR implicitly refers to the applicat= ion identified by the Application-Id field of the enclosing answer, the rea= lm 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 mea= ning in the context of the enclosing answer. If you moved an OLR from one a= nswer to another, it's meaning may change completely. >>>=20 >>> I think this approach is a mistake. I would greatly prefer that we expl= icitly include such values in the OLR itself, for multiple reasons: >>>=20 >>> 1) It's more complex to interpret implicit, contextual values than expl= icit values. The consumer cannot simply look at the OLR; it must look in va= rious other AVPs to find all the information it needs. For example, I think= a common software design for overload control processing to be separated f= rom 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 OL= R, 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 "c= ontext" avps that must be interpreted can grow large. This approach is erro= r prone, and will likely encourage brittle, hard-to-maintain code. Self-con= tained OLRs would keep all the information related to overload in one place= . making for simpler implementations. >>>=20 >>> 2) It's more complex for the reporting node to send implicit values tha= n explicit values. The sender cannot simply set the context to match the OL= R--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 ins= ert OLRs into answers created by other nodes.=20 >>>=20 >>> If the reporting node screws this up, the meaning of the OLR may change= significantly. So again, implicit meaning gives us error prone implementat= ions. Self-contained OLRs are simpler to create and send. >>>=20 >>> 3) Implicit values don't work at all for certain problems. For=20 >>> example, if an agent needs to originate an OLR, it typically needs to=20 >>> insert that OLR into an existing Diameter answer created by a server.=20 >>> It can't create its own answer without affecting the application=20 >>> state. If the responding node assumes the OLR comes from or refers to=20 >>> the node identified by the Origin-Host AVP in the enclosing answer,=20 >>> things break. (For examples of when an agent needs to send OLRs that=20 >>> are distinct from those sent by a server, see Steve's agent overload=20 >>> draft, or my dh/dr example.) >>>=20 >>> OTOH, explicit values will work for all cases where we need to associat= e some arbitrary value with an OLR. >>>=20 >>> 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 ov= erload 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 trans= ported, this won't work. We would have to create a new or significantly mod= ified OLR format if we found a need to transport OLRs in different ways. Se= lf-contained OLRs would allow much greater flexibility. >>>=20 >>> 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. >>>=20 >>> Thanks! >>>=20 >>> Ben. >>> _______________________________________________ >>> DiME mailing list >>>=20 >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >> _______________________________________________ >> DiME mailing list >>=20 >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >>=20 >> _______________________________________________ >> DiME mailing list >>=20 >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >>=20 >>=20 >> ________________________________________________________________________= _________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations confi= dentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites = ou copies sans autorisation. Si vous avez recu ce message par erreur, veuil= lez 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. Merc= i. >>=20 >> This message and its attachments may contain confidential or privileged = information that may be protected by law; they should not be distributed, u= sed or copied without authorisation. >> If you have received this email in error, please notify the sender and d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >>=20 >>=20 >> ________________________________________________________________________= _________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations confi= dentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites = ou copies sans autorisation. Si vous avez recu ce message par erreur, veuil= lez 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. Merc= i. >>=20 >> This message and its attachments may contain confidential or privileged = information that may be protected by law; they should not be distributed, u= sed or copied without authorisation. >> If you have received this email in error, please notify the sender and d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >>=20 >> _______________________________________________ >> DiME mailing list >>=20 >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >>=20 >> _______________________________________________ >> DiME mailing list >>=20 >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >>=20 >>=20 >>=20 >=20 > _______________________________________________ > 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 From ulrich.wiehe@nsn.com Wed Dec 4 02:00:31 2013 Return-Path: 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 260EA1AE21C for ; Wed, 4 Dec 2013 02:00:31 -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 MbzSwNDTtz45 for ; Wed, 4 Dec 2013 02:00:29 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id B47101AE047 for ; Wed, 4 Dec 2013 02:00:28 -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 rB4A0NUS014547 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 4 Dec 2013 11:00:24 +0100 Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rB4A0NSd030127 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Dec 2013 11:00:23 +0100 Received: from DEMUHTC012.nsn-intra.net (10.159.42.43) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 4 Dec 2013 11:00:22 +0100 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.152]) by DEMUHTC012.nsn-intra.net ([10.159.42.43]) with mapi id 14.03.0123.003; Wed, 4 Dec 2013 11:00:22 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: ext Ben Campbell Thread-Topic: [Dime] endpoint determination Thread-Index: Ac7sNGlk8/aQM1p4QPOTYH1OvkMS+gENDhIAABmkvQA= Date: Wed, 4 Dec 2013 10:00:22 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519D603@DEMUMBX014.nsn-intra.net> References: <5BCBA1FC2B7F0B4C9D935572D90006681519BD77@DEMUMBX014.nsn-intra.net> In-Reply-To: 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="us-ascii" 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: 3560 X-purgate-ID: 151667::1386151224-00006154-04201736/0-0/0-0 Cc: "dime@ietf.org" Subject: Re: [Dime] endpoint determination X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 10:00:31 -0000 Ben, please see inline. Ulrich -----Original Message----- From: ext Ben Campbell [mailto:ben@nostrum.com]=20 Sent: Tuesday, December 03, 2013 10:46 PM To: Wiehe, Ulrich (NSN - DE/Munich) Cc: dime@ietf.org Subject: Re: [Dime] endpoint determination On Nov 28, 2013, at 6:21 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: > Hi, >=20 > draft-ietf-dime-ovli-00 in Clause 5.1 says: >=20 > How the endpoints are determined is specific to a deployment, a Diameter = node role in that deployment and local configuration. >=20 >=20 > In order to better address REQ 6 of RFC 7068 I would like to propose som= e principles that should be taken into account: >=20 > 1. A client that supports the Diameter Overload Control Mechanism must (o= ffer to) take the role of a reacting endpoint and hence includes the OC-Fea= ture-Vector AVP when sending requests. > 2. An Agent that - based on local configuration - takes the role of a rep= orting endpoint (towards the downstream reacting endpoint) must also (offer= to) take the role of a reacting endpoint towards the server and hence repl= ace the received OC-Feature-Vector AVP with its own OC-Featur-Vector AVP. I agree with the concepts in 1 and 2, but not as written (assuming you inte= nd the use of must to be normative.) I think this is better written in term= s of a definition of what reporting node and reacting node means, then ment= ion that a supporting client is normally a reacting node, a supporting serv= er is normally a reporting node, and an agent can be both. > 3. An agent that supports the Diameter Overload Control Mechanism and tha= t - based on absence of local configuration - does not take the role of a r= eporting endpoint must be able to detect whether a downstream agent or clie= nt already takes the role of the reacting endpoint (e.g. by checking the p= resence of an OC-Feature-Vector AVP in the received request). If it detects= that no downstream node took the role of the reacting endpoint, the agent= must take the role of the reacting endpoint and hence insert an OC-Feature= AVP to the request. I.e. determination of the reporting endpoint is done d= ynamically and does not rely on local configuration. I read that to mean you expect an agent to "take over" as the reacting node= even if the administrator has completely turned off OC? If so, I don't agr= ee, at least not as a normative requirement. Implementors can choose to cre= ate such a mode if they want to, but we don't need to require it. [Wiehe, Ulrich (NSN - DE/Munich)] The original intention was to say: "An ag= ent that supports DOIC must be able to detect whether a downstream agent or= client already takes the role of the reacting endpoint..." This is to cove= r the case in figure 4 (see clause 5.1) where the reacting DEP is in A inst= ead of C (A performs throttling on behalf of C towards the reporting endpoi= nt S). But then I noticed that in figure 6 the agent does not take the role= of the reacting endpoint on behalf of C2 because A already is the reportin= g endpoint (by configuration) (A performs throttling on behalf of C2 toward= s the reporting endpoint A). If the administrator turns off the reporting e= ndpoint functionality in A, then we would have a DOIC association beween C1= and S and a DOIC association between A (on behalf of C2) and S. In summary= : the agent takes over the reacting DEP functionality on behalf of the clie= nt unless the agent itself is the reporting DEP. From jouni.nospam@gmail.com Wed Dec 4 02:02:58 2013 Return-Path: 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 08EBE1AE220 for ; Wed, 4 Dec 2013 02:02:58 -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 DFI2_wIvoiHK for ; Wed, 4 Dec 2013 02:02:55 -0800 (PST) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 799EC1AE059 for ; Wed, 4 Dec 2013 02:02:55 -0800 (PST) Received: by mail-lb0-f175.google.com with SMTP id x18so9136396lbi.20 for ; Wed, 04 Dec 2013 02:02:51 -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=7hxPB99fIeAzgQwUb9nq3F8mbX6hxpBrp3Y0YQqzu8k=; b=mIXmg02mHH88d/9rSIQpUj3RdUe4Ir9hW5sGdj3oR/zEJZ6bL4ViNmf+F6yIT7U4ju xIvZLpk1hlGr0CR+XwZsxgSPH3nAQZX3EXHDeV93F1zLQiof2epf8JeEPOHIDR0VSerH EGWLuy9gKjH8i0/N89TZSdi5XUV3tU+nvxTASieuWJxuntcp3nMhyWnPPjfwYSm0kWFz bPIWd8dpmUi98S+L2ZwUCGjkTyEqtOo+YIBmovGOs1Sa6Pc0jJwOxByJhcxdrnIzLtGO F+xg13jAdsmTqDY+7Ruea9MgeWHRmjdg5zsa0paDH7HrJ2B3E0CYB98NI3p+YE47m8oP 1z2w== X-Received: by 10.112.155.106 with SMTP id vv10mr243552lbb.53.1386151371746; Wed, 04 Dec 2013 02:02:51 -0800 (PST) Received: from [192.168.250.212] ([194.100.71.98]) by mx.google.com with ESMTPSA id m5sm91415334laj.4.2013.12.04.02.02.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Dec 2013 02:02:48 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: Date: Wed, 4 Dec 2013 12:02:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5BCBA1FC2B7F0B4C9D935572D90006681519BD77@DEMUMBX014.nsn-intra.net> To: Ben Campbell X-Mailer: Apple Mail (2.1510) Cc: "dime@ietf.org" Subject: Re: [Dime] endpoint determination X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 10:02:58 -0000 On Dec 3, 2013, at 11:45 PM, Ben Campbell wrote: >=20 > On Nov 28, 2013, at 6:21 AM, Wiehe, Ulrich (NSN - DE/Munich) = wrote: >=20 >> Hi, >>=20 >> draft-ietf-dime-ovli-00 in Clause 5.1 says: >>=20 >> How the endpoints are determined is specific to a deployment, a = Diameter node role in that deployment and local configuration. >>=20 >>=20 >> In order to better address REQ 6 of RFC 7068 I would like to propose = some principles that should be taken into account: >>=20 >> 1. A client that supports the Diameter Overload Control Mechanism = must (offer to) take the role of a reacting endpoint and hence includes = the OC-Feature-Vector AVP when sending requests. >> 2. An Agent that - based on local configuration - takes the role of a = reporting endpoint (towards the downstream reacting endpoint) must also = (offer to) take the role of a reacting endpoint towards the server and = hence replace the received OC-Feature-Vector AVP with its own = OC-Featur-Vector AVP. This should already be possible according to the current spec.. > I agree with the concepts in 1 and 2, but not as written (assuming you = intend the use of must to be normative.) I think this is better written = in terms of a definition of what reporting node and reacting node means, = then mention that a supporting client is normally a reacting node, a = supporting server is normally a reporting node, and an agent can be = both. >=20 >> 3. An agent that supports the Diameter Overload Control Mechanism and = that - based on absence of local configuration - does not take the role = of a reporting endpoint must be able to detect whether a downstream = agent or client already takes the role of the reacting endpoint (e.g. = by checking the presence of an OC-Feature-Vector AVP in the received = request). If it detects that no downstream node took the role of the = reacting endpoint, the agent must take the role of the reacting = endpoint and hence=20 I do not agree the MUST here to be written into the spec. The agent is free to do the above procedure but it is an implementation & local config issue.=20 - JOuni >> insert an OC-Feature AVP to the request. I.e. determination of the = reporting endpoint is done dynamically and does not rely on local = configuration. >=20 > I read that to mean you expect an agent to "take over" as the reacting = node even if the administrator has completely turned off OC? If so, I = don't agree, at least not as a normative requirement. Implementors can = choose to create such a mode if they want to, but we don't need to = require it. >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From jouni.nospam@gmail.com Wed Dec 4 02:14:39 2013 Return-Path: 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 660751AE230 for ; Wed, 4 Dec 2013 02:14:39 -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 jHPFUxa5L650 for ; Wed, 4 Dec 2013 02:14:36 -0800 (PST) Received: from mail-bk0-x234.google.com (mail-bk0-x234.google.com [IPv6:2a00:1450:4008:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 8B1ED1AE232 for ; Wed, 4 Dec 2013 02:14:36 -0800 (PST) Received: by mail-bk0-f52.google.com with SMTP id u14so6421378bkz.25 for ; Wed, 04 Dec 2013 02:14:33 -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=lMX6rXM0n0GMVMtUfKv9R8pMzJuLjEzsE2zDixavqjE=; b=XeZpaZzoTlHWeJH2vt1LUj2QdCDqxN4gjB49VYe2/A0XEOX/AAjlIPpkuHpVyw653t TQJcSt0wUJnY8rgG4P+EXranXmyQe+JkcGStVHtBWZuc6KmNZu929ZEYxpUeGq7e6EPm QiEb5Iwf2FDun/d+2mySohAgXpnj6D8p/UMwc1NUIvhazRxIaKimgIf1vXfgkn1ahPyw M3mgwPao0Z7Xcyclnq0eIUGkpAzraTwQJhaS/icWYW0WaO7icfUAU3rf/HtYXwMQRa7+ 8D4J7+wTxAz6nUyMI69KUM7S5yuHI7bWjCY5ve2iykwkSrfYCyRXp9QEpvQwpzGsyWKC 1OdA== X-Received: by 10.205.35.204 with SMTP id sx12mr5201307bkb.49.1386152073055; Wed, 04 Dec 2013 02:14:33 -0800 (PST) Received: from ?IPv6:2001:6e8:480:60:ed07:fe0e:d711:f11c? ([2001:6e8:480:60:ed07:fe0e:d711:f11c]) by mx.google.com with ESMTPSA id on10sm81357797bkb.13.2013.12.04.02.14.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Dec 2013 02:14:30 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <960_1386111033_529E6039_960_7297_1_6B7134B31289DC4FAF731D844122B36E3196C3@PEXCVZYM11.corporate.adroot.infra.ftgroup> Date: Wed, 4 Dec 2013 12:14:32 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <26806_1386092152_529E1678_26806_2515_1_6B7134B31289DC4FAF731D844122B36E313B4B@PEXCVZYM13.corporate.adroot.infra.ftgroup> <960_1386111033_529E6039_960_7297_1_6B7134B31289DC4FAF731D844122B36E3196C3@PEXCVZYM11.corporate.adroot.infra.ftgroup> To: lionel.morand@orange.com X-Mailer: Apple Mail (2.1510) Cc: "dime@ietf.org" Subject: Re: [Dime] OVLI: Clarification on the format of the OC-Report-Type AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 10:14:39 -0000 On Dec 4, 2013, at 12:50 AM, lionel.morand@orange.com wrote: > Hi Jouni, >=20 > The setting of the M-bit will be decided per application and not by = this document. > Obviously, when reused in existing applications, it will be purely = optional. But designers may decide to include this AVP as mandatory AVP = to understand in a new application and then the issues regarding = Enumerated AVP will come back, no? Changing the enumerated to unsigned64 does not change the situation. You have the same issue still. The best thing we can do is to define the procedures when receiving a value that is not understood. We do have an error code for invalid values. So the application designer have two choices. Define the report type with M=3D0 and just ignore the AVP (+OLR) when the value is not understood or then just return DIAMETER_INVALID_AVP_VALUE when M=3D1. This is independent whether the AVP type is enumerated or something homegrown.=20 - JOuni >=20 > Lionel >=20 > -----Message d'origine----- > De : Jouni [mailto:jouni.nospam@gmail.com]=20 > Envoy=E9 : mardi 3 d=E9cembre 2013 19:15 > =C0 : MORAND Lionel IMT/OLN > Cc : dime@ietf.org > Objet : Re: [Dime] OVLI: Clarification on the format of the = OC-Report-Type AVP >=20 >=20 > On Dec 3, 2013, at 7:35 PM, = wrote: >=20 >> Hi, >>=20 >> The proposed format for OC-Report-Type AVP is Enumerated. >> This would lead to extensibility issue as discussed several times. >=20 > I know what you refer to but I think it is a non-issue since the > AVP is optional and we can define the default behavior when the > content is not understood. >=20 > - Jouni >=20 >=20 >=20 >>=20 >> I would propose to define the OC-Report-Type AVP as Unsigned64 and = create specific values. The same registry can be used to add values but = we would get rid of the problem with Enumerated AVP. >>=20 >> Comment? >>=20 >> Lionel >>=20 >> = __________________________________________________________________________= _______________________________________________ >>=20 >> 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. >>=20 >> 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. >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >=20 >=20 > = __________________________________________________________________________= _______________________________________________ >=20 > 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. >=20 > 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. >=20 From jouni.nospam@gmail.com Wed Dec 4 02:16:47 2013 Return-Path: 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 2F69C1AE0EE for ; Wed, 4 Dec 2013 02:16:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 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, FREEMAIL_REPLY=1, SPF_PASS=-0.001] autolearn=no 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 wflqRuEHy_BJ for ; Wed, 4 Dec 2013 02:16:44 -0800 (PST) Received: from mail-bk0-x232.google.com (mail-bk0-x232.google.com [IPv6:2a00:1450:4008:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2731AE237 for ; Wed, 4 Dec 2013 02:16:10 -0800 (PST) Received: by mail-bk0-f50.google.com with SMTP id e11so6518921bkh.37 for ; Wed, 04 Dec 2013 02:16:06 -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=D4hI5u1HfAWDdd1RQFuHhQ2Itv/cAsFiut482h8x+mg=; b=0NuZ9K1nb1iExIFDlWbnSFaXU5gk2LcwFQ+kmUfXut1+6Lnam2jhNeCRga3lsxurS0 trNq6Y7SiTgRDJeoecswdAXUcaAH7s+ys0e3HleuacMrWSmVpRPIwnEk3kzpEkoSRZ4C NHopwcnfW/GQD5U1Ctp9nmWuZ6wEc1fAurLDUFY2BC4WxkEUs6I9LoSxPI3nflosewGn cC/n5v+hMzwJMrvXeGjGNw6JssUTlWYUPhj6BX3tv/adOlTP6345p1ZxA4Ozil//I8RI y3STnGXPJSHALgmVc4bj6QNCjRhLk5hNrqyJRfWa7TOFoXhCWkj1kXE87Mbv/e2yASl8 SUhA== X-Received: by 10.204.102.72 with SMTP id f8mr5345704bko.44.1386152166884; Wed, 04 Dec 2013 02:16:06 -0800 (PST) Received: from ?IPv6:2001:6e8:480:60:ed07:fe0e:d711:f11c? ([2001:6e8:480:60:ed07:fe0e:d711:f11c]) by mx.google.com with ESMTPSA id qe6sm81216451bkb.5.2013.12.04.02.16.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Dec 2013 02:16:06 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <10558_1386067228_529DB51C_10558_2647_1_6B7134B31289DC4FAF731D844122B36E3129AA@PEXCVZYM13.corporate.adroot.infra.ftgroup> Date: Wed, 4 Dec 2013 12:16:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <70873A4B-C7CF-4649-AE84-B4B9A4D51FD4@gmail.com> References: <5BCBA1FC2B7F0B4C9D935572D90006681519C296@DEMUMBX014.nsn-intra.net> <10558_1386067228_529DB51C_10558_2647_1_6B7134B31289DC4FAF731D844122B36E3129AA@PEXCVZYM13.corporate.adroot.infra.ftgroup> To: lionel.morand@orange.com X-Mailer: Apple Mail (2.1510) Cc: "dime@ietf.org" Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same type) within a response message X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 10:16:54 -0000 X-List-Received-Date: Wed, 04 Dec 2013 10:16:54 -0000 On Dec 3, 2013, at 12:40 PM, lionel.morand@orange.com wrote: > Nirav, > =20 > If there are more than one OLR of the same type in the same answer, = based on what I understood from the examples given below, the client = will have to figure out which reduction to apply only based on extra = AVPs received in the OLRs. I'm not so sure that it is something = advisable from a standard point of view. Definitely not advisable. - Jouni > =20 > Regards, > =20 > Lionel > =20 > De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich = (NSN - DE/Munich) > Envoy=E9 : mardi 3 d=E9cembre 2013 10:48 > =C0 : ext Nirav Salot (nsalot); Maria Cruz Bartolome; dime@ietf.org > Objet : Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same = type) within a response message > =20 > Nirav, > =20 > I still do not see the need for more than one OLR in an answer. > =20 > More than one OLR means more complexity. Let=92s try to avoid that. > =20 > The server gets a request that either is or is not in the narrower = scope. If it is not, why shoud the server return an OLR for the narrower = scope? It can do so when it gets a request within the narrower scope = (which possibly never happens). > =20 > Ulrich > =20 > =20 > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Nirav Salot = (nsalot) > Sent: Tuesday, December 03, 2013 10:26 AM > To: Maria Cruz Bartolome; dime@ietf.org > Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same = type) within a response message > =20 > Maria-Cruz, > =20 > > we may think that we need two different OLRs with ReportType=3Dhost, = and one of them includes the extra info (AVPs) required for that = application > Yes. The above is my concern. I tried giving APN as one example AVP = which we may want to include in OC-OLR. Let me give another possible = example. > As of now, the OC-OLR can indicate application + host/realm level = "required-reduction-percentage". > However, for the given application (e.g. Gx) we may want to define a = narrower scope with "session-type =3D {M2M, Others}" AVP. So basically, = the Gx nodes can advertise different "required-reduction-percentage" for = M2M sessions v/s other type of sessions for the same application Gx and = for the same destination-host. > =20 > So in general, if any application needs to define a different (i.e. = narrower) scope than application + host/realm, it can do so by adding a = new AVP in OC-OLR. > And then we might have two instances of OC-OLR from the same host. > =20 > We could achieve the above by defining new Report-Type for each new = AVP added by each application. But would this scale or is this a = reasonable approach? > I am not sure and you have already identified one of my concerns below > > if we extend ReportType, does it need to be done by IETF, or could = it be done per application by 3GPP? > =20 > In summary, in my view, we need to define the handling of multiple = instances with the same Report-Type as part of the DOIC draft. Or we say = that multiple instances with the same Report-Type is not allowed =96 = this seems unnecessary restriction to me. > Otherwise, if later, we realize the need to do so then we may not be = able to do so since the handling is not defined in the base solution. > =20 > Regards, > Nirav. > =20 > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Maria Cruz = Bartolome > Sent: Tuesday, December 03, 2013 1:57 PM > To: dime@ietf.org > Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same = type) within a response message > =20 > Nirav, > =20 > I think I understand your concern. It may occur that we need that a = reacting node should apply two different OLR when sending a request = towards one specific host. > Then, we may think that we need two different OLRs with = ReportType=3Dhost, and one of them includes the extra info (AVPs) = required for that application, I think this is your interpretation, but=85= we can as well consider a new ReportType=3DapplicX_ReportY, that may = apply e.g. for any request send to this application, or just for this = application+host, and then Host could be another AVP to be included in = the OLR, or we could define expected behaviour when defining this new = ReportType. > =20 > Would this cover your concerns? If not, could you try to provide an = example that requires two OLR with ReportType=3Dhost? > =20 > A part from that, a question for all, if we extend ReportType, does it = need to be done by IETF, or could it be done per application by 3GPP? > =20 > Thanks > /MCruz > =20 > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Nirav Salot = (nsalot) > Sent: jueves, 28 de noviembre de 2013 17:11 > To: lionel.morand@orange.com > Cc: dime@ietf.org > Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same = type) within a response message > =20 > Hi Lionel, > =20 > I am not sure if defining new ReportType for every new AVP 3GPP would = add for a specific application would be a good solution. > I thought ReportType would indicate if the corresponding OC-OLR should = be used while sending the traffic towards the host or towards the realm. > So from that point of view, all the OC-OLR generated by the server = should have ReportType=3Dhost. i.e. when the reacting node sends the = traffic towards that host, it should make use of the corresponding = OC-OLR. Now, this OC-OLR may contain the AVPs defined by DOIC draft as = well as 3GPP application specific AVPs. > =20 > In general, I was just thinking that it may be good idea to define = some of the principles such as > - More than one instances of OC-OLR with ReportType=3Dhost = may be present in the answer message if the OC-OLR definition is = extended by the application using the same. In that case, it is the = responsibility of the application to define the valid combination of = OC-OLR instances in a given message > - If the reporting node includes more than one instance of = OC-OLR, the reporting node shall always include all the active instances = of OC-OLR in a response message. > - When the reacting node receives one or more instances of = OC-OLR with the given ReportType and with new timestamp value, it should = overwrite all the existing OC-OLR of the same ReportType. > =20 > Regards, > Nirav. > =20 > From: lionel.morand@orange.com [mailto:lionel.morand@orange.com]=20 > Sent: Thursday, November 28, 2013 7:39 PM > To: Nirav Salot (nsalot) > Cc: dime@ietf.org > Subject: RE: DOIC: Multiple instance of OC-OLR AVP (of the same type) = within a response message > =20 > Hi Nirav, > =20 > The Report Type should be able to differentiate such cases. In your = example, I would define a specific Report type. > But difficult to appraise all the future use cases. But for me, the = main use of the report type is to differentiate OC-OLR received in the = same message. > And it is the reasons of my recommendation. Actually, the exact = wording will be a "SHOULD" saying that it is recommended but you may = have serious reasons to do otherwise. > =20 > Lionel > =20 > De : Nirav Salot (nsalot) [mailto:nsalot@cisco.com]=20 > Envoy=E9 : jeudi 28 novembre 2013 13:00 > =C0 : MORAND Lionel IMT/OLN > Cc : dime@ietf.org > Objet : RE: DOIC: Multiple instance of OC-OLR AVP (of the same type) = within a response message > =20 > Lionel, >=20 > 3gpp may define an optional avp which can be included by the reporting = node if it wishes to do so. E.g. APN can be additionally included by the = reporting node to indicate APN specific overload within the given = application. > In that case, the reporting node may also want to indicate application = level overload without including the APN (e.g. this overload report is = applicable to all other APNs). >=20 > And hence there is a possibility of including multiple instances of = the overload report. >=20 > I am not suggesting that 3gpp will define APN (or any other avp) = within overload report. But later, if 3gpp need to define the same, then = corresponding handling needs to be defined within IETF now. >=20 > Regards, > Nirav. >=20 > On Nov 28, 2013 3:56 PM, "lionel.morand@orange.com" = wrote: > Hi Nirav, > =20 > Not sure to understand the proposal or question. > The OLR is significant per application (piggybacking principle). So if = the 3GPP decides to add specific AVPs in the OLR (that will be = possible), what would be the need to add the OLR without the specific = 3GPP AVPs as the OLR will be anyway handle by 3GPP aware entities? > =20 > Lionel > =20 > De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot = (nsalot) > Envoy=E9 : jeudi 28 novembre 2013 10:33 > =C0 : dime@ietf.org > Objet : [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same = type) within a response message > =20 > Hi, > =20 > As I understand IETF will define the base overload control solution as = part of DOIC. Then 3GPP would adopt the defined solution for each of its = application. > When that happens, 3GPP might want to add 3GPP specific AVP within = OC-OLR AVP. Based on the current definition of the OC-OLR AVP this = should be allowed since it contains "* [AVP]" in its definition. > e.g. for a given application 3GPP decides to add information into = OC-OLR which changes the scope of the OC-OLR from application level to = the provided information level. > Additionally, the reporting may want to advertise the OC-OLR at the = application level scope =96 i.e. the OC-OLR without any 3GPP specific = info. > =20 > So if the above is allowed, we will have the possibility of the = reporting node wanting to include two instances of OC-OLR with the = Report-Type=3D"host". > And then we need to define the handling of multiple instances of = OC-OLR in the DOIC draft. > =20 > So the questions are, > - Is 3GPP (or any other SDO) allowed to extend the definition = of OC-OLR by adding information into it? > - If no, can we guarantee that application level scope of = OC-OLR (which is what we have defined currently) is sufficient (and not = restricting) to all the applications of 3GPP? > =20 > Regards, > Nirav. > =20 > = __________________________________________________________________________= _______________________________________________ > =20 > 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. > =20 > 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. > = __________________________________________________________________________= _______________________________________________ > =20 > 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. > =20 > 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. > = __________________________________________________________________________= _______________________________________________ >=20 > 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. >=20 > 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. >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From jouni.nospam@gmail.com Wed Dec 4 02:18:35 2013 Return-Path: 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 445291AE237 for ; Wed, 4 Dec 2013 02:18:35 -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 GzWnp-3js-Au for ; Wed, 4 Dec 2013 02:18:26 -0800 (PST) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id B9A931AE0EE for ; Wed, 4 Dec 2013 02:18:19 -0800 (PST) Received: by mail-la0-f41.google.com with SMTP id eo20so9634823lab.14 for ; Wed, 04 Dec 2013 02:18:16 -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=cGEXHu77TlyfQI39xfK/no/8O6yKnBls2e2jHqIPKDQ=; b=AlxgXAgOBcLMl2IcFykyRnF4nc2j9TZyvaUqS6uHBU7AjCOAux9G6Z/MqWeFeuYTGq RgG0qJkrNyBobMA9eMp4IdIyhpEd/bxmHfzfoHgDevfvciuabh4KzHfnLV2QINV6zwTy ApaJmq6DDLIjBdouJIjfkb/5Eg6y8EpDOIFYnV8Xg/RxYl7v88YESqBW1bDlWGo2IZLD HftJ7dXcMYyeN5+tS2ujzNdcNaCi2/yNV6TCbAY6hohuB1N09oj8z9kDRRVaQ++1DHTO JmemNzi0xQHdt18xAkvw8VTU1EY+qbkJCd/0MKR+DUGsrQ5bQb5AIdEVgt3Qnjr/YzYy qxpw== X-Received: by 10.112.199.225 with SMTP id jn1mr465562lbc.49.1386152296043; Wed, 04 Dec 2013 02:18:16 -0800 (PST) Received: from [192.168.250.212] ([194.100.71.98]) by mx.google.com with ESMTPSA id n13sm24582052lbl.17.2013.12.04.02.18.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Dec 2013 02:18:14 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <78E23951-EE6E-4295-BBE3-FDC37C5E362D@nostrum.com> Date: Wed, 4 Dec 2013 12:18:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <66DEB166-8DEB-42CA-A46E-8128F0D0900B@nostrum.com> <4CFE9D80-E25A-4B8F-96D1-EB7C21F2F11A@nostrum.com> <9AC5C876-99AD-4C43-9B13-3288C76459FB@gmail.com> <18796_1385626955_5296FD4B_18796_11001_1_6B7134B31289DC4FAF731D844122B36E3071A0@PEXCVZYM13.corporate.adroot.infra.ftgroup> <78E23951-EE6E-4295-BBE3-FDC37C5E362D@nostrum.com> To: Ben Campbell X-Mailer: Apple Mail (2.1510) Cc: "dime@ietf.org" Subject: Re: [Dime] Proposed Example Text for draft-docdt-dime-ovli-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 10:18:37 -0000 On Dec 4, 2013, at 12:05 AM, Ben Campbell wrote: >=20 > On Nov 28, 2013, at 2:22 AM, lionel.morand@orange.com wrote: >=20 >> I could discuss the need for the report type for a longtime... >> But I can live with the following approach: >>=20 >> - Keep the report type AVP >> - Keep the Report type as optional in the OC-OLR >> - Clarify that the OC-OLR applies to the Origin-Host of the Answer = when the report type is absent >> - Multiple OLRs can be found in the answer only if the OLRs have = different Report types e.g. response to an initial request (with only = dest-Realm AVP) may contain overload status of the node and of the realm >> - Remove "aggregated" >>=20 >> Is it OK for everyone? >=20 > What does it mean for the report type to be optional? More to the = point, do we expect all reacting nodes to support ReportType? If not, = what behavior do we expect from a node that doesn't understand = ReportType, and gets a report that includes it? The answer can't be to = ignore the presence of ReportType, because that is likely to cause = incorrect action. I defined a while back a default value for the OC-Report-Type. In the absence of the AVP, the default applies. - JOuni >=20 >=20 From ulrich.wiehe@nsn.com Wed Dec 4 02:19:51 2013 Return-Path: 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 807EC1AE23B for ; Wed, 4 Dec 2013 02:19:51 -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 w7ZrhToDkatr for ; Wed, 4 Dec 2013 02:19:32 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 97DF81AE242 for ; Wed, 4 Dec 2013 02:19:24 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rB4AJJ1P029189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 4 Dec 2013 11:19:20 +0100 Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rB4AJJNI023095 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Dec 2013 11:19:19 +0100 Received: from DEMUHTC005.nsn-intra.net (10.159.42.36) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 4 Dec 2013 11:19:19 +0100 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.152]) by DEMUHTC005.nsn-intra.net ([10.159.42.36]) with mapi id 14.03.0123.003; Wed, 4 Dec 2013 11:19:19 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: "ext lionel.morand@orange.com" , "Maria Cruz Bartolome" , "dime@ietf.org" Thread-Topic: [Dime] OVLI: clarification in 4.2 Thread-Index: AQHO8EzE9ycp5vvTJkqYnoN9DMqTSJpD08WA Date: Wed, 4 Dec 2013 10:19:18 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519D64C@DEMUMBX014.nsn-intra.net> References: <087A34937E64E74E848732CFF8354B920972C119@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D90006681519D427@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B920972C3CE@ESESSMB101.ericsson.se> <26806_1386091563_529E142A_26806_2128_1_6B7134B31289DC4FAF731D844122B36E313AC8@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <26806_1386091563_529E142A_26806_2128_1_6B7134B31289DC4FAF731D844122B36E313AC8@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: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D90006681519D64CDEMUMBX014nsnin_" 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: 30794 X-purgate-ID: 151667::1386152360-000022AE-4DF8D484/0-0/0-0 Subject: Re: [Dime] OVLI: clarification in 4.2 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 10:19:51 -0000 X-List-Received-Date: Wed, 04 Dec 2013 10:19:51 -0000 --_000_5BCBA1FC2B7F0B4C9D935572D90006681519D64CDEMUMBX014nsnin_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I prefer the more explicit description in the previous proposal. Ulrich From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext lionel.morand@or= ange.com Sent: Tuesday, December 03, 2013 6:26 PM To: Maria Cruz Bartolome; dime@ietf.org Subject: Re: [Dime] OVLI: clarification in 4.2 The clarification is welcome but I think that we don't have to state what i= s missing in the OLR (because a lot of things could be added to the list) b= ut what we can do with the OLR as defined in this document. We could have something as simple as: As defined in this document, the overload report contained in the OC-OLR AV= P applies to the application identified by the application-id used in the Dia= meter header of the Diameter message. The value of the Report-Type AVP indicates the sco= pe of applicability of this overload report for this application, as described in= section 4.6. No need for extra info here as we have more details in section 4.6 e.g. "Th= e reacting node learns the "host" implicitly from the Origin-Host AVP of th= e received message that contained the OC-OLR AVP" Regards, Lionel De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome Envoy=E9 : mardi 3 d=E9cembre 2013 16:11 =C0 : dime@ietf.org Objet : Re: [Dime] OVLI: clarification in 4.2 Hello Ulrich, You are right, it is 4.3 in version under development: https://github.com/jounikor/draft-docdt-dime-ovli/blob/master/draft-ietf-di= me-ovli-01.txt Your proposal looks fine. Best regards MCruz From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Sent: martes, 03 de diciembre de 2013 16:03 To: Maria Cruz Bartolome; dime@ietf.org Subject: RE: [Dime] OVLI: clarification in 4.2 Hi MCruz, isn't this clause 4.3? I agree that clarification is needed. But isn't it so that the OLR contains some explicit information (e.g. the R= eport-Type) that is not implicitly learned from the encapsulating Diameter = message? My proposal: The OC-OLR AVP does not contain explicitly all information needed by the re= acting node in order to decide whether a subsequent request must undergo a = throttling process with the reported percentage. To take this decision the = reacting node must check a) whether the subsequent request's Application-ID matches the Applica= tion-Id received in the OC-OLR AVP's encapsulating answer command; b) if the Report-Type received in the OC-ORL is "host" b1) whether the subsequent request's Destination Host is present and match= es the Origin Host received in the OC-OLR AVP's encapsulating answer comman= d; if the Report-Type received in the OC-OLR is "realm" b2) whether the subsequent request' Destination Host is absent and the Dest= ination Realm matches the Origin Realm received in the OC-OLR AVP's encaps= ulating answer command; Best regards Ulrich From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto= lome Sent: Tuesday, December 03, 2013 2:56 PM To: dime@ietf.org Subject: [Dime] OVLI: clarification in 4.2 Hello, I would like to propose a clarification on 4.2 .... The OC-OLR AVP does not contain explicit information to which application it applies to and who inserted the AVP or whom the specific OC-OLR AVP concerns to. Both these information is implicitly learned from the encapsulating Diameter message/command. The application the OC-OLR AVP applies to is the same as the Application-Id found in the Diameter message header. The identity the OC-OLR AVP concerns is determined from the Origin-Host AVP found from the encapsulating Diameter command. My understanding is that "who inserted the AVP" cannot always be learned fr= om the encapsulating Diameter message, since "origin-host" may not always c= ontain the host that inserted the OLR. A part from that, "whom the specific OC-OLR AVP concerns to", could be a bi= t misleading... "whom" may be host, realm, or any other future ReportType, = or even any other "narrowed scope" within the OLR. Last sentence is affecte= d by this ambiguity as well. Some rephrasing may be considered: The OC-OLR AVP does not contain explicit information that may be implicitly learned from the encapsulating Diameter message/command. The application the OC-OLR AVP applies to is the same as the Application-Id found in the Diameter message header. When Report-Type is a Destination-Host, the identity the OC-OLR AVP concerns is determined from the Origin-Host AVP found from the encapsulating Diameter command. Best regards /MCruz ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. --_000_5BCBA1FC2B7F0B4C9D935572D90006681519D64CDEMUMBX014nsnin_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I prefe= r the more explicit description in the previous proposal.=

Ulrich<= o:p>

&n= bsp;

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext lionel.morand@orange.com
Sent: Tuesday, December 03, 2013 6:26 PM
To: Maria Cruz Bartolome; dime@ietf.org
Subject: Re: [Dime] OVLI: clarification in 4.2

 

The cla= rification is welcome but I think that we don't have to state what is missi= ng in the OLR (because a lot of things could be added to the list) but what= we can do with the OLR as defined in this document.

&n= bsp;

We coul= d have something as simple as:

&n= bsp;

As defined in this document, the overload report cont= ained in the OC-OLR AVP

applies to the application identified by the applicat= ion-id used in the Diameter header

of the Diameter message. The value of the Report-Type= AVP indicates the scope of

applicability of this overload report for this applic= ation, as described in section 4.6.

&n= bsp;

No need= for extra info here as we have more details in section 4.6 e.g. "The = reacting node learns the "host" implicitly from the Origin-Host A= VP of the received message that contained the OC-OLR AVP"

&n= bsp;

Regards= ,

&n= bsp;

Lionel =

&n= bsp;

De : DiME [mailto:d= ime-bounces@ietf.org] De la part de Maria Cruz Bartolome
Envoy=E9 : mardi 3 d=E9cembre 2013 16:11
=C0 : dime@ietf.org
Objet : Re: [Dime] OVLI: clarification in 4.2=

 

Hello U= lrich,

&n= bsp;

You are= right, it is 4.3 in version under development:

https://github.com/jo= unikor/draft-docdt-dime-ovli/blob/master/draft-ietf-dime-ovli-01.txt

Your pr= oposal looks fine.

Best re= gards

MCruz

&n= bsp;

From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
Sent: martes, 03 de diciembre de 2013 16:03
To: Maria Cruz Bartolome; dime@ietf= .org
Subject: RE: [Dime] OVLI: clarification in 4.2

 

Hi MCruz,

 

isn’t this claus= e 4.3?

 

I agree= that clarification is needed.

But isn= ’t it so that the OLR contains some explicit information (e.g. the Re= port-Type) that is not implicitly learned from the encapsulating Diameter m= essage?

&n= bsp;

My prop= osal:

The OC-= OLR AVP does not contain explicitly all information needed by the reacting = node in order to decide whether a subsequent request must undergo a throttl= ing process with the reported percentage. To take this decision the reacting node must check

= a)      whether the subsequent request’s Application-ID matches the Applicat= ion-Id received in the OC-OLR AVP’s encapsulating answer command;

= b)      if the Report-Type received in the OC-ORL is “host”=

b1)  whether the subsequent request’s Dest= ination Host is present and matches the Origin Host received in the OC-OLR = AVP’s encapsulating answer command;

if the Report-Type received in the= OC-OLR is “realm”

b2) whether the subsequent request’ Destination= Host is absent and the Destination Realm matches the Origin Realm received= in the OC-OLR AVP’s  encapsulating answer command;

&n= bsp;

Best re= gards

Ulrich<= o:p>

&n= bsp;

&n= bsp;

&n= bsp;

From: DiME [mailto= :dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Bartolome
Sent: Tuesday, December 03, 2013 2:56 PM
To: dime@ietf.org
Subject: [Dime] OVLI: clarification in 4.2

 

Hello,

 

I would like to propose a clari= fication on 4.2

     &= nbsp;          ….

   The OC-OLR AVP does not contain explicit information to wh= ich

   application it applies to and who inserted the AVP= or whom the

   specific OC-OLR AVP concerns to. Both these information is
   i=
mplicitly learned from the encapsulating Diameter message/command.
   T=
he application the OC-OLR AVP applies to is the same as the
   A=
pplication-Id found in the Diameter message header.  The identity=

   t=
he OC-OLR AVP concerns is determined from the Origin-Host AVP found
   f=
rom the encapsulating Diameter command.

 

 

My understanding is that “= ;who inserted the AVP” cannot always be learned from the encapsulatin= g Diameter message, since “origin-host” may not always contain = the host that inserted the OLR.

A part from that, “whom t= he specific OC-OLR AVP concerns to”, could be a bit misleading…= “whom” may be host, realm, or any other future ReportType, or = even any other “narrowed scope” within the OLR. Last sentence i= s affected by this ambiguity as well.

 

Some rephrasing may be consider= ed:

   The OC-OLR AVP does not contain explicit information that may be 

  &n=
bsp;implicitly learned from the encapsulating Diameter message/command.
   <=
/span>The application the OC-OLR AVP a=
pplies to is the same as the
   A=
pplication-Id found in the Diameter message header. When Report-Type is 
  &nbs=
p;a Destination-Host, the identity
   t=
he OC-OLR AVP concerns is determined from the Origin-Host AVP found
   f=
rom the encapsulating Diameter command.

 

 

Best regards<= /p>

/MCruz

 

________________________________________________________________=
_________________________________________________________=

 
Ce message et ses pieces jointes peuvent contenir des informatio=
ns confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vou=
s 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 pri=
vileged information that may be protected by law;


they should not be distributed, used or copied without authorisa=
tion.


If you have received this email in error, please notify the send=
er 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.
--_000_5BCBA1FC2B7F0B4C9D935572D90006681519D64CDEMUMBX014nsnin_-- From ulrich.wiehe@nsn.com Wed Dec 4 02:52:59 2013 Return-Path: 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 11A7C1AE0F3 for ; Wed, 4 Dec 2013 02:52:59 -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 RYNdi0vO-T_h for ; Wed, 4 Dec 2013 02:52:56 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 7775B1AE0A6 for ; Wed, 4 Dec 2013 02:52:55 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rB4AqmYu008461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 4 Dec 2013 11:52:48 +0100 Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rB4AqlM8031208 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Dec 2013 11:52:47 +0100 Received: from DEMUHTC009.nsn-intra.net (10.159.42.40) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 4 Dec 2013 11:52:47 +0100 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.152]) by DEMUHTC009.nsn-intra.net ([10.159.42.40]) with mapi id 14.03.0123.003; Wed, 4 Dec 2013 11:52:47 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: ext Ben Campbell Thread-Topic: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same type) within a response message Thread-Index: Ac7wCaL7cwdoL1xIRoywlc8N1o+kQQAAkVNQABg9QAAAHGQXMA== Date: Wed, 4 Dec 2013 10:52:46 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519D6B3@DEMUMBX014.nsn-intra.net> References: <5BCBA1FC2B7F0B4C9D935572D90006681519C296@DEMUMBX014.nsn-intra.net> <4244E2A6-F8E6-4CE5-B377-B42E99107C33@nostrum.com> In-Reply-To: <4244E2A6-F8E6-4CE5-B377-B42E99107C33@nostrum.com> 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: 12821 X-purgate-ID: 151667::1386154368-000022AE-25A84430/0-0/0-0 Cc: "dime@ietf.org" Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same type) within a response message X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 10:52:59 -0000 Not allowing more than one OLR adds some complexity to the agent (not to th= e potentially overloaded server), as the agent should replace rather than a= dd an OLR. -----Original Message----- From: ext Ben Campbell [mailto:ben@nostrum.com]=20 Sent: Tuesday, December 03, 2013 11:16 PM To: Wiehe, Ulrich (NSN - DE/Munich) Cc: ext Nirav Salot (nsalot); Maria Cruz Bartolome; dime@ietf.org Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same type= ) within a response message On Dec 3, 2013, at 3:48 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: > Nirav, > =20 > I still do not see the need for more than one OLR in an answer. > =20 > More than one OLR means more complexity. Let's try to avoid that. I agree it adds complexity for the reacting node. As I outlined in my origi= nal email on the mixed dh/dr example, I think _not_ allowing it adds more c= omplexity for the reporting node, since it may need to send more reports th= an it has answers to put them in. I think it's reasonable to transfer complexity from the reporting node to t= he reacting node, since the reporting node is often the overloaded entity. > =20 > The server gets a request that either is or is not in the narrower scope.= If it is not, why shoud the server return an OLR for the narrower scope? I= t can do so when it gets a request within the narrower scope (which possibl= y never happens). > =20 > Ulrich > =20 > =20 > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Nirav Salot (n= salot) > Sent: Tuesday, December 03, 2013 10:26 AM > To: Maria Cruz Bartolome; dime@ietf.org > Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same ty= pe) within a response message > =20 > Maria-Cruz, > =20 > > we may think that we need two different OLRs with ReportType=3Dhost, an= d one of them includes the extra info (AVPs) required for that application > Yes. The above is my concern. I tried giving APN as one example AVP which= we may want to include in OC-OLR. Let me give another possible example. > As of now, the OC-OLR can indicate application + host/realm level "requir= ed-reduction-percentage". > However, for the given application (e.g. Gx) we may want to define a narr= ower scope with "session-type =3D {M2M, Others}" AVP. So basically, the Gx = nodes can advertise different "required-reduction-percentage" for M2M sessi= ons v/s other type of sessions for the same application Gx and for the same= destination-host. > =20 > So in general, if any application needs to define a different (i.e. narro= wer) scope than application + host/realm, it can do so by adding a new AVP = in OC-OLR. > And then we might have two instances of OC-OLR from the same host. > =20 > We could achieve the above by defining new Report-Type for each new AVP a= dded by each application. But would this scale or is this a reasonable appr= oach? > I am not sure and you have already identified one of my concerns below > > if we extend ReportType, does it need to be done by IETF, or could it b= e done per application by 3GPP? > =20 > In summary, in my view, we need to define the handling of multiple instan= ces with the same Report-Type as part of the DOIC draft. Or we say that mul= tiple instances with the same Report-Type is not allowed - this seems unnec= essary restriction to me. > Otherwise, if later, we realize the need to do so then we may not be able= to do so since the handling is not defined in the base solution. > =20 > Regards, > Nirav. > =20 > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Maria Cruz Bartolo= me > Sent: Tuesday, December 03, 2013 1:57 PM > To: dime@ietf.org > Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same ty= pe) within a response message > =20 > Nirav, > =20 > I think I understand your concern. It may occur that we need that a react= ing node should apply two different OLR when sending a request towards one = specific host. > Then, we may think that we need two different OLRs with ReportType=3Dhost= , and one of them includes the extra info (AVPs) required for that applicat= ion, I think this is your interpretation, but. we can as well consider a ne= w ReportType=3DapplicX_ReportY, that may apply e.g. for any request send to= this application, or just for this application+host, and then Host could b= e another AVP to be included in the OLR, or we could define expected behavi= our when defining this new ReportType. > =20 > Would this cover your concerns? If not, could you try to provide an examp= le that requires two OLR with ReportType=3Dhost? > =20 > A part from that, a question for all, if we extend ReportType, does it ne= ed to be done by IETF, or could it be done per application by 3GPP? > =20 > Thanks > /MCruz > =20 > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Nirav Salot (nsalo= t) > Sent: jueves, 28 de noviembre de 2013 17:11 > To: lionel.morand@orange.com > Cc: dime@ietf.org > Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same ty= pe) within a response message > =20 > Hi Lionel, > =20 > I am not sure if defining new ReportType for every new AVP 3GPP would add= for a specific application would be a good solution. > I thought ReportType would indicate if the corresponding OC-OLR should be= used while sending the traffic towards the host or towards the realm. > So from that point of view, all the OC-OLR generated by the server should= have ReportType=3Dhost. i.e. when the reacting node sends the traffic towa= rds that host, it should make use of the corresponding OC-OLR. Now, this OC= -OLR may contain the AVPs defined by DOIC draft as well as 3GPP application= specific AVPs. > =20 > In general, I was just thinking that it may be good idea to define some o= f the principles such as > - More than one instances of OC-OLR with ReportType=3Dhost may b= e present in the answer message if the OC-OLR definition is extended by the= application using the same. In that case, it is the responsibility of the = application to define the valid combination of OC-OLR instances in a given = message > - If the reporting node includes more than one instance of OC-OL= R, the reporting node shall always include all the active instances of OC-O= LR in a response message. > - When the reacting node receives one or more instances of OC-OL= R with the given ReportType and with new timestamp value, it should overwri= te all the existing OC-OLR of the same ReportType. > =20 > Regards, > Nirav. > =20 > From: lionel.morand@orange.com [mailto:lionel.morand@orange.com]=20 > Sent: Thursday, November 28, 2013 7:39 PM > To: Nirav Salot (nsalot) > Cc: dime@ietf.org > Subject: RE: DOIC: Multiple instance of OC-OLR AVP (of the same type) wit= hin a response message > =20 > Hi Nirav, > =20 > The Report Type should be able to differentiate such cases. In your examp= le, I would define a specific Report type. > But difficult to appraise all the future use cases. But for me, the main = use of the report type is to differentiate OC-OLR received in the same mess= age. > And it is the reasons of my recommendation. Actually, the exact wording w= ill be a "SHOULD" saying that it is recommended but you may have serious re= asons to do otherwise. > =20 > Lionel > =20 > De : Nirav Salot (nsalot) [mailto:nsalot@cisco.com]=20 > Envoy=E9 : jeudi 28 novembre 2013 13:00 > =C0 : MORAND Lionel IMT/OLN > Cc : dime@ietf.org > Objet : RE: DOIC: Multiple instance of OC-OLR AVP (of the same type) with= in a response message > =20 > Lionel, >=20 > 3gpp may define an optional avp which can be included by the reporting no= de if it wishes to do so. E.g. APN can be additionally included by the repo= rting node to indicate APN specific overload within the given application. > In that case, the reporting node may also want to indicate application le= vel overload without including the APN (e.g. this overload report is applic= able to all other APNs). >=20 > And hence there is a possibility of including multiple instances of the o= verload report. >=20 > I am not suggesting that 3gpp will define APN (or any other avp) within o= verload report. But later, if 3gpp need to define the same, then correspond= ing handling needs to be defined within IETF now. >=20 > Regards, > Nirav. >=20 > On Nov 28, 2013 3:56 PM, "lionel.morand@orange.com" wrote: > Hi Nirav, > =20 > Not sure to understand the proposal or question. > The OLR is significant per application (piggybacking principle). So if th= e 3GPP decides to add specific AVPs in the OLR (that will be possible), wha= t would be the need to add the OLR without the specific 3GPP AVPs as the OL= R will be anyway handle by 3GPP aware entities? > =20 > Lionel > =20 > De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot (nsalo= t) > Envoy=E9 : jeudi 28 novembre 2013 10:33 > =C0 : dime@ietf.org > Objet : [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same type) w= ithin a response message > =20 > Hi, > =20 > As I understand IETF will define the base overload control solution as pa= rt of DOIC. Then 3GPP would adopt the defined solution for each of its appl= ication. > When that happens, 3GPP might want to add 3GPP specific AVP within OC-OLR= AVP. Based on the current definition of the OC-OLR AVP this should be allo= wed since it contains "* [AVP]" in its definition. > e.g. for a given application 3GPP decides to add information into OC-OLR = which changes the scope of the OC-OLR from application level to the provide= d information level. > Additionally, the reporting may want to advertise the OC-OLR at the appli= cation level scope - i.e. the OC-OLR without any 3GPP specific info. > =20 > So if the above is allowed, we will have the possibility of the reporting= node wanting to include two instances of OC-OLR with the Report-Type=3D"ho= st". > And then we need to define the handling of multiple instances of OC-OLR i= n the DOIC draft. > =20 > So the questions are, > - Is 3GPP (or any other SDO) allowed to extend the definition of= OC-OLR by adding information into it? > - If no, can we guarantee that application level scope of OC-OLR= (which is what we have defined currently) is sufficient (and not restricti= ng) to all the applications of 3GPP? > =20 > Regards, > Nirav. > =20 > _________________________________________________________________________= ________________________________________________ > =20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu 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 o= u falsifie. Merci. > =20 > This message and its attachments may contain confidential or privileged i= nformation 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 de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > _________________________________________________________________________= ________________________________________________ > =20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu 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 o= u falsifie. Merci. > =20 > This message and its attachments may contain confidential or privileged i= nformation 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 de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From lionel.morand@orange.com Wed Dec 4 03:21:53 2013 Return-Path: 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 128401AE0F3 for ; Wed, 4 Dec 2013 03:21:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 Q849PH3hREKw for ; Wed, 4 Dec 2013 03:21:48 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 258B91AE101 for ; Wed, 4 Dec 2013 03:21:45 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id D794818C407; Wed, 4 Dec 2013 12:21:41 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id BF0D035C05B; Wed, 4 Dec 2013 12:21:41 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0158.001; Wed, 4 Dec 2013 12:21:41 +0100 From: To: "Wiehe, Ulrich (NSN - DE/Munich)" , "Maria Cruz Bartolome" , "dime@ietf.org" Thread-Topic: [Dime] OVLI: clarification in 4.2 Thread-Index: AQHO8EzE9ycp5vvTJkqYnoN9DMqTSJpD08WAgAAI+/A= Date: Wed, 4 Dec 2013 11:21:40 +0000 Message-ID: <7773_1386156101_529F1045_7773_621_1_6B7134B31289DC4FAF731D844122B36E3270A8@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <087A34937E64E74E848732CFF8354B920972C119@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D90006681519D427@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B920972C3CE@ESESSMB101.ericsson.se> <26806_1386091563_529E142A_26806_2128_1_6B7134B31289DC4FAF731D844122B36E313AC8@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519D64C@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681519D64C@DEMUMBX014.nsn-intra.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E3270A8PEXCVZYM13corpora_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.20.60015 Subject: Re: [Dime] OVLI: clarification in 4.2 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 11:21:53 -0000 --_000_6B7134B31289DC4FAF731D844122B36E3270A8PEXCVZYM13corpora_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In this section, we are only defining the Grouped AVP, not all the AVPs con= tained in the Grouped AVP. Lionel De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Envoy=E9 : mercredi 4 d=E9cembre 2013 11:19 =C0 : MORAND Lionel IMT/OLN; Maria Cruz Bartolome; dime@ietf.org Objet : RE: [Dime] OVLI: clarification in 4.2 I prefer the more explicit description in the previous proposal. Ulrich From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext lionel.morand@or= ange.com Sent: Tuesday, December 03, 2013 6:26 PM To: Maria Cruz Bartolome; dime@ietf.org Subject: Re: [Dime] OVLI: clarification in 4.2 The clarification is welcome but I think that we don't have to state what i= s missing in the OLR (because a lot of things could be added to the list) b= ut what we can do with the OLR as defined in this document. We could have something as simple as: As defined in this document, the overload report contained in the OC-OLR AVP applies to the application identified by the application-id used in the Dia= meter header of the Diameter message. The value of the Report-Type AVP indicates the sco= pe of applicability of this overload report for this application, as described in= section 4.6. No need for extra info here as we have more details in section 4.6 e.g. "Th= e reacting node learns the "host" implicitly from the Origin-Host AVP of th= e received message that contained the OC-OLR AVP" Regards, Lionel De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome Envoy=E9 : mardi 3 d=E9cembre 2013 16:11 =C0 : dime@ietf.org Objet : Re: [Dime] OVLI: clarification in 4.2 Hello Ulrich, You are right, it is 4.3 in version under development: https://github.com/jounikor/draft-docdt-dime-ovli/blob/master/draft-ietf-di= me-ovli-01.txt Your proposal looks fine. Best regards MCruz From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Sent: martes, 03 de diciembre de 2013 16:03 To: Maria Cruz Bartolome; dime@ietf.org Subject: RE: [Dime] OVLI: clarification in 4.2 Hi MCruz, isn't this clause 4.3? I agree that clarification is needed. But isn't it so that the OLR contains some explicit information (e.g. the R= eport-Type) that is not implicitly learned from the encapsulating Diameter = message? My proposal: The OC-OLR AVP does not contain explicitly all information needed by the re= acting node in order to decide whether a subsequent request must undergo a = throttling process with the reported percentage. To take this decision the = reacting node must check a) whether the subsequent request's Application-ID matches the Applica= tion-Id received in the OC-OLR AVP's encapsulating answer command; b) if the Report-Type received in the OC-ORL is "host" b1) whether the subsequent request's Destination Host is present and match= es the Origin Host received in the OC-OLR AVP's encapsulating answer comman= d; if the Report-Type received in the OC-OLR is "realm" b2) whether the subsequent request' Destination Host is absent and the Dest= ination Realm matches the Origin Realm received in the OC-OLR AVP's encaps= ulating answer command; Best regards Ulrich From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto= lome Sent: Tuesday, December 03, 2013 2:56 PM To: dime@ietf.org Subject: [Dime] OVLI: clarification in 4.2 Hello, I would like to propose a clarification on 4.2 .... The OC-OLR AVP does not contain explicit information to which application it applies to and who inserted the AVP or whom the specific OC-OLR AVP concerns to. Both these information is implicitly learned from the encapsulating Diameter message/command. The application the OC-OLR AVP applies to is the same as the Application-Id found in the Diameter message header. The identity the OC-OLR AVP concerns is determined from the Origin-Host AVP found from the encapsulating Diameter command. My understanding is that "who inserted the AVP" cannot always be learned fr= om the encapsulating Diameter message, since "origin-host" may not always c= ontain the host that inserted the OLR. A part from that, "whom the specific OC-OLR AVP concerns to", could be a bi= t misleading... "whom" may be host, realm, or any other future ReportType, = or even any other "narrowed scope" within the OLR. Last sentence is affecte= d by this ambiguity as well. Some rephrasing may be considered: The OC-OLR AVP does not contain explicit information that may be implicitly learned from the encapsulating Diameter message/command. The application the OC-OLR AVP applies to is the same as the Application-Id found in the Diameter message header. When Report-Type is a Destination-Host, the identity the OC-OLR AVP concerns is determined from the Origin-Host AVP found from the encapsulating Diameter command. Best regards /MCruz ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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 confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. --_000_6B7134B31289DC4FAF731D844122B36E3270A8PEXCVZYM13corpora_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

In this= section, we are only defining the Grouped AVP, not all the AVPs contained = in the Grouped AVP.

&n= bsp;

Lionel<= o:p>

&n= bsp;

De : Wieh= e, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
Envoy=E9 : mercredi 4 d=E9cembre 2013 11:19
=C0 : MORAND Lionel IMT/OLN; Maria Cruz Bartolome; dime@ietf.or= g
Objet : RE: [Dime] OVLI: clarification in 4.2=

 

I prefe= r the more explicit description in the previous proposal.

Ulrich<= /span>

 <= /span>

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext lionel.morand@orange.com
Sent: Tuesday, December 03, 2013 6:26 PM
To: Maria Cruz Bartolome; dime@ietf.org
Subject: Re: [Dime] OVLI: clarification in 4.2

 

The cla= rification is welcome but I think that we don't have to state what is missi= ng in the OLR (because a lot of things could be added to the list) but what= we can do with the OLR as defined in this document.

 <= /span>

We coul= d have something as simple as:

 <= /span>

As defined in this document, the overload report cont= ained in the OC-OLR AVP

applies to the application identified by the applicat= ion-id used in the Diameter header

of the Diameter message. The value of the Report-Type= AVP indicates the scope of

applicability of this overload report for this applic= ation, as described in section 4.6.

 <= /span>

No need= for extra info here as we have more details in section 4.6 e.g. "The = reacting node learns the "host" implicitly from the Origin-Host A= VP of the received message that contained the OC-OLR AVP"

 <= /span>

Regards= ,

 <= /span>

Lionel =

 <= /span>

De : DiME= [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome
Envoy=E9 : mardi 3 d=E9cembre 2013 16:11
=C0 : dime@ietf.org
Objet : Re: [Dime] OVLI: clarification in 4.2

 

Hello U= lrich,

 <= /span>

You are= right, it is 4.3 in version under development:

https://github.com/jo= unikor/draft-docdt-dime-ovli/blob/master/draft-ietf-dime-ovli-01.txt

Your pr= oposal looks fine.

Best re= gards

MCruz

 <= /span>

From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
Sent: martes, 03 de diciembre de 2013 16:03
To: Maria Cruz Bartolome; dime@ietf= .org
Subject: RE: [Dime] OVLI: clarification in 4.2

 =

Hi MCruz,<= /span>

 

isn’= t this clause 4.3?

 

I agree= that clarification is needed.

But isn= ’t it so that the OLR contains some explicit information (e.g. the Re= port-Type) that is not implicitly learned from the encapsulating Diameter m= essage?

 <= /span>

My prop= osal:

The OC-= OLR AVP does not contain explicitly all information needed by the reacting = node in order to decide whether a subsequent request must undergo a throttl= ing process with the reported percentage. To take this decision the reacting node must check

a)  &= nbsp;   whether the subsequent request’s Applicatio= n-ID matches the Application-Id received in the OC-OLR AVP’s encapsul= ating answer command;

b)  &= nbsp;   if the Report-Type received in the OC-ORL is R= 20;host”

b1)  whether the subsequent request’s Dest= ination Host is present and matches the Origin Host received in the OC-OLR = AVP’s encapsulating answer command;

if the Report-Type received in the= OC-OLR is “realm”

b2) whether the subsequent request’ Destination= Host is absent and the Destination Realm matches the Origin Realm received= in the OC-OLR AVP’s  encapsulating answer command;

 <= /span>

Best re= gards

Ulrich<= /span>

 <= /span>

 <= /span>

 <= /span>

From: DiME [mailto= :dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Bartolome
Sent: Tuesday, December 03, 2013 2:56 PM
To: dime@ietf.org
Subject: [Dime] OVLI: clarification in 4.2<= o:p>

 

Hello,=

 =

I would like to propose a clari= fication on 4.2

     &= nbsp;          ….=

   The OC-OLR AVP does not contain explicit information to wh= ich

   application it applies to and who inserted the AVP= or whom the

   specific OC-OLR AVP concerns to. Both these information is=

   i=
mplicitly learned from the encapsulating Diameter message/command.
   T=
he application the OC-OLR AVP applies to is the same as the
   A=
pplication-Id found in the Diameter message header.  The identity
   t=
he OC-OLR AVP concerns is determined from the Origin-Host AVP found<=
span lang=3D"DE">
   f=
rom the encapsulating Diameter command.=

 

 =

My understanding is that “= ;who inserted the AVP” cannot always be learned from the encapsulatin= g Diameter message, since “origin-host” may not always contain = the host that inserted the OLR.<= /p>

A part from that, “whom t= he specific OC-OLR AVP concerns to”, could be a bit misleading…= “whom” may be host, realm, or any other future ReportType, or = even any other “narrowed scope” within the OLR. Last sentence i= s affected by this ambiguity as well.

 =

Some rephrasing may be consider= ed:

   The OC-OLR AVP does not contain explicit information that may be 

  &n=
bsp;implicitly learned from the encapsulating Diameter message/command.
   <=
/span>The application the OC-OLR AVP a=
pplies to is the same as the
   A=
pplication-Id found in the Diameter message header. When Report-Type is 
  &nbs=
p;a Destination-Host, the identity
   t=
he OC-OLR AVP concerns is determined from the Origin-Host AVP found<=
span lang=3D"DE">
   f=
rom the encapsulating Diameter command.=

 =

 =

Best regards

/MCruz=

 = 

_=
___________________________________________________________________________=
_____________________________________________=

&=
nbsp;
C=
e message et ses pieces jointes peuvent contenir des informations confident=
ielles ou privilegiees et ne doivent donc
p=
as 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 ele=
ctroniques etant susceptibles d'alteration,
O=
range decline toute responsabilite si ce message a ete altere, deforme ou f=
alsifie. Merci.
&=
nbsp;
T=
his message and its attachments may contain confidential or privileged info=
rmation that may be protected by law;
t=
hey should not be distributed, used or copied without authorisation.=

I=
f you have received this email in error, please notify the sender and delet=
e this message and its attachments.
A=
s emails may be altered, Orange is not liable for messages that have been m=
odified, changed or falsified.

T=
hank you.


______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles 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 el=
ectroniques 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 inf=
ormation 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 dele=
te 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.
--_000_6B7134B31289DC4FAF731D844122B36E3270A8PEXCVZYM13corpora_-- From ulrich.wiehe@nsn.com Wed Dec 4 04:29:09 2013 Return-Path: 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 1A9471AE122 for ; Wed, 4 Dec 2013 04:29:09 -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 SrFOkG_8Ji59 for ; Wed, 4 Dec 2013 04:29:06 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 08E2A1AE113 for ; Wed, 4 Dec 2013 04:29:05 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rB4CT0V9016036 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 4 Dec 2013 13:29:00 +0100 Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rB4CT03G017391 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Dec 2013 13:29:00 +0100 Received: from DEMUHTC005.nsn-intra.net (10.159.42.36) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 4 Dec 2013 13:29:00 +0100 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.152]) by DEMUHTC005.nsn-intra.net ([10.159.42.36]) with mapi id 14.03.0123.003; Wed, 4 Dec 2013 13:28:59 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: ext Jouni Korhonen , Ben Campbell Thread-Topic: [Dime] endpoint determination Thread-Index: Ac7sNGlk8/aQM1p4QPOTYH1OvkMS+gEo5X0TAATa5LA= Date: Wed, 4 Dec 2013 12:28:59 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519D739@DEMUMBX014.nsn-intra.net> References: <5BCBA1FC2B7F0B4C9D935572D90006681519BD77@DEMUMBX014.nsn-intra.net> In-Reply-To: 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="us-ascii" 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: 3386 X-purgate-ID: 151667::1386160141-00006154-F1645648/0-0/0-0 Cc: "dime@ietf.org" Subject: Re: [Dime] endpoint determination X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 12:29:09 -0000 Jouni, local configuration is exactly wht REQ6 aims to avoid. With regard to figure 4 in clause 5.1: why would the agent base its decisio= n (to take over the role of the reacting node on behalf of the non supporti= ng client) on local configuration data rather than on absence of the Featur= e-Vector AVP? Ulrich -----Original Message----- From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20 Sent: Wednesday, December 04, 2013 11:03 AM To: Ben Campbell Cc: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org Subject: Re: [Dime] endpoint determination On Dec 3, 2013, at 11:45 PM, Ben Campbell wrote: >=20 > On Nov 28, 2013, at 6:21 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >=20 >> Hi, >>=20 >> draft-ietf-dime-ovli-00 in Clause 5.1 says: >>=20 >> How the endpoints are determined is specific to a deployment, a Diameter= node role in that deployment and local configuration. >>=20 >>=20 >> In order to better address REQ 6 of RFC 7068 I would like to propose so= me principles that should be taken into account: >>=20 >> 1. A client that supports the Diameter Overload Control Mechanism must (= offer to) take the role of a reacting endpoint and hence includes the OC-Fe= ature-Vector AVP when sending requests. >> 2. An Agent that - based on local configuration - takes the role of a re= porting endpoint (towards the downstream reacting endpoint) must also (offe= r to) take the role of a reacting endpoint towards the server and hence rep= lace the received OC-Feature-Vector AVP with its own OC-Featur-Vector AVP. This should already be possible according to the current spec.. > I agree with the concepts in 1 and 2, but not as written (assuming you in= tend the use of must to be normative.) I think this is better written in te= rms of a definition of what reporting node and reacting node means, then me= ntion that a supporting client is normally a reacting node, a supporting se= rver is normally a reporting node, and an agent can be both. >=20 >> 3. An agent that supports the Diameter Overload Control Mechanism and th= at - based on absence of local configuration - does not take the role of a = reporting endpoint must be able to detect whether a downstream agent or cli= ent already takes the role of the reacting endpoint (e.g. by checking the = presence of an OC-Feature-Vector AVP in the received request). If it detect= s that no downstream node took the role of the reacting endpoint, the agen= t must take the role of the reacting endpoint and hence=20 I do not agree the MUST here to be written into the spec. The agent is free to do the above procedure but it is an implementation & local config issue.=20 - JOuni >> insert an OC-Feature AVP to the request. I.e. determination of the repor= ting endpoint is done dynamically and does not rely on local configuration. >=20 > I read that to mean you expect an agent to "take over" as the reacting no= de even if the administrator has completely turned off OC? If so, I don't a= gree, at least not as a normative requirement. Implementors can choose to c= reate such a mode if they want to, but we don't need to require it. >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From jouni.nospam@gmail.com Wed Dec 4 06:27:45 2013 Return-Path: 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 775561ACB4E for ; Wed, 4 Dec 2013 06:27:45 -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 XEobjswV6cqR for ; Wed, 4 Dec 2013 06:27:43 -0800 (PST) Received: from mail-bk0-x232.google.com (mail-bk0-x232.google.com [IPv6:2a00:1450:4008:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 16FC61AC4C1 for ; Wed, 4 Dec 2013 06:27:42 -0800 (PST) Received: by mail-bk0-f50.google.com with SMTP id e11so6637209bkh.37 for ; Wed, 04 Dec 2013 06:27:38 -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=Bd5BKoj4f7kYrQjB4wQ82SnjF5zXOpQA7iHAIELyHbE=; b=cENuepvkVhYAgFzc8mgiz/15EIyKppSxjKlZSLn1QfgQ7yFHTDDV8acCYEXPOe1aak /kUVXpkIdcZats7uxmIkFSUHJJVsbT8fZrqCP/KBw7jd6jziDgKiqgURvUEHJ7RFL7kA JAunnR3ePp4vTOpQvmbWZGBB4nj9TkhyfanGVCQBz0Y7OIo28E7ZEd3sWSm3hmLNagdY aBTnSnDPNsJsxn0hDZJiyy7vtem0b61lTzooIOwDJyaYYbJpUpv6xcwgmrTq/9pH+rEq s8KfNlWKKMSbUhTDuyhF042eOLDSE7G8pDX6n/vWiQ8YglWhQtZDynVH/ZUezvXNAFhI 5cCg== X-Received: by 10.205.97.69 with SMTP id cj5mr38419bkc.132.1386167258553; Wed, 04 Dec 2013 06:27:38 -0800 (PST) Received: from ?IPv6:2001:6e8:480:60:787f:3bfd:4b90:9728? ([2001:6e8:480:60:787f:3bfd:4b90:9728]) by mx.google.com with ESMTPSA id z6sm81833493bkn.8.2013.12.04.06.27.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Dec 2013 06:27:35 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681519D739@DEMUMBX014.nsn-intra.net> Date: Wed, 4 Dec 2013 16:27:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5BCBA1FC2B7F0B4C9D935572D90006681519BD77@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681519D739@DEMUMBX014.nsn-intra.net> To: "Wiehe, Ulrich (NSN - DE/Munich)" X-Mailer: Apple Mail (2.1510) Cc: Ben Campbell , "dime@ietf.org" Subject: Re: [Dime] endpoint determination X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 14:27:45 -0000 - Jouni On Dec 4, 2013, at 2:28 PM, "Wiehe, Ulrich (NSN - DE/Munich)" = wrote: > Jouni, >=20 > local configuration is exactly wht REQ6 aims to avoid. I still do not agree on the MUST in your proposal, since the REQ6 is SHOULD. >=20 > With regard to figure 4 in clause 5.1: why would the agent base its = decision (to take over the role of the reacting node on behalf of the = non supporting client) on local configuration data rather than on = absence of the Feature-Vector AVP? Because a network administrator may have a reason beyond our current visibility to prohibit and agent of doing so. For example the administrator might=20 want to prohibit DOIC for some realms talking to its servers. - Jouni >=20 > Ulrich >=20 > -----Original Message----- > From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20 > Sent: Wednesday, December 04, 2013 11:03 AM > To: Ben Campbell > Cc: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org > Subject: Re: [Dime] endpoint determination >=20 >=20 > On Dec 3, 2013, at 11:45 PM, Ben Campbell wrote: >=20 >>=20 >> On Nov 28, 2013, at 6:21 AM, Wiehe, Ulrich (NSN - DE/Munich) = wrote: >>=20 >>> Hi, >>>=20 >>> draft-ietf-dime-ovli-00 in Clause 5.1 says: >>>=20 >>> How the endpoints are determined is specific to a deployment, a = Diameter node role in that deployment and local configuration. >>>=20 >>>=20 >>> In order to better address REQ 6 of RFC 7068 I would like to = propose some principles that should be taken into account: >>>=20 >>> 1. A client that supports the Diameter Overload Control Mechanism = must (offer to) take the role of a reacting endpoint and hence includes = the OC-Feature-Vector AVP when sending requests. >>> 2. An Agent that - based on local configuration - takes the role of = a reporting endpoint (towards the downstream reacting endpoint) must = also (offer to) take the role of a reacting endpoint towards the server = and hence replace the received OC-Feature-Vector AVP with its own = OC-Featur-Vector AVP. >=20 > This should already be possible according to the current > spec.. >=20 >> I agree with the concepts in 1 and 2, but not as written (assuming = you intend the use of must to be normative.) I think this is better = written in terms of a definition of what reporting node and reacting = node means, then mention that a supporting client is normally a reacting = node, a supporting server is normally a reporting node, and an agent can = be both. >>=20 >>> 3. An agent that supports the Diameter Overload Control Mechanism = and that - based on absence of local configuration - does not take the = role of a reporting endpoint must be able to detect whether a downstream = agent or client already takes the role of the reacting endpoint (e.g. = by checking the presence of an OC-Feature-Vector AVP in the received = request). If it detects that no downstream node took the role of the = reacting endpoint, the agent must take the role of the reacting = endpoint and hence=20 >=20 > I do not agree the MUST here to be written into the spec. > The agent is free to do the above procedure but it is an > implementation & local config issue.=20 >=20 > - JOuni >=20 >=20 >>> insert an OC-Feature AVP to the request. I.e. determination of the = reporting endpoint is done dynamically and does not rely on local = configuration. >>=20 >> I read that to mean you expect an agent to "take over" as the = reacting node even if the administrator has completely turned off OC? If = so, I don't agree, at least not as a normative requirement. Implementors = can choose to create such a mode if they want to, but we don't need to = require it. >>=20 >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >=20 From ben@nostrum.com Wed Dec 4 13:43:41 2013 Return-Path: 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 58A2E1ADF2E for ; Wed, 4 Dec 2013 13:43:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no 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 qKlf5bwhudPs for ; Wed, 4 Dec 2013 13:43:37 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9C74C1AE13B for ; Wed, 4 Dec 2013 13:43:36 -0800 (PST) Received: from [172.20.10.7] (mobile-166-147-069-166.mycingular.net [166.147.69.166]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rB4LhQOk000856 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 4 Dec 2013 15:43:32 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ben Campbell In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681519D57E@DEMUMBX014.nsn-intra.net> Date: Wed, 4 Dec 2013 15:43:21 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <6EC4AFCD-E8BB-4EF8-92C8-3FD7387FCD9D@nostrum.com> References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> , <5BCBA1FC2B7F0B4C9D935572D90006681519C087@DEMUMBX014.nsn-intra.net> <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> <5BCBA1FC2B7F0B4C9D935572D90006681519D57E@DEMUMBX014.nsn-intra.net> To: "Wiehe, Ulrich (NSN - DE/Munich)" X-Mailer: Apple Mail (2.1822) Received-SPF: pass (shaman.nostrum.com: 166.147.69.166 is authenticated by a trusted mechanism) Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 21:43:41 -0000 On Dec 4, 2013, at 2:23 AM, Wiehe, Ulrich (NSN - DE/Munich) = wrote: > Ben, >=20 > 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. >=20 > What is an ambiguous OLR? > What should the client do when receiving 5 OLRs in one answer three of = which are ambiguous? >=20 > Let's try to avoid complexity. >=20 > Ulrich=20 >=20 > -----Original Message----- > From: ext Ben Campbell [mailto:ben@nostrum.com]=20 > 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 >=20 >=20 > On Dec 3, 2013, at 9:56 AM, Wiehe, Ulrich (NSN - DE/Munich) = wrote: >=20 >> Steve, >>=20 >> 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. >>=20 >=20 > Can we restate the "not forced to process" to say "not be forced to = choose between ambiguous" OLRs? >=20 >> Ulrich >>=20 >> 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 >>=20 >> 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. >>=20 >> It also makes it more difficult to achieve the more granular = differentiated overload report types that Nirav is suggesting. >>=20 >> Steve >>=20 >> On 12/3/13 7:52 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >> Hi Lionel, >>=20 >> 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. >>=20 >> Best regards >> Ulrich >>=20 >> -----Original Message----- >> From: ext lionel.morand@orange.com [mailto:lionel.morand@orange.com]=20= >> 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 >>=20 >> Hi Ulrich, >>=20 >> I don't see the complexity if each OLR instance received is clearly = distinguished by the Report-Type.=20 >> Again, it is not said that it will be mandated for any deployment to = rely on multiple OLR instances.=20 >>=20 >> Regards, >>=20 >> Lionel >>=20 >> -----Message d'origine----- >> De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 >> Envoy=E9 : mardi 3 d=E9cembre 2013 11:46 >> =C0 : MORAND Lionel IMT/OLN; ext Maria Cruz Bartolome; dime@ietf.org = list >> Objet : RE: [Dime] DOIC: Self-Contained OLRs >>=20 >> Hi Lionel, >>=20 >> my point is simple: >>=20 >> 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. >>=20 >> Ulrich=20 >>=20 >> -----Original Message----- >> From: ext lionel.morand@orange.com [mailto:lionel.morand@orange.com]=20= >> 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 >>=20 >> Hi Ulrich, >>=20 >> 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. >>=20 >> Regards, >>=20 >> Lionel=20 >>=20 >> -----Message d'origine----- >> De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich = (NSN - DE/Munich) >> Envoy=E9 : mardi 3 d=E9cembre 2013 10:21 >> =C0 : ext Maria Cruz Bartolome; dime@ietf.org list >> Objet : Re: [Dime] DOIC: Self-Contained OLRs >>=20 >> Dear MCruz, >> thank you for your support. >>=20 >> 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.=20 >>=20 >> 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. >>=20 >> In any case there is no need for more than one OLR in an answer. >>=20 >> Ulrich >>=20 >>=20 >>=20 >>=20 >> -----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 >>=20 >> Dear all, >>=20 >> My interpretation is as well in line to what is summarized by Lionel = below. >>=20 >> 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. >>=20 >> Best regards >> /MCruz >>=20 >> -----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 >>=20 >>=20 >> My understanding (and current editing) has already been towards what = Lionel said below. >>=20 >> - Jouni >>=20 >>=20 >> On Dec 2, 2013, at 4:19 PM, lionel.morand@orange.com wrote: >>=20 >> I agree with last part. It was the reason I've reconsidered my = position on the need for the Report-Type. >>=20 >> 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. >>=20 >> 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. >>=20 >> Regards, >>=20 >> Lionel >>=20 >>=20 >> De : Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Envoy=E9 : lundi = 2=20 >> d=E9cembre 2013 14:58 =C0 : Wiehe, Ulrich (NSN - DE/Munich) Cc :=20 >> dime@ietf.org list; ext Jouni Korhonen; MORAND Lionel IMT/OLN; Ben=20 >> Campbell Objet : RE: [Dime] DOIC: Self-Contained OLRs >>=20 >> Ulrich, >>=20 >> 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? >>=20 >> I would prefer to derive the context of the OLR based on the message = which contains the OLR. >>=20 >> 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. >>=20 >> Regards, >> Nirav. >>=20 >> On Dec 2, 2013 5:27 PM, "Wiehe, Ulrich (NSN - DE/Munich)" = wrote: >> Nirav, >>=20 >> 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. >>=20 >> 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. >>=20 >> Ulrich >>=20 >>=20 >>=20 >> -----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=20 >> Jouni Korhonen; Ben Campbell >> Cc: dime@ietf.org list >> Subject: RE: [Dime] DOIC: Self-Contained OLRs >>=20 >> Ulrich, >>=20 >> I have a basic question. >>=20 >> 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? >>=20 >> Regards, >> Nirav. >>=20 >> -----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=20 >> Korhonen; Ben Campbell >> Cc: dime@ietf.org list >> Subject: RE: [Dime] DOIC: Self-Contained OLRs >>=20 >> Hi Nirav, >>=20 >> please see inline. >>=20 >> Regards >> Ulrich >>=20 >> -----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=20 >> Jouni Korhonen; Ben Campbell >> Cc: dime@ietf.org list >> Subject: RE: [Dime] DOIC: Self-Contained OLRs >>=20 >> Ulrich, >>=20 >> 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.=20 >> [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 =3Dx1, destination realm =3Dx2 application=3D 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... >>=20 >> 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.=20 >> [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. >>=20 >> If we strictly want to ensure that the realm-type OLR is not sent=20 >> out-of-context [Wiehe, Ulrich (NSN - DE/Munich)] That was not my=20 >> proposal. My proposal was to clearly mark out-of-context OLRs in=20 >> answer messages (if we allow including out-of-context OLRs) >>=20 >> , 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). >>=20 >> 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=20= >> (NSN - DE/Munich)] only the out-of-context one >>=20 >> , 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). >>=20 >> 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). >>=20 >>=20 >> 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? >>=20 >> 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. >>=20 >> Regards, >> Nirav. >>=20 >> -----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=20 >> Korhonen; Ben Campbell >> Cc: dime@ietf.org list >> Subject: RE: [Dime] DOIC: Self-Contained OLRs >>=20 >> Hi Nirav, >>=20 >> 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. >>=20 >> Best regards >> Ulrich >>=20 >>=20 >> -----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=20 >> Jouni Korhonen; Ben Campbell >> Cc: dime@ietf.org list >> Subject: RE: [Dime] DOIC: Self-Contained OLRs >>=20 >> Hi Ulrich, >>=20 >> If an additional OLR is present with a different ReportType, why it = should be ignored by the reacting node? >>=20 >> Regards, >> Nirav. >>=20 >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich=20= >> (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 >>=20 >> Hi Lionel, >>=20 >> 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. >>=20 >> Ulrich >>=20 >>=20 >> -----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 >>=20 >> Hi Ulrich, >>=20 >> 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.=20 >>=20 >> 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. >>=20 >> I'm not sure of what is missing in this reasoning... >>=20 >> Lionel >>=20 >> -----Message d'origine----- >> De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 >> Envoy=E9 : jeudi 28 novembre 2013 11:30 =C0 : MORAND Lionel IMT/OLN; = ext=20 >> Jouni Korhonen; Ben Campbell Cc : dime@ietf.org list Objet : RE:=20 >> [Dime] DOIC: Self-Contained OLRs >>=20 >> Lionel, >>=20 >> my understanding was that _the_ reporting end point provides _the_ = OLR. >>=20 >> 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. >>=20 >> 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. >>=20 >> Ulrich >>=20 >>=20 >>=20 >> -----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 >>=20 >> Hi, >>=20 >> 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. >>=20 >> Lionel >>=20 >> -----Message d'origine----- >> De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich=20= >> (NSN - DE/Munich) Envoy=E9 : jeudi 28 novembre 2013 10:26 =C0 : ext = Jouni=20 >> Korhonen; Ben Campbell Cc : dime@ietf.org list Objet : Re: [Dime]=20 >> DOIC: Self-Contained OLRs >>=20 >> Hi, >>=20 >> 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? >>=20 >> Ulrich >>=20 >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Jouni=20 >> Korhonen >> Sent: Wednesday, November 27, 2013 11:44 PM >> To: Ben Campbell >> Cc: dime@ietf.org list >> Subject: Re: [Dime] DOIC: Self-Contained OLRs >>=20 >>=20 >> On Nov 28, 2013, at 12:27 AM, Ben Campbell wrote: >>=20 >> Hi, >>=20 >> I mentioned in another thread that I prefer putting an explicit=20 >> ReportType AVP in an OLR, rather than >>=20 >> 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. >>=20 >> I skip the rest of the mail.. too much text ;-) >>=20 >>=20 >> - Jouni >>=20 >>=20 >>=20 >>=20 >>=20 >> 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. >>=20 >> 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. >>=20 >> I think this approach is a mistake. I would greatly prefer that we = explicitly include such values in the OLR itself, for multiple reasons: >>=20 >> 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. >>=20 >> 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.=20= >>=20 >> 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. >>=20 >> 3) Implicit values don't work at all for certain problems. For=20 >> example, if an agent needs to originate an OLR, it typically needs=20 >> to insert that OLR into an existing Diameter answer created by a = server. >> It can't create its own answer without affecting the application=20 >> state. If the responding node assumes the OLR comes from or refers=20 >> to the node identified by the Origin-Host AVP in the enclosing=20 >> answer, things break. (For examples of when an agent needs to send=20 >> OLRs that are distinct from those sent by a server, see Steve's=20 >> agent overload draft, or my dh/dr example.) >>=20 >> OTOH, explicit values will work for all cases where we need to = associate some arbitrary value with an OLR. >>=20 >> 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. >>=20 >> 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. >>=20 >> Thanks! >>=20 >> Ben. >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >>=20 >> _______________________________________________ >> 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 >>=20 >> = ______________________________________________________________________ >> ___________________________________________________ >>=20 >> 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. >>=20 >> 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. >>=20 >>=20 >> = ______________________________________________________________________ >> ___________________________________________________ >>=20 >> 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. >>=20 >> 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. >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> = ______________________________________________________________________ >> ___________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations=20 >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20= >> exploites ou copies sans autorisation. Si vous avez recu ce message=20= >> 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. >>=20 >> This message and its attachments may contain confidential or=20 >> 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. >>=20 >>=20 >> _______________________________________________ >> 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 >>=20 >> = __________________________________________________________________________= _______________________________________________ >>=20 >> 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. >>=20 >> 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. >>=20 >>=20 >> = __________________________________________________________________________= _______________________________________________ >>=20 >> 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. >>=20 >> 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. >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >>=20 >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From ben@nostrum.com Wed Dec 4 13:44:25 2013 Return-Path: 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 E4D271ADFB8 for ; Wed, 4 Dec 2013 13:44:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no 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 oapw9VNjCy5j for ; Wed, 4 Dec 2013 13:44:23 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id A46371ADF2E for ; Wed, 4 Dec 2013 13:44:22 -0800 (PST) Received: from [172.20.10.7] (mobile-166-147-069-166.mycingular.net [166.147.69.166]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rB4LhQOl000856 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 4 Dec 2013 15:44:18 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ben Campbell In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681519D59C@DEMUMBX014.nsn-intra.net> Date: Wed, 4 Dec 2013 15:44:18 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <8582D429-25EB-426E-A0F6-982836FC3D4F@nostrum.com> References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D90006681519BC90@DEMUMBX014.nsn-intra.net> <6390_1385631044_52970D44_6390_18593_1_6B7134B31289DC4FAF731D844122B36E30748E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BD19@DEMUMBX014.nsn-intra.net> <17872_1385720008_529868C8_17872_2613_1_6B7134B31289DC4FAF731D844122B36E3096B8@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BF1B@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681519BFAE@DEMUMBX014.nsn-intra.net> <529CA616.2040205@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006681519D59C@DEMUMBX014.nsn-intra.net> To: "Wiehe, Ulrich (NSN - DE/Munich)" X-Mailer: Apple Mail (2.1822) Received-SPF: pass (shaman.nostrum.com: 166.147.69.166 is authenticated by a trusted mechanism) Cc: "dime@ietf.org list" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 21:44:26 -0000 On Dec 4, 2013, at 2:40 AM, Wiehe, Ulrich (NSN - DE/Munich) = wrote: > Ben, >=20 > we have this feature negotiation/adverisement mechanism that allows = the reporting endpoint to understand what is supported by the reacting = endpoint. The reporting endpoint should not send in OLRs not supported = by the reacting node. >=20 Assuming we add ReportType to the list of things for which we advertise = support, I agree. > Ulrich >=20 >=20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Ben = Campbell > Sent: Wednesday, December 04, 2013 12:00 AM > To: Steve Donovan > Cc: dime@ietf.org list > Subject: Re: [Dime] DOIC: Self-Contained OLRs >=20 >=20 > On Dec 2, 2013, at 9:24 AM, Steve Donovan = wrote: >=20 >> Ulrich, >>=20 >> Designing an overload solution that allows a reacting node to ignore = an overload report seems strange to me. The system is under stress. = Overload reports should be reacted to as quickly as possible, = independent of how the overload report is received by the reacting node. >>=20 >=20 > While I don't agree with the "out-of-context" concern, I can see = saying that a reacting node ignore an OLR if it does not understand the = ReportType. Otherwise, it doesn't understand the meaning of the report, = and is likely to do the wrong thing. An alternative might be to say the = reacting node should treat anything it doesn't understand as "Realm". >=20 >> Steve >>=20 >> On 12/1/13 1:38 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >>> Hi Nirav, >>>=20 >>> 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. >>>=20 >>> Best regards >>> Ulrich=20 >>>=20 >>>=20 >>> -----Original Message----- >>> From: ext Nirav Salot (nsalot) [ >>> mailto:nsalot@cisco.com >>> ]=20 >>> Sent: Friday, November 29, 2013 4:49 PM >>> To: Wiehe, Ulrich (NSN - DE/Munich); ext=20 >>> lionel.morand@orange.com >>> ; ext Jouni Korhonen; Ben Campbell >>> Cc:=20 >>> dime@ietf.org >>> list >>> Subject: RE: [Dime] DOIC: Self-Contained OLRs >>>=20 >>> Hi Ulrich, >>>=20 >>> If an additional OLR is present with a different ReportType, why it = should be ignored by the reacting node? >>>=20 >>> Regards, >>> Nirav. >>>=20 >>> -----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=20 >>> lionel.morand@orange.com >>> ; ext Jouni Korhonen; Ben Campbell >>> Cc:=20 >>> dime@ietf.org >>> list >>> Subject: Re: [Dime] DOIC: Self-Contained OLRs >>>=20 >>> Hi Lionel, >>>=20 >>> 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. >>>=20 >>> Ulrich >>>=20 >>>=20 >>> -----Original Message----- >>> From: ext=20 >>> 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:=20 >>> dime@ietf.org >>> list >>> Subject: RE: [Dime] DOIC: Self-Contained OLRs >>>=20 >>> Hi Ulrich, >>>=20 >>> 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.=20 >>>=20 >>> 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. >>>=20 >>> I'm not sure of what is missing in this reasoning... >>>=20 >>> Lionel >>>=20 >>> -----Message d'origine----- >>> De : Wiehe, Ulrich (NSN - DE/Munich) [ >>> mailto:ulrich.wiehe@nsn.com] Envoy=E9 : jeudi 28 novembre 2013 11:30 = =C0 : MORAND Lionel IMT/OLN; ext Jouni Korhonen; Ben Campbell Cc : = dime@ietf.org >>> list Objet : RE: [Dime] DOIC: Self-Contained OLRs >>>=20 >>> Lionel, >>>=20 >>> my understanding was that _the_ reporting end point provides _the_ = OLR. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> Ulrich >>>=20 >>>=20 >>>=20 >>> -----Original Message----- >>> From: ext=20 >>> 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:=20 >>> dime@ietf.org >>> list >>> Subject: RE: [Dime] DOIC: Self-Contained OLRs >>>=20 >>> Hi, >>>=20 >>> 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. >>>=20 >>> Lionel >>>=20 >>> -----Message d'origine----- >>> De : DiME [ >>> mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN - = DE/Munich) Envoy=E9 : jeudi 28 novembre 2013 10:26 =C0 : ext Jouni = Korhonen; Ben Campbell Cc : dime@ietf.org >>> list Objet : Re: [Dime] DOIC: Self-Contained OLRs >>>=20 >>> Hi, >>>=20 >>> 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? >>>=20 >>> Ulrich >>>=20 >>> -----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:=20 >>> dime@ietf.org >>> list >>> Subject: Re: [Dime] DOIC: Self-Contained OLRs >>>=20 >>>=20 >>> On Nov 28, 2013, at 12:27 AM, Ben Campbell=20 >>> >>> wrote: >>>=20 >>>=20 >>>> Hi, >>>>=20 >>>> I mentioned in another thread that I prefer putting an explicit=20 >>>> ReportType AVP in an OLR, rather than >>>>=20 >>> 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. >>>=20 >>> I skip the rest of the mail.. too much text ;-) >>>=20 >>>=20 >>> - Jouni >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>> 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. >>>>=20 >>>> 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. >>>>=20 >>>> I think this approach is a mistake. I would greatly prefer that we = explicitly include such values in the OLR itself, for multiple reasons: >>>>=20 >>>> 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. >>>>=20 >>>> 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.=20= >>>>=20 >>>> 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. >>>>=20 >>>> 3) Implicit values don't work at all for certain problems. For=20 >>>> example, if an agent needs to originate an OLR, it typically needs = to=20 >>>> insert that OLR into an existing Diameter answer created by a = server.=20 >>>> It can't create its own answer without affecting the application=20 >>>> state. If the responding node assumes the OLR comes from or refers = to=20 >>>> the node identified by the Origin-Host AVP in the enclosing answer,=20= >>>> things break. (For examples of when an agent needs to send OLRs = that=20 >>>> are distinct from those sent by a server, see Steve's agent = overload=20 >>>> draft, or my dh/dr example.) >>>>=20 >>>> OTOH, explicit values will work for all cases where we need to = associate some arbitrary value with an OLR. >>>>=20 >>>> 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. >>>>=20 >>>> 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. >>>>=20 >>>> Thanks! >>>>=20 >>>> Ben. >>>> _______________________________________________ >>>> DiME mailing list >>>>=20 >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >>> _______________________________________________ >>> DiME mailing list >>>=20 >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>>=20 >>> _______________________________________________ >>> DiME mailing list >>>=20 >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>>=20 >>>=20 >>> = __________________________________________________________________________= _______________________________________________ >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>>=20 >>> = __________________________________________________________________________= _______________________________________________ >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> _______________________________________________ >>> DiME mailing list >>>=20 >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>>=20 >>> _______________________________________________ >>> DiME mailing list >>>=20 >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>>=20 >>>=20 >>>=20 >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >=20 > _______________________________________________ > 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 From ben@nostrum.com Wed Dec 4 13:55:09 2013 Return-Path: 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 F0A441ADE71 for ; Wed, 4 Dec 2013 13:55:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no 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 6CbyM5mi9QMa for ; Wed, 4 Dec 2013 13:55:06 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 755751AD948 for ; Wed, 4 Dec 2013 13:55:06 -0800 (PST) Received: from [172.20.10.7] (mobile-166-147-069-166.mycingular.net [166.147.69.166]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rB4Lt1xt001359 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 4 Dec 2013 15:55:02 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ben Campbell In-Reply-To: <17146_1386112679_529E66A7_17146_16391_1_6B7134B31289DC4FAF731D844122B36E31A900@PEXCVZYM11.corporate.adroot.infra.ftgroup> Date: Wed, 4 Dec 2013 15:54:55 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D90006681519BC90@DEMUMBX014.nsn-intra.net> <6390_1385631044_52970D44_6390_18593_1_6B7134B31289DC4FAF731D844122B36E30748E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BD31@DEMUMBX014.nsn-intra.net> <47383DC2-1A1B-4D1A-ADD5-9E3CE60B06C8@gmail.com> <8467_1385735507_5298A553_8467_17054_3_6B7134B31289DC4FAF731D844122B36E309D0D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <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> To: "ext lionel.morand@orange.com" X-Mailer: Apple Mail (2.1822) Received-SPF: pass (shaman.nostrum.com: 166.147.69.166 is authenticated by a trusted mechanism) Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 21:55:09 -0000 On Dec 3, 2013, at 5:17 PM, lionel.morand@orange.com wrote: > Hi Ben, >=20 > I may be wrong somewhere in my summary but I think that it was the = result of the discussions and agreements reached regarding existing = requirements, at least from 3GPP point of view, compared to possible = optimizations for future optimizations not so obvious. We are not the 3GPP. Our requirements are RFC 7068. I believe = self-contained OLRs do a better job of meeting Req 31 than the = contextually-defined OLRs. I've made several technical arguments here--does anyone have _technical_ = arguments in favor of contextually-defined OLRs? > And because the solution offers extensibility via the definition of = new algo, new report type and addition of any new AVP in the existing = Grouped OLR, the "limitations" of the proposed solution might be removed = by someone if really required according to new requirements. >=20 It might be worth considering a compromise approach: Define _optional_ = AVPs that allow an OLR to be self-contained. If they are not present, = then the various values default to those from the enclosing Diameter = message. Possibly add support for this to the list of things that = reacting nodes can advertise. This could be in the base, or in a follow on extension. (If left for an = extension, it's worth considering whether ReportType needs to be in the = base, or this or some other extension.)=20 > Regards, >=20 > Lionel >=20 > -----Message d'origine----- > De : Ben Campbell [mailto:ben@nostrum.com]=20 > Envoy=E9 : mardi 3 d=E9cembre 2013 23:56 > =C0 : MORAND Lionel IMT/OLN > Cc : Steve Donovan; dime@ietf.org > Objet : Re: [Dime] DOIC: Self-Contained OLRs >=20 >=20 > On Dec 2, 2013, at 10:18 AM, lionel.morand@orange.com wrote: >=20 >> Hi Steve, >>=20 >> I think that is not only about few bytes in the answer. It is also = about the solution principles agreed so far: >> =B7 the current need is for an OLR bound to the application = in use >> =B7 the OLR is received from the node targeted in the = request. >> =B7 the OLR is defined per application >=20 > I don't think those principles have been well tested. I don't recall = any discussion of their benefits. What benefits do you see they have = over self-contained OLRs? >=20 > All I see from these are restrictions in the flexibility of the = solution, with very little in return. >=20 >> So all the implicit information (application, origin-host, = origin-realm) are meaningful in this context. >> And the actual solution is designed based on these assumptions. The = extensibility of the solution will allow extra info if required in other = use cases but it was agreed to go with a straightforward solution that = will satisfy most of us. >>=20 >> Regards, >>=20 >> Lionel >>=20 >> De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan >> Envoy=E9 : lundi 2 d=E9cembre 2013 16:37 >> =C0 : dime@ietf.org >> Objet : Re: [Dime] DOIC: Self-Contained OLRs >>=20 >> I don't believe that Ben's proposal was to change the piggybacking = assumption in the baseline mechanism. Ben's proposal is to design the = solution in such a way that it is not dependent on the piggybacking = transport mechanism. =20 >>=20 >> I share Ben's concern that we have over optimized the content of the = overload report in a way that makes implementations brittle, = interoperability more difficult to achieve and extensibility more = complex. And what do we gain from this optimization? A few bites in = answer messages. >>=20 >> Self contained overload reports, transported using the piggybacking = mechanism, is a cleaner solution. >>=20 >> Steve >>=20 >> On 11/29/13 8:31 AM, lionel.morand@orange.com wrote: >> I totally agree with Nirav. No need to revert at this stage the = working assumption on piggybacking of OLR in application answer = messages, especially when the aim is to define a basic mechanism called = "reduction". >>=20 >> Anyone would be able to further add extra info for optimization if = needed but there is no need at all for the basic mechanism. >>=20 >> Regards, >>=20 >> Lionel >>=20 >> -----Message d'origine----- >> De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot = (nsalot) >> Envoy=E9 : vendredi 29 novembre 2013 12:24 >> =C0 : Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org = list >> Cc : Ben Campbell >> Objet : Re: [Dime] DOIC: Self-Contained OLRs >>=20 >> Jouni, Ben, >>=20 >> I am totally against the idea of self-contained OC-OLR specifically = since we have adopted the principles of piggybacking the OC-OLR over = existing application message. >> Self-contained OC-OLR - which means adding all the information which = defines the scope of the OC-OLR into the OC-OLR - does not make sense in = the piggybacking approach. In fact, it is adding lot of information, = which is anyway available within the message containing the OC-OLR, into = the OC-OLR. So it is adding lot of redundant information in a message = which increases the processing requirement for the sender as well as the = receiver. (And this is un-optimization, in my view). >>=20 >> Besides, I am not convinced with the other reasons provided here: >> - One software module within a node can provide OC-OLR to another = software module in the same node without passing other related info >> Within a node, based on the design, lots of information may need to = be passed between two software modules and we cannot optimize those = aspects by replicating unnecessary information in a protocol message. >> In summary, it is node's internal software design issue and we need = not optimize that at protocol level. >>=20 >> - Once the reporting node realizes that it is overloaded, it has to = wait for right answer to send OC-OLR >> What is the point of sending OC-OLR for a context for which there is = no messaging? Why should the reacting node care if it never sends a = message for a context for which the reporting node is overloaded? >> So this waiting is justified since it ensures that the overload is = reported only when necessary and only to the applicable reacting node. = Not to all the nodes in the network. >>=20 >> - The agent needs to wait for the answer generated by the server and = the right context >> The same argument as applicable for the server applies here. The = agent need not send out-of-context overload info to a node. >> Why should reacting node receive/process/store the overload info = for the scope for which it is not sending any messages. >>=20 >> - For sending OC-OLR in dedicated Diameter application??? >> Piggybacking was the first basic principle we agreed before putting = other principles in place. So we may want to go back the drawing board = if we decide to change this principle. >>=20 >> Regards, >> Nirav. >>=20 >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen >> Sent: Friday, November 29, 2013 2:50 PM >> To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list >> Cc: Ben Campbell >> Subject: Re: [Dime] DOIC: Self-Contained OLRs >>=20 >>=20 >>=20 >> So, are we reaching any level of consensus here? >>=20 >> - JOuni >>=20 >> (as a note.. that we are converging back to where we started with = OLRs ;) >>=20 >>=20 >>=20 >> On Nov 28, 2013, at 12:40 PM, "Wiehe, Ulrich (NSN - DE/Munich)" = wrote: >>=20 >> Hi, >>=20 >> another question: >>=20 >> If we go for explicit self contained OLRs, why would we then need the = ReportType? >>=20 >> The realm-type OLR would explicitly contain application-Id, Realm, = but no Host whereas the host-type OLR would explicitly contain = application-Id, Host, but probably (I'm not sure) no Realm. >>=20 >> Ulrich >>=20 >>=20 >>=20 >> -----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 >>=20 >> Hi, >>=20 >> 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. >>=20 >> Lionel >>=20 >> -----Message d'origine----- >> De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich=20= >> (NSN - DE/Munich) Envoy=E9 : jeudi 28 novembre 2013 10:26 =C0 : ext = Jouni=20 >> Korhonen; Ben Campbell Cc : dime@ietf.org list Objet : Re: [Dime]=20 >> DOIC: Self-Contained OLRs >>=20 >> Hi, >>=20 >> 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? >>=20 >> Ulrich >>=20 >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Jouni=20 >> Korhonen >> Sent: Wednesday, November 27, 2013 11:44 PM >> To: Ben Campbell >> Cc: dime@ietf.org list >> Subject: Re: [Dime] DOIC: Self-Contained OLRs >>=20 >>=20 >> On Nov 28, 2013, at 12:27 AM, Ben Campbell wrote: >>=20 >> Hi, >>=20 >> I mentioned in another thread that I prefer putting an explicit=20 >> ReportType AVP in an OLR, rather than >>=20 >> The more I spent time thinking/writing the actual procedures on the=20= >> endpoints, the more it makes sense to me to keep the ReportType in = the=20 >> OC-OLR. Even if the baseline does not have agent overload etc, the=20 >> ReportType fits well to the "endpoint principle" we have in the = draft.=20 >> It indeed gives more tools to make a host vs. realm base decision on = the reacting node and is plain more clear. >>=20 >> I skip the rest of the mail.. too much text ;-) >>=20 >>=20 >> - Jouni >>=20 >>=20 >>=20 >>=20 >>=20 >> 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. >>=20 >> 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. >>=20 >> I think this approach is a mistake. I would greatly prefer that we = explicitly include such values in the OLR itself, for multiple reasons: >>=20 >> 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. >>=20 >> 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.=20= >>=20 >> 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. >>=20 >> 3) Implicit values don't work at all for certain problems. For=20 >> example, if an agent needs to originate an OLR, it typically needs to=20= >> insert that OLR into an existing Diameter answer created by a server.=20= >> It can't create its own answer without affecting the application=20 >> state. If the responding node assumes the OLR comes from or refers to=20= >> the node identified by the Origin-Host AVP in the enclosing answer,=20= >> things break. (For examples of when an agent needs to send OLRs that=20= >> are distinct from those sent by a server, see Steve's agent overload=20= >> draft, or my dh/dr example.) >>=20 >> OTOH, explicit values will work for all cases where we need to = associate some arbitrary value with an OLR. >>=20 >> 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. >>=20 >> 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. >>=20 >> Thanks! >>=20 >> Ben. >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >>=20 >> _______________________________________________ >> 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 >>=20 >> = ______________________________________________________________________ >> ___________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations=20 >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20= >> exploites ou copies sans autorisation. Si vous avez recu ce message=20= >> 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. >>=20 >> This message and its attachments may contain confidential or=20 >> 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. >>=20 >>=20 >> _______________________________________________ >> 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 >>=20 >> = __________________________________________________________________________= _______________________________________________ >>=20 >> 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. >>=20 >> 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. >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >>=20 >>=20 >> = __________________________________________________________________________= _______________________________________________ >>=20 >> 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. >>=20 >> 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. >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >=20 >=20 > = __________________________________________________________________________= _______________________________________________ >=20 > 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. >=20 > 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. >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From lionel.morand@orange.com Wed Dec 4 16:03:40 2013 Return-Path: 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 C046F1AE1CF for ; Wed, 4 Dec 2013 16:03:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 HSHWfr07iopX for ; Wed, 4 Dec 2013 16:03:35 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id D84401ADFBD for ; Wed, 4 Dec 2013 16:03:34 -0800 (PST) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id D9D9637469F; Thu, 5 Dec 2013 01:03:30 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id BB01915807E; Thu, 5 Dec 2013 01:03:27 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0158.001; Thu, 5 Dec 2013 01:03:27 +0100 From: To: Ben Campbell , "Wiehe, Ulrich (NSN - DE/Munich)" Thread-Topic: [Dime] DOIC: Self-Contained OLRs Thread-Index: AQHO8TnZo7y6FFeeaEmQ38aKczpYQJpEuAIg Date: Thu, 5 Dec 2013 00:03:26 +0000 Message-ID: <876_1386201807_529FC2CF_876_10551_1_6B7134B31289DC4FAF731D844122B36E3295E0@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> , <5BCBA1FC2B7F0B4C9D935572D90006681519C087@DEMUMBX014.nsn-intra.net> <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> <5BCBA1FC2B7F0B4C9D935572D90006681519D57E@DEMUMBX014.nsn-intra.net> <6EC4AFCD-E8BB-4EF8-92C8-3FD7387FCD9D@nostrum.com> In-Reply-To: <6EC4AFCD-E8BB-4EF8-92C8-3FD7387FCD9D@nostrum.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.12.4.75415 Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 00:03:41 -0000 Hi Ben, Ulrich, Please see below. Lionel -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Ben Campbell Envoy=E9=A0: mercredi 4 d=E9cembre 2013 22:43 =C0=A0: Wiehe, Ulrich (NSN - DE/Munich) Cc=A0: dime@ietf.org Objet=A0: Re: [Dime] DOIC: Self-Contained OLRs On Dec 4, 2013, at 2:23 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: > Ben, >=20 > No. One OLR per answer (if no extension is supported). I don't understand the intent. What difference does an extension make? Do y= ou consider additional ReportType values to be extensions? In particular, if we end up supporting both Realm and Server type reports i= n the base, I think you should be able to have one of each in an answer. Bu= t I agree, two Realm reports or two Server reports in the same answer can c= reate a conflict. [LM] it is why it is proposed to avoid multiple OLRs with the same report t= ype in the same answer. >=20 > What is an ambiguous OLR? > What should the client do when receiving 5 OLRs in one answer three of wh= ich are ambiguous? >=20 > Let's try to avoid complexity. >=20 > Ulrich=20 >=20 > -----Original Message----- > From: ext Ben Campbell [mailto:ben@nostrum.com]=20 > 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 >=20 >=20 > On Dec 3, 2013, at 9:56 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >=20 >> Steve, >>=20 >> 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 e= xtension (like agent overload) must not be forced to process more than one = OLR per answer. >>=20 >=20 > Can we restate the "not forced to process" to say "not be forced to choos= e between ambiguous" OLRs? >=20 >> Ulrich >>=20 >> 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 >>=20 >> I am strongly against saying that there can never be more than one overl= oad report in a message. This makes it impossible to extend the base proto= col to support agent overload. >>=20 >> It also makes it more difficult to achieve the more granular differentia= ted overload report types that Nirav is suggesting. >>=20 >> Steve >>=20 >> On 12/3/13 7:52 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >> Hi Lionel, >>=20 >> the more OLRs a client must process (in every answer) the more complex i= s the solution. I don't see how it helps that multiple OLRs are not mandate= d for the reporting node; the reacting node would still be required to proc= ess all received OLRs. >>=20 >> Best regards >> Ulrich >>=20 >> -----Original Message----- >> From: ext lionel.morand@orange.com [mailto:lionel.morand@orange.com]=20 >> 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 >>=20 >> Hi Ulrich, >>=20 >> I don't see the complexity if each OLR instance received is clearly dist= inguished by the Report-Type.=20 >> Again, it is not said that it will be mandated for any deployment to rel= y on multiple OLR instances.=20 >>=20 >> Regards, >>=20 >> Lionel >>=20 >> -----Message d'origine----- >> De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 >> Envoy=E9 : mardi 3 d=E9cembre 2013 11:46 >> =C0 : MORAND Lionel IMT/OLN; ext Maria Cruz Bartolome; dime@ietf.org list >> Objet : RE: [Dime] DOIC: Self-Contained OLRs >>=20 >> Hi Lionel, >>=20 >> my point is simple: >>=20 >> 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 t= hem. >> Clients must not be forced to process additional OLRs. >>=20 >> Ulrich=20 >>=20 >> -----Original Message----- >> From: ext lionel.morand@orange.com [mailto:lionel.morand@orange.com]=20 >> 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 >>=20 >> Hi Ulrich, >>=20 >> Honestly, I don't get your point. >> It could be done as you've described below and there is no reason to pro= hibit this way of doing. The consequence for the client is that it will nev= er receive more than one OLR. I think it was never mandated that an agent M= UST insert a realm-based OLR. >> But there is no reason to prohibit the presence of both OLRs in the same= answer. >>=20 >> Regards, >>=20 >> Lionel=20 >>=20 >> -----Message d'origine----- >> De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NS= N - DE/Munich) >> Envoy=E9 : mardi 3 d=E9cembre 2013 10:21 >> =C0 : ext Maria Cruz Bartolome; dime@ietf.org list >> Objet : Re: [Dime] DOIC: Self-Contained OLRs >>=20 >> Dear MCruz, >> thank you for your support. >>=20 >> 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 r= eturns 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 Desti= nation Host in which case any realm-type OLR inserted by A would be useless= to C.=20 >>=20 >> 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 reque= st. S then returns a host-type OLR to A, and A replaces the host-type OLR r= eceived from S with a realm-type OLR. There is no need that the host-type O= LR 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 Destinati= on Host in which case any host-type OLR conveyed to C would be useless to C. >>=20 >> In any case there is no need for more than one OLR in an answer. >>=20 >> Ulrich >>=20 >>=20 >>=20 >>=20 >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Ba= rtolome >> Sent: Monday, December 02, 2013 4:55 PM >> To: dime@ietf.org list >> Subject: Re: [Dime] DOIC: Self-Contained OLRs >>=20 >> Dear all, >>=20 >> My interpretation is as well in line to what is summarized by Lionel bel= ow. >>=20 >> 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, a= nd 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 o= n the realm overload status in the corresponding answer, if required. >>=20 >> Best regards >> /MCruz >>=20 >> -----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 >>=20 >>=20 >> My understanding (and current editing) has already been towards what Lio= nel said below. >>=20 >> - Jouni >>=20 >>=20 >> On Dec 2, 2013, at 4:19 PM, lionel.morand@orange.com wrote: >>=20 >> I agree with last part. It was the reason I've reconsidered my position = on the need for the Report-Type. >>=20 >> 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 D= estination-Host is not in the answer. So receiving a host-based OLR in resp= onse 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 po= sitive 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" o= ffered by the use of the Report-Type. But there is nothing wrong. It is onl= y to comply with the Diameter routing principle: subsequent requests from t= he client could include a destination-host or not. So the client needs to k= now which reduction to apply from a previous answer. >>=20 >> 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 c= ontext based on the type of request. >>=20 >> Regards, >>=20 >> Lionel >>=20 >>=20 >> De : Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Envoy=E9 : lundi 2= =20 >> d=E9cembre 2013 14:58 =C0 : Wiehe, Ulrich (NSN - DE/Munich) Cc :=20 >> dime@ietf.org list; ext Jouni Korhonen; MORAND Lionel IMT/OLN; Ben=20 >> Campbell Objet : RE: [Dime] DOIC: Self-Contained OLRs >>=20 >> Ulrich, >>=20 >> 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? >>=20 >> I would prefer to derive the context of the OLR based on the message whi= ch contains the OLR. >>=20 >> Back to the topic of this thread, I don't think we need to define an "op= tional" optimization at this stage. Either it is respected by all the nodes= supporting the solution or we drop that optimization. >>=20 >> Regards, >> Nirav. >>=20 >> On Dec 2, 2013 5:27 PM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: >> Nirav, >>=20 >> If the reacting node sends a request without Destination Host, a realm-t= ype OLR in the answer would be in-context whereas a host-type OLR in the an= swer would be out of context. >>=20 >> Similarly, if the reacting node sends a request containing Destination H= ost, a realm-type OLR in the answer would be out-of-context and a host-type= OLR in the answer would be in-context. >>=20 >> Ulrich >>=20 >>=20 >>=20 >> -----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= =20 >> Jouni Korhonen; Ben Campbell >> Cc: dime@ietf.org list >> Subject: RE: [Dime] DOIC: Self-Contained OLRs >>=20 >> Ulrich, >>=20 >> I have a basic question. >>=20 >> 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 o= r host-type? >>=20 >> Regards, >> Nirav. >>=20 >> -----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=20 >> Korhonen; Ben Campbell >> Cc: dime@ietf.org list >> Subject: RE: [Dime] DOIC: Self-Contained OLRs >>=20 >> Hi Nirav, >>=20 >> please see inline. >>=20 >> Regards >> Ulrich >>=20 >> -----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= =20 >> Jouni Korhonen; Ben Campbell >> Cc: dime@ietf.org list >> Subject: RE: [Dime] DOIC: Self-Contained OLRs >>=20 >> Ulrich, >>=20 >> When the client sends request containing destination-realm (and not cont= aining destination-host), it gets back answer containing origin-host (set b= y the actual server) as well as host-type OLR. >> So purely from the response message perspective, the host-type OLR in th= is response message is not out-of-context information.=20 >> [Wiehe, Ulrich (NSN - DE/Munich)] But we do not purely take the response= message perspective. The client sends a request of type x (destination hos= t =3Dx1, destination realm =3Dx2 application=3D 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 v= alue of Report-Type in the answer whether Destination Host was present in t= he request... >>=20 >> On the other hand, we discussed - as part of Maria Cruz's alternative so= lution - to define the response message's context based on the request mess= age. And hence if the request message was sent to destination-realm, the co= rresponding response message can only contain realm-type OLR. >> But this requires the client to remember the context of the request whil= e processing the response and hence it was considered as introducing unnece= ssary complexity.=20 >> [Wiehe, Ulrich (NSN - DE/Munich)] I agree. This means: the report-type A= VP is needed to let the client deduce from information received in the answ= er whether the request contained a destination host. It does not mean that = we need two OLRs in one answer. >>=20 >> If we strictly want to ensure that the realm-type OLR is not sent=20 >> out-of-context [Wiehe, Ulrich (NSN - DE/Munich)] That was not my=20 >> proposal. My proposal was to clearly mark out-of-context OLRs in=20 >> answer messages (if we allow including out-of-context OLRs) >>=20 >> , then we should agree to Lionel's alternative solution - to send realm-= type OLR only when the destination-realm based request is rejected. So basi= cally, realm-type OLR is never included in a response message which contain= s origin-host AVP. (And I am ready to reconsider the same if we want to ens= ure the context of the response message and the OLR it contains). >>=20 >> However, as per our current agreement, we are introducing Report-Type AV= P [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 o= ne 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=20 >> (NSN - DE/Munich)] only the out-of-context one >>=20 >> , 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 o= r agent wants to offer this optimization), and may be processed by the reac= ting node (if the reacting node wants to make use of this optimization). >>=20 >> and what is the point of defining Report-Type AVP? >> [Wiehe, Ulrich (NSN - DE/Munich)] to let the reacting node deduce from i= nformation received in the answer whether the corresponding request contain= ed a destination host (so there is no need to remember). >>=20 >>=20 >> In summary, if we define Report-Type AVP and corresponding handling at t= he 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? >>=20 >> 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 optimiz= ation but the incusion of out-of-context OLRs. And I'm ok not to proceed wi= th this optimization as it is not needed. >>=20 >> Regards, >> Nirav. >>=20 >> -----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=20 >> Korhonen; Ben Campbell >> Cc: dime@ietf.org list >> Subject: RE: [Dime] DOIC: Self-Contained OLRs >>=20 >> Hi Nirav, >>=20 >> 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, thi= s OLR is out-of-context. >> Similary, when the client sends a request containing destination host an= d gets back an answer containing a realm-type OLR, this OLR is out-of-conte= xt. >> There is nothing wrong with storing such out-of-context OLRs at the clie= nt, but it is simply not needed as the client will learn this OLR from resp= onses received within the context. >>=20 >> Best regards >> Ulrich >>=20 >>=20 >> -----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= =20 >> Jouni Korhonen; Ben Campbell >> Cc: dime@ietf.org list >> Subject: RE: [Dime] DOIC: Self-Contained OLRs >>=20 >> Hi Ulrich, >>=20 >> If an additional OLR is present with a different ReportType, why it shou= ld be ignored by the reacting node? >>=20 >> Regards, >> Nirav. >>=20 >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich=20 >> (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 >>=20 >> Hi Lionel, >>=20 >> there is nothing missing exept the clarification that everything works f= ine when only one OLR (the OLR created by the reporting endpoint) is presen= t in the answer and additional OLRs (not created by the reporting endpoint)= may just be present as an optional optimization i.e. optionally inserted b= y the reporting endpoint and optionally ignored by the reacting endpoint. >>=20 >> Ulrich >>=20 >>=20 >> -----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 >>=20 >> Hi Ulrich, >>=20 >> Using the Report Type "host report", you know that the OLR applies for s= ubsequent 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.=20 >>=20 >> It is not so important to know what the type of request was and which no= de 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 architect= ure to provide the same information. >>=20 >> I'm not sure of what is missing in this reasoning... >>=20 >> Lionel >>=20 >> -----Message d'origine----- >> De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 >> Envoy=E9 : jeudi 28 novembre 2013 11:30 =C0 : MORAND Lionel IMT/OLN; ext= =20 >> Jouni Korhonen; Ben Campbell Cc : dime@ietf.org list Objet : RE:=20 >> [Dime] DOIC: Self-Contained OLRs >>=20 >> Lionel, >>=20 >> my understanding was that _the_ reporting end point provides _the_ OLR. >>=20 >> 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 additiona= l OLR created by another node. >>=20 >> We have two cases: >> a) The request sent by the client (reacting end point) contains no Desti= nation Host. The agent (reporting node) (after forwarding the request to th= e 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 O= LR as learned from the selected server. The client may ignore the addition= al OLR. >> b) The request sent by the client (reacting endpoint) contains the Desti= nation Host. The Server (reporting node) returns a host-type OLR as the act= ual reporting-node-created OLR in the answer. The agent may optionally inse= rt a realm-type OLR as additional OLR to the answer. The client may ignore = the additional OLR. >>=20 >> Ulrich >>=20 >>=20 >>=20 >> -----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 >>=20 >> Hi, >>=20 >> There is no assumption on which entity is providing the realm overload s= tatus. It could be provided an agent inserting this info in answers receive= d 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 se= rver itself, one for the realm for new request sent to the realm with only = Dest-Realm AVP. >>=20 >> Lionel >>=20 >> -----Message d'origine----- >> De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich=20 >> (NSN - DE/Munich) Envoy=E9 : jeudi 28 novembre 2013 10:26 =C0 : ext Joun= i=20 >> Korhonen; Ben Campbell Cc : dime@ietf.org list Objet : Re: [Dime]=20 >> DOIC: Self-Contained OLRs >>=20 >> Hi, >>=20 >> I don't see how the possibility to send more than one OLR in an answer i= s aligned with the "endpoint principle". If the ReportType is "realm" this = indicates to the reacting end point that the reporting end point is an agen= t (e.g. SFE) rather than a server. If the ReportType is "host" this indicat= es to the reacting end point that the reporting end point is a server. How = can the reporting end point be both agent and server? >>=20 >> Ulrich >>=20 >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Jouni=20 >> Korhonen >> Sent: Wednesday, November 27, 2013 11:44 PM >> To: Ben Campbell >> Cc: dime@ietf.org list >> Subject: Re: [Dime] DOIC: Self-Contained OLRs >>=20 >>=20 >> On Nov 28, 2013, at 12:27 AM, Ben Campbell wrote: >>=20 >> Hi, >>=20 >> I mentioned in another thread that I prefer putting an explicit=20 >> ReportType AVP in an OLR, rather than >>=20 >> The more I spent time thinking/writing the actual procedures on the endp= oints, 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 p= lain more clear. >>=20 >> I skip the rest of the mail.. too much text ;-) >>=20 >>=20 >> - Jouni >>=20 >>=20 >>=20 >>=20 >>=20 >> making a responding node infer the type or meaning of the OLR from a Dia= meter request that corresponds to the answer containing the OLR. My reasons= for that go beyond just ReportType, so I'm starting a separate thread. >>=20 >> As currently described, a consumer of an OLR must infer several things f= rom other context. In most cases, that context is in the Diameter answer th= at carries the OLR. For example, the OLR implicitly refers to the applicati= on identified by the Application-Id field of the enclosing answer, the real= m identified by Origin-Realm, and so on. This means that the "meaning" of a= n OLR cannot be determined from the OLR contents alone; OLRs only have mean= ing in the context of the enclosing answer. If you moved an OLR from one an= swer to another, it's meaning may change completely. >>=20 >> I think this approach is a mistake. I would greatly prefer that we expli= citly include such values in the OLR itself, for multiple reasons: >>=20 >> 1) It's more complex to interpret implicit, contextual values than expli= cit values. The consumer cannot simply look at the OLR; it must look in var= ious other AVPs to find all the information it needs. For example, I think = a common software design for overload control processing to be separated fr= om 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 "co= ntext" avps that must be interpreted can grow large. This approach is error= prone, and will likely encourage brittle, hard-to-maintain code. Self-cont= ained OLRs would keep all the information related to overload in one place.= making for simpler implementations. >>=20 >> 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 inse= rt OLRs into answers created by other nodes.=20 >>=20 >> If the reporting node screws this up, the meaning of the OLR may change = significantly. So again, implicit meaning gives us error prone implementati= ons. Self-contained OLRs are simpler to create and send. >>=20 >> 3) Implicit values don't work at all for certain problems. For=20 >> example, if an agent needs to originate an OLR, it typically needs=20 >> to insert that OLR into an existing Diameter answer created by a server. >> It can't create its own answer without affecting the application=20 >> state. If the responding node assumes the OLR comes from or refers=20 >> to the node identified by the Origin-Host AVP in the enclosing=20 >> answer, things break. (For examples of when an agent needs to send=20 >> OLRs that are distinct from those sent by a server, see Steve's=20 >> agent overload draft, or my dh/dr example.) >>=20 >> OTOH, explicit values will work for all cases where we need to associate= some arbitrary value with an OLR. >>=20 >> 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 ove= rload reports were self-contained, one could just reuse the report format w= e specify here. But if the meaning of an OLR depends on the way it's transp= orted, this won't work. We would have to create a new or significantly modi= fied OLR format if we found a need to transport OLRs in different ways. Sel= f-contained OLRs would allow much greater flexibility. >>=20 >> So, in summary, I think that self-contained OLRs would lead to simpler i= mplementations, less brittle deployments, and more flexibility for future e= volution of standards. >>=20 >> Thanks! >>=20 >> Ben. >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >>=20 >> _______________________________________________ >> 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 >>=20 >> ______________________________________________________________________ >> ___________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations confi= dentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites = ou copies sans autorisation. Si vous avez recu ce message par erreur, veuil= lez 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. Merc= i. >>=20 >> This message and its attachments may contain confidential or privileged = information that may be protected by law; they should not be distributed, u= sed or copied without authorisation. >> If you have received this email in error, please notify the sender and d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >>=20 >>=20 >> ______________________________________________________________________ >> ___________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations confi= dentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites = ou copies sans autorisation. Si vous avez recu ce message par erreur, veuil= lez 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. Merc= i. >>=20 >> This message and its attachments may contain confidential or privileged = information that may be protected by law; they should not be distributed, u= sed or copied without authorisation. >> If you have received this email in error, please notify the sender and d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> ______________________________________________________________________ >> ___________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations=20 >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 >> exploites ou copies sans autorisation. Si vous avez recu ce message=20 >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que= les pieces jointes. Les messages electroniques etant susceptibles d'altera= tion, Orange decline toute responsabilite si ce message a ete altere, defor= me ou falsifie. Merci. >>=20 >> This message and its attachments may contain confidential or=20 >> 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 d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >>=20 >>=20 >> _______________________________________________ >> 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 >>=20 >> ________________________________________________________________________= _________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations confi= dentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez r= ecu 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. >>=20 >> 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 d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >>=20 >>=20 >> ________________________________________________________________________= _________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations confi= dentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez r= ecu 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. >>=20 >> 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 d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >>=20 >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >=20 > _______________________________________________ > 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 confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. From lionel.morand@orange.com Wed Dec 4 16:08:14 2013 Return-Path: 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 8E05A1AE0F3 for ; Wed, 4 Dec 2013 16:08:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 WQswXn7gIBPq for ; Wed, 4 Dec 2013 16:08:09 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 62E891ADFBD for ; Wed, 4 Dec 2013 16:08:08 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 8E829264427; Thu, 5 Dec 2013 01:08:04 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 7246C238055; Thu, 5 Dec 2013 01:08:04 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0158.001; Thu, 5 Dec 2013 01:08:04 +0100 From: To: Ben Campbell , "Wiehe, Ulrich (NSN - DE/Munich)" Thread-Topic: [Dime] DOIC: Self-Contained OLRs Thread-Index: AQHO8Tn7o7y6FFeeaEmQ38aKczpYQJpEuIWA Date: Thu, 5 Dec 2013 00:08:03 +0000 Message-ID: <14594_1386202084_529FC3E4_14594_12015_1_6B7134B31289DC4FAF731D844122B36E3296E9@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D90006681519BC90@DEMUMBX014.nsn-intra.net> <6390_1385631044_52970D44_6390_18593_1_6B7134B31289DC4FAF731D844122B36E30748E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BD19@DEMUMBX014.nsn-intra.net> <17872_1385720008_529868C8_17872_2613_1_6B7134B31289DC4FAF731D844122B36E3096B8@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BF1B@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681519BFAE@DEMUMBX014.nsn-intra.net> <529CA616.2040205@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006681519D59C@DEMUMBX014.nsn-intra.net> <8582D429-25EB-426E-A0F6-982836FC3D4F@nostrum.com> In-Reply-To: <8582D429-25EB-426E-A0F6-982836FC3D4F@nostrum.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.12.4.163016 Cc: "dime@ietf.org list" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 00:08:15 -0000 Ben, Ulrich, Considering the base' solution with Report type "Host" or "Realm", I don't = understand the following statement "The reporting endpoint should not send = in OLRs not supported by the reacting node". The Reduction algo will say "I'm/be prepared to receive OLR from Host or Re= alm", so why will the reacting node not support one of them? Regards, Lionel -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Ben Campbell Envoy=E9=A0: mercredi 4 d=E9cembre 2013 22:44 =C0=A0: Wiehe, Ulrich (NSN - DE/Munich) Cc=A0: dime@ietf.org list Objet=A0: Re: [Dime] DOIC: Self-Contained OLRs On Dec 4, 2013, at 2:40 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: > Ben, >=20 > we have this feature negotiation/adverisement mechanism that allows the r= eporting endpoint to understand what is supported by the reacting endpoint.= The reporting endpoint should not send in OLRs not supported by the reacti= ng node. >=20 Assuming we add ReportType to the list of things for which we advertise sup= port, I agree. > Ulrich >=20 >=20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Ben Campbell > Sent: Wednesday, December 04, 2013 12:00 AM > To: Steve Donovan > Cc: dime@ietf.org list > Subject: Re: [Dime] DOIC: Self-Contained OLRs >=20 >=20 > On Dec 2, 2013, at 9:24 AM, Steve Donovan wrot= e: >=20 >> Ulrich, >>=20 >> Designing an overload solution that allows a reacting node to ignore an = overload report seems strange to me. The system is under stress. Overload= reports should be reacted to as quickly as possible, independent of how th= e overload report is received by the reacting node. >>=20 >=20 > While I don't agree with the "out-of-context" concern, I can see saying t= hat a reacting node ignore an OLR if it does not understand the ReportType.= Otherwise, it doesn't understand the meaning of the report, and is likely = to do the wrong thing. An alternative might be to say the reacting node sh= ould treat anything it doesn't understand as "Realm". >=20 >> Steve >>=20 >> On 12/1/13 1:38 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >>> Hi Nirav, >>>=20 >>> When the client sends a request that contains only destination realm bu= t no destination host an gets back an answer containing a host-type OLR, th= is OLR is out-of-context. >>> Similary, when the client sends a request containing destination host a= nd gets back an answer containing a realm-type OLR, this OLR is out-of-cont= ext. >>> There is nothing wrong with storing such out-of-context OLRs at the cli= ent, but it is simply not needed as the client will learn this OLR from res= ponses received within the context. >>>=20 >>> Best regards >>> Ulrich=20 >>>=20 >>>=20 >>> -----Original Message----- >>> From: ext Nirav Salot (nsalot) [ >>> mailto:nsalot@cisco.com >>> ]=20 >>> Sent: Friday, November 29, 2013 4:49 PM >>> To: Wiehe, Ulrich (NSN - DE/Munich); ext=20 >>> lionel.morand@orange.com >>> ; ext Jouni Korhonen; Ben Campbell >>> Cc:=20 >>> dime@ietf.org >>> list >>> Subject: RE: [Dime] DOIC: Self-Contained OLRs >>>=20 >>> Hi Ulrich, >>>=20 >>> If an additional OLR is present with a different ReportType, why it sho= uld be ignored by the reacting node? >>>=20 >>> Regards, >>> Nirav. >>>=20 >>> -----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=20 >>> lionel.morand@orange.com >>> ; ext Jouni Korhonen; Ben Campbell >>> Cc:=20 >>> dime@ietf.org >>> list >>> Subject: Re: [Dime] DOIC: Self-Contained OLRs >>>=20 >>> Hi Lionel, >>>=20 >>> there is nothing missing exept the clarification that everything works = fine when only one OLR (the OLR created by the reporting endpoint) is prese= nt 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. >>>=20 >>> Ulrich >>>=20 >>>=20 >>> -----Original Message----- >>> From: ext=20 >>> 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:=20 >>> dime@ietf.org >>> list >>> Subject: RE: [Dime] DOIC: Self-Contained OLRs >>>=20 >>> Hi Ulrich, >>>=20 >>> 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 use= d as soon as a request needs to be sent without destination-realm.=20 >>>=20 >>> It is not so important to know what the type of request was and which n= ode inserts this information. It can be any node having sufficient knowledg= e of the realm overload status. An agent in the path could be this one but,= for instance, future development could allow a distributed server architec= ture to provide the same information. >>>=20 >>> I'm not sure of what is missing in this reasoning... >>>=20 >>> Lionel >>>=20 >>> -----Message d'origine----- >>> De : Wiehe, Ulrich (NSN - DE/Munich) [ >>> mailto:ulrich.wiehe@nsn.com] Envoy=E9 : jeudi 28 novembre 2013 11:30 = =C0 : MORAND Lionel IMT/OLN; ext Jouni Korhonen; Ben Campbell Cc : dime@iet= f.org >>> list Objet : RE: [Dime] DOIC: Self-Contained OLRs >>>=20 >>> Lionel, >>>=20 >>> my understanding was that _the_ reporting end point provides _the_ OLR. >>>=20 >>> 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 addition= al OLR created by another node. >>>=20 >>> We have two cases: >>> a) The request sent by the client (reacting end point) contains no Dest= ination Host. The agent (reporting node) (after forwarding the request to t= he selected server and receiving the answer) returns a realm-type OLR as th= e actual reporting-node-created OLR and optionally in addition a host-type = OLR as learned from the selected server. The client may ignore the additio= nal OLR. >>> b) The request sent by the client (reacting endpoint) contains the Dest= ination Host. The Server (reporting node) returns a host-type OLR as the ac= tual reporting-node-created OLR in the answer. The agent may optionally ins= ert a realm-type OLR as additional OLR to the answer. The client may ignore= the additional OLR. >>>=20 >>> Ulrich >>>=20 >>>=20 >>>=20 >>> -----Original Message----- >>> From: ext=20 >>> 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:=20 >>> dime@ietf.org >>> list >>> Subject: RE: [Dime] DOIC: Self-Contained OLRs >>>=20 >>> Hi, >>>=20 >>> There is no assumption on which entity is providing the realm overload = status. It could be provided an agent inserting this info in answers receiv= ed 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 successfu= l answer from the server for an initial request with only Dest-Realm AVP, i= t should be possible to have both report types in the answer: one for the s= erver itself, one for the realm for new request sent to the realm with only= Dest-Realm AVP. >>>=20 >>> Lionel >>>=20 >>> -----Message d'origine----- >>> De : DiME [ >>> mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN - DE/Mun= ich) Envoy=E9 : jeudi 28 novembre 2013 10:26 =C0 : ext Jouni Korhonen; Ben = Campbell Cc : dime@ietf.org >>> list Objet : Re: [Dime] DOIC: Self-Contained OLRs >>>=20 >>> Hi, >>>=20 >>> 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 age= nt (e.g. SFE) rather than a server. If the ReportType is "host" this indica= tes to the reacting end point that the reporting end point is a server. How= can the reporting end point be both agent and server? >>>=20 >>> Ulrich >>>=20 >>> -----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:=20 >>> dime@ietf.org >>> list >>> Subject: Re: [Dime] DOIC: Self-Contained OLRs >>>=20 >>>=20 >>> On Nov 28, 2013, at 12:27 AM, Ben Campbell=20 >>> >>> wrote: >>>=20 >>>=20 >>>> Hi, >>>>=20 >>>> I mentioned in another thread that I prefer putting an explicit=20 >>>> ReportType AVP in an OLR, rather than >>>>=20 >>> The more I spent time thinking/writing the actual procedures on the end= points, 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 mor= e tools to make a host vs. realm base decision on the reacting node and is = plain more clear. >>>=20 >>> I skip the rest of the mail.. too much text ;-) >>>=20 >>>=20 >>> - Jouni >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>> making a responding node infer the type or meaning of the OLR from a D= iameter request that corresponds to the answer containing the OLR. My reaso= ns for that go beyond just ReportType, so I'm starting a separate thread. >>>>=20 >>>> 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 applica= tion identified by the Application-Id field of the enclosing answer, the re= alm 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 me= aning in the context of the enclosing answer. If you moved an OLR from one = answer to another, it's meaning may change completely. >>>>=20 >>>> I think this approach is a mistake. I would greatly prefer that we exp= licitly include such values in the OLR itself, for multiple reasons: >>>>=20 >>>> 1) It's more complex to interpret implicit, contextual values than exp= licit values. The consumer cannot simply look at the OLR; it must look in v= arious other AVPs to find all the information it needs. For example, I thin= k a common software design for overload control processing to be separated = from application processing. The consumer cannot simply hand the OLR to tha= t module and expect things to work. The OC module must not only parse the O= LR, but parse any other AVPs that are relevant. As OLR contents get extende= d (assumedly following the same strategy as the base spec), the number of "= context" avps that must be interpreted can grow large. This approach is err= or prone, and will likely encourage brittle, hard-to-maintain code. Self-co= ntained OLRs would keep all the information related to overload in one plac= e. making for simpler implementations. >>>>=20 >>>> 2) It's more complex for the reporting node to send implicit values th= an explicit values. The sender cannot simply set the context to match the O= LR--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 righ= t answer that contains the right context before it can send the OLR. This i= s particularly troublesome for agents, since they will typically have to in= sert OLRs into answers created by other nodes.=20 >>>>=20 >>>> If the reporting node screws this up, the meaning of the OLR may chang= e significantly. So again, implicit meaning gives us error prone implementa= tions. Self-contained OLRs are simpler to create and send. >>>>=20 >>>> 3) Implicit values don't work at all for certain problems. For=20 >>>> example, if an agent needs to originate an OLR, it typically needs to= =20 >>>> insert that OLR into an existing Diameter answer created by a server.= =20 >>>> It can't create its own answer without affecting the application=20 >>>> state. If the responding node assumes the OLR comes from or refers to= =20 >>>> the node identified by the Origin-Host AVP in the enclosing answer,=20 >>>> things break. (For examples of when an agent needs to send OLRs that= =20 >>>> are distinct from those sent by a server, see Steve's agent overload= =20 >>>> draft, or my dh/dr example.) >>>>=20 >>>> OTOH, explicit values will work for all cases where we need to associa= te some arbitrary value with an OLR. >>>>=20 >>>> 4) Implicit values seriously constrain the future evolution of Diamete= r OC standards. For example, lets say we find a good reason to allow OLRs t= o be sent out of band, or be sent in a dedicated Diameter application. If o= verload 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 tran= sported, this won't work. We would have to create a new or significantly mo= dified OLR format if we found a need to transport OLRs in different ways. S= elf-contained OLRs would allow much greater flexibility. >>>>=20 >>>> 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. >>>>=20 >>>> Thanks! >>>>=20 >>>> Ben. >>>> _______________________________________________ >>>> DiME mailing list >>>>=20 >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >>> _______________________________________________ >>> DiME mailing list >>>=20 >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>>=20 >>> _______________________________________________ >>> DiME mailing list >>>=20 >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>>=20 >>>=20 >>> _______________________________________________________________________= __________________________________________________ >>>=20 >>> Ce message et ses pieces jointes peuvent contenir des informations conf= identielles ou privilegiees et ne doivent donc pas etre diffuses, exploites= ou copies sans autorisation. Si vous avez recu ce message par erreur, veui= llez le signaler a l'expediteur et le detruire ainsi que les pieces jointes= . Les messages electroniques etant susceptibles d'alteration, Orange declin= e toute responsabilite si ce message a ete altere, deforme ou falsifie. Mer= ci. >>>=20 >>> 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 b= een modified, changed or falsified. >>> Thank you. >>>=20 >>>=20 >>> _______________________________________________________________________= __________________________________________________ >>>=20 >>> Ce message et ses pieces jointes peuvent contenir des informations conf= identielles ou privilegiees et ne doivent donc pas etre diffuses, exploites= ou copies sans autorisation. Si vous avez recu ce message par erreur, veui= llez le signaler a l'expediteur et le detruire ainsi que les pieces jointes= . Les messages electroniques etant susceptibles d'alteration, Orange declin= e toute responsabilite si ce message a ete altere, deforme ou falsifie. Mer= ci. >>>=20 >>> 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 b= een modified, changed or falsified. >>> Thank you. >>>=20 >>> _______________________________________________ >>> DiME mailing list >>>=20 >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>>=20 >>> _______________________________________________ >>> DiME mailing list >>>=20 >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>>=20 >>>=20 >>>=20 >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >=20 > _______________________________________________ > 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 confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. From lionel.morand@orange.com Wed Dec 4 16:42:53 2013 Return-Path: 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 680DE1AE1D1 for ; Wed, 4 Dec 2013 16:42:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 DjecCJcKQSyY for ; Wed, 4 Dec 2013 16:42:50 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 5A9A41ADFBA for ; Wed, 4 Dec 2013 16:42:49 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 4B64022C7A0; Thu, 5 Dec 2013 01:42:45 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 3008C238055; Thu, 5 Dec 2013 01:42:45 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0158.001; Thu, 5 Dec 2013 01:42:44 +0100 From: To: Ben Campbell Thread-Topic: [Dime] DOIC: Self-Contained OLRs Thread-Index: AQHO8Tt3o7y6FFeeaEmQ38aKczpYQJpEu0Zg Date: Thu, 5 Dec 2013 00:42:43 +0000 Message-ID: <14594_1386204165_529FCC05_14594_12646_1_6B7134B31289DC4FAF731D844122B36E329907@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D90006681519BC90@DEMUMBX014.nsn-intra.net> <6390_1385631044_52970D44_6390_18593_1_6B7134B31289DC4FAF731D844122B36E30748E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BD31@DEMUMBX014.nsn-intra.net> <47383DC2-1A1B-4D1A-ADD5-9E3CE60B06C8@gmail.com> <8467_1385735507_5298A553_8467_17054_3_6B7134B31289DC4FAF731D844122B36E309D0D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <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> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.12.4.163016 Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 00:42:53 -0000 Hi Ben, 3GPP operational requirements have triggered and driven this work, and 3GPP= will be the main client for this solution (if not the only for a while...)= . Main parties involved in the discussions are 3GPP vendors and 3GPP operat= ors. So instead trying to keep private preserve, we should welcome and enfo= rce cooperative work with 3GPP on this task if we want that the solution de= fined in IETF will be used in 3GPP. Otherwise, 3GPP may decide not to wait = for IETF and develop its own solution, as done in the past (e.g. developing= 3GPP-specific Cx application instead of adopting the IETF-standard Diamete= r SIP application). About the technical discussion, the Req31 says: REQ 31: There are multiple situations where a Diameter node may be overloaded for some purposes but not others. For example, this can happen to an agent or server that supports multiple applications, or when a server depends on multiple external resources, some of which may become overloaded while others are fully available. The solution MUST allow Diameter nodes to indicate overload with sufficient granularity to allow clients to take action based on the overloaded resources without unreasonably forcing available capacity to go unused. The solution MUST support specification of overload information with granularities of at least "Diameter node", "realm", and "Diameter application" and MUST allow extensibility for others to be added in the future. The "MUST" part says: enough granularity with at least host/realm and appli= cation. And the existing solution is compliant with this requirement. If a node is = supporting N applications, an OLR can be sent "per application" with a repo= rt type indicating if it is for the host or the realm. And the extensibilit= y capability is provided by the base solution. So my technical argument is that the existing proposal fulfills the basic r= equirements for an overload control without compromising future extension f= or further granularity. Regards, Lionel=20 -----Message d'origine----- De=A0: Ben Campbell [mailto:ben@nostrum.com]=20 Envoy=E9=A0: mercredi 4 d=E9cembre 2013 22:55 =C0=A0: MORAND Lionel IMT/OLN Cc=A0: dime@ietf.org Objet=A0: Re: [Dime] DOIC: Self-Contained OLRs On Dec 3, 2013, at 5:17 PM, lionel.morand@orange.com wrote: > Hi Ben, >=20 > I may be wrong somewhere in my summary but I think that it was the result= of the discussions and agreements reached regarding existing requirements,= at least from 3GPP point of view, compared to possible optimizations for f= uture optimizations not so obvious. We are not the 3GPP. Our requirements are RFC 7068. I believe self-containe= d OLRs do a better job of meeting Req 31 than the contextually-defined OLRs. I've made several technical arguments here--does anyone have _technical_ ar= guments in favor of contextually-defined OLRs? > And because the solution offers extensibility via the definition of new a= lgo, new report type and addition of any new AVP in the existing Grouped OL= R, the "limitations" of the proposed solution might be removed by someone i= f really required according to new requirements. >=20 It might be worth considering a compromise approach: Define _optional_ AVPs= that allow an OLR to be self-contained. If they are not present, then the = various values default to those from the enclosing Diameter message. Possib= ly add support for this to the list of things that reacting nodes can adver= tise. This could be in the base, or in a follow on extension. (If left for an ext= ension, it's worth considering whether ReportType needs to be in the base, = or this or some other extension.)=20 > Regards, >=20 > Lionel >=20 > -----Message d'origine----- > De : Ben Campbell [mailto:ben@nostrum.com]=20 > Envoy=E9 : mardi 3 d=E9cembre 2013 23:56 > =C0 : MORAND Lionel IMT/OLN > Cc : Steve Donovan; dime@ietf.org > Objet : Re: [Dime] DOIC: Self-Contained OLRs >=20 >=20 > On Dec 2, 2013, at 10:18 AM, lionel.morand@orange.com wrote: >=20 >> Hi Steve, >>=20 >> I think that is not only about few bytes in the answer. It is also about= the solution principles agreed so far: >> =B7 the current need is for an OLR bound to the application in u= se >> =B7 the OLR is received from the node targeted in the request. >> =B7 the OLR is defined per application >=20 > I don't think those principles have been well tested. I don't recall any = discussion of their benefits. What benefits do you see they have over self-= contained OLRs? >=20 > All I see from these are restrictions in the flexibility of the solution,= with very little in return. >=20 >> So all the implicit information (application, origin-host, origin-realm)= are meaningful in this context. >> And the actual solution is designed based on these assumptions. The exte= nsibility of the solution will allow extra info if required in other use ca= ses but it was agreed to go with a straightforward solution that will satis= fy most of us. >>=20 >> Regards, >>=20 >> Lionel >>=20 >> De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan >> Envoy=E9 : lundi 2 d=E9cembre 2013 16:37 >> =C0 : dime@ietf.org >> Objet : Re: [Dime] DOIC: Self-Contained OLRs >>=20 >> I don't believe that Ben's proposal was to change the piggybacking assum= ption in the baseline mechanism. Ben's proposal is to design the solution = in such a way that it is not dependent on the piggybacking transport mechan= ism.=20=20 >>=20 >> I share Ben's concern that we have over optimized the content of the ove= rload report in a way that makes implementations brittle, interoperability = more difficult to achieve and extensibility more complex. And what do we g= ain from this optimization? A few bites in answer messages. >>=20 >> Self contained overload reports, transported using the piggybacking mech= anism, is a cleaner solution. >>=20 >> Steve >>=20 >> On 11/29/13 8:31 AM, lionel.morand@orange.com wrote: >> I totally agree with Nirav. No need to revert at this stage the working = assumption on piggybacking of OLR in application answer messages, especiall= y when the aim is to define a basic mechanism called "reduction". >>=20 >> Anyone would be able to further add extra info for optimization if neede= d but there is no need at all for the basic mechanism. >>=20 >> Regards, >>=20 >> Lionel >>=20 >> -----Message d'origine----- >> De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot (nsal= ot) >> Envoy=E9 : vendredi 29 novembre 2013 12:24 >> =C0 : Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list >> Cc : Ben Campbell >> Objet : Re: [Dime] DOIC: Self-Contained OLRs >>=20 >> Jouni, Ben, >>=20 >> I am totally against the idea of self-contained OC-OLR specifically sinc= e we have adopted the principles of piggybacking the OC-OLR over existing a= pplication message. >> Self-contained OC-OLR - which means adding all the information which def= ines the scope of the OC-OLR into the OC-OLR - does not make sense in the p= iggybacking approach. In fact, it is adding lot of information, which is an= yway available within the message containing the OC-OLR, into the OC-OLR. S= o it is adding lot of redundant information in a message which increases th= e processing requirement for the sender as well as the receiver. (And this = is un-optimization, in my view). >>=20 >> Besides, I am not convinced with the other reasons provided here: >> - One software module within a node can provide OC-OLR to another softwa= re module in the same node without passing other related info >> Within a node, based on the design, lots of information may need to be= passed between two software modules and we cannot optimize those aspects b= y replicating unnecessary information in a protocol message. >> In summary, it is node's internal software design issue and we need no= t optimize that at protocol level. >>=20 >> - Once the reporting node realizes that it is overloaded, it has to wait= for right answer to send OC-OLR >> What is the point of sending OC-OLR for a context for which there is no= messaging? Why should the reacting node care if it never sends a message f= or a context for which the reporting node is overloaded? >> So this waiting is justified since it ensures that the overload is repo= rted only when necessary and only to the applicable reacting node. Not to a= ll the nodes in the network. >>=20 >> - The agent needs to wait for the answer generated by the server and the= right context >> The same argument as applicable for the server applies here. The agent= need not send out-of-context overload info to a node. >> Why should reacting node receive/process/store the overload info for t= he scope for which it is not sending any messages. >>=20 >> - For sending OC-OLR in dedicated Diameter application??? >> Piggybacking was the first basic principle we agreed before putting oth= er principles in place. So we may want to go back the drawing board if we d= ecide to change this principle. >>=20 >> Regards, >> Nirav. >>=20 >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen >> Sent: Friday, November 29, 2013 2:50 PM >> To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list >> Cc: Ben Campbell >> Subject: Re: [Dime] DOIC: Self-Contained OLRs >>=20 >>=20 >>=20 >> So, are we reaching any level of consensus here? >>=20 >> - JOuni >>=20 >> (as a note.. that we are converging back to where we started with OLRs ;) >>=20 >>=20 >>=20 >> On Nov 28, 2013, at 12:40 PM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: >>=20 >> Hi, >>=20 >> another question: >>=20 >> If we go for explicit self contained OLRs, why would we then need the Re= portType? >>=20 >> The realm-type OLR would explicitly contain application-Id, Realm, but n= o Host whereas the host-type OLR would explicitly contain application-Id, H= ost, but probably (I'm not sure) no Realm. >>=20 >> Ulrich >>=20 >>=20 >>=20 >> -----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 >>=20 >> Hi, >>=20 >> There is no assumption on which entity is providing the realm overload s= tatus. It could be provided an agent inserting this info in answers receive= d 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 se= rver itself, one for the realm for new request sent to the realm with only = Dest-Realm AVP. >>=20 >> Lionel >>=20 >> -----Message d'origine----- >> De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich=20 >> (NSN - DE/Munich) Envoy=E9 : jeudi 28 novembre 2013 10:26 =C0 : ext Joun= i=20 >> Korhonen; Ben Campbell Cc : dime@ietf.org list Objet : Re: [Dime]=20 >> DOIC: Self-Contained OLRs >>=20 >> Hi, >>=20 >> I don't see how the possibility to send more than one OLR in an answer i= s aligned with the "endpoint principle". If the ReportType is "realm" this = indicates to the reacting end point that the reporting end point is an agen= t (e.g. SFE) rather than a server. If the ReportType is "host" this indicat= es to the reacting end point that the reporting end point is a server. How = can the reporting end point be both agent and server? >>=20 >> Ulrich >>=20 >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Jouni=20 >> Korhonen >> Sent: Wednesday, November 27, 2013 11:44 PM >> To: Ben Campbell >> Cc: dime@ietf.org list >> Subject: Re: [Dime] DOIC: Self-Contained OLRs >>=20 >>=20 >> On Nov 28, 2013, at 12:27 AM, Ben Campbell wrote: >>=20 >> Hi, >>=20 >> I mentioned in another thread that I prefer putting an explicit=20 >> ReportType AVP in an OLR, rather than >>=20 >> The more I spent time thinking/writing the actual procedures on the=20 >> endpoints, the more it makes sense to me to keep the ReportType in the= =20 >> OC-OLR. Even if the baseline does not have agent overload etc, the=20 >> ReportType fits well to the "endpoint principle" we have in the draft.= =20 >> It indeed gives more tools to make a host vs. realm base decision on the= reacting node and is plain more clear. >>=20 >> I skip the rest of the mail.. too much text ;-) >>=20 >>=20 >> - Jouni >>=20 >>=20 >>=20 >>=20 >>=20 >> making a responding node infer the type or meaning of the OLR from a Dia= meter request that corresponds to the answer containing the OLR. My reasons= for that go beyond just ReportType, so I'm starting a separate thread. >>=20 >> As currently described, a consumer of an OLR must infer several things f= rom other context. In most cases, that context is in the Diameter answer th= at carries the OLR. For example, the OLR implicitly refers to the applicati= on identified by the Application-Id field of the enclosing answer, the real= m identified by Origin-Realm, and so on. This means that the "meaning" of a= n OLR cannot be determined from the OLR contents alone; OLRs only have mean= ing in the context of the enclosing answer. If you moved an OLR from one an= swer to another, it's meaning may change completely. >>=20 >> I think this approach is a mistake. I would greatly prefer that we expli= citly include such values in the OLR itself, for multiple reasons: >>=20 >> 1) It's more complex to interpret implicit, contextual values than expli= cit values. The consumer cannot simply look at the OLR; it must look in var= ious other AVPs to find all the information it needs. For example, I think = a common software design for overload control processing to be separated fr= om 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 "co= ntext" avps that must be interpreted can grow large. This approach is error= prone, and will likely encourage brittle, hard-to-maintain code. Self-cont= ained OLRs would keep all the information related to overload in one place.= making for simpler implementations. >>=20 >> 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 inse= rt OLRs into answers created by other nodes.=20 >>=20 >> If the reporting node screws this up, the meaning of the OLR may change = significantly. So again, implicit meaning gives us error prone implementati= ons. Self-contained OLRs are simpler to create and send. >>=20 >> 3) Implicit values don't work at all for certain problems. For=20 >> example, if an agent needs to originate an OLR, it typically needs to=20 >> insert that OLR into an existing Diameter answer created by a server.=20 >> It can't create its own answer without affecting the application=20 >> state. If the responding node assumes the OLR comes from or refers to=20 >> the node identified by the Origin-Host AVP in the enclosing answer,=20 >> things break. (For examples of when an agent needs to send OLRs that=20 >> are distinct from those sent by a server, see Steve's agent overload=20 >> draft, or my dh/dr example.) >>=20 >> OTOH, explicit values will work for all cases where we need to associate= some arbitrary value with an OLR. >>=20 >> 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 ove= rload reports were self-contained, one could just reuse the report format w= e specify here. But if the meaning of an OLR depends on the way it's transp= orted, this won't work. We would have to create a new or significantly modi= fied OLR format if we found a need to transport OLRs in different ways. Sel= f-contained OLRs would allow much greater flexibility. >>=20 >> So, in summary, I think that self-contained OLRs would lead to simpler i= mplementations, less brittle deployments, and more flexibility for future e= volution of standards. >>=20 >> Thanks! >>=20 >> Ben. >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >>=20 >> _______________________________________________ >> 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 >>=20 >> ______________________________________________________________________ >> ___________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations=20 >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 >> exploites ou copies sans autorisation. Si vous avez recu ce message=20 >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que= les pieces jointes. Les messages electroniques etant susceptibles d'altera= tion, Orange decline toute responsabilite si ce message a ete altere, defor= me ou falsifie. Merci. >>=20 >> This message and its attachments may contain confidential or=20 >> 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 d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >>=20 >>=20 >> _______________________________________________ >> 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 >>=20 >> ________________________________________________________________________= _________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations confi= dentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez r= ecu 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. >>=20 >> 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 d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >>=20 >>=20 >> ________________________________________________________________________= _________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations confi= dentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez r= ecu 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. >>=20 >> 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 d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >=20 >=20 > _________________________________________________________________________= ________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu 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 o= u falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged i= nformation 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 de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. From maria.cruz.bartolome@ericsson.com Wed Dec 4 18:23:06 2013 Return-Path: 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 E0BE81AE311 for ; Wed, 4 Dec 2013 18:23:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 TOHfkqXQQrvH for ; Wed, 4 Dec 2013 18:23:02 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id F27361AE164 for ; Wed, 4 Dec 2013 18:23:00 -0800 (PST) X-AuditID: c1b4fb25-b7eff8e000000eda-f5-529fe380bc10 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 37.E2.03802.083EF925; Thu, 5 Dec 2013 03:22:56 +0100 (CET) Received: from ESESSMB101.ericsson.se ([169.254.1.118]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.02.0347.000; Thu, 5 Dec 2013 03:22:56 +0100 From: Maria Cruz Bartolome To: "dime@ietf.org" Thread-Topic: [Dime] DOIC: Self-Contained OLRs Thread-Index: AQHO8HrX2PaAGa/GgUyaCwjRxXVUh5pDChOAgAF7IoCAAC7igIAAKrUQ Date: Thu, 5 Dec 2013 02:22:55 +0000 Message-ID: <087A34937E64E74E848732CFF8354B920972CCAA@ESESSMB101.ericsson.se> References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D90006681519BC90@DEMUMBX014.nsn-intra.net> <6390_1385631044_52970D44_6390_18593_1_6B7134B31289DC4FAF731D844122B36E30748E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BD31@DEMUMBX014.nsn-intra.net> <47383DC2-1A1B-4D1A-ADD5-9E3CE60B06C8@gmail.com> <8467_1385735507_5298A553_8467_17054_3_6B7134B31289DC4FAF731D844122B36E309D0D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <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> <14594_1386204165_529FCC05_14594_12646_1_6B7134B31289DC4FAF731D844122B36E329907@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <14594_1386204165_529FCC05_14594_12646_1_6B7134B31289DC4FAF731D844122B36E329907@PEXCVZYM13.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrFLMWRmVeSWpSXmKPExsUyM+JvrW7D4/lBBmemqljM7V3B5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujL6Vz5kLJhxirFjWP4+1gfHDXMYuRk4OCQETidWXDrNC2GIS F+6tZ+ti5OIQEjjEKNH4ehs7hLOYUWJBbxc7SBWbgJ3EpdMvmLoYOThEBJQlTv9yAAkLC+hK bDv1gRnEFhHQk3hxciUThO0m8eTePTCbRUBF4vaRLrDFvAK+Et9m32eGmP+OQ2LZpTesIA6n QDujxIk7H1hAqhiBTvp+ag1YN7OAuMStJ/OZIE4VkFiy5zwzhC0q8fLxP6gXlCRWbL/ECFGv J3Fj6hQ2CFtbYtnC18wQmwUlTs58wjKBUXQWkrGzkLTMQtIyC0nLAkaWVYzsuYmZOenlRpsY geF/cMtv1R2Md86JHGKU5mBREuf98NY5SEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAPjZl5h Xr+Zx6yeXFifyCxz4cAPQSkr00fTzus7PhA71DtP27GeWfXq2mV7FaobXrL9vaeaEf0wau2J +xPL9JssrlSG9Wd9PXkyYPWfu7vSHsVxnZzB+dvltlbJ89OF31g2ZLzddktZ8cXhv+t7bi+P 3MXfWsT+tyVcPVX68RyXt4GbmOeeerRwiRJLcUaioRZzUXEiADC6FN1NAgAA 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 02:23:07 -0000 Dear all, I agree with Lionel argumentation below. A part from that, one concern with "self-contained OLRs" is that some data= is duplicated. Duplication should be avoided, since then we need to assure= consistency, and error handing in case implicit and explicit data values a= re different for any reason... what means that it may always be required to= check both implicit and explicit data. Also, I think this is a pure implementation proposal. Regardless how the da= ta is transported it could be packed in a "self-contained OLRs" within the = diameter application, if for any implementation this is preferred. Regards /MCruz -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange= .com Sent: jueves, 05 de diciembre de 2013 1:43 To: Ben Campbell Cc: dime@ietf.org Subject: Re: [Dime] DOIC: Self-Contained OLRs Hi Ben, 3GPP operational requirements have triggered and driven this work, and 3GPP= will be the main client for this solution (if not the only for a while...)= . Main parties involved in the discussions are 3GPP vendors and 3GPP operat= ors. So instead trying to keep private preserve, we should welcome and enfo= rce cooperative work with 3GPP on this task if we want that the solution de= fined in IETF will be used in 3GPP. Otherwise, 3GPP may decide not to wait = for IETF and develop its own solution, as done in the past (e.g. developing= 3GPP-specific Cx application instead of adopting the IETF-standard Diamete= r SIP application). About the technical discussion, the Req31 says: REQ 31: There are multiple situations where a Diameter node may be overloaded for some purposes but not others. For example, this can happen to an agent or server that supports multiple applications, or when a server depends on multiple external resources, some of which may become overloaded while others are fully available. The solution MUST allow Diameter nodes to indicate overload with sufficient granularity to allow clients to take action based on the overloaded resources without unreasonably forcing available capacity to go unused. The solution MUST support specification of overload information with granularities of at least "Diameter node", "realm", and "Diameter application" and MUST allow extensibility for others to be added in the future. The "MUST" part says: enough granularity with at least host/realm and appli= cation. And the existing solution is compliant with this requirement. If a node is = supporting N applications, an OLR can be sent "per application" with a repo= rt type indicating if it is for the host or the realm. And the extensibilit= y capability is provided by the base solution. So my technical argument is that the existing proposal fulfills the basic r= equirements for an overload control without compromising future extension f= or further granularity. Regards, Lionel=20 -----Message d'origine----- De=A0: Ben Campbell [mailto:ben@nostrum.com]=20 Envoy=E9=A0: mercredi 4 d=E9cembre 2013 22:55 =C0=A0: MORAND Lionel IMT/OLN Cc=A0: dime@ietf.org Objet=A0: Re: [Dime] DOIC: Self-Contained OLRs On Dec 3, 2013, at 5:17 PM, lionel.morand@orange.com wrote: > Hi Ben, >=20 > I may be wrong somewhere in my summary but I think that it was the result= of the discussions and agreements reached regarding existing requirements,= at least from 3GPP point of view, compared to possible optimizations for f= uture optimizations not so obvious. We are not the 3GPP. Our requirements are RFC 7068. I believe self-containe= d OLRs do a better job of meeting Req 31 than the contextually-defined OLRs= . I've made several technical arguments here--does anyone have _technical_ ar= guments in favor of contextually-defined OLRs? > And because the solution offers extensibility via the definition of new a= lgo, new report type and addition of any new AVP in the existing Grouped OL= R, the "limitations" of the proposed solution might be removed by someone i= f really required according to new requirements. >=20 It might be worth considering a compromise approach: Define _optional_ AVPs= that allow an OLR to be self-contained. If they are not present, then the = various values default to those from the enclosing Diameter message. Possib= ly add support for this to the list of things that reacting nodes can adver= tise. This could be in the base, or in a follow on extension. (If left for an ext= ension, it's worth considering whether ReportType needs to be in the base, = or this or some other extension.)=20 > Regards, >=20 > Lionel >=20 > -----Message d'origine----- > De : Ben Campbell [mailto:ben@nostrum.com]=20 > Envoy=E9 : mardi 3 d=E9cembre 2013 23:56 > =C0 : MORAND Lionel IMT/OLN > Cc : Steve Donovan; dime@ietf.org > Objet : Re: [Dime] DOIC: Self-Contained OLRs >=20 >=20 > On Dec 2, 2013, at 10:18 AM, lionel.morand@orange.com wrote: >=20 >> Hi Steve, >>=20 >> I think that is not only about few bytes in the answer. It is also about= the solution principles agreed so far: >> =B7 the current need is for an OLR bound to the application in u= se >> =B7 the OLR is received from the node targeted in the request. >> =B7 the OLR is defined per application >=20 > I don't think those principles have been well tested. I don't recall any = discussion of their benefits. What benefits do you see they have over self-= contained OLRs? >=20 > All I see from these are restrictions in the flexibility of the solution,= with very little in return. >=20 >> So all the implicit information (application, origin-host, origin-realm)= are meaningful in this context. >> And the actual solution is designed based on these assumptions. The exte= nsibility of the solution will allow extra info if required in other use ca= ses but it was agreed to go with a straightforward solution that will satis= fy most of us. >>=20 >> Regards, >>=20 >> Lionel >>=20 >> De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan >> Envoy=E9 : lundi 2 d=E9cembre 2013 16:37 >> =C0 : dime@ietf.org >> Objet : Re: [Dime] DOIC: Self-Contained OLRs >>=20 >> I don't believe that Ben's proposal was to change the piggybacking assum= ption in the baseline mechanism. Ben's proposal is to design the solution = in such a way that it is not dependent on the piggybacking transport mechan= ism. =20 >>=20 >> I share Ben's concern that we have over optimized the content of the ove= rload report in a way that makes implementations brittle, interoperability = more difficult to achieve and extensibility more complex. And what do we g= ain from this optimization? A few bites in answer messages. >>=20 >> Self contained overload reports, transported using the piggybacking mech= anism, is a cleaner solution. >>=20 >> Steve >>=20 >> On 11/29/13 8:31 AM, lionel.morand@orange.com wrote: >> I totally agree with Nirav. No need to revert at this stage the working = assumption on piggybacking of OLR in application answer messages, especiall= y when the aim is to define a basic mechanism called "reduction". >>=20 >> Anyone would be able to further add extra info for optimization if neede= d but there is no need at all for the basic mechanism. >>=20 >> Regards, >>=20 >> Lionel >>=20 >> -----Message d'origine----- >> De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot (nsal= ot) >> Envoy=E9 : vendredi 29 novembre 2013 12:24 >> =C0 : Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org lis= t >> Cc : Ben Campbell >> Objet : Re: [Dime] DOIC: Self-Contained OLRs >>=20 >> Jouni, Ben, >>=20 >> I am totally against the idea of self-contained OC-OLR specifically sinc= e we have adopted the principles of piggybacking the OC-OLR over existing a= pplication message. >> Self-contained OC-OLR - which means adding all the information which def= ines the scope of the OC-OLR into the OC-OLR - does not make sense in the p= iggybacking approach. In fact, it is adding lot of information, which is an= yway available within the message containing the OC-OLR, into the OC-OLR. S= o it is adding lot of redundant information in a message which increases th= e processing requirement for the sender as well as the receiver. (And this = is un-optimization, in my view). >>=20 >> Besides, I am not convinced with the other reasons provided here: >> - One software module within a node can provide OC-OLR to another softwa= re module in the same node without passing other related info >> Within a node, based on the design, lots of information may need to be= passed between two software modules and we cannot optimize those aspects b= y replicating unnecessary information in a protocol message. >> In summary, it is node's internal software design issue and we need no= t optimize that at protocol level. >>=20 >> - Once the reporting node realizes that it is overloaded, it has to wait= for right answer to send OC-OLR >> What is the point of sending OC-OLR for a context for which there is no= messaging? Why should the reacting node care if it never sends a message f= or a context for which the reporting node is overloaded? >> So this waiting is justified since it ensures that the overload is repo= rted only when necessary and only to the applicable reacting node. Not to a= ll the nodes in the network. >>=20 >> - The agent needs to wait for the answer generated by the server and the= right context >> The same argument as applicable for the server applies here. The agent= need not send out-of-context overload info to a node. >> Why should reacting node receive/process/store the overload info for t= he scope for which it is not sending any messages. >>=20 >> - For sending OC-OLR in dedicated Diameter application??? >> Piggybacking was the first basic principle we agreed before putting oth= er principles in place. So we may want to go back the drawing board if we d= ecide to change this principle. >>=20 >> Regards, >> Nirav. >>=20 >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen >> Sent: Friday, November 29, 2013 2:50 PM >> To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list >> Cc: Ben Campbell >> Subject: Re: [Dime] DOIC: Self-Contained OLRs >>=20 >>=20 >>=20 >> So, are we reaching any level of consensus here? >>=20 >> - JOuni >>=20 >> (as a note.. that we are converging back to where we started with OLRs ;= ) >>=20 >>=20 >>=20 >> On Nov 28, 2013, at 12:40 PM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: >>=20 >> Hi, >>=20 >> another question: >>=20 >> If we go for explicit self contained OLRs, why would we then need the Re= portType? >>=20 >> The realm-type OLR would explicitly contain application-Id, Realm, but n= o Host whereas the host-type OLR would explicitly contain application-Id, H= ost, but probably (I'm not sure) no Realm. >>=20 >> Ulrich >>=20 >>=20 >>=20 >> -----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 >>=20 >> Hi, >>=20 >> There is no assumption on which entity is providing the realm overload s= tatus. It could be provided an agent inserting this info in answers receive= d 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 se= rver itself, one for the realm for new request sent to the realm with only = Dest-Realm AVP. >>=20 >> Lionel >>=20 >> -----Message d'origine----- >> De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich=20 >> (NSN - DE/Munich) Envoy=E9 : jeudi 28 novembre 2013 10:26 =C0 : ext Joun= i=20 >> Korhonen; Ben Campbell Cc : dime@ietf.org list Objet : Re: [Dime]=20 >> DOIC: Self-Contained OLRs >>=20 >> Hi, >>=20 >> I don't see how the possibility to send more than one OLR in an answer i= s aligned with the "endpoint principle". If the ReportType is "realm" this = indicates to the reacting end point that the reporting end point is an agen= t (e.g. SFE) rather than a server. If the ReportType is "host" this indicat= es to the reacting end point that the reporting end point is a server. How = can the reporting end point be both agent and server? >>=20 >> Ulrich >>=20 >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Jouni=20 >> Korhonen >> Sent: Wednesday, November 27, 2013 11:44 PM >> To: Ben Campbell >> Cc: dime@ietf.org list >> Subject: Re: [Dime] DOIC: Self-Contained OLRs >>=20 >>=20 >> On Nov 28, 2013, at 12:27 AM, Ben Campbell wrote: >>=20 >> Hi, >>=20 >> I mentioned in another thread that I prefer putting an explicit=20 >> ReportType AVP in an OLR, rather than >>=20 >> The more I spent time thinking/writing the actual procedures on the=20 >> endpoints, the more it makes sense to me to keep the ReportType in the=20 >> OC-OLR. Even if the baseline does not have agent overload etc, the=20 >> ReportType fits well to the "endpoint principle" we have in the draft.=20 >> It indeed gives more tools to make a host vs. realm base decision on the= reacting node and is plain more clear. >>=20 >> I skip the rest of the mail.. too much text ;-) >>=20 >>=20 >> - Jouni >>=20 >>=20 >>=20 >>=20 >>=20 >> making a responding node infer the type or meaning of the OLR from a Dia= meter request that corresponds to the answer containing the OLR. My reasons= for that go beyond just ReportType, so I'm starting a separate thread. >>=20 >> As currently described, a consumer of an OLR must infer several things f= rom other context. In most cases, that context is in the Diameter answer th= at carries the OLR. For example, the OLR implicitly refers to the applicati= on identified by the Application-Id field of the enclosing answer, the real= m identified by Origin-Realm, and so on. This means that the "meaning" of a= n OLR cannot be determined from the OLR contents alone; OLRs only have mean= ing in the context of the enclosing answer. If you moved an OLR from one an= swer to another, it's meaning may change completely. >>=20 >> I think this approach is a mistake. I would greatly prefer that we expli= citly include such values in the OLR itself, for multiple reasons: >>=20 >> 1) It's more complex to interpret implicit, contextual values than expli= cit values. The consumer cannot simply look at the OLR; it must look in var= ious other AVPs to find all the information it needs. For example, I think = a common software design for overload control processing to be separated fr= om 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 "co= ntext" avps that must be interpreted can grow large. This approach is error= prone, and will likely encourage brittle, hard-to-maintain code. Self-cont= ained OLRs would keep all the information related to overload in one place.= making for simpler implementations. >>=20 >> 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 inse= rt OLRs into answers created by other nodes.=20 >>=20 >> If the reporting node screws this up, the meaning of the OLR may change = significantly. So again, implicit meaning gives us error prone implementati= ons. Self-contained OLRs are simpler to create and send. >>=20 >> 3) Implicit values don't work at all for certain problems. For=20 >> example, if an agent needs to originate an OLR, it typically needs to=20 >> insert that OLR into an existing Diameter answer created by a server.=20 >> It can't create its own answer without affecting the application=20 >> state. If the responding node assumes the OLR comes from or refers to=20 >> the node identified by the Origin-Host AVP in the enclosing answer,=20 >> things break. (For examples of when an agent needs to send OLRs that=20 >> are distinct from those sent by a server, see Steve's agent overload=20 >> draft, or my dh/dr example.) >>=20 >> OTOH, explicit values will work for all cases where we need to associate= some arbitrary value with an OLR. >>=20 >> 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 ove= rload reports were self-contained, one could just reuse the report format w= e specify here. But if the meaning of an OLR depends on the way it's transp= orted, this won't work. We would have to create a new or significantly modi= fied OLR format if we found a need to transport OLRs in different ways. Sel= f-contained OLRs would allow much greater flexibility. >>=20 >> So, in summary, I think that self-contained OLRs would lead to simpler i= mplementations, less brittle deployments, and more flexibility for future e= volution of standards. >>=20 >> Thanks! >>=20 >> Ben. >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >>=20 >> _______________________________________________ >> 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 >>=20 >> ______________________________________________________________________ >> ___________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations=20 >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 >> exploites ou copies sans autorisation. Si vous avez recu ce message=20 >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que= les pieces jointes. Les messages electroniques etant susceptibles d'altera= tion, Orange decline toute responsabilite si ce message a ete altere, defor= me ou falsifie. Merci. >>=20 >> This message and its attachments may contain confidential or=20 >> 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 d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >>=20 >>=20 >> _______________________________________________ >> 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 >>=20 >> ________________________________________________________________________= _________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations confi= dentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez r= ecu 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. >>=20 >> 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 d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >>=20 >>=20 >> ________________________________________________________________________= _________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations confi= dentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez r= ecu 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. >>=20 >> 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 d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >=20 >=20 > _________________________________________________________________________= ________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu 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 o= u falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged i= nformation 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 de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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 From ulrich.wiehe@nsn.com Thu Dec 5 00:55:37 2013 Return-Path: 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 ; 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 ; 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 ; 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)" To: "ext lionel.morand@orange.com" , Ben Campbell Thread-Topic: [Dime] DOIC: Self-Contained OLRs Thread-Index: AQHO67/t2PaAGa/GgUyaCwjRxXVUh5o5m/0AgAC8o/D///ghgIAAFu+wgAGHVQCAACqasIAAMwWAgANxipCAAKJuAIAATHjQgAAM5ICAABPPEIAAFwqAgAAGBICAAAUigIAAJC3wgAEbsUCAAAYOAIAAGIwQ///0igCAAEGG8IAAESYAgAARq0CAAGUiAIAAraWggADRWYCAACcjAIAAlfeQ Date: Thu, 5 Dec 2013 08:55:23 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519D888@DEMUMBX014.nsn-intra.net> References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> , <5BCBA1FC2B7F0B4C9D935572D90006681519C087@DEMUMBX014.nsn-intra.net> <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> <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" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 co= rresponding request would have matched) and that is the OLR the reacting no= de 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 orde= r to let the reacting node detect without referring back to the original re= quest 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 exc= hange 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 anyt= hing 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') betw= een A and S. The different DOIC associations d and d' may have different ad= vertised/negotiated features and must be strictly separated. An host-type O= LR sent from S to A is in-context for d' but not for d and therefore must n= ot be forwarded transparently to C (it can be forwarded but then it must be= marked as "out-of-context").=20 Ulrich -----Original Message----- From: ext lionel.morand@orange.com [mailto:lionel.morand@orange.com]=20 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=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Ben Campbell Envoy=E9=A0: mercredi 4 d=E9cembre 2013 22:43 =C0=A0: Wiehe, Ulrich (NSN - DE/Munich) Cc=A0: dime@ietf.org Objet=A0: Re: [Dime] DOIC: Self-Contained OLRs On Dec 4, 2013, at 2:23 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: > Ben, >=20 > No. One OLR per answer (if no extension is supported). I don't understand the intent. What difference does an extension make? Do y= ou consider additional ReportType values to be extensions? In particular, if we end up supporting both Realm and Server type reports i= n the base, I think you should be able to have one of each in an answer. Bu= t I agree, two Realm reports or two Server reports in the same answer can c= reate a conflict. [LM] it is why it is proposed to avoid multiple OLRs with the same report t= ype in the same answer. >=20 > What is an ambiguous OLR? > What should the client do when receiving 5 OLRs in one answer three of wh= ich are ambiguous? >=20 > Let's try to avoid complexity. >=20 > Ulrich=20 >=20 > -----Original Message----- > From: ext Ben Campbell [mailto:ben@nostrum.com]=20 > 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 >=20 >=20 > On Dec 3, 2013, at 9:56 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >=20 >> Steve, >>=20 >> 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 e= xtension (like agent overload) must not be forced to process more than one = OLR per answer. >>=20 >=20 > Can we restate the "not forced to process" to say "not be forced to choos= e between ambiguous" OLRs? >=20 >> Ulrich >>=20 >> 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 >>=20 >> I am strongly against saying that there can never be more than one overl= oad report in a message. This makes it impossible to extend the base proto= col to support agent overload. >>=20 >> It also makes it more difficult to achieve the more granular differentia= ted overload report types that Nirav is suggesting. >>=20 >> Steve >>=20 >> On 12/3/13 7:52 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >> Hi Lionel, >>=20 >> the more OLRs a client must process (in every answer) the more complex i= s the solution. I don't see how it helps that multiple OLRs are not mandate= d for the reporting node; the reacting node would still be required to proc= ess all received OLRs. >>=20 >> Best regards >> Ulrich >>=20 >> -----Original Message----- >> From: ext lionel.morand@orange.com [mailto:lionel.morand@orange.com]=20 >> 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 >>=20 >> Hi Ulrich, >>=20 >> I don't see the complexity if each OLR instance received is clearly dist= inguished by the Report-Type.=20 >> Again, it is not said that it will be mandated for any deployment to rel= y on multiple OLR instances.=20 >>=20 >> Regards, >>=20 >> Lionel >>=20 >> -----Message d'origine----- >> De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 >> Envoy=E9 : mardi 3 d=E9cembre 2013 11:46 >> =C0 : MORAND Lionel IMT/OLN; ext Maria Cruz Bartolome; dime@ietf.org lis= t >> Objet : RE: [Dime] DOIC: Self-Contained OLRs >>=20 >> Hi Lionel, >>=20 >> my point is simple: >>=20 >> 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 t= hem. >> Clients must not be forced to process additional OLRs. >>=20 >> Ulrich=20 >>=20 >> -----Original Message----- >> From: ext lionel.morand@orange.com [mailto:lionel.morand@orange.com]=20 >> 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 >>=20 >> Hi Ulrich, >>=20 >> Honestly, I don't get your point. >> It could be done as you've described below and there is no reason to pro= hibit this way of doing. The consequence for the client is that it will nev= er receive more than one OLR. I think it was never mandated that an agent M= UST insert a realm-based OLR. >> But there is no reason to prohibit the presence of both OLRs in the same= answer. >>=20 >> Regards, >>=20 >> Lionel=20 >>=20 >> -----Message d'origine----- >> De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NS= N - DE/Munich) >> Envoy=E9 : mardi 3 d=E9cembre 2013 10:21 >> =C0 : ext Maria Cruz Bartolome; dime@ietf.org list >> Objet : Re: [Dime] DOIC: Self-Contained OLRs >>=20 >> Dear MCruz, >> thank you for your support. >>=20 >> 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 r= eturns 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 Desti= nation Host in which case any realm-type OLR inserted by A would be useless= to C.=20 >>=20 >> 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 reque= st. S then returns a host-type OLR to A, and A replaces the host-type OLR r= eceived from S with a realm-type OLR. There is no need that the host-type O= LR 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 Destinati= on Host in which case any host-type OLR conveyed to C would be useless to C= . >>=20 >> In any case there is no need for more than one OLR in an answer. >>=20 >> Ulrich >>=20 >>=20 >>=20 >>=20 >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Ba= rtolome >> Sent: Monday, December 02, 2013 4:55 PM >> To: dime@ietf.org list >> Subject: Re: [Dime] DOIC: Self-Contained OLRs >>=20 >> Dear all, >>=20 >> My interpretation is as well in line to what is summarized by Lionel bel= ow. >>=20 >> 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, a= nd 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 o= n the realm overload status in the corresponding answer, if required. >>=20 >> Best regards >> /MCruz >>=20 >> -----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 >>=20 >>=20 >> My understanding (and current editing) has already been towards what Lio= nel said below. >>=20 >> - Jouni >>=20 >>=20 >> On Dec 2, 2013, at 4:19 PM, lionel.morand@orange.com wrote: >>=20 >> I agree with last part. It was the reason I've reconsidered my position = on the need for the Report-Type. >>=20 >> 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 D= estination-Host is not in the answer. So receiving a host-based OLR in resp= onse 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 po= sitive 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" o= ffered by the use of the Report-Type. But there is nothing wrong. It is onl= y to comply with the Diameter routing principle: subsequent requests from t= he client could include a destination-host or not. So the client needs to k= now which reduction to apply from a previous answer. >>=20 >> 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 c= ontext based on the type of request. >>=20 >> Regards, >>=20 >> Lionel >>=20 >>=20 >> De : Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Envoy=E9 : lundi 2=20 >> d=E9cembre 2013 14:58 =C0 : Wiehe, Ulrich (NSN - DE/Munich) Cc :=20 >> dime@ietf.org list; ext Jouni Korhonen; MORAND Lionel IMT/OLN; Ben=20 >> Campbell Objet : RE: [Dime] DOIC: Self-Contained OLRs >>=20 >> Ulrich, >>=20 >> 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? >>=20 >> I would prefer to derive the context of the OLR based on the message whi= ch contains the OLR. >>=20 >> Back to the topic of this thread, I don't think we need to define an "op= tional" optimization at this stage. Either it is respected by all the nodes= supporting the solution or we drop that optimization. >>=20 >> Regards, >> Nirav. >>=20 >> On Dec 2, 2013 5:27 PM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: >> Nirav, >>=20 >> If the reacting node sends a request without Destination Host, a realm-t= ype OLR in the answer would be in-context whereas a host-type OLR in the an= swer would be out of context. >>=20 >> Similarly, if the reacting node sends a request containing Destination H= ost, a realm-type OLR in the answer would be out-of-context and a host-type= OLR in the answer would be in-context. >>=20 >> Ulrich >>=20 >>=20 >>=20 >> -----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=20 >> Jouni Korhonen; Ben Campbell >> Cc: dime@ietf.org list >> Subject: RE: [Dime] DOIC: Self-Contained OLRs >>=20 >> Ulrich, >>=20 >> I have a basic question. >>=20 >> 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 o= r host-type? >>=20 >> Regards, >> Nirav. >>=20 >> -----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=20 >> Korhonen; Ben Campbell >> Cc: dime@ietf.org list >> Subject: RE: [Dime] DOIC: Self-Contained OLRs >>=20 >> Hi Nirav, >>=20 >> please see inline. >>=20 >> Regards >> Ulrich >>=20 >> -----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=20 >> Jouni Korhonen; Ben Campbell >> Cc: dime@ietf.org list >> Subject: RE: [Dime] DOIC: Self-Contained OLRs >>=20 >> Ulrich, >>=20 >> When the client sends request containing destination-realm (and not cont= aining destination-host), it gets back answer containing origin-host (set b= y the actual server) as well as host-type OLR. >> So purely from the response message perspective, the host-type OLR in th= is response message is not out-of-context information.=20 >> [Wiehe, Ulrich (NSN - DE/Munich)] But we do not purely take the response= message perspective. The client sends a request of type x (destination hos= t =3Dx1, destination realm =3Dx2 application=3D 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 v= alue of Report-Type in the answer whether Destination Host was present in t= he request... >>=20 >> On the other hand, we discussed - as part of Maria Cruz's alternative so= lution - to define the response message's context based on the request mess= age. And hence if the request message was sent to destination-realm, the co= rresponding response message can only contain realm-type OLR. >> But this requires the client to remember the context of the request whil= e processing the response and hence it was considered as introducing unnece= ssary complexity.=20 >> [Wiehe, Ulrich (NSN - DE/Munich)] I agree. This means: the report-type A= VP is needed to let the client deduce from information received in the answ= er whether the request contained a destination host. It does not mean that = we need two OLRs in one answer. >>=20 >> If we strictly want to ensure that the realm-type OLR is not sent=20 >> out-of-context [Wiehe, Ulrich (NSN - DE/Munich)] That was not my=20 >> proposal. My proposal was to clearly mark out-of-context OLRs in=20 >> answer messages (if we allow including out-of-context OLRs) >>=20 >> , then we should agree to Lionel's alternative solution - to send realm-= type OLR only when the destination-realm based request is rejected. So basi= cally, realm-type OLR is never included in a response message which contain= s origin-host AVP. (And I am ready to reconsider the same if we want to ens= ure the context of the response message and the OLR it contains). >>=20 >> However, as per our current agreement, we are introducing Report-Type AV= P [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 o= ne 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=20 >> (NSN - DE/Munich)] only the out-of-context one >>=20 >> , 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 o= r agent wants to offer this optimization), and may be processed by the reac= ting node (if the reacting node wants to make use of this optimization). >>=20 >> and what is the point of defining Report-Type AVP? >> [Wiehe, Ulrich (NSN - DE/Munich)] to let the reacting node deduce from i= nformation received in the answer whether the corresponding request contain= ed a destination host (so there is no need to remember). >>=20 >>=20 >> In summary, if we define Report-Type AVP and corresponding handling at t= he 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? >>=20 >> 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 optimiz= ation but the incusion of out-of-context OLRs. And I'm ok not to proceed wi= th this optimization as it is not needed. >>=20 >> Regards, >> Nirav. >>=20 >> -----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=20 >> Korhonen; Ben Campbell >> Cc: dime@ietf.org list >> Subject: RE: [Dime] DOIC: Self-Contained OLRs >>=20 >> Hi Nirav, >>=20 >> 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, thi= s OLR is out-of-context. >> Similary, when the client sends a request containing destination host an= d gets back an answer containing a realm-type OLR, this OLR is out-of-conte= xt. >> There is nothing wrong with storing such out-of-context OLRs at the clie= nt, but it is simply not needed as the client will learn this OLR from resp= onses received within the context. >>=20 >> Best regards >> Ulrich >>=20 >>=20 >> -----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=20 >> Jouni Korhonen; Ben Campbell >> Cc: dime@ietf.org list >> Subject: RE: [Dime] DOIC: Self-Contained OLRs >>=20 >> Hi Ulrich, >>=20 >> If an additional OLR is present with a different ReportType, why it shou= ld be ignored by the reacting node? >>=20 >> Regards, >> Nirav. >>=20 >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich=20 >> (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 >>=20 >> Hi Lionel, >>=20 >> there is nothing missing exept the clarification that everything works f= ine when only one OLR (the OLR created by the reporting endpoint) is presen= t in the answer and additional OLRs (not created by the reporting endpoint)= may just be present as an optional optimization i.e. optionally inserted b= y the reporting endpoint and optionally ignored by the reacting endpoint. >>=20 >> Ulrich >>=20 >>=20 >> -----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 >>=20 >> Hi Ulrich, >>=20 >> Using the Report Type "host report", you know that the OLR applies for s= ubsequent 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.=20 >>=20 >> It is not so important to know what the type of request was and which no= de 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 architect= ure to provide the same information. >>=20 >> I'm not sure of what is missing in this reasoning... >>=20 >> Lionel >>=20 >> -----Message d'origine----- >> De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 >> Envoy=E9 : jeudi 28 novembre 2013 11:30 =C0 : MORAND Lionel IMT/OLN; ext= =20 >> Jouni Korhonen; Ben Campbell Cc : dime@ietf.org list Objet : RE:=20 >> [Dime] DOIC: Self-Contained OLRs >>=20 >> Lionel, >>=20 >> my understanding was that _the_ reporting end point provides _the_ OLR. >>=20 >> 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 additiona= l OLR created by another node. >>=20 >> We have two cases: >> a) The request sent by the client (reacting end point) contains no Desti= nation Host. The agent (reporting node) (after forwarding the request to th= e 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 O= LR as learned from the selected server. The client may ignore the addition= al OLR. >> b) The request sent by the client (reacting endpoint) contains the Desti= nation Host. The Server (reporting node) returns a host-type OLR as the act= ual reporting-node-created OLR in the answer. The agent may optionally inse= rt a realm-type OLR as additional OLR to the answer. The client may ignore = the additional OLR. >>=20 >> Ulrich >>=20 >>=20 >>=20 >> -----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 >>=20 >> Hi, >>=20 >> There is no assumption on which entity is providing the realm overload s= tatus. It could be provided an agent inserting this info in answers receive= d 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 se= rver itself, one for the realm for new request sent to the realm with only = Dest-Realm AVP. >>=20 >> Lionel >>=20 >> -----Message d'origine----- >> De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich=20 >> (NSN - DE/Munich) Envoy=E9 : jeudi 28 novembre 2013 10:26 =C0 : ext Joun= i=20 >> Korhonen; Ben Campbell Cc : dime@ietf.org list Objet : Re: [Dime]=20 >> DOIC: Self-Contained OLRs >>=20 >> Hi, >>=20 >> I don't see how the possibility to send more than one OLR in an answer i= s aligned with the "endpoint principle". If the ReportType is "realm" this = indicates to the reacting end point that the reporting end point is an agen= t (e.g. SFE) rather than a server. If the ReportType is "host" this indicat= es to the reacting end point that the reporting end point is a server. How = can the reporting end point be both agent and server? >>=20 >> Ulrich >>=20 >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Jouni=20 >> Korhonen >> Sent: Wednesday, November 27, 2013 11:44 PM >> To: Ben Campbell >> Cc: dime@ietf.org list >> Subject: Re: [Dime] DOIC: Self-Contained OLRs >>=20 >>=20 >> On Nov 28, 2013, at 12:27 AM, Ben Campbell wrote: >>=20 >> Hi, >>=20 >> I mentioned in another thread that I prefer putting an explicit=20 >> ReportType AVP in an OLR, rather than >>=20 >> The more I spent time thinking/writing the actual procedures on the endp= oints, 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 p= lain more clear. >>=20 >> I skip the rest of the mail.. too much text ;-) >>=20 >>=20 >> - Jouni >>=20 >>=20 >>=20 >>=20 >>=20 >> making a responding node infer the type or meaning of the OLR from a Dia= meter request that corresponds to the answer containing the OLR. My reasons= for that go beyond just ReportType, so I'm starting a separate thread. >>=20 >> As currently described, a consumer of an OLR must infer several things f= rom other context. In most cases, that context is in the Diameter answer th= at carries the OLR. For example, the OLR implicitly refers to the applicati= on identified by the Application-Id field of the enclosing answer, the real= m identified by Origin-Realm, and so on. This means that the "meaning" of a= n OLR cannot be determined from the OLR contents alone; OLRs only have mean= ing in the context of the enclosing answer. If you moved an OLR from one an= swer to another, it's meaning may change completely. >>=20 >> I think this approach is a mistake. I would greatly prefer that we expli= citly include such values in the OLR itself, for multiple reasons: >>=20 >> 1) It's more complex to interpret implicit, contextual values than expli= cit values. The consumer cannot simply look at the OLR; it must look in var= ious other AVPs to find all the information it needs. For example, I think = a common software design for overload control processing to be separated fr= om 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 "co= ntext" avps that must be interpreted can grow large. This approach is error= prone, and will likely encourage brittle, hard-to-maintain code. Self-cont= ained OLRs would keep all the information related to overload in one place.= making for simpler implementations. >>=20 >> 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 inse= rt OLRs into answers created by other nodes.=20 >>=20 >> If the reporting node screws this up, the meaning of the OLR may change = significantly. So again, implicit meaning gives us error prone implementati= ons. Self-contained OLRs are simpler to create and send. >>=20 >> 3) Implicit values don't work at all for certain problems. For=20 >> example, if an agent needs to originate an OLR, it typically needs=20 >> to insert that OLR into an existing Diameter answer created by a server. >> It can't create its own answer without affecting the application=20 >> state. If the responding node assumes the OLR comes from or refers=20 >> to the node identified by the Origin-Host AVP in the enclosing=20 >> answer, things break. (For examples of when an agent needs to send=20 >> OLRs that are distinct from those sent by a server, see Steve's=20 >> agent overload draft, or my dh/dr example.) >>=20 >> OTOH, explicit values will work for all cases where we need to associate= some arbitrary value with an OLR. >>=20 >> 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 ove= rload reports were self-contained, one could just reuse the report format w= e specify here. But if the meaning of an OLR depends on the way it's transp= orted, this won't work. We would have to create a new or significantly modi= fied OLR format if we found a need to transport OLRs in different ways. Sel= f-contained OLRs would allow much greater flexibility. >>=20 >> So, in summary, I think that self-contained OLRs would lead to simpler i= mplementations, less brittle deployments, and more flexibility for future e= volution of standards. >>=20 >> Thanks! >>=20 >> Ben. >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >>=20 >> _______________________________________________ >> 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 >>=20 >> ______________________________________________________________________ >> ___________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations confi= dentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites = ou copies sans autorisation. Si vous avez recu ce message par erreur, veuil= lez 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. Merc= i. >>=20 >> This message and its attachments may contain confidential or privileged = information that may be protected by law; they should not be distributed, u= sed or copied without authorisation. >> If you have received this email in error, please notify the sender and d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >>=20 >>=20 >> ______________________________________________________________________ >> ___________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations confi= dentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites = ou copies sans autorisation. Si vous avez recu ce message par erreur, veuil= lez 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. Merc= i. >>=20 >> This message and its attachments may contain confidential or privileged = information that may be protected by law; they should not be distributed, u= sed or copied without authorisation. >> If you have received this email in error, please notify the sender and d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> ______________________________________________________________________ >> ___________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations=20 >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 >> exploites ou copies sans autorisation. Si vous avez recu ce message=20 >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que= les pieces jointes. Les messages electroniques etant susceptibles d'altera= tion, Orange decline toute responsabilite si ce message a ete altere, defor= me ou falsifie. Merci. >>=20 >> This message and its attachments may contain confidential or=20 >> 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 d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >>=20 >>=20 >> _______________________________________________ >> 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 >>=20 >> ________________________________________________________________________= _________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations confi= dentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez r= ecu 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. >>=20 >> 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 d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >>=20 >>=20 >> ________________________________________________________________________= _________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations confi= dentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez r= ecu 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. >>=20 >> 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 d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >>=20 >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >=20 > _______________________________________________ > 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 confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. From nsalot@cisco.com Thu Dec 5 01:29:39 2013 Return-Path: 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 7CC5C1ADBC9 for ; Thu, 5 Dec 2013 01:29:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.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 UCa1Nv2xKDEA for ; Thu, 5 Dec 2013 01:29:35 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 9BE081AD9AD for ; Thu, 5 Dec 2013 01:29:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18921; q=dns/txt; s=iport; t=1386235772; x=1387445372; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=MtVmc0mjIfUIE3T/p+cW4AHhtUs4yTraPrrVWW+wzhY=; b=JJgrcuxn+151YRKgu/NBxLrbaEXagstTzYUZtPExYLi2UB4zMAjR+yVH sZ4iSx0dEEa9GY9k5vua/c4YB64dQNtNLPOU7V05RVOTIigeaaRrRDbNU j5xU+KuZxJk8woXPzG2IZ1H67bnZONySgHo7KnKWBnVsekd3C9sI+XcZp A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAO5GoFKtJXG//2dsb2JhbABZgwc4U7hsgRgWdIIlAQEBAwEBAQFkBwYFBQcEAgEIEQQBAQEKHQcnCxQJCAIEAQ0FCBOHYQYNwRgTBI4dARACAR4xBwaDGoETA4kKoR2DKYIq X-IronPort-AV: E=Sophos;i="4.93,831,1378857600"; d="scan'208";a="289515673" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-7.cisco.com with ESMTP; 05 Dec 2013 09:29:30 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id rB59TUe7030654 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Dec 2013 09:29:30 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.250]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Thu, 5 Dec 2013 03:29:29 -0600 From: "Nirav Salot (nsalot)" To: Ben Campbell , Maria Cruz Bartolome Thread-Topic: [Dime] DOIC: Self-Contained OLRs Thread-Index: AQHO67/s/vGpiVuf2UayvwQoJbzwfZo6EVYAgACzUoCAAAFygIAAE10AgAF8EQD//7X5YIAAoQmAgAAJY4CABMWYAIACA+SAgAHHfUA= Date: Thu, 5 Dec 2013 09:29:29 +0000 Message-ID: References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D90006681519BC90@DEMUMBX014.nsn-intra.net> <6390_1385631044_52970D44_6390_18593_1_6B7134B31289DC4FAF731D844122B36E30748E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BD31@DEMUMBX014.nsn-intra.net> <47383DC2-1A1B-4D1A-ADD5-9E3CE60B06C8@gmail.com> <8467_1385735507_5298A553_8467_17054_3_6B7134B31289DC4FAF731D844122B36E309D0D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B920972B9BE@ESESSMB101.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.234.42] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 09:29:39 -0000 On December 04, 2013 4:14 AM, Ben Campbell wrote: > I can also imagine very useful ways to exchange OLRs out-of-band. I can understand some of those imaginations. However, I do not agree to def= ine the current solution with all the future imagination which may or may n= ot come true.=20 Regards, Nirav. -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell Sent: Wednesday, December 04, 2013 4:14 AM To: Maria Cruz Bartolome Cc: dime@ietf.org Subject: Re: [Dime] DOIC: Self-Contained OLRs On Dec 2, 2013, at 9:57 AM, Maria Cruz Bartolome wrote: > Dear all, >=20 > About self-contained OLRs, I agree with Nirav, Lionel and JJ. > Duplication of information should be avoided, once we have considered pig= gybacking as the overload info conveyance mechanism. It's not duplication. It's decoupling. In many cases, that sort of decoupli= ng can greatly simplify the solution. For example, let's say I save an OLR in a log. With self-contained OLRs, I = can just save the OLR. Otherwise, I have to save some or all of the answer = with it. This is true of _any_ interpretation and creation of the OLR. Self= -contained OLRs are less work to create, less work to insert in the request= , and less work to interpret. This is true even for a purely piggybacked so= lution. But more importantly, self-contained OLRs allow for much more extensibility= and reuse. For example, if we find a need to create a dedicated overload a= pplication, we can do so without creating a new format. If we want to exten= d the solution later to allow sending OLRs in requests, we can do so, again= without a new format. The same is true if we later decide to extend the so= lution to allow OLRs in watchdog messages. I can also imagine very useful ways to exchange OLRs out-of-band. >=20 > Best regards > /MCruz >=20 >=20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN,=20 > JEAN-JACQUES (JEAN-JACQUES) > Sent: viernes, 29 de noviembre de 2013 16:05 > To: dime@ietf.org > Subject: Re: [Dime] DOIC: Self-Contained OLRs >=20 > Dear all >=20 > In the baseline mechanism as currently defined in the draft, the OLR cont= ent is simple, and is related to the message conveying it in particular app= lication origin host/realm and destination to which the OLR is sent back. = As Lionel indicated, it is not so important to know which node inserts the = OLR or to have other information. >=20 > There is a performance aspect to consider: the OLRs defined in the baseli= ne may be frequently sent (in particular to compensate possible message l= osses and to manage the loopback to the reporting node ensuring the quick c= onvergence towards the optimal throughput). So we have to minimize the proc= essing of these OLRs. As OLRs are piggybacked in the relevant messages, t= hey may be simply forwarded in the same message by the DAs on the path exce= pt if there are particular reasons a DA to act on them. =20 >=20 > I am cautious about duplication of information, it always means additiona= l checks to ensure consistency. If the OLR has an application id and orig= in host different from the message conveying it, what to do with this OLR,= is it an error case? or should it be put in another message in the path? O= ur current piggybacking mechanism allows the OLR to remain in the same mess= age from the reporting node to the reacting node.=20 >=20 > An important point is extensibility, as we may have to introduce other t= ype of OLRs, additional AVPs, more sophisticated processing, but these exte= nsions should not impact the baseline mechanism by making the baseline mor= e complex. the current draft allows extensions without impacting the baseli= ne. >=20 > Currently I do not see drawbacks on the OLRs defined for the baseline mec= hanism. So my comments join the Nirav and Lionel's ones. >=20 > Best regards >=20 > JJacques >=20 >=20 > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de=20 > lionel.morand@orange.com Envoy=E9 : vendredi 29 novembre 2013 15:32 =C0 := =20 > Nirav Salot (nsalot); Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich);=20 > dime@ietf.org list Cc : Ben Campbell Objet : Re: [Dime] DOIC:=20 > Self-Contained OLRs >=20 > I totally agree with Nirav. No need to revert at this stage the working a= ssumption on piggybacking of OLR in application answer messages, especially= when the aim is to define a basic mechanism called "reduction". >=20 > Anyone would be able to further add extra info for optimization if needed= but there is no need at all for the basic mechanism. >=20 > Regards, >=20 > Lionel >=20 > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot=20 > (nsalot) Envoy=E9 : vendredi 29 novembre 2013 12:24 =C0 : Jouni Korhonen;= =20 > Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list Cc : Ben Campbell=20 > Objet : Re: [Dime] DOIC: Self-Contained OLRs >=20 > Jouni, Ben, >=20 > I am totally against the idea of self-contained OC-OLR specifically since= we have adopted the principles of piggybacking the OC-OLR over existing ap= plication message. > Self-contained OC-OLR - which means adding all the information which defi= nes the scope of the OC-OLR into the OC-OLR - does not make sense in the pi= ggybacking approach. In fact, it is adding lot of information, which is any= way available within the message containing the OC-OLR, into the OC-OLR. So= it is adding lot of redundant information in a message which increases the= processing requirement for the sender as well as the receiver. (And this i= s un-optimization, in my view). >=20 > Besides, I am not convinced with the other reasons provided here: > - One software module within a node can provide OC-OLR to another softwar= e module in the same node without passing other related info > Within a node, based on the design, lots of information may need to be = passed between two software modules and we cannot optimize those aspects by= replicating unnecessary information in a protocol message. > In summary, it is node's internal software design issue and we need not= optimize that at protocol level. >=20 > - Once the reporting node realizes that it is overloaded, it has to=20 > wait for right answer to send OC-OLR What is the point of sending OC-OLR= for a context for which there is no messaging? Why should the reacting nod= e care if it never sends a message for a context for which the reporting no= de is overloaded? > So this waiting is justified since it ensures that the overload is repor= ted only when necessary and only to the applicable reacting node. Not to al= l the nodes in the network. >=20 > - The agent needs to wait for the answer generated by the server and the = right context > The same argument as applicable for the server applies here. The agent = need not send out-of-context overload info to a node. > Why should reacting node receive/process/store the overload info for th= e scope for which it is not sending any messages. >=20 > - For sending OC-OLR in dedicated Diameter application??? > Piggybacking was the first basic principle we agreed before putting othe= r principles in place. So we may want to go back the drawing board if we de= cide to change this principle. >=20 > Regards, > Nirav. >=20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen > Sent: Friday, November 29, 2013 2:50 PM > To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list > Cc: Ben Campbell > Subject: Re: [Dime] DOIC: Self-Contained OLRs >=20 >=20 >=20 > So, are we reaching any level of consensus here? >=20 > - JOuni >=20 > (as a note.. that we are converging back to where we started with OLRs=20 > ;) >=20 >=20 >=20 > On Nov 28, 2013, at 12:40 PM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: >=20 >> Hi, >>=20 >> another question: >>=20 >> If we go for explicit self contained OLRs, why would we then need the Re= portType? >>=20 >> The realm-type OLR would explicitly contain application-Id, Realm, but n= o Host whereas the host-type OLR would explicitly contain application-Id, H= ost, but probably (I'm not sure) no Realm. >>=20 >> Ulrich >>=20 >>=20 >>=20 >> -----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 >>=20 >> Hi, >>=20 >> There is no assumption on which entity is providing the realm overload s= tatus. It could be provided an agent inserting this info in answers receive= d 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 se= rver itself, one for the realm for new request sent to the realm with only = Dest-Realm AVP. >>=20 >> Lionel >>=20 >> -----Message d'origine----- >> De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich=20 >> (NSN - DE/Munich) Envoy=E9 : jeudi 28 novembre 2013 10:26 =C0 : ext Joun= i=20 >> Korhonen; Ben Campbell Cc : dime@ietf.org list Objet : Re: [Dime] >> DOIC: Self-Contained OLRs >>=20 >> Hi, >>=20 >> I don't see how the possibility to send more than one OLR in an answer i= s aligned with the "endpoint principle". If the ReportType is "realm" this = indicates to the reacting end point that the reporting end point is an agen= t (e.g. SFE) rather than a server. If the ReportType is "host" this indicat= es to the reacting end point that the reporting end point is a server. How = can the reporting end point be both agent and server? >>=20 >> Ulrich >>=20 >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Jouni=20 >> Korhonen >> Sent: Wednesday, November 27, 2013 11:44 PM >> To: Ben Campbell >> Cc: dime@ietf.org list >> Subject: Re: [Dime] DOIC: Self-Contained OLRs >>=20 >>=20 >> On Nov 28, 2013, at 12:27 AM, Ben Campbell wrote: >>=20 >>> Hi, >>>=20 >>> I mentioned in another thread that I prefer putting an explicit=20 >>> ReportType AVP in an OLR, rather than >>=20 >> The more I spent time thinking/writing the actual procedures on the=20 >> endpoints, the more it makes sense to me to keep the ReportType in=20 >> the OC-OLR. Even if the baseline does not have agent overload etc,=20 >> the ReportType fits well to the "endpoint principle" we have in the draf= t. >> It indeed gives more tools to make a host vs. realm base decision on the= reacting node and is plain more clear. >>=20 >> I skip the rest of the mail.. too much text ;-) >>=20 >>=20 >> - Jouni >>=20 >>=20 >>=20 >>=20 >>=20 >>> making a responding node infer the type or meaning of the OLR from a Di= ameter request that corresponds to the answer containing the OLR. My reason= s for that go beyond just ReportType, so I'm starting a separate thread. >>>=20 >>> 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 t= hat carries the OLR. For example, the OLR implicitly refers to the applicat= ion identified by the Application-Id field of the enclosing answer, the rea= lm 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 mea= ning in the context of the enclosing answer. If you moved an OLR from one a= nswer to another, it's meaning may change completely. >>>=20 >>> I think this approach is a mistake. I would greatly prefer that we expl= icitly include such values in the OLR itself, for multiple reasons: >>>=20 >>> 1) It's more complex to interpret implicit, contextual values than expl= icit values. The consumer cannot simply look at the OLR; it must look in va= rious other AVPs to find all the information it needs. For example, I think= a common software design for overload control processing to be separated f= rom 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 OL= R, 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 "c= ontext" avps that must be interpreted can grow large. This approach is erro= r prone, and will likely encourage brittle, hard-to-maintain code. Self-con= tained OLRs would keep all the information related to overload in one place= . making for simpler implementations. >>>=20 >>> 2) It's more complex for the reporting node to send implicit values tha= n explicit values. The sender cannot simply set the context to match the OL= R--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 ins= ert OLRs into answers created by other nodes.=20 >>>=20 >>> If the reporting node screws this up, the meaning of the OLR may change= significantly. So again, implicit meaning gives us error prone implementat= ions. Self-contained OLRs are simpler to create and send. >>>=20 >>> 3) Implicit values don't work at all for certain problems. For=20 >>> example, if an agent needs to originate an OLR, it typically needs=20 >>> to insert that OLR into an existing Diameter answer created by a server= . >>> It can't create its own answer without affecting the application=20 >>> state. If the responding node assumes the OLR comes from or refers=20 >>> to the node identified by the Origin-Host AVP in the enclosing=20 >>> answer, things break. (For examples of when an agent needs to send=20 >>> OLRs that are distinct from those sent by a server, see Steve's=20 >>> agent overload draft, or my dh/dr example.) >>>=20 >>> OTOH, explicit values will work for all cases where we need to associat= e some arbitrary value with an OLR. >>>=20 >>> 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 ov= erload 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 trans= ported, this won't work. We would have to create a new or significantly mod= ified OLR format if we found a need to transport OLRs in different ways. Se= lf-contained OLRs would allow much greater flexibility. >>>=20 >>> 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. >>>=20 >>> Thanks! >>>=20 >>> Ben. >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>=20 >> _______________________________________________ >> 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 >>=20 >> _____________________________________________________________________ >> _ ___________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations=20 >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 >> exploites ou copies sans autorisation. Si vous avez recu ce message=20 >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que= les pieces jointes. Les messages electroniques etant susceptibles d'altera= tion, Orange decline toute responsabilite si ce message a ete altere, defor= me ou falsifie. Merci. >>=20 >> This message and its attachments may contain confidential or=20 >> 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 d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >>=20 >=20 > _______________________________________________ > 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 >=20 > ______________________________________________________________________ > ___________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc pas etre diffuses, exploites o= u copies sans autorisation. Si vous avez recu ce message par erreur, veuill= ez 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= . >=20 > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; they should not be distributed, us= ed or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > 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 From nsalot@cisco.com Thu Dec 5 01:29:42 2013 Return-Path: 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 5D62C1ADBCC for ; Thu, 5 Dec 2013 01:29:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.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 aOahyyoLI7aF for ; Thu, 5 Dec 2013 01:29:38 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 6793D1AD9B6 for ; Thu, 5 Dec 2013 01:29:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16422; q=dns/txt; s=iport; t=1386235775; x=1387445375; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=/i0c190B7pVRbnNFtTO85JnYeJZHS5eKNvl9IhSAvAE=; b=cxef3alDWp6IGKtd2QniQAsO6FjFpPcdIoDi2YUq79edYf7GJhv5Oe1J LLqDBNb7FU7Pf9MVb2vJSyZ8szkMxzvIgiPrprojnEU3LKi0X7OofZbnE yAQeG+sdqWzS3wmXlbwGsc+hl/lDhS/0TeKjmqZd+WDAhW0CW9SitYE09 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFANtGoFKtJXG//2dsb2JhbABZgwc4U7hsgRgWdIIlAQEBAwEBAQFkBwQHBQcEAgEIEQEDAQEBCh0HJwsUAwYIAgQOBQgRh2MGDcEYEwSOHQEQAgEeMQcGgxqBEwOJCqEdgymBaAc7 X-IronPort-AV: E=Sophos;i="4.93,831,1378857600"; d="scan'208";a="289544750" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-6.cisco.com with ESMTP; 05 Dec 2013 09:29:34 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id rB59TYA8030762 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Dec 2013 09:29:34 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.250]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Thu, 5 Dec 2013 03:29:34 -0600 From: "Nirav Salot (nsalot)" To: Ben Campbell Thread-Topic: [Dime] DOIC: Self-Contained OLRs Thread-Index: AQHO67/s/vGpiVuf2UayvwQoJbzwfZo6EVYAgACzUoCAAAFygIAAE10AgAF8EQD//7X5YIAHfJgAgAHAgTA= Date: Thu, 5 Dec 2013 09:29:33 +0000 Message-ID: References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D90006681519BC90@DEMUMBX014.nsn-intra.net> <6390_1385631044_52970D44_6390_18593_1_6B7134B31289DC4FAF731D844122B36E30748E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BD31@DEMUMBX014.nsn-intra.net> <47383DC2-1A1B-4D1A-ADD5-9E3CE60B06C8@gmail.com> <0E3F4DF0-0C5F-482D-8CA4-F77B5B2A5F09@nostrum.com> In-Reply-To: <0E3F4DF0-0C5F-482D-8CA4-F77B5B2A5F09@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.234.42] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dime@ietf.org list" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 09:29:42 -0000 Ben, Lets not assume that the implementation concern you have raised applies to = all the architecture and all the products.=20 I understand that you have talked to your developers but let us also not as= sume that all architectures are the same and layering is the de-facto imple= mentation and the existing proposal is "hard" to implement. > I didn't say that no messages existed that could carry the report. The is= sue is, there may be a lot of other messages that _cannot_ carry it. So the= sender has to sort through all the messages to find the ones that can work= . I am really confused now by your various arguments related to "the reportin= g node has to wait for the right context to send the OC-OLR if the OC-OLR i= s not self-contained!" As I understand from your proposal "the self-contained OC-OLR includes exac= tly the same parameters that are included in the message carrying the OC-OL= R (and which defines the context of OC-OLR)". So in that case, the reporting node has to anyway wait "for the right conte= xt which can carry particular OC-OLR" and replicate the parameters inside t= he message and inside the OC-OLR. So the "self-contained OC-OLR" is not goi= ng to change the waiting aspect at all. But if you say that "with self-contained OC-OLR reporting node can include = out-of-context OC-OLR (e.g. OC-OLR applicable for different application) in= a message" then I understand your arguments regarding "the reporting node = need not wait for the right context." But then this breaks the piggybacking principle and hence not agreeable.=20 Regards, Nirav. -----Original Message----- From: Ben Campbell [mailto:ben@nostrum.com]=20 Sent: Wednesday, December 04, 2013 4:45 AM To: Nirav Salot (nsalot) Cc: Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list Subject: Re: [Dime] DOIC: Self-Contained OLRs (oops, sorry, I sent my previous response before I was finished. On Nov 29, 2013, at 5:24 AM, Nirav Salot (nsalot) wrote: > Jouni, Ben, >=20 > I am totally against the idea of self-contained OC-OLR specifically since= we have adopted the principles of piggybacking the OC-OLR over existing ap= plication message. > Self-contained OC-OLR - which means adding all the information which defi= nes the scope of the OC-OLR into the OC-OLR - does not make sense in the pi= ggybacking approach. In fact, it is adding lot of information, which is any= way available within the message containing the OC-OLR, into the OC-OLR. So= it is adding lot of redundant information in a message which increases the= processing requirement for the sender as well as the receiver. (And this i= s un-optimization, in my view). It's not clear to me that piggybacking implies any particular relationship = between an OLR and the enclosing message, other than transport. >=20 > Besides, I am not convinced with the other reasons provided here: > - One software module within a node can provide OC-OLR to another softwar= e module in the same node without passing other related info > Within a node, based on the design, lots of information may need to be = passed between two software modules and we cannot optimize those aspects by= replicating unnecessary information in a protocol message. > In summary, it is node's internal software design issue and we need not= optimize that at protocol level. We should absolutely not ignore implementation concerns. I think that overl= oad control should be considered a separate layer than the Diameter applica= tion. The whole point of layering is about reducing implementation complexi= ty. In fact, I think this whole disagreement comes from different assumptions a= bout layering. Part of why I've brought this up is, I have talked to implem= entors who think that we've made life hard for them by tying OLRs to tightl= y to the application. This is particularly hard for anything that wants to = handle OLC for arbitrary applications in an application-independent way. (W= hich, by the way, is required by the requirements RFC). >=20 > - Once the reporting node realizes that it is overloaded, it has to=20 > wait for right answer to send OC-OLR What is the point of sending OC-OLR= for a context for which there is no messaging? Why should the reacting nod= e care if it never sends a message for a context for which the reporting no= de is overloaded? I didn't say that no messages existed that could carry the report. The issu= e is, there may be a lot of other messages that _cannot_ carry it. So the s= ender has to sort through all the messages to find the ones that can work. > So this waiting is justified since it ensures that the overload is repor= ted only when necessary and only to the applicable reacting node. Not to al= l the nodes in the network. With self-contained OLRs, you don't have to worry about an inappropriate no= de getting the request. Sure you can choose to send OLRs only to appropriat= e reacting nodes, but that becomes an implementation decision rather than a= protocol requirement. >=20 > - The agent needs to wait for the answer generated by the server and the = right context > The same argument as applicable for the server applies here. The agent = need not send out-of-context overload info to a node. > Why should reacting node receive/process/store the overload info for th= e scope for which it is not sending any messages. If it's not sending (or going to send) any messages for the scope, it can i= gnore the OLR. >=20 > - For sending OC-OLR in dedicated Diameter application??? > Piggybacking was the first basic principle we agreed before putting othe= r principles in place. So we may want to go back the drawing board if we de= cide to change this principle. Piggybacking does not conflict with self-contained OLRs. The roach draft wa= s piggybacked, and still used self-contained OLRs. All we have to do to use= self-contained OLRs is add the necessary AVPs to the OLR format, and possi= bly remove a bunch of restrictions on how you can use them. If we need othe= r transport designs (i.e. dedicated applications), we can add those later. I'd like to remind people that the original mandate given to the design tea= m at the Berlin DIME meeting was to define a format and semantics, not defi= ne how we move reports around. We went way beyond that. I don't object to t= hat fact, but I think we should avoid too many limitations in the format an= d semantics that prevent other ways of moving the reports around. >=20 > Regards, > Nirav. >=20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen > Sent: Friday, November 29, 2013 2:50 PM > To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list > Cc: Ben Campbell > Subject: Re: [Dime] DOIC: Self-Contained OLRs >=20 >=20 >=20 > So, are we reaching any level of consensus here? >=20 > - JOuni >=20 > (as a note.. that we are converging back to where we started with OLRs=20 > ;) >=20 >=20 >=20 > On Nov 28, 2013, at 12:40 PM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: >=20 >> Hi, >>=20 >> another question: >>=20 >> If we go for explicit self contained OLRs, why would we then need the Re= portType? >>=20 >> The realm-type OLR would explicitly contain application-Id, Realm, but n= o Host whereas the host-type OLR would explicitly contain application-Id, H= ost, but probably (I'm not sure) no Realm. >>=20 >> Ulrich >>=20 >>=20 >>=20 >> -----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 >>=20 >> Hi, >>=20 >> There is no assumption on which entity is providing the realm overload s= tatus. It could be provided an agent inserting this info in answers receive= d 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 se= rver itself, one for the realm for new request sent to the realm with only = Dest-Realm AVP. >>=20 >> Lionel >>=20 >> -----Message d'origine----- >> De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich=20 >> (NSN - DE/Munich) Envoy=E9 : jeudi 28 novembre 2013 10:26 =C0 : ext Joun= i=20 >> Korhonen; Ben Campbell Cc : dime@ietf.org list Objet : Re: [Dime] >> DOIC: Self-Contained OLRs >>=20 >> Hi, >>=20 >> I don't see how the possibility to send more than one OLR in an answer i= s aligned with the "endpoint principle". If the ReportType is "realm" this = indicates to the reacting end point that the reporting end point is an agen= t (e.g. SFE) rather than a server. If the ReportType is "host" this indicat= es to the reacting end point that the reporting end point is a server. How = can the reporting end point be both agent and server? >>=20 >> Ulrich >>=20 >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Jouni=20 >> Korhonen >> Sent: Wednesday, November 27, 2013 11:44 PM >> To: Ben Campbell >> Cc: dime@ietf.org list >> Subject: Re: [Dime] DOIC: Self-Contained OLRs >>=20 >>=20 >> On Nov 28, 2013, at 12:27 AM, Ben Campbell wrote: >>=20 >>> Hi, >>>=20 >>> I mentioned in another thread that I prefer putting an explicit=20 >>> ReportType AVP in an OLR, rather than >>=20 >> The more I spent time thinking/writing the actual procedures on the=20 >> endpoints, the more it makes sense to me to keep the ReportType in=20 >> the OC-OLR. Even if the baseline does not have agent overload etc,=20 >> the ReportType fits well to the "endpoint principle" we have in the draf= t. >> It indeed gives more tools to make a host vs. realm base decision on the= reacting node and is plain more clear. >>=20 >> I skip the rest of the mail.. too much text ;-) >>=20 >>=20 >> - Jouni >>=20 >>=20 >>=20 >>=20 >>=20 >>> making a responding node infer the type or meaning of the OLR from a Di= ameter request that corresponds to the answer containing the OLR. My reason= s for that go beyond just ReportType, so I'm starting a separate thread. >>>=20 >>> 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 t= hat carries the OLR. For example, the OLR implicitly refers to the applicat= ion identified by the Application-Id field of the enclosing answer, the rea= lm 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 mea= ning in the context of the enclosing answer. If you moved an OLR from one a= nswer to another, it's meaning may change completely. >>>=20 >>> I think this approach is a mistake. I would greatly prefer that we expl= icitly include such values in the OLR itself, for multiple reasons: >>>=20 >>> 1) It's more complex to interpret implicit, contextual values than expl= icit values. The consumer cannot simply look at the OLR; it must look in va= rious other AVPs to find all the information it needs. For example, I think= a common software design for overload control processing to be separated f= rom 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 OL= R, 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 "c= ontext" avps that must be interpreted can grow large. This approach is erro= r prone, and will likely encourage brittle, hard-to-maintain code. Self-con= tained OLRs would keep all the information related to overload in one place= . making for simpler implementations. >>>=20 >>> 2) It's more complex for the reporting node to send implicit values tha= n explicit values. The sender cannot simply set the context to match the OL= R--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 ins= ert OLRs into answers created by other nodes.=20 >>>=20 >>> If the reporting node screws this up, the meaning of the OLR may change= significantly. So again, implicit meaning gives us error prone implementat= ions. Self-contained OLRs are simpler to create and send. >>>=20 >>> 3) Implicit values don't work at all for certain problems. For=20 >>> example, if an agent needs to originate an OLR, it typically needs=20 >>> to insert that OLR into an existing Diameter answer created by a server= . >>> It can't create its own answer without affecting the application=20 >>> state. If the responding node assumes the OLR comes from or refers=20 >>> to the node identified by the Origin-Host AVP in the enclosing=20 >>> answer, things break. (For examples of when an agent needs to send=20 >>> OLRs that are distinct from those sent by a server, see Steve's=20 >>> agent overload draft, or my dh/dr example.) >>>=20 >>> OTOH, explicit values will work for all cases where we need to associat= e some arbitrary value with an OLR. >>>=20 >>> 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 ov= erload 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 trans= ported, this won't work. We would have to create a new or significantly mod= ified OLR format if we found a need to transport OLRs in different ways. Se= lf-contained OLRs would allow much greater flexibility. >>>=20 >>> 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. >>>=20 >>> Thanks! >>>=20 >>> Ben. >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>=20 >> _______________________________________________ >> 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 >>=20 >> _____________________________________________________________________ >> _ ___________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations=20 >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 >> exploites ou copies sans autorisation. Si vous avez recu ce message=20 >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que= les pieces jointes. Les messages electroniques etant susceptibles d'altera= tion, Orange decline toute responsabilite si ce message a ete altere, defor= me ou falsifie. Merci. >>=20 >> This message and its attachments may contain confidential or=20 >> 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 d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >>=20 >=20 > _______________________________________________ > 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 From nsalot@cisco.com Thu Dec 5 01:29:45 2013 Return-Path: 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 CD2331ADBD3 for ; Thu, 5 Dec 2013 01:29:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.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 8ovc_FC9BpeL for ; Thu, 5 Dec 2013 01:29:41 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB171ADBCB for ; Thu, 5 Dec 2013 01:29:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22238; q=dns/txt; s=iport; t=1386235778; x=1387445378; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=7u3LsaMwpWMX4TwYXNl2+dzEXR2CgXaNwLITK5XTcWA=; b=exV4JZ5MLCNcGvJjAK5Xw+rlQdgb6jXd0yQ6SvSyeQzIwfA55VtyRUKz HH5Jrhiv0Rz1iVdW7/ImgNGygqRIMxEB5RGW0fFPjTY40OC9waOQFRmW/ g1sv0NUppxehVZYixdZQMIqIJcIaDk15C9DZBI9ZfE4wiKGe6zlCZ5p3P 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAO5GoFKtJV2b/2dsb2JhbABZgwc4U7hsgRgWdIIlAQEBAwEBAQEXTQUCBgIDBQcEAgEIEQQBAQEKHQcnCxQJCAIEAQ0FCBOHYQYNwRgTBI4dARACAR4xBwaDGoETA4kKiyeVdoMpgio X-IronPort-AV: E=Sophos;i="4.93,831,1378857600"; d="scan'208";a="4500797" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-5.cisco.com with ESMTP; 05 Dec 2013 09:29:37 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rB59Tb7F002667 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Dec 2013 09:29:37 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.250]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Thu, 5 Dec 2013 03:29:37 -0600 From: "Nirav Salot (nsalot)" To: "lionel.morand@orange.com" , Ben Campbell Thread-Topic: [Dime] DOIC: Self-Contained OLRs Thread-Index: AQHO67/s/vGpiVuf2UayvwQoJbzwfZo6EVYAgACzUoCAAAFygIAAE10AgAF8EQD//7X5YIAAoQmAgATJUQCAAAuBAIACAWkAgAAGHYCAAAkGgIABvLkw Date: Thu, 5 Dec 2013 09:29:36 +0000 Message-ID: References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D90006681519BC90@DEMUMBX014.nsn-intra.net> <6390_1385631044_52970D44_6390_18593_1_6B7134B31289DC4FAF731D844122B36E30748E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BD31@DEMUMBX014.nsn-intra.net> <47383DC2-1A1B-4D1A-ADD5-9E3CE60B06C8@gmail.com> <8467_1385735507_5298A553_8467_17054_3_6B7134B31289DC4FAF731D844122B36E309D0D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <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> <14257_1386114616_529E6E38_14257_8534_1_6B7134B31289DC4FAF731D844122B36E31AA09@PEXCVZYM11.corporate.adroot.infra.ftgroup> In-Reply-To: <14257_1386114616_529E6E38_14257_8534_1_6B7134B31289DC4FAF731D844122B36E31AA09@PEXCVZYM11.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.234.42] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 09:29:46 -0000 I fully agree with Lionel, below. Besides, in future, if and when we have to define a new dedicated applicati= on for conveying OC-OLR, we may have to define lot of new aspects from scra= tch. And lets worry about all of those aspects at that point of time instea= d of trying to solve some of those aspects today - e.g. we may be able to c= arry the OC-OLR defined today in a new dedicated application in future. Regards, Nirav. -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange= .com Sent: Wednesday, December 04, 2013 5:20 AM To: Ben Campbell Cc: dime@ietf.org Subject: Re: [Dime] DOIC: Self-Contained OLRs In addition, if a totally application-independent solution to convey any ty= pe of overload report for any application, the more straightforward solutio= n would have been the definition of a new application. I think that we have to be pragmatic. A lot of meeting time and email discu= ssions have been spent on this topic since more than one year and we are ab= out to miss the deadline for a stable document that could be used as refere= nce for protocol work in 3GPP. The existing content of the draft was based = on working assumptions for a basic solution for overload agreed between key= participants on the topic and extensibility of the solution was carefully = addressed to allow further development. Of course, the discussion is still open and I can't/don't want to close it.= But it will be soon time to decide what to do with the proposed solution i= n order to let 3GPP know what to do. Regards, Lionel -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de lionel.morand@oran= ge.com Envoy=E9=A0: mercredi 4 d=E9cembre 2013 00:18 =C0=A0: Ben Campbell C= c=A0: dime@ietf.org Objet=A0: Re: [Dime] DOIC: Self-Contained OLRs Hi Ben, I may be wrong somewhere in my summary but I think that it was the result o= f the discussions and agreements reached regarding existing requirements, a= t least from 3GPP point of view, compared to possible optimizations for fut= ure optimizations not so obvious. And because the solution offers extensibility via the definition of new alg= o, new report type and addition of any new AVP in the existing Grouped OLR,= the "limitations" of the proposed solution might be removed by someone if = really required according to new requirements. Regards, Lionel -----Message d'origine----- De=A0: Ben Campbell [mailto:ben@nostrum.com] Envoy=E9=A0: mardi 3 d=E9cembr= e 2013 23:56 =C0=A0: MORAND Lionel IMT/OLN Cc=A0: Steve Donovan; dime@ietf.= org Objet=A0: Re: [Dime] DOIC: Self-Contained OLRs On Dec 2, 2013, at 10:18 AM, lionel.morand@orange.com wrote: > Hi Steve, > =20 > I think that is not only about few bytes in the answer. It is also about = the solution principles agreed so far: > =B7 the current need is for an OLR bound to the application in us= e > =B7 the OLR is received from the node targeted in the request. > =B7 the OLR is defined per application I don't think those principles have been well tested. I don't recall any di= scussion of their benefits. What benefits do you see they have over self-co= ntained OLRs? All I see from these are restrictions in the flexibility of the solution, w= ith very little in return. > So all the implicit information (application, origin-host, origin-realm) = are meaningful in this context. > And the actual solution is designed based on these assumptions. The exten= sibility of the solution will allow extra info if required in other use cas= es but it was agreed to go with a straightforward solution that will satisf= y most of us. > =20 > Regards, > =20 > Lionel > =20 > De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan > Envoy=E9 : lundi 2 d=E9cembre 2013 16:37 > =C0 : dime@ietf.org > Objet : Re: [Dime] DOIC: Self-Contained OLRs > =20 > I don't believe that Ben's proposal was to change the piggybacking assump= tion in the baseline mechanism. Ben's proposal is to design the solution i= n such a way that it is not dependent on the piggybacking transport mechani= sm. =20 >=20 > I share Ben's concern that we have over optimized the content of the over= load report in a way that makes implementations brittle, interoperability m= ore difficult to achieve and extensibility more complex. And what do we ga= in from this optimization? A few bites in answer messages. >=20 > Self contained overload reports, transported using the piggybacking mecha= nism, is a cleaner solution. >=20 > Steve >=20 > On 11/29/13 8:31 AM, lionel.morand@orange.com wrote: > I totally agree with Nirav. No need to revert at this stage the working a= ssumption on piggybacking of OLR in application answer messages, especially= when the aim is to define a basic mechanism called "reduction". > =20 > Anyone would be able to further add extra info for optimization if needed= but there is no need at all for the basic mechanism. > =20 > Regards, > =20 > Lionel > =20 > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot (nsalo= t) > Envoy=E9 : vendredi 29 novembre 2013 12:24 > =C0 : Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list > Cc : Ben Campbell > Objet : Re: [Dime] DOIC: Self-Contained OLRs > =20 > Jouni, Ben, > =20 > I am totally against the idea of self-contained OC-OLR specifically since= we have adopted the principles of piggybacking the OC-OLR over existing ap= plication message. > Self-contained OC-OLR - which means adding all the information which defi= nes the scope of the OC-OLR into the OC-OLR - does not make sense in the pi= ggybacking approach. In fact, it is adding lot of information, which is any= way available within the message containing the OC-OLR, into the OC-OLR. So= it is adding lot of redundant information in a message which increases the= processing requirement for the sender as well as the receiver. (And this i= s un-optimization, in my view). > =20 > Besides, I am not convinced with the other reasons provided here: > - One software module within a node can provide OC-OLR to another softwar= e module in the same node without passing other related info > Within a node, based on the design, lots of information may need to be= passed between two software modules and we cannot optimize those aspects b= y replicating unnecessary information in a protocol message. > In summary, it is node's internal software design issue and we need no= t optimize that at protocol level. > =20 > - Once the reporting node realizes that it is overloaded, it has to wait = for right answer to send OC-OLR > What is the point of sending OC-OLR for a context for which there is no= messaging? Why should the reacting node care if it never sends a message f= or a context for which the reporting node is overloaded? > So this waiting is justified since it ensures that the overload is repo= rted only when necessary and only to the applicable reacting node. Not to a= ll the nodes in the network. > =20 > - The agent needs to wait for the answer generated by the server and the = right context > The same argument as applicable for the server applies here. The agent= need not send out-of-context overload info to a node. > Why should reacting node receive/process/store the overload info for t= he scope for which it is not sending any messages. > =20 > - For sending OC-OLR in dedicated Diameter application??? > Piggybacking was the first basic principle we agreed before putting oth= er principles in place. So we may want to go back the drawing board if we d= ecide to change this principle. > =20 > Regards, > Nirav. > =20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen > Sent: Friday, November 29, 2013 2:50 PM > To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list > Cc: Ben Campbell > Subject: Re: [Dime] DOIC: Self-Contained OLRs > =20 > =20 > =20 > So, are we reaching any level of consensus here? > =20 > - JOuni > =20 > (as a note.. that we are converging back to where we started with OLRs ;) > =20 > =20 > =20 > On Nov 28, 2013, at 12:40 PM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: > =20 > Hi, > =20 > another question: > =20 > If we go for explicit self contained OLRs, why would we then need the Rep= ortType? > =20 > The realm-type OLR would explicitly contain application-Id, Realm, but no= Host whereas the host-type OLR would explicitly contain application-Id, Ho= st, but probably (I'm not sure) no Realm. > =20 > Ulrich > =20 > =20 > =20 > -----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 > =20 > Hi, > =20 > There is no assumption on which entity is providing the realm overload st= atus. 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 s= ome 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 ser= ver itself, one for the realm for new request sent to the realm with only D= est-Realm AVP. > =20 > Lionel > =20 > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich=20 > (NSN - DE/Munich) Envoy=E9 : jeudi 28 novembre 2013 10:26 =C0 : ext Jouni= =20 > Korhonen; Ben Campbell Cc : dime@ietf.org list Objet : Re: [Dime]=20 > DOIC: Self-Contained OLRs > =20 > Hi, > =20 > 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 i= ndicates 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 indicate= s to the reacting end point that the reporting end point is a server. How c= an the reporting end point be both agent and server? > =20 > Ulrich > =20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Jouni=20 > Korhonen > Sent: Wednesday, November 27, 2013 11:44 PM > To: Ben Campbell > Cc: dime@ietf.org list > Subject: Re: [Dime] DOIC: Self-Contained OLRs > =20 > =20 > On Nov 28, 2013, at 12:27 AM, Ben Campbell wrote: > =20 > Hi, > =20 > I mentioned in another thread that I prefer putting an explicit=20 > ReportType AVP in an OLR, rather than > =20 > The more I spent time thinking/writing the actual procedures on the=20 > endpoints, the more it makes sense to me to keep the ReportType in the=20 > OC-OLR. Even if the baseline does not have agent overload etc, the=20 > ReportType fits well to the "endpoint principle" we have in the draft.=20 > It indeed gives more tools to make a host vs. realm base decision on the = reacting node and is plain more clear. > =20 > I skip the rest of the mail.. too much text ;-) > =20 > =20 > - Jouni > =20 > =20 > =20 > =20 > =20 > making a responding node infer the type or meaning of the OLR from a Diam= eter request that corresponds to the answer containing the OLR. My reasons = for that go beyond just ReportType, so I'm starting a separate thread. > =20 > As currently described, a consumer of an OLR must infer several things fr= om other context. In most cases, that context is in the Diameter answer tha= t carries the OLR. For example, the OLR implicitly refers to the applicatio= n 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 meani= ng in the context of the enclosing answer. If you moved an OLR from one ans= wer to another, it's meaning may change completely. > =20 > I think this approach is a mistake. I would greatly prefer that we explic= itly include such values in the OLR itself, for multiple reasons: > =20 > 1) It's more complex to interpret implicit, contextual values than explic= it values. The consumer cannot simply look at the OLR; it must look in vari= ous other AVPs to find all the information it needs. For example, I think a= common software design for overload control processing to be separated fro= m application processing. The consumer cannot simply hand the OLR to that m= odule 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 "con= text" avps that must be interpreted can grow large. This approach is error = prone, and will likely encourage brittle, hard-to-maintain code. Self-conta= ined OLRs would keep all the information related to overload in one place. = making for simpler implementations. > =20 > 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 r= eporting node realizes that it is overloade, it has to wait for the right a= nswer that contains the right context before it can send the OLR. This is p= articularly troublesome for agents, since they will typically have to inser= t OLRs into answers created by other nodes.=20 > =20 > If the reporting node screws this up, the meaning of the OLR may change s= ignificantly. So again, implicit meaning gives us error prone implementatio= ns. Self-contained OLRs are simpler to create and send. > =20 > 3) Implicit values don't work at all for certain problems. For=20 > example, if an agent needs to originate an OLR, it typically needs to=20 > insert that OLR into an existing Diameter answer created by a server.=20 > It can't create its own answer without affecting the application=20 > state. If the responding node assumes the OLR comes from or refers to=20 > the node identified by the Origin-Host AVP in the enclosing answer,=20 > things break. (For examples of when an agent needs to send OLRs that=20 > are distinct from those sent by a server, see Steve's agent overload=20 > draft, or my dh/dr example.) > =20 > OTOH, explicit values will work for all cases where we need to associate = some arbitrary value with an OLR. > =20 > 4) Implicit values seriously constrain the future evolution of Diameter O= C standards. For example, lets say we find a good reason to allow OLRs to b= e sent out of band, or be sent in a dedicated Diameter application. If over= load 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 transpo= rted, this won't work. We would have to create a new or significantly modif= ied OLR format if we found a need to transport OLRs in different ways. Self= -contained OLRs would allow much greater flexibility. > =20 > So, in summary, I think that self-contained OLRs would lead to simpler im= plementations, less brittle deployments, and more flexibility for future ev= olution of standards. > =20 > Thanks! > =20 > Ben. > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > =20 > _______________________________________________ > 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 > =20 > ______________________________________________________________________ > ___________________________________________________ > =20 > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci. > =20 > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not be d= istributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > =20 > =20 > _______________________________________________ > 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 > =20 > _________________________________________________________________________= ________________________________________________ > =20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu 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 o= u falsifie. Merci. > =20 > This message and its attachments may contain confidential or privileged i= nformation 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 de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > =20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > =20 > =20 > _________________________________________________________________________= ________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu 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 o= u falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged i= nformation 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 de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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 confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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 From nsalot@cisco.com Thu Dec 5 01:29:51 2013 Return-Path: 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 2A3E81ADBD3 for ; Thu, 5 Dec 2013 01:29:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.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 MlZRpIdvq_GU for ; Thu, 5 Dec 2013 01:29:45 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id CEC921ADBCE for ; Thu, 5 Dec 2013 01:29:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25652; q=dns/txt; s=iport; t=1386235782; x=1387445382; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=oGJcK4BXNW04TMKlXttVr8lLWyMEMXtLTa/KsKEb8CI=; b=QQ+/DTA0yfs/q9dKWVyFHc+467HrEXWdnwTcgCJpDhsHYs6c5J8E2fD9 9qhy1SFSkQPKhfxtz2dwO+8bG8/rE6NZgfJPRqROVqJCp7yoZITZKezFL qPLji5/nZavxaDuY/bj9FvmV0o2pkY4hDw3FyNhtn8eY80oBKbP0lERA+ 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAO5GoFKtJV2d/2dsb2JhbABZgwc4U7hsgRgWdIIlAQEBAwEBAQEXTQUCBgIIBwQCAQgRBAEBAQodBycLFAkIAgQBEggTh2EGDcEYEwSOHQEQAgEeOAaDGoETA4kKoR2DKYIq X-IronPort-AV: E=Sophos;i="4.93,831,1378857600"; d="scan'208";a="289541189" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP; 05 Dec 2013 09:29:40 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id rB59Te99017865 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Dec 2013 09:29:40 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.250]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Thu, 5 Dec 2013 03:29:39 -0600 From: "Nirav Salot (nsalot)" To: Maria Cruz Bartolome , "dime@ietf.org" Thread-Topic: [Dime] DOIC: Self-Contained OLRs Thread-Index: AQHO67/s/vGpiVuf2UayvwQoJbzwfZo6EVYAgACzUoCAAAFygIAAE10AgAF8EQD//7X5YIAAoQmAgATJUQCAAAuBAIACAWkAgAAGHYCAAXsigIAALuKAgAAb/4CAAAErgA== Date: Thu, 5 Dec 2013 09:29:39 +0000 Message-ID: References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D90006681519BC90@DEMUMBX014.nsn-intra.net> <6390_1385631044_52970D44_6390_18593_1_6B7134B31289DC4FAF731D844122B36E30748E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BD31@DEMUMBX014.nsn-intra.net> <47383DC2-1A1B-4D1A-ADD5-9E3CE60B06C8@gmail.com> <8467_1385735507_5298A553_8467_17054_3_6B7134B31289DC4FAF731D844122B36E309D0D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <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> <14594_1386204165_529FCC05_14594_12646_1_6B7134B31289DC4FAF731D844122B36E329907@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B920972CCAA@ESESSMB101.ericsson.se> In-Reply-To: <087A34937E64E74E848732CFF8354B920972CCAA@ESESSMB101.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.234.42] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 09:29:51 -0000 Agree with Lionel's view and Maria-Cruz's arguments below. The "self-contained OC-OLR" - which I assume contains the same information = as present in the message containing the OC-OLR - adds extra complexity as = highlighted by Maria-Cruz. The benefit highlighted can be achieved in an implementation specific way b= y the receiver duplicating the information into OC-OLR before passing it to= the layer processing the OC-OLR. Regards, Nirav. -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Maria Cruz Bartolome Sent: Thursday, December 05, 2013 7:53 AM To: dime@ietf.org Subject: Re: [Dime] DOIC: Self-Contained OLRs Dear all, I agree with Lionel argumentation below. A part from that, one concern with "self-contained OLRs" is that some data= is duplicated. Duplication should be avoided, since then we need to assure= consistency, and error handing in case implicit and explicit data values a= re different for any reason... what means that it may always be required to= check both implicit and explicit data. Also, I think this is a pure implementation proposal. Regardless how the da= ta is transported it could be packed in a "self-contained OLRs" within the = diameter application, if for any implementation this is preferred. Regards /MCruz -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange= .com Sent: jueves, 05 de diciembre de 2013 1:43 To: Ben Campbell Cc: dime@ietf.org Subject: Re: [Dime] DOIC: Self-Contained OLRs Hi Ben, 3GPP operational requirements have triggered and driven this work, and 3GPP= will be the main client for this solution (if not the only for a while...)= . Main parties involved in the discussions are 3GPP vendors and 3GPP operat= ors. So instead trying to keep private preserve, we should welcome and enfo= rce cooperative work with 3GPP on this task if we want that the solution de= fined in IETF will be used in 3GPP. Otherwise, 3GPP may decide not to wait = for IETF and develop its own solution, as done in the past (e.g. developing= 3GPP-specific Cx application instead of adopting the IETF-standard Diamete= r SIP application). About the technical discussion, the Req31 says: REQ 31: There are multiple situations where a Diameter node may be overloaded for some purposes but not others. For example, this can happen to an agent or server that supports multiple applications, or when a server depends on multiple external resources, some of which may become overloaded while others are fully available. The solution MUST allow Diameter nodes to indicate overload with sufficient granularity to allow clients to take action based on the overloaded resources without unreasonably forcing available capacity to go unused. The solution MUST support specification of overload information with granularities of at least "Diameter node", "realm", and "Diameter application" and MUST allow extensibility for others to be added in the future. The "MUST" part says: enough granularity with at least host/realm and appli= cation. And the existing solution is compliant with this requirement. If a node is = supporting N applications, an OLR can be sent "per application" with a repo= rt type indicating if it is for the host or the realm. And the extensibilit= y capability is provided by the base solution. So my technical argument is that the existing proposal fulfills the basic r= equirements for an overload control without compromising future extension f= or further granularity. Regards, Lionel=20 -----Message d'origine----- De=A0: Ben Campbell [mailto:ben@nostrum.com] Envoy=E9=A0: mercredi 4 d=E9ce= mbre 2013 22:55 =C0=A0: MORAND Lionel IMT/OLN Cc=A0: dime@ietf.org Objet=A0= : Re: [Dime] DOIC: Self-Contained OLRs On Dec 3, 2013, at 5:17 PM, lionel.morand@orange.com wrote: > Hi Ben, >=20 > I may be wrong somewhere in my summary but I think that it was the result= of the discussions and agreements reached regarding existing requirements,= at least from 3GPP point of view, compared to possible optimizations for f= uture optimizations not so obvious. We are not the 3GPP. Our requirements are RFC 7068. I believe self-containe= d OLRs do a better job of meeting Req 31 than the contextually-defined OLRs= . I've made several technical arguments here--does anyone have _technical_ ar= guments in favor of contextually-defined OLRs? > And because the solution offers extensibility via the definition of new a= lgo, new report type and addition of any new AVP in the existing Grouped OL= R, the "limitations" of the proposed solution might be removed by someone i= f really required according to new requirements. >=20 It might be worth considering a compromise approach: Define _optional_ AVPs= that allow an OLR to be self-contained. If they are not present, then the = various values default to those from the enclosing Diameter message. Possib= ly add support for this to the list of things that reacting nodes can adver= tise. This could be in the base, or in a follow on extension. (If left for an ext= ension, it's worth considering whether ReportType needs to be in the base, = or this or some other extension.)=20 > Regards, >=20 > Lionel >=20 > -----Message d'origine----- > De : Ben Campbell [mailto:ben@nostrum.com] Envoy=E9 : mardi 3 d=E9cembre= =20 > 2013 23:56 =C0 : MORAND Lionel IMT/OLN Cc : Steve Donovan; dime@ietf.org= =20 > Objet : Re: [Dime] DOIC: Self-Contained OLRs >=20 >=20 > On Dec 2, 2013, at 10:18 AM, lionel.morand@orange.com wrote: >=20 >> Hi Steve, >>=20 >> I think that is not only about few bytes in the answer. It is also about= the solution principles agreed so far: >> =B7 the current need is for an OLR bound to the application in u= se >> =B7 the OLR is received from the node targeted in the request. >> =B7 the OLR is defined per application >=20 > I don't think those principles have been well tested. I don't recall any = discussion of their benefits. What benefits do you see they have over self-= contained OLRs? >=20 > All I see from these are restrictions in the flexibility of the solution,= with very little in return. >=20 >> So all the implicit information (application, origin-host, origin-realm)= are meaningful in this context. >> And the actual solution is designed based on these assumptions. The exte= nsibility of the solution will allow extra info if required in other use ca= ses but it was agreed to go with a straightforward solution that will satis= fy most of us. >>=20 >> Regards, >>=20 >> Lionel >>=20 >> De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan >> Envoy=E9 : lundi 2 d=E9cembre 2013 16:37 >> =C0 : dime@ietf.org >> Objet : Re: [Dime] DOIC: Self-Contained OLRs >>=20 >> I don't believe that Ben's proposal was to change the piggybacking assum= ption in the baseline mechanism. Ben's proposal is to design the solution = in such a way that it is not dependent on the piggybacking transport mechan= ism. =20 >>=20 >> I share Ben's concern that we have over optimized the content of the ove= rload report in a way that makes implementations brittle, interoperability = more difficult to achieve and extensibility more complex. And what do we g= ain from this optimization? A few bites in answer messages. >>=20 >> Self contained overload reports, transported using the piggybacking mech= anism, is a cleaner solution. >>=20 >> Steve >>=20 >> On 11/29/13 8:31 AM, lionel.morand@orange.com wrote: >> I totally agree with Nirav. No need to revert at this stage the working = assumption on piggybacking of OLR in application answer messages, especiall= y when the aim is to define a basic mechanism called "reduction". >>=20 >> Anyone would be able to further add extra info for optimization if neede= d but there is no need at all for the basic mechanism. >>=20 >> Regards, >>=20 >> Lionel >>=20 >> -----Message d'origine----- >> De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot (nsal= ot) >> Envoy=E9 : vendredi 29 novembre 2013 12:24 >> =C0 : Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org lis= t >> Cc : Ben Campbell >> Objet : Re: [Dime] DOIC: Self-Contained OLRs >>=20 >> Jouni, Ben, >>=20 >> I am totally against the idea of self-contained OC-OLR specifically sinc= e we have adopted the principles of piggybacking the OC-OLR over existing a= pplication message. >> Self-contained OC-OLR - which means adding all the information which def= ines the scope of the OC-OLR into the OC-OLR - does not make sense in the p= iggybacking approach. In fact, it is adding lot of information, which is an= yway available within the message containing the OC-OLR, into the OC-OLR. S= o it is adding lot of redundant information in a message which increases th= e processing requirement for the sender as well as the receiver. (And this = is un-optimization, in my view). >>=20 >> Besides, I am not convinced with the other reasons provided here: >> - One software module within a node can provide OC-OLR to another softwa= re module in the same node without passing other related info >> Within a node, based on the design, lots of information may need to be= passed between two software modules and we cannot optimize those aspects b= y replicating unnecessary information in a protocol message. >> In summary, it is node's internal software design issue and we need no= t optimize that at protocol level. >>=20 >> - Once the reporting node realizes that it is overloaded, it has to wait= for right answer to send OC-OLR >> What is the point of sending OC-OLR for a context for which there is no= messaging? Why should the reacting node care if it never sends a message f= or a context for which the reporting node is overloaded? >> So this waiting is justified since it ensures that the overload is repo= rted only when necessary and only to the applicable reacting node. Not to a= ll the nodes in the network. >>=20 >> - The agent needs to wait for the answer generated by the server and the= right context >> The same argument as applicable for the server applies here. The agent= need not send out-of-context overload info to a node. >> Why should reacting node receive/process/store the overload info for t= he scope for which it is not sending any messages. >>=20 >> - For sending OC-OLR in dedicated Diameter application??? >> Piggybacking was the first basic principle we agreed before putting oth= er principles in place. So we may want to go back the drawing board if we d= ecide to change this principle. >>=20 >> Regards, >> Nirav. >>=20 >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen >> Sent: Friday, November 29, 2013 2:50 PM >> To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list >> Cc: Ben Campbell >> Subject: Re: [Dime] DOIC: Self-Contained OLRs >>=20 >>=20 >>=20 >> So, are we reaching any level of consensus here? >>=20 >> - JOuni >>=20 >> (as a note.. that we are converging back to where we started with OLRs ;= ) >>=20 >>=20 >>=20 >> On Nov 28, 2013, at 12:40 PM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: >>=20 >> Hi, >>=20 >> another question: >>=20 >> If we go for explicit self contained OLRs, why would we then need the Re= portType? >>=20 >> The realm-type OLR would explicitly contain application-Id, Realm, but n= o Host whereas the host-type OLR would explicitly contain application-Id, H= ost, but probably (I'm not sure) no Realm. >>=20 >> Ulrich >>=20 >>=20 >>=20 >> -----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 >>=20 >> Hi, >>=20 >> There is no assumption on which entity is providing the realm overload s= tatus. It could be provided an agent inserting this info in answers receive= d 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 se= rver itself, one for the realm for new request sent to the realm with only = Dest-Realm AVP. >>=20 >> Lionel >>=20 >> -----Message d'origine----- >> De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich=20 >> (NSN - DE/Munich) Envoy=E9 : jeudi 28 novembre 2013 10:26 =C0 : ext Joun= i=20 >> Korhonen; Ben Campbell Cc : dime@ietf.org list Objet : Re: [Dime]=20 >> DOIC: Self-Contained OLRs >>=20 >> Hi, >>=20 >> I don't see how the possibility to send more than one OLR in an answer i= s aligned with the "endpoint principle". If the ReportType is "realm" this = indicates to the reacting end point that the reporting end point is an agen= t (e.g. SFE) rather than a server. If the ReportType is "host" this indicat= es to the reacting end point that the reporting end point is a server. How = can the reporting end point be both agent and server? >>=20 >> Ulrich >>=20 >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Jouni=20 >> Korhonen >> Sent: Wednesday, November 27, 2013 11:44 PM >> To: Ben Campbell >> Cc: dime@ietf.org list >> Subject: Re: [Dime] DOIC: Self-Contained OLRs >>=20 >>=20 >> On Nov 28, 2013, at 12:27 AM, Ben Campbell wrote: >>=20 >> Hi, >>=20 >> I mentioned in another thread that I prefer putting an explicit=20 >> ReportType AVP in an OLR, rather than >>=20 >> The more I spent time thinking/writing the actual procedures on the=20 >> endpoints, the more it makes sense to me to keep the ReportType in the=20 >> OC-OLR. Even if the baseline does not have agent overload etc, the=20 >> ReportType fits well to the "endpoint principle" we have in the draft.=20 >> It indeed gives more tools to make a host vs. realm base decision on the= reacting node and is plain more clear. >>=20 >> I skip the rest of the mail.. too much text ;-) >>=20 >>=20 >> - Jouni >>=20 >>=20 >>=20 >>=20 >>=20 >> making a responding node infer the type or meaning of the OLR from a Dia= meter request that corresponds to the answer containing the OLR. My reasons= for that go beyond just ReportType, so I'm starting a separate thread. >>=20 >> As currently described, a consumer of an OLR must infer several things f= rom other context. In most cases, that context is in the Diameter answer th= at carries the OLR. For example, the OLR implicitly refers to the applicati= on identified by the Application-Id field of the enclosing answer, the real= m identified by Origin-Realm, and so on. This means that the "meaning" of a= n OLR cannot be determined from the OLR contents alone; OLRs only have mean= ing in the context of the enclosing answer. If you moved an OLR from one an= swer to another, it's meaning may change completely. >>=20 >> I think this approach is a mistake. I would greatly prefer that we expli= citly include such values in the OLR itself, for multiple reasons: >>=20 >> 1) It's more complex to interpret implicit, contextual values than expli= cit values. The consumer cannot simply look at the OLR; it must look in var= ious other AVPs to find all the information it needs. For example, I think = a common software design for overload control processing to be separated fr= om 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 "co= ntext" avps that must be interpreted can grow large. This approach is error= prone, and will likely encourage brittle, hard-to-maintain code. Self-cont= ained OLRs would keep all the information related to overload in one place.= making for simpler implementations. >>=20 >> 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 inse= rt OLRs into answers created by other nodes.=20 >>=20 >> If the reporting node screws this up, the meaning of the OLR may change = significantly. So again, implicit meaning gives us error prone implementati= ons. Self-contained OLRs are simpler to create and send. >>=20 >> 3) Implicit values don't work at all for certain problems. For=20 >> example, if an agent needs to originate an OLR, it typically needs to=20 >> insert that OLR into an existing Diameter answer created by a server.=20 >> It can't create its own answer without affecting the application=20 >> state. If the responding node assumes the OLR comes from or refers to=20 >> the node identified by the Origin-Host AVP in the enclosing answer,=20 >> things break. (For examples of when an agent needs to send OLRs that=20 >> are distinct from those sent by a server, see Steve's agent overload=20 >> draft, or my dh/dr example.) >>=20 >> OTOH, explicit values will work for all cases where we need to associate= some arbitrary value with an OLR. >>=20 >> 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 ove= rload reports were self-contained, one could just reuse the report format w= e specify here. But if the meaning of an OLR depends on the way it's transp= orted, this won't work. We would have to create a new or significantly modi= fied OLR format if we found a need to transport OLRs in different ways. Sel= f-contained OLRs would allow much greater flexibility. >>=20 >> So, in summary, I think that self-contained OLRs would lead to simpler i= mplementations, less brittle deployments, and more flexibility for future e= volution of standards. >>=20 >> Thanks! >>=20 >> Ben. >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >>=20 >> _______________________________________________ >> 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 >>=20 >> ______________________________________________________________________ >> ___________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations=20 >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 >> exploites ou copies sans autorisation. Si vous avez recu ce message=20 >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que= les pieces jointes. Les messages electroniques etant susceptibles d'altera= tion, Orange decline toute responsabilite si ce message a ete altere, defor= me ou falsifie. Merci. >>=20 >> This message and its attachments may contain confidential or=20 >> 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 d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >>=20 >>=20 >> _______________________________________________ >> 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 >>=20 >> ________________________________________________________________________= _________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations confi= dentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez r= ecu 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. >>=20 >> 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 d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >>=20 >>=20 >> ________________________________________________________________________= _________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations confi= dentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez r= ecu 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. >>=20 >> 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 d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >=20 >=20 > _________________________________________________________________________= ________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu 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 o= u falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged i= nformation 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 de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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 From jean-jacques.trottin@alcatel-lucent.com Thu Dec 5 03:14:34 2013 Return-Path: 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 BD50B1ADF2F for ; Thu, 5 Dec 2013 03:14:34 -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 QAfiRiMx2LCC for ; Thu, 5 Dec 2013 03:14:30 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 06EFF1ADED5 for ; Thu, 5 Dec 2013 03:14:29 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id rB5BELQc023622 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 5 Dec 2013 05:14:22 -0600 (CST) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id rB5BELll001486 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 5 Dec 2013 12:14:21 +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; Thu, 5 Dec 2013 12:14:21 +0100 From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" To: "dime@ietf.org" Thread-Topic: [Dime] DOIC: Self-Contained OLRs Thread-Index: AQHO67/uc4Hi6cqE9USGBLWwFB86UZo5m/0AgACzUoCAAAFygIAAE14AgAF8EACAACKcAIAANGaAgATJUgCAAAuAAIACAWkAgAAGHYCAAXsigIAAykrg Date: Thu, 5 Dec 2013 11:14:20 +0000 Message-ID: References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D90006681519BC90@DEMUMBX014.nsn-intra.net> <6390_1385631044_52970D44_6390_18593_1_6B7134B31289DC4FAF731D844122B36E30748E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BD31@DEMUMBX014.nsn-intra.net> <47383DC2-1A1B-4D1A-ADD5-9E3CE60B06C8@gmail.com> <8467_1385735507_5298A553_8467_17054_3_6B7134B31289DC4FAF731D844122B36E309D0D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <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> In-Reply-To: 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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 11:14:34 -0000 Hi=20 A lot of mails on this topic...I would suggest to introduce an overload con= trol on the Dime email threads:) =20 On my side, I rely on what we have written in the draft for the "baseline"= mechanism and that we have to keep as it is simple and efficient, here I j= oin Lionel, Nirav and MCruz' positions. This thread then addresses extensions cases, I agree that we will have to = address such extensions: Nirav mentioned the example with APN that if rel= evant would a 3GGP application case, I would add the Session Group about w= hich we had some discussion a while ago and which is a more generic IETF c= ase. There is also the agent overload case. Have you others? Always good to= have some use cases in mind. What is important for me is that adding extensions should not modify the ba= seline and making it more complex when used alone. I also make a differenc= e between principles and protocol tuning where we may have to choose betwee= n various protocol solution but addressing the same functionality or princi= ple. =20 About piggybacking, in the baseline, the principle is that OLRs which ar= e addressed to sources of traffic are put in answer messages towards this = traffic sources (origin Host) (even if these messages may be processed by = intermediate DAs), which is simple and the OLR can be kept unchanged in the= same message up to the origin Host if no specific process in intermediate= DAs. To have a piggybacking allowing to put any OLR in any message (as it= was in draft roach) is adding complexity that is not justified for the ba= seline and we have not retained it in the existing draft . About extensions, the APN or session group examples address parts of the = traffic between a server and a client (so a higher granularity in the throt= tling than the baseline one), related OLRs are conveyed in the messages tow= ards the origin Host so with an implicit reference to the Application, the = Origin and Destination Host as for the baseline, so not requiring self con= tained OLRs. I also do not see the interest to send these new extensions O= LR only in answers directly related to this OLR (as Ulrich proposed), eg on= ly in an answer dealing with an APN if the OLR is related to APN throttling= . The main point is that the OLR takes a direct "train" towards the right = destination for a given application (as for baseline). This does not exclude that we may have other cases not entering the above e= xamples characteristics, but as Nirav mentioned, we have to remain pragmat= ic and see this when such new use cases will be addressed. The extensibilit= y possibilities of current draft give us a lot of flexibility, e.g. if som= e extensions need more self contained AVPs, why not, but this is outside th= e current draft.=20 About extensions, I also think that they may need to be identified in the c= apability part, as the related OLRs should not be sent by a reacting node i= f the extension is not supported. Last important point, as Lionel mentioned, we have to finalize the draft s= oon, to be able to start Rel12 3GGP work relying on this draft. My position= is that the current draft is currently well suited for the baseline and th= at extensions will be addressed separately =20 Best regards JJacques=20 =20 -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Ben Campbell Envoy=E9=A0: mercredi 4 d=E9cembre 2013 22:55 =C0=A0: ext lionel.morand@orange.com Cc=A0: dime@ietf.org Objet=A0: Re: [Dime] DOIC: Self-Contained OLRs On Dec 3, 2013, at 5:17 PM, lionel.morand@orange.com wrote: > Hi Ben, >=20 > I may be wrong somewhere in my summary but I think that it was the result= of the discussions and agreements reached regarding existing requirements,= at least from 3GPP point of view, compared to possible optimizations for f= uture optimizations not so obvious. We are not the 3GPP. Our requirements are RFC 7068. I believe self-containe= d OLRs do a better job of meeting Req 31 than the contextually-defined OLRs= . I've made several technical arguments here--does anyone have _technical_ ar= guments in favor of contextually-defined OLRs? > And because the solution offers extensibility via the definition of new a= lgo, new report type and addition of any new AVP in the existing Grouped OL= R, the "limitations" of the proposed solution might be removed by someone i= f really required according to new requirements. >=20 It might be worth considering a compromise approach: Define _optional_ AVPs= that allow an OLR to be self-contained. If they are not present, then the = various values default to those from the enclosing Diameter message. Possib= ly add support for this to the list of things that reacting nodes can adver= tise. This could be in the base, or in a follow on extension. (If left for an ext= ension, it's worth considering whether ReportType needs to be in the base, = or this or some other extension.)=20 > Regards, >=20 > Lionel >=20 > -----Message d'origine----- > De : Ben Campbell [mailto:ben@nostrum.com] Envoy=E9 : mardi 3 d=E9cembre= =20 > 2013 23:56 =C0 : MORAND Lionel IMT/OLN Cc : Steve Donovan; dime@ietf.org= =20 > Objet : Re: [Dime] DOIC: Self-Contained OLRs >=20 >=20 > On Dec 2, 2013, at 10:18 AM, lionel.morand@orange.com wrote: >=20 >> Hi Steve, >>=20 >> I think that is not only about few bytes in the answer. It is also about= the solution principles agreed so far: >> =B7 the current need is for an OLR bound to the application in u= se >> =B7 the OLR is received from the node targeted in the request. >> =B7 the OLR is defined per application >=20 > I don't think those principles have been well tested. I don't recall any = discussion of their benefits. What benefits do you see they have over self-= contained OLRs? >=20 > All I see from these are restrictions in the flexibility of the solution,= with very little in return. >=20 >> So all the implicit information (application, origin-host, origin-realm)= are meaningful in this context. >> And the actual solution is designed based on these assumptions. The exte= nsibility of the solution will allow extra info if required in other use ca= ses but it was agreed to go with a straightforward solution that will satis= fy most of us. >>=20 >> Regards, >>=20 >> Lionel >>=20 >> De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan >> Envoy=E9 : lundi 2 d=E9cembre 2013 16:37 >> =C0 : dime@ietf.org >> Objet : Re: [Dime] DOIC: Self-Contained OLRs >>=20 >> I don't believe that Ben's proposal was to change the piggybacking assum= ption in the baseline mechanism. Ben's proposal is to design the solution = in such a way that it is not dependent on the piggybacking transport mechan= ism. =20 >>=20 >> I share Ben's concern that we have over optimized the content of the ove= rload report in a way that makes implementations brittle, interoperability = more difficult to achieve and extensibility more complex. And what do we g= ain from this optimization? A few bites in answer messages. >>=20 >> Self contained overload reports, transported using the piggybacking mech= anism, is a cleaner solution. >>=20 >> Steve >>=20 >> On 11/29/13 8:31 AM, lionel.morand@orange.com wrote: >> I totally agree with Nirav. No need to revert at this stage the working = assumption on piggybacking of OLR in application answer messages, especiall= y when the aim is to define a basic mechanism called "reduction". >>=20 >> Anyone would be able to further add extra info for optimization if neede= d but there is no need at all for the basic mechanism. >>=20 >> Regards, >>=20 >> Lionel >>=20 >> -----Message d'origine----- >> De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot (nsal= ot) >> Envoy=E9 : vendredi 29 novembre 2013 12:24 >> =C0 : Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org lis= t >> Cc : Ben Campbell >> Objet : Re: [Dime] DOIC: Self-Contained OLRs >>=20 >> Jouni, Ben, >>=20 >> I am totally against the idea of self-contained OC-OLR specifically sinc= e we have adopted the principles of piggybacking the OC-OLR over existing a= pplication message. >> Self-contained OC-OLR - which means adding all the information which def= ines the scope of the OC-OLR into the OC-OLR - does not make sense in the p= iggybacking approach. In fact, it is adding lot of information, which is an= yway available within the message containing the OC-OLR, into the OC-OLR. S= o it is adding lot of redundant information in a message which increases th= e processing requirement for the sender as well as the receiver. (And this = is un-optimization, in my view). >>=20 >> Besides, I am not convinced with the other reasons provided here: >> - One software module within a node can provide OC-OLR to another softwa= re module in the same node without passing other related info >> Within a node, based on the design, lots of information may need to be= passed between two software modules and we cannot optimize those aspects b= y replicating unnecessary information in a protocol message. >> In summary, it is node's internal software design issue and we need no= t optimize that at protocol level. >>=20 >> - Once the reporting node realizes that it is overloaded, it has to wait= for right answer to send OC-OLR >> What is the point of sending OC-OLR for a context for which there is no= messaging? Why should the reacting node care if it never sends a message f= or a context for which the reporting node is overloaded? >> So this waiting is justified since it ensures that the overload is repo= rted only when necessary and only to the applicable reacting node. Not to a= ll the nodes in the network. >>=20 >> - The agent needs to wait for the answer generated by the server and the= right context >> The same argument as applicable for the server applies here. The agent= need not send out-of-context overload info to a node. >> Why should reacting node receive/process/store the overload info for t= he scope for which it is not sending any messages. >>=20 >> - For sending OC-OLR in dedicated Diameter application??? >> Piggybacking was the first basic principle we agreed before putting oth= er principles in place. So we may want to go back the drawing board if we d= ecide to change this principle. >>=20 >> Regards, >> Nirav. >>=20 >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen >> Sent: Friday, November 29, 2013 2:50 PM >> To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list >> Cc: Ben Campbell >> Subject: Re: [Dime] DOIC: Self-Contained OLRs >>=20 >>=20 >>=20 >> So, are we reaching any level of consensus here? >>=20 >> - JOuni >>=20 >> (as a note.. that we are converging back to where we started with OLRs ;= ) >>=20 >>=20 >>=20 >> On Nov 28, 2013, at 12:40 PM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: >>=20 >> Hi, >>=20 >> another question: >>=20 >> If we go for explicit self contained OLRs, why would we then need the Re= portType? >>=20 >> The realm-type OLR would explicitly contain application-Id, Realm, but n= o Host whereas the host-type OLR would explicitly contain application-Id, H= ost, but probably (I'm not sure) no Realm. >>=20 >> Ulrich >>=20 >>=20 >>=20 >> -----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 >>=20 >> Hi, >>=20 >> There is no assumption on which entity is providing the realm overload s= tatus. It could be provided an agent inserting this info in answers receive= d 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 se= rver itself, one for the realm for new request sent to the realm with only = Dest-Realm AVP. >>=20 >> Lionel >>=20 >> -----Message d'origine----- >> De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich=20 >> (NSN - DE/Munich) Envoy=E9 : jeudi 28 novembre 2013 10:26 =C0 : ext Joun= i=20 >> Korhonen; Ben Campbell Cc : dime@ietf.org list Objet : Re: [Dime]=20 >> DOIC: Self-Contained OLRs >>=20 >> Hi, >>=20 >> I don't see how the possibility to send more than one OLR in an answer i= s aligned with the "endpoint principle". If the ReportType is "realm" this = indicates to the reacting end point that the reporting end point is an agen= t (e.g. SFE) rather than a server. If the ReportType is "host" this indicat= es to the reacting end point that the reporting end point is a server. How = can the reporting end point be both agent and server? >>=20 >> Ulrich >>=20 >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Jouni=20 >> Korhonen >> Sent: Wednesday, November 27, 2013 11:44 PM >> To: Ben Campbell >> Cc: dime@ietf.org list >> Subject: Re: [Dime] DOIC: Self-Contained OLRs >>=20 >>=20 >> On Nov 28, 2013, at 12:27 AM, Ben Campbell wrote: >>=20 >> Hi, >>=20 >> I mentioned in another thread that I prefer putting an explicit=20 >> ReportType AVP in an OLR, rather than >>=20 >> The more I spent time thinking/writing the actual procedures on the=20 >> endpoints, the more it makes sense to me to keep the ReportType in the=20 >> OC-OLR. Even if the baseline does not have agent overload etc, the=20 >> ReportType fits well to the "endpoint principle" we have in the draft.=20 >> It indeed gives more tools to make a host vs. realm base decision on the= reacting node and is plain more clear. >>=20 >> I skip the rest of the mail.. too much text ;-) >>=20 >>=20 >> - Jouni >>=20 >>=20 >>=20 >>=20 >>=20 >> making a responding node infer the type or meaning of the OLR from a Dia= meter request that corresponds to the answer containing the OLR. My reasons= for that go beyond just ReportType, so I'm starting a separate thread. >>=20 >> As currently described, a consumer of an OLR must infer several things f= rom other context. In most cases, that context is in the Diameter answer th= at carries the OLR. For example, the OLR implicitly refers to the applicati= on identified by the Application-Id field of the enclosing answer, the real= m identified by Origin-Realm, and so on. This means that the "meaning" of a= n OLR cannot be determined from the OLR contents alone; OLRs only have mean= ing in the context of the enclosing answer. If you moved an OLR from one an= swer to another, it's meaning may change completely. >>=20 >> I think this approach is a mistake. I would greatly prefer that we expli= citly include such values in the OLR itself, for multiple reasons: >>=20 >> 1) It's more complex to interpret implicit, contextual values than expli= cit values. The consumer cannot simply look at the OLR; it must look in var= ious other AVPs to find all the information it needs. For example, I think = a common software design for overload control processing to be separated fr= om 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 "co= ntext" avps that must be interpreted can grow large. This approach is error= prone, and will likely encourage brittle, hard-to-maintain code. Self-cont= ained OLRs would keep all the information related to overload in one place.= making for simpler implementations. >>=20 >> 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 inse= rt OLRs into answers created by other nodes.=20 >>=20 >> If the reporting node screws this up, the meaning of the OLR may change = significantly. So again, implicit meaning gives us error prone implementati= ons. Self-contained OLRs are simpler to create and send. >>=20 >> 3) Implicit values don't work at all for certain problems. For=20 >> example, if an agent needs to originate an OLR, it typically needs to=20 >> insert that OLR into an existing Diameter answer created by a server.=20 >> It can't create its own answer without affecting the application=20 >> state. If the responding node assumes the OLR comes from or refers to=20 >> the node identified by the Origin-Host AVP in the enclosing answer,=20 >> things break. (For examples of when an agent needs to send OLRs that=20 >> are distinct from those sent by a server, see Steve's agent overload=20 >> draft, or my dh/dr example.) >>=20 >> OTOH, explicit values will work for all cases where we need to associate= some arbitrary value with an OLR. >>=20 >> 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 ove= rload reports were self-contained, one could just reuse the report format w= e specify here. But if the meaning of an OLR depends on the way it's transp= orted, this won't work. We would have to create a new or significantly modi= fied OLR format if we found a need to transport OLRs in different ways. Sel= f-contained OLRs would allow much greater flexibility. >>=20 >> So, in summary, I think that self-contained OLRs would lead to simpler i= mplementations, less brittle deployments, and more flexibility for future e= volution of standards. >>=20 >> Thanks! >>=20 >> Ben. >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >>=20 >> _______________________________________________ >> 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 >>=20 >> ______________________________________________________________________ >> ___________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations=20 >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 >> exploites ou copies sans autorisation. Si vous avez recu ce message=20 >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que= les pieces jointes. Les messages electroniques etant susceptibles d'altera= tion, Orange decline toute responsabilite si ce message a ete altere, defor= me ou falsifie. Merci. >>=20 >> This message and its attachments may contain confidential or=20 >> 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 d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >>=20 >>=20 >> _______________________________________________ >> 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 >>=20 >> ________________________________________________________________________= _________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations confi= dentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez r= ecu 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. >>=20 >> 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 d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >>=20 >>=20 >> ________________________________________________________________________= _________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations confi= dentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez r= ecu 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. >>=20 >> 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 d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >=20 >=20 > _________________________________________________________________________= ________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu 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 o= u falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged i= nformation 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 de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > 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 From jean-jacques.trottin@alcatel-lucent.com Thu Dec 5 03:50:56 2013 Return-Path: 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 A3A591ADF7A for ; Thu, 5 Dec 2013 03:50:56 -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 zEL03DPLJjDd for ; Thu, 5 Dec 2013 03:50:52 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 53A2A1ADF7D for ; Thu, 5 Dec 2013 03:50: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 rB5Bokhq026016 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 5 Dec 2013 05:50:48 -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 rB5Bokva018597 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 5 Dec 2013 12:50:46 +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; Thu, 5 Dec 2013 12:50:46 +0100 From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" To: "dime@ietf.org" Thread-Topic: [Dime] DOIC: Self-Contained OLRs Thread-Index: AQHO67/uc4Hi6cqE9USGBLWwFB86UZo5m/0AgACzUoCAAAFygIAAE14AgAF8EACAACKcAIAANGaAgATJUgCAAAuAAIACAWkAgAAGHYCAAXsigIAAykrggAAvUUA= Date: Thu, 5 Dec 2013 11:50:45 +0000 Message-ID: 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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Subject: [Dime] TR: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 11:50:56 -0000 Sorry, in the following sentence it is "reporting node" and not "reacting n= ode" as written in my previous mail: =20 "About extensions, I also think that they may need to be identified in the = capability part, as the related OLRs should not be sent by a reporting node= if the extension is not supported." Best regards JJacques=20 -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de TROTTIN, JEAN-JACQ= UES (JEAN-JACQUES) Envoy=E9=A0: jeudi 5 d=E9cembre 2013 12:14 =C0=A0: dime@ietf.org Objet=A0: Re: [Dime] DOIC: Self-Contained OLRs Hi=20 A lot of mails on this topic...I would suggest to introduce an overload con= trol on the Dime email threads:) =20 On my side, I rely on what we have written in the draft for the "baseline"= mechanism and that we have to keep as it is simple and efficient, here I j= oin Lionel, Nirav and MCruz' positions. This thread then addresses extensions cases, I agree that we will have to = address such extensions: Nirav mentioned the example with APN that if rel= evant would a 3GGP application case, I would add the Session Group about w= hich we had some discussion a while ago and which is a more generic IETF c= ase. There is also the agent overload case. Have you others? Always good to= have some use cases in mind. What is important for me is that adding extensions should not modify the ba= seline and making it more complex when used alone. I also make a differenc= e between principles and protocol tuning where we may have to choose betwee= n various protocol solution but addressing the same functionality or princi= ple. =20 About piggybacking, in the baseline, the principle is that OLRs which ar= e addressed to sources of traffic are put in answer messages towards this = traffic sources (origin Host) (even if these messages may be processed by = intermediate DAs), which is simple and the OLR can be kept unchanged in the= same message up to the origin Host if no specific process in intermediate= DAs. To have a piggybacking allowing to put any OLR in any message (as it= was in draft roach) is adding complexity that is not justified for the ba= seline and we have not retained it in the existing draft . About extensions, the APN or session group examples address parts of the = traffic between a server and a client (so a higher granularity in the throt= tling than the baseline one), related OLRs are conveyed in the messages tow= ards the origin Host so with an implicit reference to the Application, the = Origin and Destination Host as for the baseline, so not requiring self con= tained OLRs. I also do not see the interest to send these new extensions O= LR only in answers directly related to this OLR (as Ulrich proposed), eg on= ly in an answer dealing with an APN if the OLR is related to APN throttling= . The main point is that the OLR takes a direct "train" towards the right = destination for a given application (as for baseline). This does not exclude that we may have other cases not entering the above e= xamples characteristics, but as Nirav mentioned, we have to remain pragmat= ic and see this when such new use cases will be addressed. The extensibilit= y possibilities of current draft give us a lot of flexibility, e.g. if som= e extensions need more self contained AVPs, why not, but this is outside th= e current draft.=20 About extensions, I also think that they may need to be identified in the c= apability part, as the related OLRs should not be sent by a reacting node i= f the extension is not supported. Last important point, as Lionel mentioned, we have to finalize the draft s= oon, to be able to start Rel12 3GGP work relying on this draft. My position= is that the current draft is currently well suited for the baseline and th= at extensions will be addressed separately =20 Best regards JJacques=20 =20 -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Ben Campbell Envoy= =E9=A0: mercredi 4 d=E9cembre 2013 22:55 =C0=A0: ext lionel.morand@orange.c= om Cc=A0: dime@ietf.org Objet=A0: Re: [Dime] DOIC: Self-Contained OLRs On Dec 3, 2013, at 5:17 PM, lionel.morand@orange.com wrote: > Hi Ben, >=20 > I may be wrong somewhere in my summary but I think that it was the result= of the discussions and agreements reached regarding existing requirements,= at least from 3GPP point of view, compared to possible optimizations for f= uture optimizations not so obvious. We are not the 3GPP. Our requirements are RFC 7068. I believe self-containe= d OLRs do a better job of meeting Req 31 than the contextually-defined OLRs= . I've made several technical arguments here--does anyone have _technical_ ar= guments in favor of contextually-defined OLRs? > And because the solution offers extensibility via the definition of new a= lgo, new report type and addition of any new AVP in the existing Grouped OL= R, the "limitations" of the proposed solution might be removed by someone i= f really required according to new requirements. >=20 It might be worth considering a compromise approach: Define _optional_ AVPs= that allow an OLR to be self-contained. If they are not present, then the = various values default to those from the enclosing Diameter message. Possib= ly add support for this to the list of things that reacting nodes can adver= tise. This could be in the base, or in a follow on extension. (If left for an ext= ension, it's worth considering whether ReportType needs to be in the base, = or this or some other extension.)=20 > Regards, >=20 > Lionel >=20 > -----Message d'origine----- > De : Ben Campbell [mailto:ben@nostrum.com] Envoy=E9 : mardi 3 d=E9cembre > 2013 23:56 =C0 : MORAND Lionel IMT/OLN Cc : Steve Donovan; dime@ietf.org= =20 > Objet : Re: [Dime] DOIC: Self-Contained OLRs >=20 >=20 > On Dec 2, 2013, at 10:18 AM, lionel.morand@orange.com wrote: >=20 >> Hi Steve, >>=20 >> I think that is not only about few bytes in the answer. It is also about= the solution principles agreed so far: >> =B7 the current need is for an OLR bound to the application in u= se >> =B7 the OLR is received from the node targeted in the request. >> =B7 the OLR is defined per application >=20 > I don't think those principles have been well tested. I don't recall any = discussion of their benefits. What benefits do you see they have over self-= contained OLRs? >=20 > All I see from these are restrictions in the flexibility of the solution,= with very little in return. >=20 >> So all the implicit information (application, origin-host, origin-realm)= are meaningful in this context. >> And the actual solution is designed based on these assumptions. The exte= nsibility of the solution will allow extra info if required in other use ca= ses but it was agreed to go with a straightforward solution that will satis= fy most of us. >>=20 >> Regards, >>=20 >> Lionel >>=20 >> De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan=20 >> Envoy=E9 : lundi 2 d=E9cembre 2013 16:37 =C0 : dime@ietf.org Objet : Re:= =20 >> [Dime] DOIC: Self-Contained OLRs >>=20 >> I don't believe that Ben's proposal was to change the piggybacking assum= ption in the baseline mechanism. Ben's proposal is to design the solution = in such a way that it is not dependent on the piggybacking transport mechan= ism. =20 >>=20 >> I share Ben's concern that we have over optimized the content of the ove= rload report in a way that makes implementations brittle, interoperability = more difficult to achieve and extensibility more complex. And what do we g= ain from this optimization? A few bites in answer messages. >>=20 >> Self contained overload reports, transported using the piggybacking mech= anism, is a cleaner solution. >>=20 >> Steve >>=20 >> On 11/29/13 8:31 AM, lionel.morand@orange.com wrote: >> I totally agree with Nirav. No need to revert at this stage the working = assumption on piggybacking of OLR in application answer messages, especiall= y when the aim is to define a basic mechanism called "reduction". >>=20 >> Anyone would be able to further add extra info for optimization if neede= d but there is no need at all for the basic mechanism. >>=20 >> Regards, >>=20 >> Lionel >>=20 >> -----Message d'origine----- >> De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot=20 >> (nsalot) Envoy=E9 : vendredi 29 novembre 2013 12:24 =C0 : Jouni Korhonen= ;=20 >> Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list Cc : Ben Campbell=20 >> Objet : Re: [Dime] DOIC: Self-Contained OLRs >>=20 >> Jouni, Ben, >>=20 >> I am totally against the idea of self-contained OC-OLR specifically sinc= e we have adopted the principles of piggybacking the OC-OLR over existing a= pplication message. >> Self-contained OC-OLR - which means adding all the information which def= ines the scope of the OC-OLR into the OC-OLR - does not make sense in the p= iggybacking approach. In fact, it is adding lot of information, which is an= yway available within the message containing the OC-OLR, into the OC-OLR. S= o it is adding lot of redundant information in a message which increases th= e processing requirement for the sender as well as the receiver. (And this = is un-optimization, in my view). >>=20 >> Besides, I am not convinced with the other reasons provided here: >> - One software module within a node can provide OC-OLR to another softwa= re module in the same node without passing other related info >> Within a node, based on the design, lots of information may need to be= passed between two software modules and we cannot optimize those aspects b= y replicating unnecessary information in a protocol message. >> In summary, it is node's internal software design issue and we need no= t optimize that at protocol level. >>=20 >> - Once the reporting node realizes that it is overloaded, it has to=20 >> wait for right answer to send OC-OLR What is the point of sending OC-OL= R for a context for which there is no messaging? Why should the reacting no= de care if it never sends a message for a context for which the reporting n= ode is overloaded? >> So this waiting is justified since it ensures that the overload is repo= rted only when necessary and only to the applicable reacting node. Not to a= ll the nodes in the network. >>=20 >> - The agent needs to wait for the answer generated by the server and the= right context >> The same argument as applicable for the server applies here. The agent= need not send out-of-context overload info to a node. >> Why should reacting node receive/process/store the overload info for t= he scope for which it is not sending any messages. >>=20 >> - For sending OC-OLR in dedicated Diameter application??? >> Piggybacking was the first basic principle we agreed before putting oth= er principles in place. So we may want to go back the drawing board if we d= ecide to change this principle. >>=20 >> Regards, >> Nirav. >>=20 >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen >> Sent: Friday, November 29, 2013 2:50 PM >> To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list >> Cc: Ben Campbell >> Subject: Re: [Dime] DOIC: Self-Contained OLRs >>=20 >>=20 >>=20 >> So, are we reaching any level of consensus here? >>=20 >> - JOuni >>=20 >> (as a note.. that we are converging back to where we started with=20 >> OLRs ;) >>=20 >>=20 >>=20 >> On Nov 28, 2013, at 12:40 PM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: >>=20 >> Hi, >>=20 >> another question: >>=20 >> If we go for explicit self contained OLRs, why would we then need the Re= portType? >>=20 >> The realm-type OLR would explicitly contain application-Id, Realm, but n= o Host whereas the host-type OLR would explicitly contain application-Id, H= ost, but probably (I'm not sure) no Realm. >>=20 >> Ulrich >>=20 >>=20 >>=20 >> -----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 >>=20 >> Hi, >>=20 >> There is no assumption on which entity is providing the realm overload s= tatus. It could be provided an agent inserting this info in answers receive= d 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 se= rver itself, one for the realm for new request sent to the realm with only = Dest-Realm AVP. >>=20 >> Lionel >>=20 >> -----Message d'origine----- >> De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich=20 >> (NSN - DE/Munich) Envoy=E9 : jeudi 28 novembre 2013 10:26 =C0 : ext Joun= i=20 >> Korhonen; Ben Campbell Cc : dime@ietf.org list Objet : Re: [Dime] >> DOIC: Self-Contained OLRs >>=20 >> Hi, >>=20 >> I don't see how the possibility to send more than one OLR in an answer i= s aligned with the "endpoint principle". If the ReportType is "realm" this = indicates to the reacting end point that the reporting end point is an agen= t (e.g. SFE) rather than a server. If the ReportType is "host" this indicat= es to the reacting end point that the reporting end point is a server. How = can the reporting end point be both agent and server? >>=20 >> Ulrich >>=20 >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Jouni=20 >> Korhonen >> Sent: Wednesday, November 27, 2013 11:44 PM >> To: Ben Campbell >> Cc: dime@ietf.org list >> Subject: Re: [Dime] DOIC: Self-Contained OLRs >>=20 >>=20 >> On Nov 28, 2013, at 12:27 AM, Ben Campbell wrote: >>=20 >> Hi, >>=20 >> I mentioned in another thread that I prefer putting an explicit=20 >> ReportType AVP in an OLR, rather than >>=20 >> The more I spent time thinking/writing the actual procedures on the=20 >> endpoints, the more it makes sense to me to keep the ReportType in=20 >> the OC-OLR. Even if the baseline does not have agent overload etc,=20 >> the ReportType fits well to the "endpoint principle" we have in the draf= t. >> It indeed gives more tools to make a host vs. realm base decision on the= reacting node and is plain more clear. >>=20 >> I skip the rest of the mail.. too much text ;-) >>=20 >>=20 >> - Jouni >>=20 >>=20 >>=20 >>=20 >>=20 >> making a responding node infer the type or meaning of the OLR from a Dia= meter request that corresponds to the answer containing the OLR. My reasons= for that go beyond just ReportType, so I'm starting a separate thread. >>=20 >> As currently described, a consumer of an OLR must infer several things f= rom other context. In most cases, that context is in the Diameter answer th= at carries the OLR. For example, the OLR implicitly refers to the applicati= on identified by the Application-Id field of the enclosing answer, the real= m identified by Origin-Realm, and so on. This means that the "meaning" of a= n OLR cannot be determined from the OLR contents alone; OLRs only have mean= ing in the context of the enclosing answer. If you moved an OLR from one an= swer to another, it's meaning may change completely. >>=20 >> I think this approach is a mistake. I would greatly prefer that we expli= citly include such values in the OLR itself, for multiple reasons: >>=20 >> 1) It's more complex to interpret implicit, contextual values than expli= cit values. The consumer cannot simply look at the OLR; it must look in var= ious other AVPs to find all the information it needs. For example, I think = a common software design for overload control processing to be separated fr= om 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 "co= ntext" avps that must be interpreted can grow large. This approach is error= prone, and will likely encourage brittle, hard-to-maintain code. Self-cont= ained OLRs would keep all the information related to overload in one place.= making for simpler implementations. >>=20 >> 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 inse= rt OLRs into answers created by other nodes.=20 >>=20 >> If the reporting node screws this up, the meaning of the OLR may change = significantly. So again, implicit meaning gives us error prone implementati= ons. Self-contained OLRs are simpler to create and send. >>=20 >> 3) Implicit values don't work at all for certain problems. For=20 >> example, if an agent needs to originate an OLR, it typically needs to=20 >> insert that OLR into an existing Diameter answer created by a server. >> It can't create its own answer without affecting the application=20 >> state. If the responding node assumes the OLR comes from or refers to=20 >> the node identified by the Origin-Host AVP in the enclosing answer,=20 >> things break. (For examples of when an agent needs to send OLRs that=20 >> are distinct from those sent by a server, see Steve's agent overload=20 >> draft, or my dh/dr example.) >>=20 >> OTOH, explicit values will work for all cases where we need to associate= some arbitrary value with an OLR. >>=20 >> 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 ove= rload reports were self-contained, one could just reuse the report format w= e specify here. But if the meaning of an OLR depends on the way it's transp= orted, this won't work. We would have to create a new or significantly modi= fied OLR format if we found a need to transport OLRs in different ways. Sel= f-contained OLRs would allow much greater flexibility. >>=20 >> So, in summary, I think that self-contained OLRs would lead to simpler i= mplementations, less brittle deployments, and more flexibility for future e= volution of standards. >>=20 >> Thanks! >>=20 >> Ben. >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >>=20 >> _______________________________________________ >> 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 >>=20 >> _____________________________________________________________________ >> _ ___________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations=20 >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 >> exploites ou copies sans autorisation. Si vous avez recu ce message=20 >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que= les pieces jointes. Les messages electroniques etant susceptibles d'altera= tion, Orange decline toute responsabilite si ce message a ete altere, defor= me ou falsifie. Merci. >>=20 >> This message and its attachments may contain confidential or=20 >> 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 d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >>=20 >>=20 >> _______________________________________________ >> 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 >>=20 >> _____________________________________________________________________ >> ____________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations=20 >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 >> exploites ou copies sans autorisation. Si vous avez recu ce message=20 >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que= les pieces jointes. Les messages electroniques etant susceptibles d'altera= tion, Orange decline toute responsabilite si ce message a ete altere, defor= me ou falsifie. Merci. >>=20 >> This message and its attachments may contain confidential or=20 >> 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 d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >>=20 >>=20 >> _____________________________________________________________________ >> ____________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations=20 >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 >> exploites ou copies sans autorisation. Si vous avez recu ce message=20 >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que= les pieces jointes. Les messages electroniques etant susceptibles d'altera= tion, Orange decline toute responsabilite si ce message a ete altere, defor= me ou falsifie. Merci. >>=20 >> This message and its attachments may contain confidential or=20 >> 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 d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >=20 >=20 > ______________________________________________________________________ > ___________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not be d= istributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > 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 From srdonovan@usdonovans.com Thu Dec 5 04:48:39 2013 Return-Path: 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 C10BA1ADFA1 for ; Thu, 5 Dec 2013 04:48:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no 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 e93t8Hh0GYQC for ; Thu, 5 Dec 2013 04:48:35 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 7228C1ADFAC for ; Thu, 5 Dec 2013 04:48:35 -0800 (PST) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:61140 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1VoYLx-0000Ed-Tv for dime@ietf.org; Thu, 05 Dec 2013 04:48:32 -0800 Message-ID: <52A07619.4030305@usdonovans.com> Date: Thu, 05 Dec 2013 06:48:25 -0600 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: dime@ietf.org References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D90006681519BC90@DEMUMBX014.nsn-intra.net> <6390_1385631044_52970D44_6390_18593_1_6B7134B31289DC4FAF731D844122B36E30748E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BD31@DEMUMBX014.nsn-intra.net> <47383DC2-1A1B-4D1A-ADD5-9E3CE60B06C8@gmail.com> <0E3F4DF0-0C5F-482D-8CA4-F77B5B2A5F09@nostrum.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060401070803000407010106" X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 12:48:40 -0000 This is a multi-part message in MIME format. --------------060401070803000407010106 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit All, I have seen the argument a couple of times, including by Nirav below, that the proposal for self contained overload reports breaks the piggybacking principle. This is not the case. The piggybacking principle means one thing -- That overload reports are transported in existing application messages. The piggybacking principle does not constrain in any way what information can be included in the overload report. Steve On 12/5/13 3:29 AM, Nirav Salot (nsalot) wrote: > Ben, > > Lets not assume that the implementation concern you have raised applies to all the architecture and all the products. > I understand that you have talked to your developers but let us also not assume that all architectures are the same and layering is the de-facto implementation and the existing proposal is "hard" to implement. > >> I didn't say that no messages existed that could carry the report. The issue is, there may be a lot of other messages that _cannot_ carry it. So the sender has to sort through all the messages to find the ones that can work. > I am really confused now by your various arguments related to "the reporting node has to wait for the right context to send the OC-OLR if the OC-OLR is not self-contained!" > As I understand from your proposal "the self-contained OC-OLR includes exactly the same parameters that are included in the message carrying the OC-OLR (and which defines the context of OC-OLR)". > So in that case, the reporting node has to anyway wait "for the right context which can carry particular OC-OLR" and replicate the parameters inside the message and inside the OC-OLR. So the "self-contained OC-OLR" is not going to change the waiting aspect at all. > > But if you say that "with self-contained OC-OLR reporting node can include out-of-context OC-OLR (e.g. OC-OLR applicable for different application) in a message" then I understand your arguments regarding "the reporting node need not wait for the right context." > But then this breaks the piggybacking principle and hence not agreeable. > > Regards, > Nirav. > > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com] > Sent: Wednesday, December 04, 2013 4:45 AM > To: Nirav Salot (nsalot) > Cc: Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list > Subject: Re: [Dime] DOIC: Self-Contained OLRs > > (oops, sorry, I sent my previous response before I was finished. > > On Nov 29, 2013, at 5:24 AM, Nirav Salot (nsalot) wrote: > >> Jouni, Ben, >> >> I am totally against the idea of self-contained OC-OLR specifically since we have adopted the principles of piggybacking the OC-OLR over existing application message. >> Self-contained OC-OLR - which means adding all the information which defines the scope of the OC-OLR into the OC-OLR - does not make sense in the piggybacking approach. In fact, it is adding lot of information, which is anyway available within the message containing the OC-OLR, into the OC-OLR. So it is adding lot of redundant information in a message which increases the processing requirement for the sender as well as the receiver. (And this is un-optimization, in my view). > It's not clear to me that piggybacking implies any particular relationship between an OLR and the enclosing message, other than transport. > >> Besides, I am not convinced with the other reasons provided here: >> - One software module within a node can provide OC-OLR to another software module in the same node without passing other related info >> Within a node, based on the design, lots of information may need to be passed between two software modules and we cannot optimize those aspects by replicating unnecessary information in a protocol message. >> In summary, it is node's internal software design issue and we need not optimize that at protocol level. > We should absolutely not ignore implementation concerns. I think that overload control should be considered a separate layer than the Diameter application. The whole point of layering is about reducing implementation complexity. > > In fact, I think this whole disagreement comes from different assumptions about layering. Part of why I've brought this up is, I have talked to implementors who think that we've made life hard for them by tying OLRs to tightly to the application. This is particularly hard for anything that wants to handle OLC for arbitrary applications in an application-independent way. (Which, by the way, is required by the requirements RFC). > > >> - Once the reporting node realizes that it is overloaded, it has to >> wait for right answer to send OC-OLR What is the point of sending OC-OLR for a context for which there is no messaging? Why should the reacting node care if it never sends a message for a context for which the reporting node is overloaded? > I didn't say that no messages existed that could carry the report. The issue is, there may be a lot of other messages that _cannot_ carry it. So the sender has to sort through all the messages to find the ones that can work. > >> So this waiting is justified since it ensures that the overload is reported only when necessary and only to the applicable reacting node. Not to all the nodes in the network. > With self-contained OLRs, you don't have to worry about an inappropriate node getting the request. Sure you can choose to send OLRs only to appropriate reacting nodes, but that becomes an implementation decision rather than a protocol requirement. > >> - The agent needs to wait for the answer generated by the server and the right context >> The same argument as applicable for the server applies here. The agent need not send out-of-context overload info to a node. >> Why should reacting node receive/process/store the overload info for the scope for which it is not sending any messages. > If it's not sending (or going to send) any messages for the scope, it can ignore the OLR. > >> - For sending OC-OLR in dedicated Diameter application??? >> Piggybacking was the first basic principle we agreed before putting other principles in place. So we may want to go back the drawing board if we decide to change this principle. > Piggybacking does not conflict with self-contained OLRs. The roach draft was piggybacked, and still used self-contained OLRs. All we have to do to use self-contained OLRs is add the necessary AVPs to the OLR format, and possibly remove a bunch of restrictions on how you can use them. If we need other transport designs (i.e. dedicated applications), we can add those later. > > I'd like to remind people that the original mandate given to the design team at the Berlin DIME meeting was to define a format and semantics, not define how we move reports around. We went way beyond that. I don't object to that fact, but I think we should avoid too many limitations in the format and semantics that prevent other ways of moving the reports around. > > >> Regards, >> Nirav. >> >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen >> Sent: Friday, November 29, 2013 2:50 PM >> To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list >> Cc: Ben Campbell >> Subject: Re: [Dime] DOIC: Self-Contained OLRs >> >> >> >> So, are we reaching any level of consensus here? >> >> - JOuni >> >> (as a note.. that we are converging back to where we started with OLRs >> ;) >> >> >> >> On Nov 28, 2013, at 12:40 PM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: >> >>> Hi, >>> >>> another question: >>> >>> If we go for explicit self contained OLRs, why would we then need the ReportType? >>> >>> The realm-type OLR would explicitly contain application-Id, Realm, but no Host whereas the host-type OLR would explicitly contain application-Id, Host, but probably (I'm not sure) no Realm. >>> >>> 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 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. >>> >> _______________________________________________ >> 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 > --------------060401070803000407010106 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit All,

I have seen the argument a couple of times, including by Nirav below, that the proposal for self contained overload reports breaks the piggybacking principle.  This is not the case.

The piggybacking principle means one thing -- That overload reports are transported in existing application messages.  The piggybacking principle does not constrain in any way what information can be included in the overload report.

Steve
On 12/5/13 3:29 AM, Nirav Salot (nsalot) wrote:
Ben,

Lets not assume that the implementation concern you have raised applies to all the architecture and all the products. 
I understand that you have talked to your developers but let us also not assume that all architectures are the same and layering is the de-facto implementation and the existing proposal is "hard" to implement.


I didn't say that no messages existed that could carry the report. The issue is, there may be a lot of other messages that _cannot_ carry it. So the sender has to sort through all the messages to find the ones that can work.

I am really confused now by your various arguments related to "the reporting node has to wait for the right context to send the OC-OLR if the OC-OLR is not self-contained!"
As I understand from your proposal "the self-contained OC-OLR includes exactly the same parameters that are included in the message carrying the OC-OLR (and which defines the context of OC-OLR)".
So in that case, the reporting node has to anyway wait "for the right context which can carry particular OC-OLR" and replicate the parameters inside the message and inside the OC-OLR. So the "self-contained OC-OLR" is not going to change the waiting aspect at all.

But if you say that "with self-contained OC-OLR reporting node can include out-of-context OC-OLR (e.g. OC-OLR applicable for different application) in a message" then I understand your arguments regarding "the reporting node need not wait for the right context."
But then this breaks the piggybacking principle and hence not agreeable. 

Regards,
Nirav.

-----Original Message-----
From: Ben Campbell [mailto:ben@nostrum.com] 
Sent: Wednesday, December 04, 2013 4:45 AM
To: Nirav Salot (nsalot)
Cc: Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list
Subject: Re: [Dime] DOIC: Self-Contained OLRs

(oops, sorry, I sent my previous response before I was finished.

On Nov 29, 2013, at 5:24 AM, Nirav Salot (nsalot) <nsalot@cisco.com> wrote:


Jouni, Ben,

I am totally against the idea of self-contained OC-OLR specifically since we have adopted the principles of piggybacking the OC-OLR over existing application message.
Self-contained OC-OLR - which means adding all the information which defines the scope of the OC-OLR into the OC-OLR - does not make sense in the piggybacking approach. In fact, it is adding lot of information, which is anyway available within the message containing the OC-OLR, into the OC-OLR. So it is adding lot of redundant information in a message which increases the processing requirement for the sender as well as the receiver. (And this is un-optimization, in my view).

It's not clear to me that piggybacking implies any particular relationship between an OLR and the enclosing message, other than transport.


Besides, I am not convinced with the other reasons provided here:
- One software module within a node can provide OC-OLR to another software module in the same node without passing other related info
  Within a node, based on the design, lots of information may need to be passed between two software modules and we cannot optimize those aspects by replicating unnecessary information in a protocol message.
  In summary, it is node's internal software design issue and we need not optimize that at protocol level.

We should absolutely not ignore implementation concerns. I think that overload control should be considered a separate layer than the Diameter application. The whole point of layering is about reducing implementation complexity.

In fact, I think this whole disagreement comes from different assumptions about layering. Part of why I've brought this up is, I have talked to implementors who think that we've made life hard for them by tying OLRs to tightly to the application. This is particularly hard for anything that wants to handle OLC for arbitrary applications in an application-independent way. (Which, by the way, is required by the requirements RFC).



- Once the reporting node realizes that it is overloaded, it has to 
wait for right answer to send OC-OLR  What is the point of sending OC-OLR for a context for which there is no messaging? Why should the reacting node care if it never sends a message for a context for which the reporting node is overloaded?

I didn't say that no messages existed that could carry the report. The issue is, there may be a lot of other messages that _cannot_ carry it. So the sender has to sort through all the messages to find the ones that can work.


 So this waiting is justified since it ensures that the overload is reported only when necessary and only to the applicable reacting node. Not to all the nodes in the network.

With self-contained OLRs, you don't have to worry about an inappropriate node getting the request. Sure you can choose to send OLRs only to appropriate reacting nodes, but that becomes an implementation decision rather than a protocol requirement.


- The agent needs to wait for the answer generated by the server and the right context
  The same argument as applicable for the server applies here. The agent need not send out-of-context overload info to a node.
  Why should reacting node receive/process/store the overload info for the scope for which it is not sending any messages.

If it's not sending (or going to send) any messages for the scope, it can ignore the OLR.


- For sending OC-OLR in dedicated Diameter application???
 Piggybacking was the first basic principle we agreed before putting other principles in place. So we may want to go back the drawing board if we decide to change this principle.

Piggybacking does not conflict with self-contained OLRs. The roach draft was piggybacked, and still used self-contained OLRs. All we have to do to use self-contained OLRs is add the necessary AVPs to the OLR format, and possibly remove a bunch of restrictions on how you can use them. If we need other transport designs (i.e. dedicated applications), we can add those later.

I'd like to remind people that the original mandate given to the design team at the Berlin DIME meeting was to define a format and semantics, not define how we move reports around. We went way beyond that. I don't object to that fact, but I think we should avoid too many limitations in the format and semantics that prevent other ways of moving the reports around.



Regards,
Nirav.

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen
Sent: Friday, November 29, 2013 2:50 PM
To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list
Cc: Ben Campbell
Subject: Re: [Dime] DOIC: Self-Contained OLRs



So, are we reaching any level of consensus here?

- JOuni

(as a note.. that we are converging back to where we started with OLRs 
;)



On Nov 28, 2013, at 12:40 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> wrote:


Hi,

another question:

If we go for explicit self contained OLRs, why would we then need the ReportType?

The realm-type OLR would explicitly contain application-Id, Realm, but no Host whereas the host-type OLR would explicitly contain application-Id, Host, but probably (I'm not sure) no Realm.

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.


_______________________________________________
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

--------------060401070803000407010106-- From srdonovan@usdonovans.com Thu Dec 5 04:55:51 2013 Return-Path: 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 BDDF81ADFAF for ; Thu, 5 Dec 2013 04:55:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no 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 fHh_fYKJz1q9 for ; Thu, 5 Dec 2013 04:55:46 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 42A2A1ADFAE for ; Thu, 5 Dec 2013 04:55:46 -0800 (PST) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:61151 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1VoYSy-0007Y4-HG for dime@ietf.org; Thu, 05 Dec 2013 04:55:42 -0800 Message-ID: <52A077CC.3000004@usdonovans.com> Date: Thu, 05 Dec 2013 06:55:40 -0600 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: dime@ietf.org References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <47383DC2-1A1B-4D1A-ADD5-9E3CE60B06C8@gmail.com> <8467_1385735507_5298A553_8467_17054_3_6B7134B31289DC4FAF731D844122B36E309D0D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <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> <14594_1386204165_529FCC05_14594_12646_1_6B7134B31289DC4FAF731D844122B36E329907@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B920972CCAA@ESESSMB101.ericsson.se> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050803040900050200030302" X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 12:55:52 -0000 This is a multi-part message in MIME format. --------------050803040900050200030302 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit If we equating "complexity" with work done by a Diameter node, then there is added "complexity" for both proposals. The extra work that needs to be done for the self contained report approach is that the reporter needs to add additional AVPs to the report. This is hardly difficult but it is extra work. The extra work in the implicit approach is that the reactor needs to gather information from multiple AVPs to understand the context of the AVP. Again, hardly difficult but more work that can be avoided in a well layered software architecture. My conclusion is that the complexity argument does not apply. There is complexity in both, its just a matter of where the work is done. Steve On 12/5/13 3:29 AM, Nirav Salot (nsalot) wrote: > Agree with Lionel's view and Maria-Cruz's arguments below. > > The "self-contained OC-OLR" - which I assume contains the same information as present in the message containing the OC-OLR - adds extra complexity as highlighted by Maria-Cruz. > The benefit highlighted can be achieved in an implementation specific way by the receiver duplicating the information into OC-OLR before passing it to the layer processing the OC-OLR. > > Regards, > Nirav. > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Maria Cruz Bartolome > Sent: Thursday, December 05, 2013 7:53 AM > To: dime@ietf.org > Subject: Re: [Dime] DOIC: Self-Contained OLRs > > Dear all, > > I agree with Lionel argumentation below. > > A part from that, one concern with "self-contained OLRs" is that some data is duplicated. Duplication should be avoided, since then we need to assure consistency, and error handing in case implicit and explicit data values are different for any reason... what means that it may always be required to check both implicit and explicit data. > > Also, I think this is a pure implementation proposal. Regardless how the data is transported it could be packed in a "self-contained OLRs" within the diameter application, if for any implementation this is preferred. > > Regards > /MCruz > > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange.com > Sent: jueves, 05 de diciembre de 2013 1:43 > To: Ben Campbell > Cc: dime@ietf.org > Subject: Re: [Dime] DOIC: Self-Contained OLRs > > Hi Ben, > > 3GPP operational requirements have triggered and driven this work, and 3GPP will be the main client for this solution (if not the only for a while...). Main parties involved in the discussions are 3GPP vendors and 3GPP operators. So instead trying to keep private preserve, we should welcome and enforce cooperative work with 3GPP on this task if we want that the solution defined in IETF will be used in 3GPP. Otherwise, 3GPP may decide not to wait for IETF and develop its own solution, as done in the past (e.g. developing 3GPP-specific Cx application instead of adopting the IETF-standard Diameter SIP application). > > About the technical discussion, the Req31 says: > > REQ 31: There are multiple situations where a Diameter node may be > overloaded for some purposes but not others. For example, > this can happen to an agent or server that supports multiple > applications, or when a server depends on multiple external > resources, some of which may become overloaded while others > are fully available. The solution MUST allow Diameter nodes > to indicate overload with sufficient granularity to allow > clients to take action based on the overloaded resources > without unreasonably forcing available capacity to go unused. > The solution MUST support specification of overload > information with granularities of at least "Diameter node", > "realm", and "Diameter application" and MUST allow > extensibility for others to be added in the future. > > The "MUST" part says: enough granularity with at least host/realm and application. > And the existing solution is compliant with this requirement. If a node is supporting N applications, an OLR can be sent "per application" with a report type indicating if it is for the host or the realm. And the extensibility capability is provided by the base solution. > > So my technical argument is that the existing proposal fulfills the basic requirements for an overload control without compromising future extension for further granularity. > > Regards, > > Lionel > > -----Message d'origine----- > De : Ben Campbell [mailto:ben@nostrum.com] Envoyé : mercredi 4 décembre 2013 22:55 À : MORAND Lionel IMT/OLN Cc : dime@ietf.org Objet : Re: [Dime] DOIC: Self-Contained OLRs > > On Dec 3, 2013, at 5:17 PM, lionel.morand@orange.com wrote: > >> Hi Ben, >> >> I may be wrong somewhere in my summary but I think that it was the result of the discussions and agreements reached regarding existing requirements, at least from 3GPP point of view, compared to possible optimizations for future optimizations not so obvious. > We are not the 3GPP. Our requirements are RFC 7068. I believe self-contained OLRs do a better job of meeting Req 31 than the contextually-defined OLRs. > > I've made several technical arguments here--does anyone have _technical_ arguments in favor of contextually-defined OLRs? > >> And because the solution offers extensibility via the definition of new algo, new report type and addition of any new AVP in the existing Grouped OLR, the "limitations" of the proposed solution might be removed by someone if really required according to new requirements. >> > It might be worth considering a compromise approach: Define _optional_ AVPs that allow an OLR to be self-contained. If they are not present, then the various values default to those from the enclosing Diameter message. Possibly add support for this to the list of things that reacting nodes can advertise. > > This could be in the base, or in a follow on extension. (If left for an extension, it's worth considering whether ReportType needs to be in the base, or this or some other extension.) > > >> Regards, >> >> Lionel >> >> -----Message d'origine----- >> De : Ben Campbell [mailto:ben@nostrum.com] Envoyé : mardi 3 décembre >> 2013 23:56 À : MORAND Lionel IMT/OLN Cc : Steve Donovan; dime@ietf.org >> Objet : Re: [Dime] DOIC: Self-Contained OLRs >> >> >> On Dec 2, 2013, at 10:18 AM, lionel.morand@orange.com wrote: >> >>> Hi Steve, >>> >>> I think that is not only about few bytes in the answer. It is also about the solution principles agreed so far: >>> · the current need is for an OLR bound to the application in use >>> · the OLR is received from the node targeted in the request. >>> · the OLR is defined per application >> I don't think those principles have been well tested. I don't recall any discussion of their benefits. What benefits do you see they have over self-contained OLRs? >> >> All I see from these are restrictions in the flexibility of the solution, with very little in return. >> >>> So all the implicit information (application, origin-host, origin-realm) are meaningful in this context. >>> And the actual solution is designed based on these assumptions. The extensibility of the solution will allow extra info if required in other use cases but it was agreed to go with a straightforward solution that will satisfy most of us. >>> >>> Regards, >>> >>> Lionel >>> >>> De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan >>> Envoyé : lundi 2 décembre 2013 16:37 >>> À : dime@ietf.org >>> Objet : Re: [Dime] DOIC: Self-Contained OLRs >>> >>> I don't believe that Ben's proposal was to change the piggybacking assumption in the baseline mechanism. Ben's proposal is to design the solution in such a way that it is not dependent on the piggybacking transport mechanism. >>> >>> I share Ben's concern that we have over optimized the content of the overload report in a way that makes implementations brittle, interoperability more difficult to achieve and extensibility more complex. And what do we gain from this optimization? A few bites in answer messages. >>> >>> Self contained overload reports, transported using the piggybacking mechanism, is a cleaner solution. >>> >>> Steve >>> >>> On 11/29/13 8:31 AM, lionel.morand@orange.com wrote: >>> I totally agree with Nirav. No need to revert at this stage the working assumption on piggybacking of OLR in application answer messages, especially when the aim is to define a basic mechanism called "reduction". >>> >>> Anyone would be able to further add extra info for optimization if needed but there is no need at all for the basic mechanism. >>> >>> Regards, >>> >>> Lionel >>> >>> -----Message d'origine----- >>> De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot (nsalot) >>> Envoyé : vendredi 29 novembre 2013 12:24 >>> À : Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list >>> Cc : Ben Campbell >>> Objet : Re: [Dime] DOIC: Self-Contained OLRs >>> >>> Jouni, Ben, >>> >>> I am totally against the idea of self-contained OC-OLR specifically since we have adopted the principles of piggybacking the OC-OLR over existing application message. >>> Self-contained OC-OLR - which means adding all the information which defines the scope of the OC-OLR into the OC-OLR - does not make sense in the piggybacking approach. In fact, it is adding lot of information, which is anyway available within the message containing the OC-OLR, into the OC-OLR. So it is adding lot of redundant information in a message which increases the processing requirement for the sender as well as the receiver. (And this is un-optimization, in my view). >>> >>> Besides, I am not convinced with the other reasons provided here: >>> - One software module within a node can provide OC-OLR to another software module in the same node without passing other related info >>> Within a node, based on the design, lots of information may need to be passed between two software modules and we cannot optimize those aspects by replicating unnecessary information in a protocol message. >>> In summary, it is node's internal software design issue and we need not optimize that at protocol level. >>> >>> - Once the reporting node realizes that it is overloaded, it has to wait for right answer to send OC-OLR >>> What is the point of sending OC-OLR for a context for which there is no messaging? Why should the reacting node care if it never sends a message for a context for which the reporting node is overloaded? >>> So this waiting is justified since it ensures that the overload is reported only when necessary and only to the applicable reacting node. Not to all the nodes in the network. >>> >>> - The agent needs to wait for the answer generated by the server and the right context >>> The same argument as applicable for the server applies here. The agent need not send out-of-context overload info to a node. >>> Why should reacting node receive/process/store the overload info for the scope for which it is not sending any messages. >>> >>> - For sending OC-OLR in dedicated Diameter application??? >>> Piggybacking was the first basic principle we agreed before putting other principles in place. So we may want to go back the drawing board if we decide to change this principle. >>> >>> Regards, >>> Nirav. >>> >>> -----Original Message----- >>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen >>> Sent: Friday, November 29, 2013 2:50 PM >>> To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list >>> Cc: Ben Campbell >>> Subject: Re: [Dime] DOIC: Self-Contained OLRs >>> >>> >>> >>> So, are we reaching any level of consensus here? >>> >>> - JOuni >>> >>> (as a note.. that we are converging back to where we started with OLRs ;) >>> >>> >>> >>> On Nov 28, 2013, at 12:40 PM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: >>> >>> Hi, >>> >>> another question: >>> >>> If we go for explicit self contained OLRs, why would we then need the ReportType? >>> >>> The realm-type OLR would explicitly contain application-Id, Realm, but no Host whereas the host-type OLR would explicitly contain application-Id, Host, but probably (I'm not sure) no Realm. >>> >>> 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 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. >>> >>> >>> _______________________________________________ >>> 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. >>> >>> _______________________________________________ >>> 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 >> >> _________________________________________________________________________________________________________________________ >> >> 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 > --------------050803040900050200030302 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit If we equating "complexity" with work done by a Diameter node, then there is added "complexity" for both proposals.

The extra work that needs to be done for the self contained report approach is that the reporter needs to add additional AVPs to the report.  This is hardly difficult but it is extra work.

The extra work in the implicit approach is that the reactor needs to gather information from multiple AVPs to understand the context of the AVP.  Again, hardly difficult but more work that can be avoided in a well layered software architecture.

My conclusion is that the complexity argument does not apply.  There is complexity in both, its just a matter of where the work is done.

Steve
On 12/5/13 3:29 AM, Nirav Salot (nsalot) wrote:
Agree with Lionel's view and Maria-Cruz's arguments below.

The "self-contained OC-OLR" - which I assume contains the same information as present in the message containing the OC-OLR - adds extra complexity as highlighted by Maria-Cruz.
The benefit highlighted can be achieved in an implementation specific way by the receiver duplicating the information into OC-OLR before passing it to the layer processing the OC-OLR.

Regards,
Nirav.

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Maria Cruz Bartolome
Sent: Thursday, December 05, 2013 7:53 AM
To: dime@ietf.org
Subject: Re: [Dime] DOIC: Self-Contained OLRs

Dear all,

I agree with Lionel argumentation below.

A part from that,  one concern with "self-contained OLRs" is that some data is duplicated. Duplication should be avoided, since then we need to assure consistency, and error handing in case implicit and explicit data values are different for any reason... what means that it may always be required to check both implicit and explicit data.

Also, I think this is a pure implementation proposal. Regardless how the data is transported it could be packed in a "self-contained OLRs" within the diameter application, if for any implementation this is preferred.

Regards
/MCruz


-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange.com
Sent: jueves, 05 de diciembre de 2013 1:43
To: Ben Campbell
Cc: dime@ietf.org
Subject: Re: [Dime] DOIC: Self-Contained OLRs

Hi Ben,

3GPP operational requirements have triggered and driven this work, and 3GPP will be the main client for this solution (if not the only for a while...). Main parties involved in the discussions are 3GPP vendors and 3GPP operators. So instead trying to keep private preserve, we should welcome and enforce cooperative work with 3GPP on this task if we want that the solution defined in IETF will be used in 3GPP. Otherwise, 3GPP may decide not to wait for IETF and develop its own solution, as done in the past (e.g. developing 3GPP-specific Cx application instead of adopting the IETF-standard Diameter SIP application).

About the technical discussion, the Req31 says:

   REQ 31: There are multiple situations where a Diameter node may be
           overloaded for some purposes but not others.  For example,
           this can happen to an agent or server that supports multiple
           applications, or when a server depends on multiple external
           resources, some of which may become overloaded while others
           are fully available.  The solution MUST allow Diameter nodes
           to indicate overload with sufficient granularity to allow
           clients to take action based on the overloaded resources
           without unreasonably forcing available capacity to go unused.
           The solution MUST support specification of overload
           information with granularities of at least "Diameter node",
           "realm", and "Diameter application" and MUST allow
           extensibility for others to be added in the future.

The "MUST" part says: enough granularity with at least host/realm and application.
And the existing solution is compliant with this requirement. If a node is supporting N applications, an OLR can be sent "per application" with a report type indicating if it is for the host or the realm. And the extensibility capability is provided by the base solution.

So my technical argument is that the existing proposal fulfills the basic requirements for an overload control without compromising future extension for further granularity.

Regards,

Lionel 

-----Message d'origine-----
De : Ben Campbell [mailto:ben@nostrum.com] Envoyé : mercredi 4 décembre 2013 22:55 À : MORAND Lionel IMT/OLN Cc : dime@ietf.org Objet : Re: [Dime] DOIC: Self-Contained OLRs

On Dec 3, 2013, at 5:17 PM, lionel.morand@orange.com wrote:


Hi Ben,

I may be wrong somewhere in my summary but I think that it was the result of the discussions and agreements reached regarding existing requirements, at least from 3GPP point of view, compared to possible optimizations for future optimizations not so obvious.

We are not the 3GPP. Our requirements are RFC 7068. I believe self-contained OLRs do a better job of meeting Req 31 than the contextually-defined OLRs.

I've made several technical arguments here--does anyone have _technical_ arguments in favor of contextually-defined OLRs?


And because the solution offers extensibility via the definition of new algo, new report type and addition of any new AVP in the existing Grouped OLR, the "limitations" of the proposed solution might be removed by someone if really required according to new requirements.


It might be worth considering a compromise approach: Define _optional_ AVPs that allow an OLR to be self-contained. If they are not present, then the various values default to those from the enclosing Diameter message. Possibly add support for this to the list of things that reacting nodes can advertise.

This could be in the base, or in a follow on extension. (If left for an extension, it's worth considering whether ReportType needs to be in the base, or this or some other extension.) 



Regards,

Lionel

-----Message d'origine-----
De : Ben Campbell [mailto:ben@nostrum.com] Envoyé : mardi 3 décembre 
2013 23:56 À : MORAND Lionel IMT/OLN Cc : Steve Donovan; dime@ietf.org 
Objet : Re: [Dime] DOIC: Self-Contained OLRs


On Dec 2, 2013, at 10:18 AM, lionel.morand@orange.com wrote:


Hi Steve,

I think that is not only about few bytes in the answer. It is also about the solution principles agreed so far:
·         the current need is for an OLR bound to the application in use
·         the OLR is received from the node targeted in the request.
·         the OLR is defined per application

I don't think those principles have been well tested. I don't recall any discussion of their benefits. What benefits do you see they have over self-contained OLRs?

All I see from these are restrictions in the flexibility of the solution, with very little in return.


So all the implicit information (application, origin-host, origin-realm) are meaningful in this context.
And the actual solution is designed based on these assumptions. The extensibility of the solution will allow extra info if required in other use cases but it was agreed to go with a straightforward solution that will satisfy most of us.

Regards,

Lionel

De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoyé : lundi 2 décembre 2013 16:37
À : dime@ietf.org
Objet : Re: [Dime] DOIC: Self-Contained OLRs

I don't believe that Ben's proposal was to change the piggybacking assumption in the baseline mechanism.  Ben's proposal is to design the solution in such a way that it is not dependent on the piggybacking transport mechanism.  

I share Ben's concern that we have over optimized the content of the overload report in a way that makes implementations brittle, interoperability more difficult to achieve and extensibility more complex.  And what do we gain from this optimization?  A few bites in answer messages.

Self contained overload reports, transported using the piggybacking mechanism, is a cleaner solution.

Steve

On 11/29/13 8:31 AM, lionel.morand@orange.com wrote:
I totally agree with Nirav. No need to revert at this stage the working assumption on piggybacking of OLR in application answer messages, especially when the aim is to define a basic mechanism called "reduction".

Anyone would be able to further add extra info for optimization if needed but there is no need at all for the basic mechanism.

Regards,

Lionel

-----Message d'origine-----
De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot (nsalot)
Envoyé : vendredi 29 novembre 2013 12:24
À : Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list
Cc : Ben Campbell
Objet : Re: [Dime] DOIC: Self-Contained OLRs

Jouni, Ben,

I am totally against the idea of self-contained OC-OLR specifically since we have adopted the principles of piggybacking the OC-OLR over existing application message.
Self-contained OC-OLR - which means adding all the information which defines the scope of the OC-OLR into the OC-OLR - does not make sense in the piggybacking approach. In fact, it is adding lot of information, which is anyway available within the message containing the OC-OLR, into the OC-OLR. So it is adding lot of redundant information in a message which increases the processing requirement for the sender as well as the receiver. (And this is un-optimization, in my view).

Besides, I am not convinced with the other reasons provided here:
- One software module within a node can provide OC-OLR to another software module in the same node without passing other related info
  Within a node, based on the design, lots of information may need to be passed between two software modules and we cannot optimize those aspects by replicating unnecessary information in a protocol message.
  In summary, it is node's internal software design issue and we need not optimize that at protocol level.

- Once the reporting node realizes that it is overloaded, it has to wait for right answer to send OC-OLR
 What is the point of sending OC-OLR for a context for which there is no messaging? Why should the reacting node care if it never sends a message for a context for which the reporting node is overloaded?
 So this waiting is justified since it ensures that the overload is reported only when necessary and only to the applicable reacting node. Not to all the nodes in the network.

- The agent needs to wait for the answer generated by the server and the right context
  The same argument as applicable for the server applies here. The agent need not send out-of-context overload info to a node.
  Why should reacting node receive/process/store the overload info for the scope for which it is not sending any messages.

- For sending OC-OLR in dedicated Diameter application???
 Piggybacking was the first basic principle we agreed before putting other principles in place. So we may want to go back the drawing board if we decide to change this principle.

Regards,
Nirav.

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen
Sent: Friday, November 29, 2013 2:50 PM
To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list
Cc: Ben Campbell
Subject: Re: [Dime] DOIC: Self-Contained OLRs



So, are we reaching any level of consensus here?

- JOuni

(as a note.. that we are converging back to where we started with OLRs ;)



On Nov 28, 2013, at 12:40 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> wrote:

Hi,

another question:

If we go for explicit self contained OLRs, why would we then need the ReportType?

The realm-type OLR would explicitly contain application-Id, Realm, but no Host whereas the host-type OLR would explicitly contain application-Id, Host, but probably (I'm not sure) no Realm.

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.


_______________________________________________
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.

_______________________________________________
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


_________________________________________________________________________________________________________________________

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

--------------050803040900050200030302-- From lionel.morand@orange.com Thu Dec 5 04:56:58 2013 Return-Path: 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 ED5081ADFAB for ; Thu, 5 Dec 2013 04:56:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 sGfnFe7OjDJG for ; Thu, 5 Dec 2013 04:56:53 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 82B9A1ADF9D for ; Thu, 5 Dec 2013 04:56:52 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 22BEA324474; Thu, 5 Dec 2013 13:56:48 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 0763427C07B; Thu, 5 Dec 2013 13:56:48 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0158.001; Thu, 5 Dec 2013 13:56:47 +0100 From: To: Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] DOIC: Self-Contained OLRs Thread-Index: AQHO67/so7y6FFeeaEmQ38aKczpYQJo6EVYAgACzUoCAAAFygIAAE10AgAF8EQD//7X5YIAHfJgAgAHAgTCAAD+1gIAAEa8g Date: Thu, 5 Dec 2013 12:56:46 +0000 Message-ID: <28317_1386248208_52A07810_28317_6447_1_6B7134B31289DC4FAF731D844122B36E32AF7B@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D90006681519BC90@DEMUMBX014.nsn-intra.net> <6390_1385631044_52970D44_6390_18593_1_6B7134B31289DC4FAF731D844122B36E30748E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BD31@DEMUMBX014.nsn-intra.net> <47383DC2-1A1B-4D1A-ADD5-9E3CE60B06C8@gmail.com> <0E3F4DF0-0C5F-482D-8CA4-F77B5B2A5F09@nostrum.com> <52A07619.4030305@usdonovans.com> In-Reply-To: <52A07619.4030305@usdonovans.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.5] Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E32AF7BPEXCVZYM13corpora_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.12.5.100914 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 12:56:58 -0000 --_000_6B7134B31289DC4FAF731D844122B36E32AF7BPEXCVZYM13corpora_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Steve, So let say that the base solution has been designed based on TWO principles: 1/ Piggybacking 2/ OLR implicitly related to the application identified in the message And the self-contained OLR approach is somehow independent of the first one= and breaks the second one. Lionel De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan Envoy=E9 : jeudi 5 d=E9cembre 2013 13:48 =C0 : dime@ietf.org Objet : Re: [Dime] DOIC: Self-Contained OLRs All, I have seen the argument a couple of times, including by Nirav below, that = the proposal for self contained overload reports breaks the piggybacking pr= inciple. This is not the case. The piggybacking principle means one thing -- That overload reports are tra= nsported in existing application messages. The piggybacking principle does= not constrain in any way what information can be included in the overload = report. Steve On 12/5/13 3:29 AM, Nirav Salot (nsalot) wrote: Ben, Lets not assume that the implementation concern you have raised applies to = all the architecture and all the products. I understand that you have talked to your developers but let us also not as= sume that all architectures are the same and layering is the de-facto imple= mentation and the existing proposal is "hard" to implement. I didn't say that no messages existed that could carry the report. The issu= e is, there may be a lot of other messages that _cannot_ carry it. So the s= ender has to sort through all the messages to find the ones that can work. I am really confused now by your various arguments related to "the reportin= g node has to wait for the right context to send the OC-OLR if the OC-OLR i= s not self-contained!" As I understand from your proposal "the self-contained OC-OLR includes exac= tly the same parameters that are included in the message carrying the OC-OL= R (and which defines the context of OC-OLR)". So in that case, the reporting node has to anyway wait "for the right conte= xt which can carry particular OC-OLR" and replicate the parameters inside t= he message and inside the OC-OLR. So the "self-contained OC-OLR" is not goi= ng to change the waiting aspect at all. But if you say that "with self-contained OC-OLR reporting node can include = out-of-context OC-OLR (e.g. OC-OLR applicable for different application) in= a message" then I understand your arguments regarding "the reporting node = need not wait for the right context." But then this breaks the piggybacking principle and hence not agreeable. Regards, Nirav. -----Original Message----- From: Ben Campbell [mailto:ben@nostrum.com] Sent: Wednesday, December 04, 2013 4:45 AM To: Nirav Salot (nsalot) Cc: Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list Subject: Re: [Dime] DOIC: Self-Contained OLRs (oops, sorry, I sent my previous response before I was finished. On Nov 29, 2013, at 5:24 AM, Nirav Salot (nsalot) wrote: Jouni, Ben, I am totally against the idea of self-contained OC-OLR specifically since w= e have adopted the principles of piggybacking the OC-OLR over existing appl= ication message. Self-contained OC-OLR - which means adding all the information which define= s the scope of the OC-OLR into the OC-OLR - does not make sense in the pigg= ybacking approach. In fact, it is adding lot of information, which is anywa= y available within the message containing the OC-OLR, into the OC-OLR. So i= t is adding lot of redundant information in a message which increases the p= rocessing requirement for the sender as well as the receiver. (And this is = un-optimization, in my view). It's not clear to me that piggybacking implies any particular relationship = between an OLR and the enclosing message, other than transport. Besides, I am not convinced with the other reasons provided here: - One software module within a node can provide OC-OLR to another software = module in the same node without passing other related info Within a node, based on the design, lots of information may need to be pa= ssed between two software modules and we cannot optimize those aspects by r= eplicating unnecessary information in a protocol message. In summary, it is node's internal software design issue and we need not o= ptimize that at protocol level. We should absolutely not ignore implementation concerns. I think that overl= oad control should be considered a separate layer than the Diameter applica= tion. The whole point of layering is about reducing implementation complexi= ty. In fact, I think this whole disagreement comes from different assumptions a= bout layering. Part of why I've brought this up is, I have talked to implem= entors who think that we've made life hard for them by tying OLRs to tightl= y to the application. This is particularly hard for anything that wants to = handle OLC for arbitrary applications in an application-independent way. (W= hich, by the way, is required by the requirements RFC). - Once the reporting node realizes that it is overloaded, it has to wait for right answer to send OC-OLR What is the point of sending OC-OLR f= or a context for which there is no messaging? Why should the reacting node = care if it never sends a message for a context for which the reporting node= is overloaded? I didn't say that no messages existed that could carry the report. The issu= e is, there may be a lot of other messages that _cannot_ carry it. So the s= ender has to sort through all the messages to find the ones that can work. So this waiting is justified since it ensures that the overload is reporte= d only when necessary and only to the applicable reacting node. Not to all = the nodes in the network. With self-contained OLRs, you don't have to worry about an inappropriate no= de getting the request. Sure you can choose to send OLRs only to appropriat= e reacting nodes, but that becomes an implementation decision rather than a= protocol requirement. - The agent needs to wait for the answer generated by the server and the ri= ght context The same argument as applicable for the server applies here. The agent ne= ed not send out-of-context overload info to a node. Why should reacting node receive/process/store the overload info for the = scope for which it is not sending any messages. If it's not sending (or going to send) any messages for the scope, it can i= gnore the OLR. - For sending OC-OLR in dedicated Diameter application??? Piggybacking was the first basic principle we agreed before putting other = principles in place. So we may want to go back the drawing board if we deci= de to change this principle. Piggybacking does not conflict with self-contained OLRs. The roach draft wa= s piggybacked, and still used self-contained OLRs. All we have to do to use= self-contained OLRs is add the necessary AVPs to the OLR format, and possi= bly remove a bunch of restrictions on how you can use them. If we need othe= r transport designs (i.e. dedicated applications), we can add those later. I'd like to remind people that the original mandate given to the design tea= m at the Berlin DIME meeting was to define a format and semantics, not defi= ne how we move reports around. We went way beyond that. I don't object to t= hat fact, but I think we should avoid too many limitations in the format an= d semantics that prevent other ways of moving the reports around. Regards, Nirav. -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen Sent: Friday, November 29, 2013 2:50 PM To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org li= st Cc: Ben Campbell Subject: Re: [Dime] DOIC: Self-Contained OLRs So, are we reaching any level of consensus here? - JOuni (as a note.. that we are converging back to where we started with OLRs ;) On Nov 28, 2013, at 12:40 PM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: Hi, another question: If we go for explicit self contained OLRs, why would we then need the Repor= tType? The realm-type OLR would explicitly contain application-Id, Realm, but no H= ost whereas the host-type OLR would explicitly contain application-Id, Host= , but probably (I'm not sure) no Realm. 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 stat= us. It could be provided an agent inserting this info in answers received f= rom a server behind but also from a server that would know this info by som= e internal magic. But in any case, if we assume that the client will received a successful an= swer from the server for an initial request with only Dest-Realm AVP, it sh= ould be possible to have both report types in the answer: one for the serve= r itself, one for the realm for new request sent to the realm with only Des= t-Realm AVP. Lionel -----Message d'origine----- De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN - DE/Munich) Envoy=E9 : jeudi 28 novembre 2013 10:26 =C0 : 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 a= ligned with the "endpoint principle". If the ReportType is "realm" this ind= icates 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 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 re= acting 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 Diamet= er request that corresponds to the answer containing the OLR. My reasons fo= r 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 i= dentified by Origin-Realm, and so on. This means that the "meaning" of an O= LR 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 answe= r to another, it's meaning may change completely. I think this approach is a mistake. I would greatly prefer that we explicit= ly 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 variou= s other AVPs to find all the information it needs. For example, I think a c= ommon software design for overload control processing to be separated from = application processing. The consumer cannot simply hand the OLR to that mod= ule and expect things to work. The OC module must not only parse the OLR, b= ut parse any other AVPs that are relevant. As OLR contents get extended (as= sumedly following the same strategy as the base spec), the number of "conte= xt" avps that must be interpreted can grow large. This approach is error pr= one, and will likely encourage brittle, hard-to-maintain code. Self-contain= ed OLRs would keep all the information related to overload in one place. ma= king for simpler implementations. 2) It's more complex for the reporting node to send implicit values than ex= plicit values. The sender cannot simply set the context to match the OLR--a= ll those other AVPs have application or protocol layer meanings. Once a rep= orting node realizes that it is overloade, it has to wait for the right ans= wer that contains the right context before it can send the OLR. This is par= ticularly 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 sig= nificantly. 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 so= me 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 overlo= ad reports were self-contained, one could just reuse the report format we s= pecify here. But if the meaning of an OLR depends on the way it's transport= ed, this won't work. We would have to create a new or significantly modifie= d OLR format if we found a need to transport OLRs in different ways. Self-c= ontained OLRs would allow much greater flexibility. So, in summary, I think that self-contained OLRs would lead to simpler impl= ementations, less brittle deployments, and more flexibility for future evol= ution 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 le= s pieces jointes. Les messages electroniques etant susceptibles d'alteratio= n, 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 dis= tributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te 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 confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. --_000_6B7134B31289DC4FAF731D844122B36E32AF7BPEXCVZYM13corpora_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Steve,

 <= /p>

So let say= that the base solution has been designed based on TWO principles:

1/ Piggyba= cking

2/ OLR imp= licitly related to the application identified in the message

And the se= lf-contained OLR approach is somehow independent of the first one and break= s the second one.

 = ;

Lionel

 = ;

De := DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9 : jeudi 5 d=E9cembre 2013 13:48
=C0 : dime@ietf.org
Objet : Re: [Dime] DOIC: Self-Contained OLRs<= /p>

 

All,

I have seen the argument a couple of times, including by Nirav below, that = the proposal for self contained overload reports breaks the piggybacking pr= inciple.  This is not the case.

The piggybacking principle means one thing -- That overload reports are tra= nsported in existing application messages.  The piggybacking principle= does not constrain in any way what information can be included in the over= load report.

Steve

On 12/5/13 3:29 AM, Nirav Salot (nsalot) wrote:= 

Ben,
 
Lets not assume that the implementation concern you have raised applie=
s to all the architecture and all the products. 
I understand that you have talked to your developers but let us also n=
ot assume that all architectures are the same and layering is the de-facto =
implementation and the existing proposal is "hard" to implement.<=
o:p>
 
I didn't say that no messages existed that could carry the report. The=
 issue is, there may be a lot of other messages that _cannot_ carry it. So =
the sender has to sort through all the messages to find the ones that can w=
ork.
I am really confused now by your various arguments related to "th=
e reporting node has to wait for the right context to send the OC-OLR if th=
e OC-OLR is not self-contained!"
As I understand from your proposal "the self-contained OC-OLR inc=
ludes exactly the same parameters that are included in the message carrying=
 the OC-OLR (and which defines the context of OC-OLR)".

So in that case, the reporting node has to anyway wait "for the r=
ight context which can carry particular OC-OLR" and replicate the para=
meters inside the message and inside the OC-OLR. So the "self-containe=
d OC-OLR" is not going to change the waiting aspect at all.=



 


But if you say that "with self-contained OC-OLR reporting node ca=
n include out-of-context OC-OLR (e.g. OC-OLR applicable for different appli=
cation) in a message" then I understand your arguments regarding "=
;the reporting node need not wait for the right context."

But then this breaks the piggybacking principle and hence not agreeabl=
e. 


 


Regards,


Nirav.


 


-----Original Message-----


From: Ben Campbell [mailto:ben@nost=
rum.com] 


Sent: Wednesday, December 04, 2013 4:45 AM


To: Nirav Salot (nsalot)


Cc: Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list


Subject: Re: [Dime] DOIC: Self-Contained OLRs


 


(oops, sorry, I sent my previous response before I was finished.<=
/o:p>


 


On Nov 29, 2013, at 5:24 AM, Nirav Salot (nsalot) <nsalot@cisco.com> wrote:


 




Jouni, Ben,


 


I am totally against the idea of self-contained OC-OLR specifically si=
nce we have adopted the principles of piggybacking the OC-OLR over existing=
 application message.


Self-contained OC-OLR - which means adding all the information which d=
efines the scope of the OC-OLR into the OC-OLR - does not make sense in the=
 piggybacking approach. In fact, it is adding lot of information, which is =
anyway available within the message containing the OC-OLR, into the OC-OLR.=
 So it is adding lot of redundant information in a message which increases =
the processing requirement for the sender as well as the receiver. (And thi=
s is un-optimization, in my view).




 


It's not clear to me that piggybacking implies any particular relation=
ship between an OLR and the enclosing message, other than transport.


 




 


Besides, I am not convinced with the other reasons provided here:=



- One software module within a node can provide OC-OLR to another soft=
ware module in the same node without passing other related info<=
/pre>

  Within a node, based on the design, lots of information may nee=
d to be passed between two software modules and we cannot optimize those as=
pects by replicating unnecessary information in a protocol message.


  In summary, it is node's internal software design issue and we =
need not optimize that at protocol level.




 


We should absolutely not ignore implementation concerns. I think that =
overload control should be considered a separate layer than the Diameter ap=
plication. The whole point of layering is about reducing implementation com=
plexity.


 


In fact, I think this whole disagreement comes from different assumpti=
ons about layering. Part of why I've brought this up is, I have talked to i=
mplementors who think that we've made life hard for them by tying OLRs to t=
ightly to the application. This is particularly hard for anything that want=
s to handle OLC for arbitrary applications in an application-independent wa=
y. (Which, by the way, is required by the requirements RFC).

 


 




 


- Once the reporting node realizes that it is overloaded, it has to 


wait for right answer to send OC-OLR  What is the point of sendin=
g OC-OLR for a context for which there is no messaging? Why should the reac=
ting node care if it never sends a message for a context for which the repo=
rting node is overloaded?




 


I didn't say that no messages existed that could carry the report. The=
 issue is, there may be a lot of other messages that _cannot_ carry it. So =
the sender has to sort through all the messages to find the ones that can w=
ork.


 




 So this waiting is justified since it ensures that the overload is re=
ported only when necessary and only to the applicable reacting node. Not to=
 all the nodes in the network.




 


With self-contained OLRs, you don't have to worry about an inappropria=
te node getting the request. Sure you can choose to send OLRs only to appro=
priate reacting nodes, but that becomes an implementation decision rather t=
han a protocol requirement.


 




 


- The agent needs to wait for the answer generated by the server and t=
he right context


  The same argument as applicable for the server applies here. Th=
e agent need not send out-of-context overload info to a node.

  Why should reacting node receive/process/store the overload inf=
o for the scope for which it is not sending any messages.




 


If it's not sending (or going to send) any messages for the scope, it =
can ignore the OLR.


 




 


- For sending OC-OLR in dedicated Diameter application???

 Piggybacking was the first basic principle we agreed before putting o=
ther principles in place. So we may want to go back the drawing board if we=
 decide to change this principle.




 


Piggybacking does not conflict with self-contained OLRs. The roach dra=
ft was piggybacked, and still used self-contained OLRs. All we have to do t=
o use self-contained OLRs is add the necessary AVPs to the OLR format, and =
possibly remove a bunch of restrictions on how you can use them. If we need=
 other transport designs (i.e. dedicated applications), we can add those la=
ter.


 


I'd like to remind people that the original mandate given to the desig=
n team at the Berlin DIME meeting was to define a format and semantics, not=
 define how we move reports around. We went way beyond that. I don't object=
 to that fact, but I think we should avoid too many limitations in the form=
at and semantics that prevent other ways of moving the reports around.=



 


 




 


Regards,


Nirav.


 


-----Original Message-----


From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of Jouni Korhonen


Sent: Friday, November 29, 2013 2:50 PM


To: Wiehe, Ulrich (NSN - DE/Munich); =
dime@ietf.org list


Cc: Ben Campbell


Subject: Re: [Dime] DOIC: Self-Contained OLRs


 


 


 


So, are we reaching any level of consensus here?


 


- JOuni


 


(as a note.. that we are converging back to where we started with OLRs=
 


;)


 


 


 


On Nov 28, 2013, at 12:40 PM, "Wiehe, Ulrich (NSN - DE/Munich)&qu=
ot; <ulrich.wiehe@nsn.com> wrote:


 




Hi,


 


another question:


 


If we go for explicit self contained OLRs, why would we then need the =
ReportType?


 


The realm-type OLR would explicitly contain application-Id, Realm, but=
 no Host whereas the host-type OLR would explicitly contain application-Id,=
 Host, but probably (I'm not sure) no Realm.


 


Ulrich


 


 


 


-----Original Message-----


From: ext lionel.morand@or=
ange.com [mailto:lionel.mor=
and@orange.com]


Sent: Thursday, November 28, 2013 10:31 AM


To: Wiehe, Ulrich (NSN - DE/Munich); ext Jouni Korhonen; Ben Campbell<=
o:p>


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 recei=
ved from a server behind but also from a server that would know this info b=
y some internal magic.


But in any case, if we assume that the client will received a successf=
ul 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 onl=
y Dest-Realm AVP.


 


Lionel


 


-----Message d'origine-----


De : DiME [mailto:dime-bounce=
s@ietf.org] De la part de Wiehe, Ulrich 


(NSN - DE/Munich) Envoy=E9 : jeudi 28 novembre 2013 10:26 =C0 : ext Jo=
uni 


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 &=
quot;realm" this indicates to the reacting end point that the reportin=
g 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 repor=
ting end point is a server. How can the reporting end point be both agent a=
nd server?


 


Ulrich


 


-----Original Message-----


From: DiME [mailto:dime-bounc=
es@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 <=
/o:p>


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 t=
he 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 D=
iameter request that corresponds to the answer containing the OLR. My reaso=
ns 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 applica=
tion identified by the Application-Id field of the enclosing answer, the re=
alm identified by Origin-Realm, and so on. This means that the "meanin=
g" of an OLR cannot be determined from the OLR contents alone; OLRs on=
ly 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 exp=
licitly include such values in the OLR itself, for multiple reasons:


 


1) It's more complex to interpret implicit, contextual values than exp=
licit values. The consumer cannot simply look at the OLR; it must look in v=
arious other AVPs to find all the information it needs. For example, I thin=
k a common software design for overload control processing to be separated =
from application processing. The consumer cannot simply hand the OLR to tha=
t module and expect things to work. The OC module must not only parse the O=
LR, but parse any other AVPs that are relevant. As OLR contents get extende=
d (assumedly following the same strategy as the base spec), the number of &=
quot;context" avps that must be interpreted can grow large. This appro=
ach is error prone, and will likely encourage brittle, hard-to-maintain cod=
e. Self-contained OLRs would keep all the information related to overload i=
n one place. making for simpler implementations.


 


2) It's more complex for the reporting node to send implicit values th=
an explicit values. The sender cannot simply set the context to match the O=
LR--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 righ=
t answer that contains the right context before it can send the OLR. This i=
s particularly troublesome for agents, since they will typically have to in=
sert OLRs into answers created by other nodes. 


 


If the reporting node screws this up, the meaning of the OLR may chang=
e significantly. So again, implicit meaning gives us error prone implementa=
tions. 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 serve=
r.


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 <=
/o:p>


agent overload draft, or my dh/dr example.)


 


OTOH, explicit values will work for all cases where we need to associa=
te some arbitrary value with an OLR.


 


4) Implicit values seriously constrain the future evolution of Diamete=
r OC standards. For example, lets say we find a good reason to allow OLRs t=
o be sent out of band, or be sent in a dedicated Diameter application. If o=
verload 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 tran=
sported, this won't work. We would have to create a new or significantly mo=
dified OLR format if we found a need to transport OLRs in different ways. S=
elf-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.iet=
f.org/mailman/listinfo/dime




 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 


_____________________________________________________________________<=
o:p>


_ ___________________________________________________


 


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 q=
ue les pieces jointes. Les messages electroniques etant susceptibles d'alte=
ration, Orange decline toute responsabilite si ce message a ete altere, def=
orme ou falsifie. Merci.


 


This message and its attachments may contain confidential or 


privileged information that may be protected by law; they should not b=
e 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.iet=
f.org/mailman/listinfo/dime


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime




 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 

 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles 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 el=
ectroniques 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 inf=
ormation 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 dele=
te 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.
--_000_6B7134B31289DC4FAF731D844122B36E32AF7BPEXCVZYM13corpora_-- From srdonovan@usdonovans.com Thu Dec 5 05:05:48 2013 Return-Path: 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 DBEDA1ADFD0 for ; Thu, 5 Dec 2013 05:05:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no 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 6Rtkrn1m4Vu7 for ; Thu, 5 Dec 2013 05:05:44 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 160A61ADFCA for ; Thu, 5 Dec 2013 05:05:44 -0800 (PST) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:61157 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1VoYcY-0001Qo-Q0 for dime@ietf.org; Thu, 05 Dec 2013 05:05:38 -0800 Message-ID: <52A07A1E.5060502@usdonovans.com> Date: Thu, 05 Dec 2013 07:05:34 -0600 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: dime@ietf.org References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <6390_1385631044_52970D44_6390_18593_1_6B7134B31289DC4FAF731D844122B36E30748E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BD31@DEMUMBX014.nsn-intra.net> <47383DC2-1A1B-4D1A-ADD5-9E3CE60B06C8@gmail.com> <8467_1385735507_5298A553_8467_17054_3_6B7134B31289DC4FAF731D844122B36E309D0D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <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> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010902060204030700000107" X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 13:05:49 -0000 This is a multi-part message in MIME format. --------------010902060204030700000107 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit On the schedule question mentioned by JJacques -- any schedule concerns can go away if everyone agrees to self contained overload reports. This discussion would end and we could move on to other things. :-) I say that somewhat in jest but please don't make the argument that this discussion should be ended because of schedule. Or if you make that argument, please don't assert that the person who disagrees with you is putting the schedule at risk. We are striving for the best technical solution. We all understand the schedule pressures. We need to balance the two. Steve On 12/5/13 5:14 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote: > Hi > > A lot of mails on this topic...I would suggest to introduce an overload control on the Dime email threads:) > > > On my side, I rely on what we have written in the draft for the "baseline" mechanism and that we have to keep as it is simple and efficient, here I join Lionel, Nirav and MCruz' positions. > > This thread then addresses extensions cases, I agree that we will have to address such extensions: Nirav mentioned the example with APN that if relevant would a 3GGP application case, I would add the Session Group about which we had some discussion a while ago and which is a more generic IETF case. There is also the agent overload case. Have you others? Always good to have some use cases in mind. > > What is important for me is that adding extensions should not modify the baseline and making it more complex when used alone. I also make a difference between principles and protocol tuning where we may have to choose between various protocol solution but addressing the same functionality or principle. > > About piggybacking, in the baseline, the principle is that OLRs which are addressed to sources of traffic are put in answer messages towards this traffic sources (origin Host) (even if these messages may be processed by intermediate DAs), which is simple and the OLR can be kept unchanged in the same message up to the origin Host if no specific process in intermediate DAs. To have a piggybacking allowing to put any OLR in any message (as it was in draft roach) is adding complexity that is not justified for the baseline and we have not retained it in the existing draft . > > About extensions, the APN or session group examples address parts of the traffic between a server and a client (so a higher granularity in the throttling than the baseline one), related OLRs are conveyed in the messages towards the origin Host so with an implicit reference to the Application, the Origin and Destination Host as for the baseline, so not requiring self contained OLRs. I also do not see the interest to send these new extensions OLR only in answers directly related to this OLR (as Ulrich proposed), eg only in an answer dealing with an APN if the OLR is related to APN throttling. The main point is that the OLR takes a direct "train" towards the right destination for a given application (as for baseline). > > This does not exclude that we may have other cases not entering the above examples characteristics, but as Nirav mentioned, we have to remain pragmatic and see this when such new use cases will be addressed. The extensibility possibilities of current draft give us a lot of flexibility, e.g. if some extensions need more self contained AVPs, why not, but this is outside the current draft. > > About extensions, I also think that they may need to be identified in the capability part, as the related OLRs should not be sent by a reacting node if the extension is not supported. > > Last important point, as Lionel mentioned, we have to finalize the draft soon, to be able to start Rel12 3GGP work relying on this draft. My position is that the current draft is currently well suited for the baseline and that extensions will be addressed separately > > Best regards > > JJacques > > > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Ben Campbell > Envoyé : mercredi 4 décembre 2013 22:55 > À : ext lionel.morand@orange.com > Cc : dime@ietf.org > Objet : Re: [Dime] DOIC: Self-Contained OLRs > > On Dec 3, 2013, at 5:17 PM, lionel.morand@orange.com wrote: > >> Hi Ben, >> >> I may be wrong somewhere in my summary but I think that it was the result of the discussions and agreements reached regarding existing requirements, at least from 3GPP point of view, compared to possible optimizations for future optimizations not so obvious. > We are not the 3GPP. Our requirements are RFC 7068. I believe self-contained OLRs do a better job of meeting Req 31 than the contextually-defined OLRs. > > I've made several technical arguments here--does anyone have _technical_ arguments in favor of contextually-defined OLRs? > >> And because the solution offers extensibility via the definition of new algo, new report type and addition of any new AVP in the existing Grouped OLR, the "limitations" of the proposed solution might be removed by someone if really required according to new requirements. >> > It might be worth considering a compromise approach: Define _optional_ AVPs that allow an OLR to be self-contained. If they are not present, then the various values default to those from the enclosing Diameter message. Possibly add support for this to the list of things that reacting nodes can advertise. > > This could be in the base, or in a follow on extension. (If left for an extension, it's worth considering whether ReportType needs to be in the base, or this or some other extension.) > > >> Regards, >> >> Lionel >> >> -----Message d'origine----- >> De : Ben Campbell [mailto:ben@nostrum.com] Envoyé : mardi 3 décembre >> 2013 23:56 À : MORAND Lionel IMT/OLN Cc : Steve Donovan; dime@ietf.org >> Objet : Re: [Dime] DOIC: Self-Contained OLRs >> >> >> On Dec 2, 2013, at 10:18 AM, lionel.morand@orange.com wrote: >> >>> Hi Steve, >>> >>> I think that is not only about few bytes in the answer. It is also about the solution principles agreed so far: >>> · the current need is for an OLR bound to the application in use >>> · the OLR is received from the node targeted in the request. >>> · the OLR is defined per application >> I don't think those principles have been well tested. I don't recall any discussion of their benefits. What benefits do you see they have over self-contained OLRs? >> >> All I see from these are restrictions in the flexibility of the solution, with very little in return. >> >>> So all the implicit information (application, origin-host, origin-realm) are meaningful in this context. >>> And the actual solution is designed based on these assumptions. The extensibility of the solution will allow extra info if required in other use cases but it was agreed to go with a straightforward solution that will satisfy most of us. >>> >>> Regards, >>> >>> Lionel >>> >>> De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan >>> Envoyé : lundi 2 décembre 2013 16:37 >>> À : dime@ietf.org >>> Objet : Re: [Dime] DOIC: Self-Contained OLRs >>> >>> I don't believe that Ben's proposal was to change the piggybacking assumption in the baseline mechanism. Ben's proposal is to design the solution in such a way that it is not dependent on the piggybacking transport mechanism. >>> >>> I share Ben's concern that we have over optimized the content of the overload report in a way that makes implementations brittle, interoperability more difficult to achieve and extensibility more complex. And what do we gain from this optimization? A few bites in answer messages. >>> >>> Self contained overload reports, transported using the piggybacking mechanism, is a cleaner solution. >>> >>> Steve >>> >>> On 11/29/13 8:31 AM, lionel.morand@orange.com wrote: >>> I totally agree with Nirav. No need to revert at this stage the working assumption on piggybacking of OLR in application answer messages, especially when the aim is to define a basic mechanism called "reduction". >>> >>> Anyone would be able to further add extra info for optimization if needed but there is no need at all for the basic mechanism. >>> >>> Regards, >>> >>> Lionel >>> >>> -----Message d'origine----- >>> De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot (nsalot) >>> Envoyé : vendredi 29 novembre 2013 12:24 >>> À : Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list >>> Cc : Ben Campbell >>> Objet : Re: [Dime] DOIC: Self-Contained OLRs >>> >>> Jouni, Ben, >>> >>> I am totally against the idea of self-contained OC-OLR specifically since we have adopted the principles of piggybacking the OC-OLR over existing application message. >>> Self-contained OC-OLR - which means adding all the information which defines the scope of the OC-OLR into the OC-OLR - does not make sense in the piggybacking approach. In fact, it is adding lot of information, which is anyway available within the message containing the OC-OLR, into the OC-OLR. So it is adding lot of redundant information in a message which increases the processing requirement for the sender as well as the receiver. (And this is un-optimization, in my view). >>> >>> Besides, I am not convinced with the other reasons provided here: >>> - One software module within a node can provide OC-OLR to another software module in the same node without passing other related info >>> Within a node, based on the design, lots of information may need to be passed between two software modules and we cannot optimize those aspects by replicating unnecessary information in a protocol message. >>> In summary, it is node's internal software design issue and we need not optimize that at protocol level. >>> >>> - Once the reporting node realizes that it is overloaded, it has to wait for right answer to send OC-OLR >>> What is the point of sending OC-OLR for a context for which there is no messaging? Why should the reacting node care if it never sends a message for a context for which the reporting node is overloaded? >>> So this waiting is justified since it ensures that the overload is reported only when necessary and only to the applicable reacting node. Not to all the nodes in the network. >>> >>> - The agent needs to wait for the answer generated by the server and the right context >>> The same argument as applicable for the server applies here. The agent need not send out-of-context overload info to a node. >>> Why should reacting node receive/process/store the overload info for the scope for which it is not sending any messages. >>> >>> - For sending OC-OLR in dedicated Diameter application??? >>> Piggybacking was the first basic principle we agreed before putting other principles in place. So we may want to go back the drawing board if we decide to change this principle. >>> >>> Regards, >>> Nirav. >>> >>> -----Original Message----- >>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen >>> Sent: Friday, November 29, 2013 2:50 PM >>> To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list >>> Cc: Ben Campbell >>> Subject: Re: [Dime] DOIC: Self-Contained OLRs >>> >>> >>> >>> So, are we reaching any level of consensus here? >>> >>> - JOuni >>> >>> (as a note.. that we are converging back to where we started with OLRs ;) >>> >>> >>> >>> On Nov 28, 2013, at 12:40 PM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: >>> >>> Hi, >>> >>> another question: >>> >>> If we go for explicit self contained OLRs, why would we then need the ReportType? >>> >>> The realm-type OLR would explicitly contain application-Id, Realm, but no Host whereas the host-type OLR would explicitly contain application-Id, Host, but probably (I'm not sure) no Realm. >>> >>> 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 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. >>> >>> >>> _______________________________________________ >>> 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. >>> >>> _______________________________________________ >>> 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 >> >> _________________________________________________________________________________________________________________________ >> >> 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 > --------------010902060204030700000107 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On the schedule question mentioned by JJacques -- any schedule concerns can go away if everyone agrees to self contained overload reports.  This discussion would end and we could move on to other things.  :-)

I say that somewhat in jest but please don't make the argument that this discussion should be ended because of schedule.  Or if you make that argument, please don't assert that the person who disagrees with you is putting the schedule at risk.

We are striving for the best technical solution.  We all understand the schedule pressures.  We need to balance the two.

Steve
On 12/5/13 5:14 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:
Hi 

A lot of mails on this topic...I would suggest to introduce an overload control on the Dime email threads:)  


On my side, I rely on what we have written in the  draft for the "baseline" mechanism and that we have to keep as it is simple and efficient, here I join Lionel, Nirav and MCruz' positions.

This thread then addresses extensions  cases, I agree that we will have to address such extensions:   Nirav mentioned the example with APN that if relevant would  a 3GGP application case, I would add the Session Group about which we had some discussion a while ago and  which is a more generic IETF case. There is also the agent overload case. Have you others? Always good to have some use cases in mind.

What is important for me is that adding extensions should not modify the baseline and making it more complex when used alone.  I also make a difference between principles and protocol tuning where we may have to choose between various protocol solution but addressing the same functionality or principle.  

About piggybacking, in the baseline,  the principle is that OLRs  which  are addressed  to sources of traffic are put in answer messages towards this traffic sources (origin Host) (even if these messages  may be processed by intermediate DAs), which is simple and the OLR can be kept unchanged in the same message  up to the origin Host if no specific process in intermediate DAs.  To have a piggybacking allowing to put any OLR in any message (as it was in draft roach)  is adding complexity that is not justified for the baseline and we have not retained it in the existing draft .

About extensions, the APN or session group  examples address  parts of the traffic between a server and a client (so a higher granularity in the throttling than the baseline one), related OLRs are conveyed in the messages towards the origin Host so with an implicit reference to the Application, the  Origin and Destination Host as for the baseline, so not requiring self contained OLRs. I also  do not see the interest to send these new extensions OLR only in answers directly related to this OLR (as Ulrich proposed), eg only in an answer dealing with an APN if the OLR is related to APN throttling.  The main point is that the OLR takes a direct "train" towards the right destination for a given application (as for baseline).

This does not exclude that we may have other cases not entering the above examples characteristics, but as Nirav mentioned, we  have to remain pragmatic and see this when such new use cases will be addressed. The extensibility possibilities of  current draft give us a lot of flexibility, e.g. if some extensions need more self contained AVPs, why not, but this is outside the current draft. 

About extensions, I also think that they may need to be identified in the capability part, as the related OLRs should not be sent by a reacting node if the extension is not supported.

Last important point, as  Lionel mentioned, we have to finalize the draft soon, to be able to start Rel12 3GGP work relying on this draft. My position is that the current draft is currently well suited for the baseline and that extensions will be addressed separately  

Best regards

JJacques 
 

-----Message d'origine-----
De : DiME [mailto:dime-bounces@ietf.org] De la part de Ben Campbell
Envoyé : mercredi 4 décembre 2013 22:55
À : ext lionel.morand@orange.com
Cc : dime@ietf.org
Objet : Re: [Dime] DOIC: Self-Contained OLRs

On Dec 3, 2013, at 5:17 PM, lionel.morand@orange.com wrote:


Hi Ben,

I may be wrong somewhere in my summary but I think that it was the result of the discussions and agreements reached regarding existing requirements, at least from 3GPP point of view, compared to possible optimizations for future optimizations not so obvious.

We are not the 3GPP. Our requirements are RFC 7068. I believe self-contained OLRs do a better job of meeting Req 31 than the contextually-defined OLRs.

I've made several technical arguments here--does anyone have _technical_ arguments in favor of contextually-defined OLRs?


And because the solution offers extensibility via the definition of new algo, new report type and addition of any new AVP in the existing Grouped OLR, the "limitations" of the proposed solution might be removed by someone if really required according to new requirements.


It might be worth considering a compromise approach: Define _optional_ AVPs that allow an OLR to be self-contained. If they are not present, then the various values default to those from the enclosing Diameter message. Possibly add support for this to the list of things that reacting nodes can advertise.

This could be in the base, or in a follow on extension. (If left for an extension, it's worth considering whether ReportType needs to be in the base, or this or some other extension.) 



Regards,

Lionel

-----Message d'origine-----
De : Ben Campbell [mailto:ben@nostrum.com] Envoyé : mardi 3 décembre 
2013 23:56 À : MORAND Lionel IMT/OLN Cc : Steve Donovan; dime@ietf.org 
Objet : Re: [Dime] DOIC: Self-Contained OLRs


On Dec 2, 2013, at 10:18 AM, lionel.morand@orange.com wrote:


Hi Steve,

I think that is not only about few bytes in the answer. It is also about the solution principles agreed so far:
·         the current need is for an OLR bound to the application in use
·         the OLR is received from the node targeted in the request.
·         the OLR is defined per application

I don't think those principles have been well tested. I don't recall any discussion of their benefits. What benefits do you see they have over self-contained OLRs?

All I see from these are restrictions in the flexibility of the solution, with very little in return.


So all the implicit information (application, origin-host, origin-realm) are meaningful in this context.
And the actual solution is designed based on these assumptions. The extensibility of the solution will allow extra info if required in other use cases but it was agreed to go with a straightforward solution that will satisfy most of us.

Regards,

Lionel

De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoyé : lundi 2 décembre 2013 16:37
À : dime@ietf.org
Objet : Re: [Dime] DOIC: Self-Contained OLRs

I don't believe that Ben's proposal was to change the piggybacking assumption in the baseline mechanism.  Ben's proposal is to design the solution in such a way that it is not dependent on the piggybacking transport mechanism.  

I share Ben's concern that we have over optimized the content of the overload report in a way that makes implementations brittle, interoperability more difficult to achieve and extensibility more complex.  And what do we gain from this optimization?  A few bites in answer messages.

Self contained overload reports, transported using the piggybacking mechanism, is a cleaner solution.

Steve

On 11/29/13 8:31 AM, lionel.morand@orange.com wrote:
I totally agree with Nirav. No need to revert at this stage the working assumption on piggybacking of OLR in application answer messages, especially when the aim is to define a basic mechanism called "reduction".

Anyone would be able to further add extra info for optimization if needed but there is no need at all for the basic mechanism.

Regards,

Lionel

-----Message d'origine-----
De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot (nsalot)
Envoyé : vendredi 29 novembre 2013 12:24
À : Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list
Cc : Ben Campbell
Objet : Re: [Dime] DOIC: Self-Contained OLRs

Jouni, Ben,

I am totally against the idea of self-contained OC-OLR specifically since we have adopted the principles of piggybacking the OC-OLR over existing application message.
Self-contained OC-OLR - which means adding all the information which defines the scope of the OC-OLR into the OC-OLR - does not make sense in the piggybacking approach. In fact, it is adding lot of information, which is anyway available within the message containing the OC-OLR, into the OC-OLR. So it is adding lot of redundant information in a message which increases the processing requirement for the sender as well as the receiver. (And this is un-optimization, in my view).

Besides, I am not convinced with the other reasons provided here:
- One software module within a node can provide OC-OLR to another software module in the same node without passing other related info
  Within a node, based on the design, lots of information may need to be passed between two software modules and we cannot optimize those aspects by replicating unnecessary information in a protocol message.
  In summary, it is node's internal software design issue and we need not optimize that at protocol level.

- Once the reporting node realizes that it is overloaded, it has to wait for right answer to send OC-OLR
 What is the point of sending OC-OLR for a context for which there is no messaging? Why should the reacting node care if it never sends a message for a context for which the reporting node is overloaded?
 So this waiting is justified since it ensures that the overload is reported only when necessary and only to the applicable reacting node. Not to all the nodes in the network.

- The agent needs to wait for the answer generated by the server and the right context
  The same argument as applicable for the server applies here. The agent need not send out-of-context overload info to a node.
  Why should reacting node receive/process/store the overload info for the scope for which it is not sending any messages.

- For sending OC-OLR in dedicated Diameter application???
 Piggybacking was the first basic principle we agreed before putting other principles in place. So we may want to go back the drawing board if we decide to change this principle.

Regards,
Nirav.

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen
Sent: Friday, November 29, 2013 2:50 PM
To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list
Cc: Ben Campbell
Subject: Re: [Dime] DOIC: Self-Contained OLRs



So, are we reaching any level of consensus here?

- JOuni

(as a note.. that we are converging back to where we started with OLRs ;)



On Nov 28, 2013, at 12:40 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> wrote:

Hi,

another question:

If we go for explicit self contained OLRs, why would we then need the ReportType?

The realm-type OLR would explicitly contain application-Id, Realm, but no Host whereas the host-type OLR would explicitly contain application-Id, Host, but probably (I'm not sure) no Realm.

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.


_______________________________________________
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.

_______________________________________________
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


_________________________________________________________________________________________________________________________

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

--------------010902060204030700000107-- From srdonovan@usdonovans.com Thu Dec 5 05:09:58 2013 Return-Path: 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 1A95F1ADFD3 for ; Thu, 5 Dec 2013 05:09:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no 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 5_JRBljVKYhT for ; Thu, 5 Dec 2013 05:09:53 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 07C1C1ADFCC for ; Thu, 5 Dec 2013 05:09:53 -0800 (PST) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:61163 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1VoYgd-0005jB-Lc; Thu, 05 Dec 2013 05:09:49 -0800 Message-ID: <52A07B1B.6090306@usdonovans.com> Date: Thu, 05 Dec 2013 07:09:47 -0600 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: lionel.morand@orange.com, "dime@ietf.org" References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D90006681519BC90@DEMUMBX014.nsn-intra.net> <6390_1385631044_52970D44_6390_18593_1_6B7134B31289DC4FAF731D844122B36E30748E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BD31@DEMUMBX014.nsn-intra.net> <47383DC2-1A1B-4D1A-ADD5-9E3CE60B06C8@gmail.com> <0E3F4DF0-0C5F-482D-8CA4-F77B5B2A5F09@nostrum.com> <52A07619.4030305@usdonovans.com> <28317_1386248208_52A07810_28317_6447_1_6B7134B31289DC4FAF731D844122B36E32AF7B@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <28317_1386248208_52A07810_28317_6447_1_6B7134B31289DC4FAF731D844122B36E32AF7B@PEXCVZYM13.corporate.adroot.infra.ftgroup> Content-Type: multipart/alternative; boundary="------------010705080508030706060701" X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 13:09:58 -0000 This is a multi-part message in MIME format. --------------010705080508030706060701 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Lionel, I agree that the current content of the draft is that application information is implied, as is the host and realm. What we are discussing is whether the draft should be changed (improved in my opinion) by making overload reports self contained. So, I don't agree that we have a second principle yet. We might get there, but we aren't there yet. Steve On 12/5/13 6:56 AM, lionel.morand@orange.com wrote: > > Hi Steve, > > > > So let say that the base solution has been designed based on TWO > principles: > > 1/ Piggybacking > > 2/ OLR implicitly related to the application identified in the message > > And the self-contained OLR approach is somehow independent of the > first one and breaks the second one. > > > > Lionel > > > > *De :*DiME [mailto:dime-bounces@ietf.org] *De la part de* Steve Donovan > *Envoyé :* jeudi 5 décembre 2013 13:48 > *À :* dime@ietf.org > *Objet :* Re: [Dime] DOIC: Self-Contained OLRs > > > > All, > > I have seen the argument a couple of times, including by Nirav below, > that the proposal for self contained overload reports breaks the > piggybacking principle. This is not the case. > > The piggybacking principle means one thing -- That overload reports > are transported in existing application messages. The piggybacking > principle does not constrain in any way what information can be > included in the overload report. > > Steve > > On 12/5/13 3:29 AM, Nirav Salot (nsalot) wrote: > > Ben, > > > > Lets not assume that the implementation concern you have raised applies to all the architecture and all the products. > > I understand that you have talked to your developers but let us also not assume that all architectures are the same and layering is the de-facto implementation and the existing proposal is "hard" to implement. > > > > I didn't say that no messages existed that could carry the report. The issue is, there may be a lot of other messages that _cannot_ carry it. So the sender has to sort through all the messages to find the ones that can work. > > I am really confused now by your various arguments related to "the reporting node has to wait for the right context to send the OC-OLR if the OC-OLR is not self-contained!" > > As I understand from your proposal "the self-contained OC-OLR includes exactly the same parameters that are included in the message carrying the OC-OLR (and which defines the context of OC-OLR)". > > So in that case, the reporting node has to anyway wait "for the right context which can carry particular OC-OLR" and replicate the parameters inside the message and inside the OC-OLR. So the "self-contained OC-OLR" is not going to change the waiting aspect at all. > > > > But if you say that "with self-contained OC-OLR reporting node can include out-of-context OC-OLR (e.g. OC-OLR applicable for different application) in a message" then I understand your arguments regarding "the reporting node need not wait for the right context." > > But then this breaks the piggybacking principle and hence not agreeable. > > > > Regards, > > Nirav. > > > > -----Original Message----- > > From: Ben Campbell [mailto:ben@nostrum.com] > > Sent: Wednesday, December 04, 2013 4:45 AM > > To: Nirav Salot (nsalot) > > Cc: Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list > > Subject: Re: [Dime] DOIC: Self-Contained OLRs > > > > (oops, sorry, I sent my previous response before I was finished. > > > > On Nov 29, 2013, at 5:24 AM, Nirav Salot (nsalot) wrote: > > > > Jouni, Ben, > > > > I am totally against the idea of self-contained OC-OLR specifically since we have adopted the principles of piggybacking the OC-OLR over existing application message. > > Self-contained OC-OLR - which means adding all the information which defines the scope of the OC-OLR into the OC-OLR - does not make sense in the piggybacking approach. In fact, it is adding lot of information, which is anyway available within the message containing the OC-OLR, into the OC-OLR. So it is adding lot of redundant information in a message which increases the processing requirement for the sender as well as the receiver. (And this is un-optimization, in my view). > > > > It's not clear to me that piggybacking implies any particular relationship between an OLR and the enclosing message, other than transport. > > > > > > Besides, I am not convinced with the other reasons provided here: > > - One software module within a node can provide OC-OLR to another software module in the same node without passing other related info > > Within a node, based on the design, lots of information may need to be passed between two software modules and we cannot optimize those aspects by replicating unnecessary information in a protocol message. > > In summary, it is node's internal software design issue and we need not optimize that at protocol level. > > > > We should absolutely not ignore implementation concerns. I think that overload control should be considered a separate layer than the Diameter application. The whole point of layering is about reducing implementation complexity. > > > > In fact, I think this whole disagreement comes from different assumptions about layering. Part of why I've brought this up is, I have talked to implementors who think that we've made life hard for them by tying OLRs to tightly to the application. This is particularly hard for anything that wants to handle OLC for arbitrary applications in an application-independent way. (Which, by the way, is required by the requirements RFC). > > > > > > > > - Once the reporting node realizes that it is overloaded, it has to > > wait for right answer to send OC-OLR What is the point of sending OC-OLR for a context for which there is no messaging? Why should the reacting node care if it never sends a message for a context for which the reporting node is overloaded? > > > > I didn't say that no messages existed that could carry the report. The issue is, there may be a lot of other messages that _cannot_ carry it. So the sender has to sort through all the messages to find the ones that can work. > > > > So this waiting is justified since it ensures that the overload is reported only when necessary and only to the applicable reacting node. Not to all the nodes in the network. > > > > With self-contained OLRs, you don't have to worry about an inappropriate node getting the request. Sure you can choose to send OLRs only to appropriate reacting nodes, but that becomes an implementation decision rather than a protocol requirement. > > > > > > - The agent needs to wait for the answer generated by the server and the right context > > The same argument as applicable for the server applies here. The agent need not send out-of-context overload info to a node. > > Why should reacting node receive/process/store the overload info for the scope for which it is not sending any messages. > > > > If it's not sending (or going to send) any messages for the scope, it can ignore the OLR. > > > > > > - For sending OC-OLR in dedicated Diameter application??? > > Piggybacking was the first basic principle we agreed before putting other principles in place. So we may want to go back the drawing board if we decide to change this principle. > > > > Piggybacking does not conflict with self-contained OLRs. The roach draft was piggybacked, and still used self-contained OLRs. All we have to do to use self-contained OLRs is add the necessary AVPs to the OLR format, and possibly remove a bunch of restrictions on how you can use them. If we need other transport designs (i.e. dedicated applications), we can add those later. > > > > I'd like to remind people that the original mandate given to the design team at the Berlin DIME meeting was to define a format and semantics, not define how we move reports around. We went way beyond that. I don't object to that fact, but I think we should avoid too many limitations in the format and semantics that prevent other ways of moving the reports around. > > > > > > > > Regards, > > Nirav. > > > > -----Original Message----- > > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen > > Sent: Friday, November 29, 2013 2:50 PM > > To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list > > Cc: Ben Campbell > > Subject: Re: [Dime] DOIC: Self-Contained OLRs > > > > > > > > So, are we reaching any level of consensus here? > > > > - JOuni > > > > (as a note.. that we are converging back to where we started with OLRs > > ;) > > > > > > > > On Nov 28, 2013, at 12:40 PM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: > > > > Hi, > > > > another question: > > > > If we go for explicit self contained OLRs, why would we then need the ReportType? > > > > The realm-type OLR would explicitly contain application-Id, Realm, but no Host whereas the host-type OLR would explicitly contain application-Id, Host, but probably (I'm not sure) no Realm. > > > > 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 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. > > > > > > _______________________________________________ > > 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. --------------010705080508030706060701 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Lionel,

I agree that the current content of the draft is that application information is implied, as is the host and realm.

What we are discussing is whether the draft should be changed (improved in my opinion) by making overload reports self contained.

So, I don't agree that we have a second principle yet.  We might get there, but we aren't there yet.

Steve
On 12/5/13 6:56 AM, lionel.morand@orange.com wrote:

Hi Steve,

 

So let say that the base solution has been designed based on TWO principles:

1/ Piggybacking

2/ OLR implicitly related to the application identified in the message

And the self-contained OLR approach is somehow independent of the first one and breaks the second one.

 

Lionel

 

De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoyé : jeudi 5 décembre 2013 13:48
À : dime@ietf.org
Objet : Re: [Dime] DOIC: Self-Contained OLRs

 

All,

I have seen the argument a couple of times, including by Nirav below, that the proposal for self contained overload reports breaks the piggybacking principle.  This is not the case.

The piggybacking principle means one thing -- That overload reports are transported in existing application messages.  The piggybacking principle does not constrain in any way what information can be included in the overload report.

Steve

On 12/5/13 3:29 AM, Nirav Salot (nsalot) wrote:

Ben,
 
Lets not assume that the implementation concern you have raised applies to all the architecture and all the products. 
I understand that you have talked to your developers but let us also not assume that all architectures are the same and layering is the de-facto implementation and the existing proposal is "hard" to implement.
 
I didn't say that no messages existed that could carry the report. The issue is, there may be a lot of other messages that _cannot_ carry it. So the sender has to sort through all the messages to find the ones that can work.
I am really confused now by your various arguments related to "the reporting node has to wait for the right context to send the OC-OLR if the OC-OLR is not self-contained!"
As I understand from your proposal "the self-contained OC-OLR includes exactly the same parameters that are included in the message carrying the OC-OLR (and which defines the context of OC-OLR)".
So in that case, the reporting node has to anyway wait "for the right context which can carry particular OC-OLR" and replicate the parameters inside the message and inside the OC-OLR. So the "self-contained OC-OLR" is not going to change the waiting aspect at all.
 
But if you say that "with self-contained OC-OLR reporting node can include out-of-context OC-OLR (e.g. OC-OLR applicable for different application) in a message" then I understand your arguments regarding "the reporting node need not wait for the right context."
But then this breaks the piggybacking principle and hence not agreeable. 
 
Regards,
Nirav.
 
-----Original Message-----
From: Ben Campbell [mailto:ben@nostrum.com] 
Sent: Wednesday, December 04, 2013 4:45 AM
To: Nirav Salot (nsalot)
Cc: Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list
Subject: Re: [Dime] DOIC: Self-Contained OLRs
 
(oops, sorry, I sent my previous response before I was finished.
 
On Nov 29, 2013, at 5:24 AM, Nirav Salot (nsalot) <nsalot@cisco.com> wrote:
 
Jouni, Ben,
 
I am totally against the idea of self-contained OC-OLR specifically since we have adopted the principles of piggybacking the OC-OLR over existing application message.
Self-contained OC-OLR - which means adding all the information which defines the scope of the OC-OLR into the OC-OLR - does not make sense in the piggybacking approach. In fact, it is adding lot of information, which is anyway available within the message containing the OC-OLR, into the OC-OLR. So it is adding lot of redundant information in a message which increases the processing requirement for the sender as well as the receiver. (And this is un-optimization, in my view).
 
It's not clear to me that piggybacking implies any particular relationship between an OLR and the enclosing message, other than transport.
 
 
Besides, I am not convinced with the other reasons provided here:
- One software module within a node can provide OC-OLR to another software module in the same node without passing other related info
  Within a node, based on the design, lots of information may need to be passed between two software modules and we cannot optimize those aspects by replicating unnecessary information in a protocol message.
  In summary, it is node's internal software design issue and we need not optimize that at protocol level.
 
We should absolutely not ignore implementation concerns. I think that overload control should be considered a separate layer than the Diameter application. The whole point of layering is about reducing implementation complexity.
 
In fact, I think this whole disagreement comes from different assumptions about layering. Part of why I've brought this up is, I have talked to implementors who think that we've made life hard for them by tying OLRs to tightly to the application. This is particularly hard for anything that wants to handle OLC for arbitrary applications in an application-independent way. (Which, by the way, is required by the requirements RFC).
 
 
 
- Once the reporting node realizes that it is overloaded, it has to 
wait for right answer to send OC-OLR  What is the point of sending OC-OLR for a context for which there is no messaging? Why should the reacting node care if it never sends a message for a context for which the reporting node is overloaded?
 
I didn't say that no messages existed that could carry the report. The issue is, there may be a lot of other messages that _cannot_ carry it. So the sender has to sort through all the messages to find the ones that can work.
 
 So this waiting is justified since it ensures that the overload is reported only when necessary and only to the applicable reacting node. Not to all the nodes in the network.
 
With self-contained OLRs, you don't have to worry about an inappropriate node getting the request. Sure you can choose to send OLRs only to appropriate reacting nodes, but that becomes an implementation decision rather than a protocol requirement.
 
 
- The agent needs to wait for the answer generated by the server and the right context
  The same argument as applicable for the server applies here. The agent need not send out-of-context overload info to a node.
  Why should reacting node receive/process/store the overload info for the scope for which it is not sending any messages.
 
If it's not sending (or going to send) any messages for the scope, it can ignore the OLR.
 
 
- For sending OC-OLR in dedicated Diameter application???
 Piggybacking was the first basic principle we agreed before putting other principles in place. So we may want to go back the drawing board if we decide to change this principle.
 
Piggybacking does not conflict with self-contained OLRs. The roach draft was piggybacked, and still used self-contained OLRs. All we have to do to use self-contained OLRs is add the necessary AVPs to the OLR format, and possibly remove a bunch of restrictions on how you can use them. If we need other transport designs (i.e. dedicated applications), we can add those later.
 
I'd like to remind people that the original mandate given to the design team at the Berlin DIME meeting was to define a format and semantics, not define how we move reports around. We went way beyond that. I don't object to that fact, but I think we should avoid too many limitations in the format and semantics that prevent other ways of moving the reports around.
 
 
 
Regards,
Nirav.
 
-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen
Sent: Friday, November 29, 2013 2:50 PM
To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list
Cc: Ben Campbell
Subject: Re: [Dime] DOIC: Self-Contained OLRs
 
 
 
So, are we reaching any level of consensus here?
 
- JOuni
 
(as a note.. that we are converging back to where we started with OLRs 
;)
 
 
 
On Nov 28, 2013, at 12:40 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> wrote:
 
Hi,
 
another question:
 
If we go for explicit self contained OLRs, why would we then need the ReportType?
 
The realm-type OLR would explicitly contain application-Id, Realm, but no Host whereas the host-type OLR would explicitly contain application-Id, Host, but probably (I'm not sure) no Realm.
 
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.
 
 
_______________________________________________
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.

--------------010705080508030706060701-- From ulrich.wiehe@nsn.com Thu Dec 5 05:23:41 2013 Return-Path: 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 2C0361ADDD2 for ; Thu, 5 Dec 2013 05:23:41 -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 WbDSDFf5rA4e for ; Thu, 5 Dec 2013 05:23:38 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 963461ADEBF for ; Thu, 5 Dec 2013 05:23:38 -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 rB5DNXYU021044 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 5 Dec 2013 14:23:34 +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 rB5DNXx7019543 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 5 Dec 2013 14:23:33 +0100 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.152]) by DEMUHTC001.nsn-intra.net ([10.159.42.32]) with mapi id 14.03.0123.003; Thu, 5 Dec 2013 14:23:33 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: "dime@ietf.org" Thread-Topic: OVLI: comments to 4.1 Thread-Index: Ac7xvTHHIECkLcDwSDuVAh2ACeOasA== Date: Thu, 5 Dec 2013 13:23:33 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519DA3E@DEMUMBX014.nsn-intra.net> 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="us-ascii" 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: 2270 X-purgate-ID: 151667::1386249814-00002466-4F64B0C5/0-0/0-0 Subject: [Dime] OVLI: comments to 4.1 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 13:23:41 -0000 Dear all, here are comments to clause 4.1: 1. The OC-Feature-Vector AVP is no longer a vector; the name of the AVP may= be misleading. Proposal is to rename it to "OC-Supported-Features AVP" 2. The OC-Feature AVP is a vector of features. Proposal is to rename it to = "OC-Feature-Vector AVP" 3. The OC-Sequence-Number within OC-Feature-Vector only makes sense if the = receiving reporting endpoint can determine the identity of the reacting end= point (which is not necessarily the origin host (client), it may be an agen= t and it may not always be the same agent), and if the reporting endpoint i= s required to store the OC-Feature-Vector / reacting-endpoint-identity pair= (which I think both is not required). The reporting endpoint can base its = processing logic on the actually received OC-Feature-Vector value, no matte= r whether it is brand-new or old but stil valid. Proposal is to delete OC-S= equence-Number AVP from OC-Feature-Vector. 4. The text The reporting node that sends the answer also includes the OC- Feature-Vector AVP that describe the capabilities it supports. The set of capabilities advertised by the reporting node depends on local policies. At least one the announced capabilities MUST match mutually. If there is no single matching capability the reacting node MUST act as if it does not implement DOIC and cease inserting any DOIC related AVPs into any Diameter messages with this specific reacting node. is not clear. Would the reporting node include the OC-Feature-Vector AVP i= n the answer only if there is at least one matching capability?=20 Mandating the reacting node to cease for all time inserting OC-Feature-Vect= or AVPs if it did not get back at least one match is also not ok. The reque= st might have been a realm-type request (i.e. without Destination Host) and= the reacting node cannot control whether subsequent requests will take the= same path to the same reporting node. Even if the request contains a destination host the reacting node cannot kn= ow wether the reacting node's capabilities have been modified by the time a= subsequent request is sent.=20 Proposal is to keep only the first sentence and delete the rest. Ulrich From lionel.morand@orange.com Thu Dec 5 05:28:19 2013 Return-Path: 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 A786C1ADF30 for ; Thu, 5 Dec 2013 05:28:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 m9f6UByoLzeC for ; Thu, 5 Dec 2013 05:28:13 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id 7BFC61ADDD2 for ; Thu, 5 Dec 2013 05:28:12 -0800 (PST) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 1F7142AC4B0 for ; Thu, 5 Dec 2013 14:28:08 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 057A0C8080 for ; Thu, 5 Dec 2013 14:28:08 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0158.001; Thu, 5 Dec 2013 14:28:07 +0100 From: To: "dime@ietf.org" Thread-Topic: [Dime] DOIC: Self-Contained OLRs Thread-Index: AQHO67/uo7y6FFeeaEmQ38aKczpYQJo5m/0AgACzUoCAAAFygIAAE14AgAF8EACAACKcAIAANGaAgATJUgCAAAuAAIACAWkAgAAGHYCAAXsigIAAykrggAA0JQCAABEyAA== Date: Thu, 5 Dec 2013 13:28:06 +0000 Message-ID: <20040_1386250088_52A07F68_20040_916_1_6B7134B31289DC4FAF731D844122B36E32B0E9@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <6390_1385631044_52970D44_6390_18593_1_6B7134B31289DC4FAF731D844122B36E30748E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BD31@DEMUMBX014.nsn-intra.net> <47383DC2-1A1B-4D1A-ADD5-9E3CE60B06C8@gmail.com> <8467_1385735507_5298A553_8467_17054_3_6B7134B31289DC4FAF731D844122B36E309D0D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <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> <52A07A1E.5060502@usdonovans.com> In-Reply-To: <52A07A1E.5060502@usdonovans.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.5] Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E32B0E9PEXCVZYM13corpora_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.19.63615 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 13:28:19 -0000 --_000_6B7134B31289DC4FAF731D844122B36E32B0E9PEXCVZYM13corpora_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable All, After this LONG thread, it seems that there are strong arguments against th= e self-contained OLRs and little support. In the contrary, it seems that the principle of OLR related to the applicat= ion in use is technically OK for everyone. So the question is quite simple: Could everyone live/survive with the "implicit approach" with the extensibi= lity mechanism allowing future extensions if needed? If yes, please focus on the finalization of the current draft. If no, let go on the discussion. Regards, Lionel De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan Envoy=E9 : jeudi 5 d=E9cembre 2013 14:06 =C0 : dime@ietf.org Objet : Re: [Dime] DOIC: Self-Contained OLRs On the schedule question mentioned by JJacques -- any schedule concerns can= go away if everyone agrees to self contained overload reports. This discu= ssion would end and we could move on to other things. :-) I say that somewhat in jest but please don't make the argument that this di= scussion should be ended because of schedule. Or if you make that argument= , please don't assert that the person who disagrees with you is putting the= schedule at risk. We are striving for the best technical solution. We all understand the sch= edule pressures. We need to balance the two. Steve On 12/5/13 5:14 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote: Hi A lot of mails on this topic...I would suggest to introduce an overload con= trol on the Dime email threads:) On my side, I rely on what we have written in the draft for the "baseline"= mechanism and that we have to keep as it is simple and efficient, here I j= oin Lionel, Nirav and MCruz' positions. This thread then addresses extensions cases, I agree that we will have to = address such extensions: Nirav mentioned the example with APN that if rel= evant would a 3GGP application case, I would add the Session Group about w= hich we had some discussion a while ago and which is a more generic IETF c= ase. There is also the agent overload case. Have you others? Always good to= have some use cases in mind. What is important for me is that adding extensions should not modify the ba= seline and making it more complex when used alone. I also make a differenc= e between principles and protocol tuning where we may have to choose betwee= n various protocol solution but addressing the same functionality or princi= ple. About piggybacking, in the baseline, the principle is that OLRs which ar= e addressed to sources of traffic are put in answer messages towards this = traffic sources (origin Host) (even if these messages may be processed by = intermediate DAs), which is simple and the OLR can be kept unchanged in the= same message up to the origin Host if no specific process in intermediate= DAs. To have a piggybacking allowing to put any OLR in any message (as it= was in draft roach) is adding complexity that is not justified for the ba= seline and we have not retained it in the existing draft . About extensions, the APN or session group examples address parts of the = traffic between a server and a client (so a higher granularity in the throt= tling than the baseline one), related OLRs are conveyed in the messages tow= ards the origin Host so with an implicit reference to the Application, the = Origin and Destination Host as for the baseline, so not requiring self con= tained OLRs. I also do not see the interest to send these new extensions O= LR only in answers directly related to this OLR (as Ulrich proposed), eg on= ly in an answer dealing with an APN if the OLR is related to APN throttling= . The main point is that the OLR takes a direct "train" towards the right = destination for a given application (as for baseline). This does not exclude that we may have other cases not entering the above e= xamples characteristics, but as Nirav mentioned, we have to remain pragmat= ic and see this when such new use cases will be addressed. The extensibilit= y possibilities of current draft give us a lot of flexibility, e.g. if som= e extensions need more self contained AVPs, why not, but this is outside th= e current draft. About extensions, I also think that they may need to be identified in the c= apability part, as the related OLRs should not be sent by a reacting node i= f the extension is not supported. Last important point, as Lionel mentioned, we have to finalize the draft s= oon, to be able to start Rel12 3GGP work relying on this draft. My position= is that the current draft is currently well suited for the baseline and th= at extensions will be addressed separately Best regards JJacques -----Message d'origine----- De : DiME [mailto:dime-bounces@ietf.org] De la part de Ben Campbell Envoy=E9 : mercredi 4 d=E9cembre 2013 22:55 =C0 : ext lionel.morand@orange.com Cc : dime@ietf.org Objet : Re: [Dime] DOIC: Self-Contained OLRs On Dec 3, 2013, at 5:17 PM, lionel.morand@orange.com wrote: Hi Ben, I may be wrong somewhere in my summary but I think that it was the result o= f the discussions and agreements reached regarding existing requirements, a= t least from 3GPP point of view, compared to possible optimizations for fut= ure optimizations not so obvious. We are not the 3GPP. Our requirements are RFC 7068. I believe self-containe= d OLRs do a better job of meeting Req 31 than the contextually-defined OLRs. I've made several technical arguments here--does anyone have _technical_ ar= guments in favor of contextually-defined OLRs? And because the solution offers extensibility via the definition of new alg= o, new report type and addition of any new AVP in the existing Grouped OLR,= the "limitations" of the proposed solution might be removed by someone if = really required according to new requirements. It might be worth considering a compromise approach: Define _optional_ AVPs= that allow an OLR to be self-contained. If they are not present, then the = various values default to those from the enclosing Diameter message. Possib= ly add support for this to the list of things that reacting nodes can adver= tise. This could be in the base, or in a follow on extension. (If left for an ext= ension, it's worth considering whether ReportType needs to be in the base, = or this or some other extension.) Regards, Lionel -----Message d'origine----- De : Ben Campbell [mailto:ben@nostrum.com] Envoy=E9 : mardi 3 d=E9cembre 2013 23:56 =C0 : MORAND Lionel IMT/OLN Cc : Steve Donovan; dime@ietf.org Objet : Re: [Dime] DOIC: Self-Contained OLRs On Dec 2, 2013, at 10:18 AM, lionel.morand@orange.com wrote: Hi Steve, I think that is not only about few bytes in the answer. It is also about th= e solution principles agreed so far: =B7 the current need is for an OLR bound to the application in use =B7 the OLR is received from the node targeted in the request. =B7 the OLR is defined per application I don't think those principles have been well tested. I don't recall any di= scussion of their benefits. What benefits do you see they have over self-co= ntained OLRs? All I see from these are restrictions in the flexibility of the solution, w= ith very little in return. So all the implicit information (application, origin-host, origin-realm) ar= e meaningful in this context. And the actual solution is designed based on these assumptions. The extensi= bility of the solution will allow extra info if required in other use cases= but it was agreed to go with a straightforward solution that will satisfy = most of us. Regards, Lionel De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan Envoy=E9 : lundi 2 d=E9cembre 2013 16:37 =C0 : dime@ietf.org Objet : Re: [Dime] DOIC: Self-Contained OLRs I don't believe that Ben's proposal was to change the piggybacking assumpti= on in the baseline mechanism. Ben's proposal is to design the solution in = such a way that it is not dependent on the piggybacking transport mechanism. I share Ben's concern that we have over optimized the content of the overlo= ad report in a way that makes implementations brittle, interoperability mor= e difficult to achieve and extensibility more complex. And what do we gain= from this optimization? A few bites in answer messages. Self contained overload reports, transported using the piggybacking mechani= sm, is a cleaner solution. Steve On 11/29/13 8:31 AM, lionel.morand@orange.com wrote: I totally agree with Nirav. No need to revert at this stage the working ass= umption on piggybacking of OLR in application answer messages, especially w= hen the aim is to define a basic mechanism called "reduction". Anyone would be able to further add extra info for optimization if needed b= ut there is no need at all for the basic mechanism. Regards, Lionel -----Message d'origine----- De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot (nsalot) Envoy=E9 : vendredi 29 novembre 2013 12:24 =C0 : Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list Cc : Ben Campbell Objet : Re: [Dime] DOIC: Self-Contained OLRs Jouni, Ben, I am totally against the idea of self-contained OC-OLR specifically since w= e have adopted the principles of piggybacking the OC-OLR over existing appl= ication message. Self-contained OC-OLR - which means adding all the information which define= s the scope of the OC-OLR into the OC-OLR - does not make sense in the pigg= ybacking approach. In fact, it is adding lot of information, which is anywa= y available within the message containing the OC-OLR, into the OC-OLR. So i= t is adding lot of redundant information in a message which increases the p= rocessing requirement for the sender as well as the receiver. (And this is = un-optimization, in my view). Besides, I am not convinced with the other reasons provided here: - One software module within a node can provide OC-OLR to another software = module in the same node without passing other related info Within a node, based on the design, lots of information may need to be pa= ssed between two software modules and we cannot optimize those aspects by r= eplicating unnecessary information in a protocol message. In summary, it is node's internal software design issue and we need not o= ptimize that at protocol level. - Once the reporting node realizes that it is overloaded, it has to wait fo= r right answer to send OC-OLR What is the point of sending OC-OLR for a context for which there is no me= ssaging? Why should the reacting node care if it never sends a message for = a context for which the reporting node is overloaded? So this waiting is justified since it ensures that the overload is reporte= d only when necessary and only to the applicable reacting node. Not to all = the nodes in the network. - The agent needs to wait for the answer generated by the server and the ri= ght context The same argument as applicable for the server applies here. The agent ne= ed not send out-of-context overload info to a node. Why should reacting node receive/process/store the overload info for the = scope for which it is not sending any messages. - For sending OC-OLR in dedicated Diameter application??? Piggybacking was the first basic principle we agreed before putting other = principles in place. So we may want to go back the drawing board if we deci= de to change this principle. Regards, Nirav. -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen Sent: Friday, November 29, 2013 2:50 PM To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org li= st Cc: Ben Campbell Subject: Re: [Dime] DOIC: Self-Contained OLRs So, are we reaching any level of consensus here? - JOuni (as a note.. that we are converging back to where we started with OLRs ;) On Nov 28, 2013, at 12:40 PM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: Hi, another question: If we go for explicit self contained OLRs, why would we then need the Repor= tType? The realm-type OLR would explicitly contain application-Id, Realm, but no H= ost whereas the host-type OLR would explicitly contain application-Id, Host= , but probably (I'm not sure) no Realm. 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 stat= us. It could be provided an agent inserting this info in answers received f= rom a server behind but also from a server that would know this info by som= e internal magic. But in any case, if we assume that the client will received a successful an= swer from the server for an initial request with only Dest-Realm AVP, it sh= ould be possible to have both report types in the answer: one for the serve= r itself, one for the realm for new request sent to the realm with only Des= t-Realm AVP. Lionel -----Message d'origine----- De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN - DE/Munich) Envoy=E9 : jeudi 28 novembre 2013 10:26 =C0 : 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 a= ligned with the "endpoint principle". If the ReportType is "realm" this ind= icates 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 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 re= acting 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 Diamet= er request that corresponds to the answer containing the OLR. My reasons fo= r 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 i= dentified by Origin-Realm, and so on. This means that the "meaning" of an O= LR 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 answe= r to another, it's meaning may change completely. I think this approach is a mistake. I would greatly prefer that we explicit= ly 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 variou= s other AVPs to find all the information it needs. For example, I think a c= ommon software design for overload control processing to be separated from = application processing. The consumer cannot simply hand the OLR to that mod= ule and expect things to work. The OC module must not only parse the OLR, b= ut parse any other AVPs that are relevant. As OLR contents get extended (as= sumedly following the same strategy as the base spec), the number of "conte= xt" avps that must be interpreted can grow large. This approach is error pr= one, and will likely encourage brittle, hard-to-maintain code. Self-contain= ed OLRs would keep all the information related to overload in one place. ma= king for simpler implementations. 2) It's more complex for the reporting node to send implicit values than ex= plicit values. The sender cannot simply set the context to match the OLR--a= ll those other AVPs have application or protocol layer meanings. Once a rep= orting node realizes that it is overloade, it has to wait for the right ans= wer that contains the right context before it can send the OLR. This is par= ticularly 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 sig= nificantly. 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 so= me 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 overlo= ad reports were self-contained, one could just reuse the report format we s= pecify here. But if the meaning of an OLR depends on the way it's transport= ed, this won't work. We would have to create a new or significantly modifie= d OLR format if we found a need to transport OLRs in different ways. Self-c= ontained OLRs would allow much greater flexibility. So, in summary, I think that self-contained OLRs would lead to simpler impl= ementations, less brittle deployments, and more flexibility for future evol= ution 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 le= s pieces jointes. Les messages electroniques etant susceptibles d'alteratio= n, 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 dis= tributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te 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 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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 confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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 confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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 confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. --_000_6B7134B31289DC4FAF731D844122B36E32B0E9PEXCVZYM13corpora_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

All,<= /o:p>

 = ;

After this= LONG thread, it seems that there are strong arguments against the self-con= tained OLRs and little support.

In the con= trary, it seems that the principle of OLR related to the application in use= is technically OK for everyone.

 = ;

So the que= stion is quite simple:

 = ;

Could ever= yone live/survive with the "implicit approach" with the extensibi= lity mechanism allowing future extensions if needed?

 = ;

If yes, pl= ease focus on the finalization of the current draft.

If no, let= go on the discussion.

 = ;

Regards,

 = ;

Lionel

 = ;

 = ;

De := DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9 : jeudi 5 d=E9cembre 2013 14:06
=C0 : dime@ietf.org
Objet : Re: [Dime] DOIC: Self-Contained OLRs<= /p>

 

On the schedule quest= ion mentioned by JJacques -- any schedule concerns can go away if everyone = agrees to self contained overload reports.  This discussion would end = and we could move on to other things.  :-)

I say that somewhat in jest but please don't make the argument that this di= scussion should be ended because of schedule.  Or if you make that arg= ument, please don't assert that the person who disagrees with you is puttin= g the schedule at risk.

We are striving for the best technical solution.  We all understand th= e schedule pressures.  We need to balance the two.

Steve

On 12/5/13 5:14 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQ= UES) wrote:

Hi 
 
A lot of mails on this topic...I would suggest to introduce an overloa=
d control on the Dime email threads:)  
 
 
On my side, I rely on what we have written in the  draft for the =
"baseline" mechanism and that we have to keep as it is simple and=
 efficient, here I join Lionel, Nirav and MCruz' positions.
 
This thread then addresses extensions  cases, I agree that we wil=
l have to address such extensions:   Nirav mentioned the example =
with APN that if relevant would  a 3GGP application case, I would add =
the Session Group about which we had some discussion a while ago and  =
which is a more generic IETF case. There is also the agent overload case. H=
ave you others? Always good to have some use cases in mind.
 
What is important for me is that adding extensions should not modify t=
he baseline and making it more complex when used alone.  I also make a=
 difference between principles and protocol tuning where we may have to cho=
ose between various protocol solution but addressing the same functionality=
 or principle.  
 
About piggybacking, in the baseline,  the principle is that OLRs&=
nbsp; which  are addressed  to sources of traffic are put in answ=
er messages towards this traffic sources (origin Host) (even if these messa=
ges  may be processed by intermediate DAs), which is simple and the OL=
R can be kept unchanged in the same message  up to the origin Host if =
no specific process in intermediate DAs.  To have a piggybacking allow=
ing to put any OLR in any message (as it was in draft roach)  is addin=
g complexity that is not justified for the baseline and we have not retaine=
d it in the existing draft .
 
About extensions, the APN or session group  examples address =
; parts of the traffic between a server and a client (so a higher granulari=
ty in the throttling than the baseline one), related OLRs are conveyed in t=
he messages towards the origin Host so with an implicit reference to the Ap=
plication, the  Origin and Destination Host as for the baseline, so no=
t requiring self contained OLRs. I also  do not see the interest to se=
nd these new extensions OLR only in answers directly related to this OLR (a=
s Ulrich proposed), eg only in an answer dealing with an APN if the OLR is =
related to APN throttling.  The main point is that the OLR takes a dir=
ect "train" towards the right destination for a given application=
 (as for baseline).
 
This does not exclude that we may have other cases not entering the ab=
ove examples characteristics, but as Nirav mentioned, we  have to rema=
in pragmatic and see this when such new use cases will be addressed. The ex=
tensibility possibilities of  current draft give us a lot of flexibili=
ty, e.g. if some extensions need more self contained AVPs, why not, but thi=
s is outside the current draft. 
 
About extensions, I also think that they may need to be identified in =
the capability part, as the related OLRs should not be sent by a reacting n=
ode if the extension is not supported.
 
Last important point, as  Lionel mentioned, we have to finalize t=
he draft soon, to be able to start Rel12 3GGP work relying on this draft. M=
y position is that the current draft is currently well suited for the basel=
ine and that extensions will be addressed separately  
 
Best regards
 
JJacques 
 
 
-----Message d'origine-----
De : DiME [mailto:dime-b=
ounces@ietf.org] De la part de Ben Campbell
Envoy=E9 : mercredi 4 d=E9cembre 2013 22:55
=C0 : ext lionel.mora=
nd@orange.com
Cc : dime@ietf.org
Objet : Re: [Dime] DOIC: Self-Contained OLRs
 
On Dec 3, 2013, at 5:17 PM, lionel.morand@orange.com wrote:
 
Hi Ben,
 
I may be wrong somewhere in my summary but I think that it was the res=
ult of the discussions and agreements reached regarding existing requiremen=
ts, at least from 3GPP point of view, compared to possible optimizations fo=
r future optimizations not so obvious.
 
We are not the 3GPP. Our requirements are RFC 7068. I believe self-con=
tained OLRs do a better job of meeting Req 31 than the contextually-defined=
 OLRs.
 
I've made several technical arguments here--does anyone have _technica=
l_ arguments in favor of contextually-defined OLRs?
 
And because the solution offers extensibility via the definition of ne=
w algo, new report type and addition of any new AVP in the existing Grouped=
 OLR, the "limitations" of the proposed solution might be removed=
 by someone if really required according to new requirements.

 


 
It might be worth considering a compromise approach: Define _optional_=
 AVPs that allow an OLR to be self-contained. If they are not present, then=
 the various values default to those from the enclosing Diameter message. P=
ossibly add support for this to the list of things that reacting nodes can =
advertise.
 
This could be in the base, or in a follow on extension. (If left for a=
n extension, it's worth considering whether ReportType needs to be in the b=
ase, or this or some other extension.) 
 
 
Regards,
 
Lionel
 
-----Message d'origine-----
De : Ben Campbell [mailto:ben@nostr=
um.com] Envoy=E9 : mardi 3 d=E9cembre 
2013 23:56 =C0 : MORAND Lionel IMT/OLN Cc : Steve Donovan; dime@ietf.org 
Objet : Re: [Dime] DOIC: Self-Contained OLRs
 
 
On Dec 2, 2013, at 10:18 AM, lionel.morand@orange.com wrote:
 
Hi Steve,
 
I think that is not only about few bytes in the answer. It is also abo=
ut the solution principles agreed so far:
=B7         the current need i=
s for an OLR bound to the application in use
=B7         the OLR is receive=
d from the node targeted in the request.
=B7         the OLR is defined=
 per application
 
I don't think those principles have been well tested. I don't recall a=
ny discussion of their benefits. What benefits do you see they have over se=
lf-contained OLRs?
 
All I see from these are restrictions in the flexibility of the soluti=
on, with very little in return.
 
So all the implicit information (application, origin-host, origin-real=
m) are meaningful in this context.
And the actual solution is designed based on these assumptions. The ex=
tensibility of the solution will allow extra info if required in other use =
cases but it was agreed to go with a straightforward solution that will sat=
isfy most of us.
 
Regards,
 
Lionel
 
De : DiME [mailto:dime-bounce=
s@ietf.org] De la part de Steve Donovan
Envoy=E9 : lundi 2 d=E9cembre 2013 16:37
=C0 : dime@ietf.org

Objet : Re: [Dime] DOIC: Self-Contained OLRs


 


I don't believe that Ben's proposal was to change the piggybacking ass=
umption in the baseline mechanism.  Ben's proposal is to design the so=
lution in such a way that it is not dependent on the piggybacking transport=
 mechanism.  


 


I share Ben's concern that we have over optimized the content of the o=
verload report in a way that makes implementations brittle, interoperabilit=
y more difficult to achieve and extensibility more complex.  And what =
do we gain from this optimization?  A few bites in answer messages.


 


Self contained overload reports, transported using the piggybacking me=
chanism, is a cleaner solution.


 


Steve


 


On 11/29/13 8:31 AM, lione=
l.morand@orange.com wrote:


I totally agree with Nirav. No need to revert at this stage the workin=
g assumption on piggybacking of OLR in application answer messages, especia=
lly when the aim is to define a basic mechanism called "reduction"=
;.


 


Anyone would be able to further add extra info for optimization if nee=
ded but there is no need at all for the basic mechanism.


 


Regards,


 


Lionel


 


-----Message d'origine-----


De : DiME [mailto:dime-bounce=
s@ietf.org] De la part de Nirav Salot (nsalot)


Envoy=E9 : vendredi 29 novembre 2013 12:24


=C0 : Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list


Cc : Ben Campbell


Objet : Re: [Dime] DOIC: Self-Contained OLRs


 


Jouni, Ben,


 


I am totally against the idea of self-contained OC-OLR specifically si=
nce we have adopted the principles of piggybacking the OC-OLR over existing=
 application message.


Self-contained OC-OLR - which means adding all the information which d=
efines the scope of the OC-OLR into the OC-OLR - does not make sense in the=
 piggybacking approach. In fact, it is adding lot of information, which is =
anyway available within the message containing the OC-OLR, into the OC-OLR.=
 So it is adding lot of redundant information in a message which increases =
the processing requirement for the sender as well as the receiver. (And thi=
s is un-optimization, in my view).


 


Besides, I am not convinced with the other reasons provided here:=



- One software module within a node can provide OC-OLR to another soft=
ware module in the same node without passing other related info<=
/pre>

  Within a node, based on the design, lots of information may nee=
d to be passed between two software modules and we cannot optimize those as=
pects by replicating unnecessary information in a protocol message.


  In summary, it is node's internal software design issue and we =
need not optimize that at protocol level.


 


- Once the reporting node realizes that it is overloaded, it has to wa=
it for right answer to send OC-OLR


 What is the point of sending OC-OLR for a context for which there is =
no messaging? Why should the reacting node care if it never sends a message=
 for a context for which the reporting node is overloaded?


 So this waiting is justified since it ensures that the overload is re=
ported only when necessary and only to the applicable reacting node. Not to=
 all the nodes in the network.


 


- The agent needs to wait for the answer generated by the server and t=
he right context


  The same argument as applicable for the server applies here. Th=
e agent need not send out-of-context overload info to a node.

  Why should reacting node receive/process/store the overload inf=
o for the scope for which it is not sending any messages.


 


- For sending OC-OLR in dedicated Diameter application???

 Piggybacking was the first basic principle we agreed before putting o=
ther principles in place. So we may want to go back the drawing board if we=
 decide to change this principle.


 


Regards,


Nirav.


 


-----Original Message-----


From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of Jouni Korhonen


Sent: Friday, November 29, 2013 2:50 PM


To: Wiehe, Ulrich (NSN - DE/Munich); =
dime@ietf.org list


Cc: Ben Campbell


Subject: Re: [Dime] DOIC: Self-Contained OLRs


 


 


 


So, are we reaching any level of consensus here?


 


- JOuni


 


(as a note.. that we are converging back to where we started with OLRs=
 ;)


 


 


 


On Nov 28, 2013, at 12:40 PM, "Wiehe, Ulrich (NSN - DE/Munich)&qu=
ot; <ulrich.wiehe@nsn.com> wrote:


 


Hi,


 


another question:


 


If we go for explicit self contained OLRs, why would we then need the =
ReportType?


 


The realm-type OLR would explicitly contain application-Id, Realm, but=
 no Host whereas the host-type OLR would explicitly contain application-Id,=
 Host, but probably (I'm not sure) no Realm.


 


Ulrich


 


 


 


-----Original Message-----


From: ext lionel.morand@or=
ange.com [mailto:lionel.mor=
and@orange.com]


Sent: Thursday, November 28, 2013 10:31 AM


To: Wiehe, Ulrich (NSN - DE/Munich); ext Jouni Korhonen; Ben Campbell<=
o:p>


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 recei=
ved from a server behind but also from a server that would know this info b=
y some internal magic.


But in any case, if we assume that the client will received a successf=
ul 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 onl=
y Dest-Realm AVP.


 


Lionel


 


-----Message d'origine-----


De : DiME [mailto:dime-bounce=
s@ietf.org] De la part de Wiehe, Ulrich 


(NSN - DE/Munich) Envoy=E9 : jeudi 28 novembre 2013 10:26 =C0 : ext Jo=
uni 


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 &=
quot;realm" this indicates to the reacting end point that the reportin=
g 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 repor=
ting end point is a server. How can the reporting end point be both agent a=
nd server?


 


Ulrich


 


-----Original Message-----


From: DiME [mailto:dime-bounc=
es@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 <=
/o:p>


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 t=
he 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 D=
iameter request that corresponds to the answer containing the OLR. My reaso=
ns 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 applica=
tion identified by the Application-Id field of the enclosing answer, the re=
alm identified by Origin-Realm, and so on. This means that the "meanin=
g" of an OLR cannot be determined from the OLR contents alone; OLRs on=
ly 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 exp=
licitly include such values in the OLR itself, for multiple reasons:


 


1) It's more complex to interpret implicit, contextual values than exp=
licit values. The consumer cannot simply look at the OLR; it must look in v=
arious other AVPs to find all the information it needs. For example, I thin=
k a common software design for overload control processing to be separated =
from application processing. The consumer cannot simply hand the OLR to tha=
t module and expect things to work. The OC module must not only parse the O=
LR, but parse any other AVPs that are relevant. As OLR contents get extende=
d (assumedly following the same strategy as the base spec), the number of &=
quot;context" avps that must be interpreted can grow large. This appro=
ach is error prone, and will likely encourage brittle, hard-to-maintain cod=
e. Self-contained OLRs would keep all the information related to overload i=
n one place. making for simpler implementations.


 


2) It's more complex for the reporting node to send implicit values th=
an explicit values. The sender cannot simply set the context to match the O=
LR--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 righ=
t answer that contains the right context before it can send the OLR. This i=
s particularly troublesome for agents, since they will typically have to in=
sert OLRs into answers created by other nodes. 


 


If the reporting node screws this up, the meaning of the OLR may chang=
e significantly. So again, implicit meaning gives us error prone implementa=
tions. 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 <=
o:p>


are distinct from those sent by a server, see Steve's agent overload <=
o:p>


draft, or my dh/dr example.)


 


OTOH, explicit values will work for all cases where we need to associa=
te some arbitrary value with an OLR.


 


4) Implicit values seriously constrain the future evolution of Diamete=
r OC standards. For example, lets say we find a good reason to allow OLRs t=
o be sent out of band, or be sent in a dedicated Diameter application. If o=
verload 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 tran=
sported, this won't work. We would have to create a new or significantly mo=
dified OLR format if we found a need to transport OLRs in different ways. S=
elf-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.iet=
f.org/mailman/listinfo/dime


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.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 q=
ue les pieces jointes. Les messages electroniques etant susceptibles d'alte=
ration, Orange decline toute responsabilite si ce message a ete altere, def=
orme ou falsifie. Merci.


 


This message and its attachments may contain confidential or 


privileged information that may be protected by law; they should not b=
e 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.iet=
f.org/mailman/listinfo/dime


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 


______________________________________________________________________=
___________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


 


This message and its attachments may contain confidential or privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
o:p>


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.iet=
f.org/mailman/listinfo/dime


 


 


______________________________________________________________________=
___________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


 


This message and its attachments may contain confidential or privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
o:p>


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.iet=
f.org/mailman/listinfo/dime


 
 
______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
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.iet=
f.org/mailman/listinfo/dime
 
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.iet=
f.org/mailman/listinfo/dime
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.iet=
f.org/mailman/listinfo/dime
 

 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles 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 el=
ectroniques 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 inf=
ormation 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 dele=
te 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.
--_000_6B7134B31289DC4FAF731D844122B36E32B0E9PEXCVZYM13corpora_-- From nsalot@cisco.com Thu Dec 5 05:49:30 2013 Return-Path: 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 7371C1ADF99 for ; Thu, 5 Dec 2013 05:49:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.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 7prJYU92NJyb for ; Thu, 5 Dec 2013 05:49:23 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id B2B9C1ADF33 for ; Thu, 5 Dec 2013 05:49:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=71817; q=dns/txt; s=iport; t=1386251359; x=1387460959; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=bp+VKvrUyI2IsbUp2gyHhpWNoERKcyr9XPSL51NGgX4=; b=h5G8hZYgMQQTb2mna/Tud+oCx7GjtUGGKvm5TfnGBbQLx10KFRfn/JV5 ZdzZKKAyNBt3cFmUK3Z2m637+WuO4H/FfwGd2/fHxVKjp+/PhhkdmVgDD PbFzwhlDfzh8DP6tZnsdA8985hqsWnu74xmw5sV8moGuAwy46e+6wrjR2 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8FACmDoFKtJV2d/2dsb2JhbABZgkNEOFO4bYEaFnSCJQEBAQMBAQEBFwESOgUCBgIIBwQCAQgOAwEDAQELFgEGBycLFAMGCAIEARIIE4dhBg3BRRMEjh0BEAIBHi0KAQaDGoETA4kKoR2DKYIq X-IronPort-AV: E=Sophos;i="4.93,833,1378857600"; d="scan'208,217";a="289596301" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 05 Dec 2013 13:49:18 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id rB5DnIU9014538 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Dec 2013 13:49:18 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.250]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Thu, 5 Dec 2013 07:49:17 -0600 From: "Nirav Salot (nsalot)" To: Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] DOIC: Self-Contained OLRs Thread-Index: AQHO67/s/vGpiVuf2UayvwQoJbzwfZo6EVYAgACzUoCAAAFygIAAE10AgAF8EQD//7X5YIAAoQmAgATJUQCAAAuBAIACAWkAgAAGHYCAAXsigIAALuKAgAAb/4CAAAErgIAAr54A//+ppoA= Date: Thu, 5 Dec 2013 13:49:17 +0000 Message-ID: References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <47383DC2-1A1B-4D1A-ADD5-9E3CE60B06C8@gmail.com> <8467_1385735507_5298A553_8467_17054_3_6B7134B31289DC4FAF731D844122B36E309D0D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <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> <14594_1386204165_529FCC05_14594_12646_1_6B7134B31289DC4FAF731D844122B36E329907@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B920972CCAA@ESESSMB101.ericsson.se> <52A077CC.3000004@usdonovans.com> In-Reply-To: <52A077CC.3000004@usdonovans.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.234.42] Content-Type: multipart/alternative; boundary="_000_A9CA33BB78081F478946E4F34BF9AAA014D2582Dxmbrcdx10ciscoc_" MIME-Version: 1.0 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 13:49:30 -0000 --_000_A9CA33BB78081F478946E4F34BF9AAA014D2582Dxmbrcdx10ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Steve, While gauging the complexity of "using the self-contained OC-OLR" It seems = you have overlooked the aspect identified by Maria-Cruz below (and JJ earli= er). > Duplication should be avoided, since then we need to assure consistency, = and error handing in case implicit and explicit data values are different f= or any reason... what means that it may always be required to check both im= plicit and explicit data. Regards, Nirav. From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: Thursday, December 05, 2013 6:26 PM To: dime@ietf.org Subject: Re: [Dime] DOIC: Self-Contained OLRs If we equating "complexity" with work done by a Diameter node, then there i= s added "complexity" for both proposals. The extra work that needs to be done for the self contained report approach= is that the reporter needs to add additional AVPs to the report. This is = hardly difficult but it is extra work. The extra work in the implicit approach is that the reactor needs to gather= information from multiple AVPs to understand the context of the AVP. Agai= n, hardly difficult but more work that can be avoided in a well layered sof= tware architecture. My conclusion is that the complexity argument does not apply. There is com= plexity in both, its just a matter of where the work is done. Steve On 12/5/13 3:29 AM, Nirav Salot (nsalot) wrote: Agree with Lionel's view and Maria-Cruz's arguments below. The "self-contained OC-OLR" - which I assume contains the same information = as present in the message containing the OC-OLR - adds extra complexity as = highlighted by Maria-Cruz. The benefit highlighted can be achieved in an implementation specific way b= y the receiver duplicating the information into OC-OLR before passing it to= the layer processing the OC-OLR. Regards, Nirav. -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Maria Cruz Bartolome Sent: Thursday, December 05, 2013 7:53 AM To: dime@ietf.org Subject: Re: [Dime] DOIC: Self-Contained OLRs Dear all, I agree with Lionel argumentation below. A part from that, one concern with "self-contained OLRs" is that some data= is duplicated. Duplication should be avoided, since then we need to assure= consistency, and error handing in case implicit and explicit data values a= re different for any reason... what means that it may always be required to= check both implicit and explicit data. Also, I think this is a pure implementation proposal. Regardless how the da= ta is transported it could be packed in a "self-contained OLRs" within the = diameter application, if for any implementation this is preferred. Regards /MCruz -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange= .com Sent: jueves, 05 de diciembre de 2013 1:43 To: Ben Campbell Cc: dime@ietf.org Subject: Re: [Dime] DOIC: Self-Contained OLRs Hi Ben, 3GPP operational requirements have triggered and driven this work, and 3GPP= will be the main client for this solution (if not the only for a while...)= . Main parties involved in the discussions are 3GPP vendors and 3GPP operat= ors. So instead trying to keep private preserve, we should welcome and enfo= rce cooperative work with 3GPP on this task if we want that the solution de= fined in IETF will be used in 3GPP. Otherwise, 3GPP may decide not to wait = for IETF and develop its own solution, as done in the past (e.g. developing= 3GPP-specific Cx application instead of adopting the IETF-standard Diamete= r SIP application). About the technical discussion, the Req31 says: REQ 31: There are multiple situations where a Diameter node may be overloaded for some purposes but not others. For example, this can happen to an agent or server that supports multiple applications, or when a server depends on multiple external resources, some of which may become overloaded while others are fully available. The solution MUST allow Diameter nodes to indicate overload with sufficient granularity to allow clients to take action based on the overloaded resources without unreasonably forcing available capacity to go unused. The solution MUST support specification of overload information with granularities of at least "Diameter node", "realm", and "Diameter application" and MUST allow extensibility for others to be added in the future. The "MUST" part says: enough granularity with at least host/realm and appli= cation. And the existing solution is compliant with this requirement. If a node is = supporting N applications, an OLR can be sent "per application" with a repo= rt type indicating if it is for the host or the realm. And the extensibilit= y capability is provided by the base solution. So my technical argument is that the existing proposal fulfills the basic r= equirements for an overload control without compromising future extension f= or further granularity. Regards, Lionel -----Message d'origine----- De : Ben Campbell [mailto:ben@nostrum.com] Envoy=E9 : mercredi 4 d=E9cembre= 2013 22:55 =C0 : MORAND Lionel IMT/OLN Cc : dime@ietf.org Objet : Re: [Dime] DOIC: Self-Contained OLRs On Dec 3, 2013, at 5:17 PM, lionel.morand@orange.com wrote: Hi Ben, I may be wrong somewhere in my summary but I think that it was the result o= f the discussions and agreements reached regarding existing requirements, a= t least from 3GPP point of view, compared to possible optimizations for fut= ure optimizations not so obvious. We are not the 3GPP. Our requirements are RFC 7068. I believe self-containe= d OLRs do a better job of meeting Req 31 than the contextually-defined OLRs= . I've made several technical arguments here--does anyone have _technical_ ar= guments in favor of contextually-defined OLRs? And because the solution offers extensibility via the definition of new alg= o, new report type and addition of any new AVP in the existing Grouped OLR,= the "limitations" of the proposed solution might be removed by someone if = really required according to new requirements. It might be worth considering a compromise approach: Define _optional_ AVPs= that allow an OLR to be self-contained. If they are not present, then the = various values default to those from the enclosing Diameter message. Possib= ly add support for this to the list of things that reacting nodes can adver= tise. This could be in the base, or in a follow on extension. (If left for an ext= ension, it's worth considering whether ReportType needs to be in the base, = or this or some other extension.) Regards, Lionel -----Message d'origine----- De : Ben Campbell [mailto:ben@nostrum.com] Envoy=E9 : mardi 3 d=E9cembre 2013 23:56 =C0 : MORAND Lionel IMT/OLN Cc : Steve Donovan; dime@ietf.org Objet : Re: [Dime] DOIC: Self-Contained OLRs On Dec 2, 2013, at 10:18 AM, lionel.morand@orange.com wrote: Hi Steve, I think that is not only about few bytes in the answer. It is also about th= e solution principles agreed so far: =B7 the current need is for an OLR bound to the application in use =B7 the OLR is received from the node targeted in the request. =B7 the OLR is defined per application I don't think those principles have been well tested. I don't recall any di= scussion of their benefits. What benefits do you see they have over self-co= ntained OLRs? All I see from these are restrictions in the flexibility of the solution, w= ith very little in return. So all the implicit information (application, origin-host, origin-realm) ar= e meaningful in this context. And the actual solution is designed based on these assumptions. The extensi= bility of the solution will allow extra info if required in other use cases= but it was agreed to go with a straightforward solution that will satisfy = most of us. Regards, Lionel De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan Envoy=E9 : lundi 2 d=E9cembre 2013 16:37 =C0 : dime@ietf.org Objet : Re: [Dime] DOIC: Self-Contained OLRs I don't believe that Ben's proposal was to change the piggybacking assumpti= on in the baseline mechanism. Ben's proposal is to design the solution in = such a way that it is not dependent on the piggybacking transport mechanism= . I share Ben's concern that we have over optimized the content of the overlo= ad report in a way that makes implementations brittle, interoperability mor= e difficult to achieve and extensibility more complex. And what do we gain= from this optimization? A few bites in answer messages. Self contained overload reports, transported using the piggybacking mechani= sm, is a cleaner solution. Steve On 11/29/13 8:31 AM, lionel.morand@orange.com wrote: I totally agree with Nirav. No need to revert at this stage the working ass= umption on piggybacking of OLR in application answer messages, especially w= hen the aim is to define a basic mechanism called "reduction". Anyone would be able to further add extra info for optimization if needed b= ut there is no need at all for the basic mechanism. Regards, Lionel -----Message d'origine----- De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot (nsalot) Envoy=E9 : vendredi 29 novembre 2013 12:24 =C0 : Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list Cc : Ben Campbell Objet : Re: [Dime] DOIC: Self-Contained OLRs Jouni, Ben, I am totally against the idea of self-contained OC-OLR specifically since w= e have adopted the principles of piggybacking the OC-OLR over existing appl= ication message. Self-contained OC-OLR - which means adding all the information which define= s the scope of the OC-OLR into the OC-OLR - does not make sense in the pigg= ybacking approach. In fact, it is adding lot of information, which is anywa= y available within the message containing the OC-OLR, into the OC-OLR. So i= t is adding lot of redundant information in a message which increases the p= rocessing requirement for the sender as well as the receiver. (And this is = un-optimization, in my view). Besides, I am not convinced with the other reasons provided here: - One software module within a node can provide OC-OLR to another software = module in the same node without passing other related info Within a node, based on the design, lots of information may need to be pa= ssed between two software modules and we cannot optimize those aspects by r= eplicating unnecessary information in a protocol message. In summary, it is node's internal software design issue and we need not o= ptimize that at protocol level. - Once the reporting node realizes that it is overloaded, it has to wait fo= r right answer to send OC-OLR What is the point of sending OC-OLR for a context for which there is no me= ssaging? Why should the reacting node care if it never sends a message for = a context for which the reporting node is overloaded? So this waiting is justified since it ensures that the overload is reporte= d only when necessary and only to the applicable reacting node. Not to all = the nodes in the network. - The agent needs to wait for the answer generated by the server and the ri= ght context The same argument as applicable for the server applies here. The agent ne= ed not send out-of-context overload info to a node. Why should reacting node receive/process/store the overload info for the = scope for which it is not sending any messages. - For sending OC-OLR in dedicated Diameter application??? Piggybacking was the first basic principle we agreed before putting other = principles in place. So we may want to go back the drawing board if we deci= de to change this principle. Regards, Nirav. -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen Sent: Friday, November 29, 2013 2:50 PM To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org li= st Cc: Ben Campbell Subject: Re: [Dime] DOIC: Self-Contained OLRs So, are we reaching any level of consensus here? - JOuni (as a note.. that we are converging back to where we started with OLRs ;) On Nov 28, 2013, at 12:40 PM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: Hi, another question: If we go for explicit self contained OLRs, why would we then need the Repor= tType? The realm-type OLR would explicitly contain application-Id, Realm, but no H= ost whereas the host-type OLR would explicitly contain application-Id, Host= , but probably (I'm not sure) no Realm. 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 stat= us. It could be provided an agent inserting this info in answers received f= rom a server behind but also from a server that would know this info by som= e internal magic. But in any case, if we assume that the client will received a successful an= swer from the server for an initial request with only Dest-Realm AVP, it sh= ould be possible to have both report types in the answer: one for the serve= r itself, one for the realm for new request sent to the realm with only Des= t-Realm AVP. Lionel -----Message d'origine----- De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN - DE/Munich) Envoy=E9 : jeudi 28 novembre 2013 10:26 =C0 : 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 a= ligned with the "endpoint principle". If the ReportType is "realm" this ind= icates 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 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 re= acting 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 Diamet= er request that corresponds to the answer containing the OLR. My reasons fo= r 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 i= dentified by Origin-Realm, and so on. This means that the "meaning" of an O= LR 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 answe= r to another, it's meaning may change completely. I think this approach is a mistake. I would greatly prefer that we explicit= ly 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 variou= s other AVPs to find all the information it needs. For example, I think a c= ommon software design for overload control processing to be separated from = application processing. The consumer cannot simply hand the OLR to that mod= ule and expect things to work. The OC module must not only parse the OLR, b= ut parse any other AVPs that are relevant. As OLR contents get extended (as= sumedly following the same strategy as the base spec), the number of "conte= xt" avps that must be interpreted can grow large. This approach is error pr= one, and will likely encourage brittle, hard-to-maintain code. Self-contain= ed OLRs would keep all the information related to overload in one place. ma= king for simpler implementations. 2) It's more complex for the reporting node to send implicit values than ex= plicit values. The sender cannot simply set the context to match the OLR--a= ll those other AVPs have application or protocol layer meanings. Once a rep= orting node realizes that it is overloade, it has to wait for the right ans= wer that contains the right context before it can send the OLR. This is par= ticularly 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 sig= nificantly. 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 so= me 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 overlo= ad reports were self-contained, one could just reuse the report format we s= pecify here. But if the meaning of an OLR depends on the way it's transport= ed, this won't work. We would have to create a new or significantly modifie= d OLR format if we found a need to transport OLRs in different ways. Self-c= ontained OLRs would allow much greater flexibility. So, in summary, I think that self-contained OLRs would lead to simpler impl= ementations, less brittle deployments, and more flexibility for future evol= ution 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 le= s pieces jointes. Les messages electroniques etant susceptibles d'alteratio= n, 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 dis= tributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te 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 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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 confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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 confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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 confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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 --_000_A9CA33BB78081F478946E4F34BF9AAA014D2582Dxmbrcdx10ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Steve,<= /p>

 <= /p>

While gauging the complex= ity of "using the self-contained OC-OLR" It seems you have overlo= oked the aspect identified by Maria-Cruz below (and JJ earlier).=

> Duplication s= hould be avoided, since then we need to assure consistency, and error handi= ng in case implicit and explicit data values are different for any reason... what means that it may always be required to check both = implicit and explicit data.

 <= /p>

Regards,

Nirav.<= /p>

 <= /p>

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: Thursday, December 05, 2013 6:26 PM
To: dime@ietf.org
Subject: Re: [Dime] DOIC: Self-Contained OLRs

 

If we equating "= complexity" with work done by a Diameter node, then there is added &qu= ot;complexity" for both proposals.

The extra work that needs to be done for the self contained report approach= is that the reporter needs to add additional AVPs to the report.  Thi= s is hardly difficult but it is extra work.

The extra work in the implicit approach is that the reactor needs to gather= information from multiple AVPs to understand the context of the AVP. = Again, hardly difficult but more work that can be avoided in a well layere= d software architecture.

My conclusion is that the complexity argument does not apply.  There i= s complexity in both, its just a matter of where the work is done.

Steve

On 12/5/13 3:29 AM, Nirav Salot (nsalot) wrote:= 

Agree with Lionel's view and Maria-Cruz's arguments below.<=
/pre>

 


The "self-contained OC-OLR" - which I assume contains the sa=
me information as present in the message containing the OC-OLR - adds extra=
 complexity as highlighted by Maria-Cruz.


The benefit highlighted can be achieved in an implementation specific =
way by the receiver duplicating the information into OC-OLR before passing =
it to the layer processing the OC-OLR.


 


Regards,


Nirav.


 


-----Original Message-----


From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of Maria Cruz Bartolome


Sent: Thursday, December 05, 2013 7:53 AM


To: dime@ietf.org

Subject: Re: [Dime] DOIC: Self-Contained OLRs


 


Dear all,


 


I agree with Lionel argumentation below.


 


A part from that,  one concern with "self-contained OLRs&quo=
t; is that some data is duplicated. Duplication should be avoided, since th=
en we need to assure consistency, and error handing in case implicit and ex=
plicit data values are different for any reason... what means that it may a=
lways be required to check both implicit and explicit data.

 


Also, I think this is a pure implementation proposal. Regardless how t=
he data is transported it could be packed in a "self-contained OLRs&qu=
ot; within the diameter application, if for any implementation this is pref=
erred.


 


Regards


/MCruz


 


 


-----Original Message-----


From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of l=
ionel.morand@orange.com


Sent: jueves, 05 de diciembre de 2013 1:43


To: Ben Campbell


Cc: dime@ietf.org

Subject: Re: [Dime] DOIC: Self-Contained OLRs


 


Hi Ben,


 


3GPP operational requirements have triggered and driven this work, and=
 3GPP will be the main client for this solution (if not the only for a whil=
e...). Main parties involved in the discussions are 3GPP vendors and 3GPP o=
perators. So instead trying to keep private preserve, we should welcome and=
 enforce cooperative work with 3GPP on this task if we want that the soluti=
on defined in IETF will be used in 3GPP. Otherwise, 3GPP may decide not to =
wait for IETF and develop its own solution, as done in the past (e.g. devel=
oping 3GPP-specific Cx application instead of adopting the IETF-standard Di=
ameter SIP application).


 


About the technical discussion, the Req31 says:


 


   REQ 31: There are multiple situations where a Diameter no=
de may be


           overloade=
d for some purposes but not others.  For example,


           this can =
happen to an agent or server that supports multiple


           applicati=
ons, or when a server depends on multiple external


           resources=
, some of which may become overloaded while others


           are fully=
 available.  The solution MUST allow Diameter nodes


           to indica=
te overload with sufficient granularity to allow


           clients t=
o take action based on the overloaded resources


           without u=
nreasonably forcing available capacity to go unused.


           The solut=
ion MUST support specification of overload


           informati=
on with granularities of at least "Diameter node",

           "rea=
lm", and "Diameter application" and MUST allow

           extensibi=
lity for others to be added in the future.


 


The "MUST" part says: enough granularity with at least host/=
realm and application.


And the existing solution is compliant with this requirement. If a nod=
e is supporting N applications, an OLR can be sent "per application&qu=
ot; with a report type indicating if it is for the host or the realm. And t=
he extensibility capability is provided by the base solution.

 


So my technical argument is that the existing proposal fulfills the ba=
sic requirements for an overload control without compromising future extens=
ion for further granularity.


 


Regards,


 


Lionel 


 


-----Message d'origine-----


De : Ben Campbell [mailto:ben@=
nostrum.com] Envoy=E9 : mercredi 4 d=E9cembre 2013 22:55 =C0 =
: MORAND Lionel IMT/OLN Cc : dime@iet=
f.org Objet : Re: [Dime] DOIC: Self-Contained OLRs

 


On Dec 3, 2013, at 5:17 PM, lionel.morand@orange.com wrote:


 




Hi Ben,


 


I may be wrong somewhere in my summary but I think that it was the res=
ult of the discussions and agreements reached regarding existing requiremen=
ts, at least from 3GPP point of view, compared to possible optimizations fo=
r future optimizations not so obvious.




 


We are not the 3GPP. Our requirements are RFC 7068. I believe self-con=
tained OLRs do a better job of meeting Req 31 than the contextually-defined=
 OLRs.


 


I've made several technical arguments here--does anyone have _technica=
l_ arguments in favor of contextually-defined OLRs?


 




And because the solution offers extensibility via the definition of ne=
w algo, new report type and addition of any new AVP in the existing Grouped=
 OLR, the "limitations" of the proposed solution might be removed=
 by someone if really required according to new requirements.

 




 


It might be worth considering a compromise approach: Define _optional_=
 AVPs that allow an OLR to be self-contained. If they are not present, then=
 the various values default to those from the enclosing Diameter message. P=
ossibly add support for this to the list of things that reacting nodes can =
advertise.


 


This could be in the base, or in a follow on extension. (If left for a=
n extension, it's worth considering whether ReportType needs to be in the b=
ase, or this or some other extension.) 


 


 




Regards,


 


Lionel


 


-----Message d'origine-----


De : Ben Campbell [mailto:ben@nostr=
um.com] Envoy=E9 : mardi 3 d=E9cembre 


2013 23:56 =C0 : MORAND Lionel IMT/OLN Cc : Steve Donovan; dime@ietf.org 


Objet : Re: [Dime] DOIC: Self-Contained OLRs


 


 


On Dec 2, 2013, at 10:18 AM, lionel.morand@orange.com wrote:


 




Hi Steve,


 


I think that is not only about few bytes in the answer. It is also abo=
ut the solution principles agreed so far:


=B7         the current need i=
s for an OLR bound to the application in use


=B7         the OLR is receive=
d from the node targeted in the request.


=B7         the OLR is defined=
 per application




 


I don't think those principles have been well tested. I don't recall a=
ny discussion of their benefits. What benefits do you see they have over se=
lf-contained OLRs?


 


All I see from these are restrictions in the flexibility of the soluti=
on, with very little in return.


 




So all the implicit information (application, origin-host, origin-real=
m) are meaningful in this context.


And the actual solution is designed based on these assumptions. The ex=
tensibility of the solution will allow extra info if required in other use =
cases but it was agreed to go with a straightforward solution that will sat=
isfy most of us.


 


Regards,


 


Lionel


 


De : DiME [mailto:dime-bounce=
s@ietf.org] De la part de Steve Donovan


Envoy=E9 : lundi 2 d=E9cembre 2013 16:37


=C0 : dime@ietf.org

Objet : Re: [Dime] DOIC: Self-Contained OLRs


 


I don't believe that Ben's proposal was to change the piggybacking ass=
umption in the baseline mechanism.  Ben's proposal is to design the so=
lution in such a way that it is not dependent on the piggybacking transport=
 mechanism.  


 


I share Ben's concern that we have over optimized the content of the o=
verload report in a way that makes implementations brittle, interoperabilit=
y more difficult to achieve and extensibility more complex.  And what =
do we gain from this optimization?  A few bites in answer messages.


 


Self contained overload reports, transported using the piggybacking me=
chanism, is a cleaner solution.


 


Steve


 


On 11/29/13 8:31 AM, lione=
l.morand@orange.com wrote:


I totally agree with Nirav. No need to revert at this stage the workin=
g assumption on piggybacking of OLR in application answer messages, especia=
lly when the aim is to define a basic mechanism called "reduction"=
;.


 


Anyone would be able to further add extra info for optimization if nee=
ded but there is no need at all for the basic mechanism.


 


Regards,


 


Lionel


 


-----Message d'origine-----


De : DiME [mailto:dime-bounce=
s@ietf.org] De la part de Nirav Salot (nsalot)


Envoy=E9 : vendredi 29 novembre 2013 12:24


=C0 : Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list


Cc : Ben Campbell


Objet : Re: [Dime] DOIC: Self-Contained OLRs


 


Jouni, Ben,


 


I am totally against the idea of self-contained OC-OLR specifically si=
nce we have adopted the principles of piggybacking the OC-OLR over existing=
 application message.


Self-contained OC-OLR - which means adding all the information which d=
efines the scope of the OC-OLR into the OC-OLR - does not make sense in the=
 piggybacking approach. In fact, it is adding lot of information, which is =
anyway available within the message containing the OC-OLR, into the OC-OLR.=
 So it is adding lot of redundant information in a message which increases =
the processing requirement for the sender as well as the receiver. (And thi=
s is un-optimization, in my view).


 


Besides, I am not convinced with the other reasons provided here:=



- One software module within a node can provide OC-OLR to another soft=
ware module in the same node without passing other related info<=
/pre>

  Within a node, based on the design, lots of information may nee=
d to be passed between two software modules and we cannot optimize those as=
pects by replicating unnecessary information in a protocol message.


  In summary, it is node's internal software design issue and we =
need not optimize that at protocol level.


 


- Once the reporting node realizes that it is overloaded, it has to wa=
it for right answer to send OC-OLR


 What is the point of sending OC-OLR for a context for which there is =
no messaging? Why should the reacting node care if it never sends a message=
 for a context for which the reporting node is overloaded?


 So this waiting is justified since it ensures that the overload is re=
ported only when necessary and only to the applicable reacting node. Not to=
 all the nodes in the network.


 


- The agent needs to wait for the answer generated by the server and t=
he right context


  The same argument as applicable for the server applies here. Th=
e agent need not send out-of-context overload info to a node.

  Why should reacting node receive/process/store the overload inf=
o for the scope for which it is not sending any messages.


 


- For sending OC-OLR in dedicated Diameter application???

 Piggybacking was the first basic principle we agreed before putting o=
ther principles in place. So we may want to go back the drawing board if we=
 decide to change this principle.


 


Regards,


Nirav.


 


-----Original Message-----


From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of Jouni Korhonen


Sent: Friday, November 29, 2013 2:50 PM


To: Wiehe, Ulrich (NSN - DE/Munich); =
dime@ietf.org list


Cc: Ben Campbell


Subject: Re: [Dime] DOIC: Self-Contained OLRs


 


 


 


So, are we reaching any level of consensus here?


 


- JOuni


 


(as a note.. that we are converging back to where we started with OLRs=
 ;)


 


 


 


On Nov 28, 2013, at 12:40 PM, "Wiehe, Ulrich (NSN - DE/Munich)&qu=
ot; <ulrich.wiehe@nsn.com> wrote:


 


Hi,


 


another question:


 


If we go for explicit self contained OLRs, why would we then need the =
ReportType?


 


The realm-type OLR would explicitly contain application-Id, Realm, but=
 no Host whereas the host-type OLR would explicitly contain application-Id,=
 Host, but probably (I'm not sure) no Realm.


 


Ulrich


 


 


 


-----Original Message-----


From: ext lionel.morand@or=
ange.com [mailto:lionel.mor=
and@orange.com]


Sent: Thursday, November 28, 2013 10:31 AM


To: Wiehe, Ulrich (NSN - DE/Munich); ext Jouni Korhonen; Ben Campbell<=
o:p>


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 recei=
ved from a server behind but also from a server that would know this info b=
y some internal magic.


But in any case, if we assume that the client will received a successf=
ul 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 onl=
y Dest-Realm AVP.


 


Lionel


 


-----Message d'origine-----


De : DiME [mailto:dime-bounce=
s@ietf.org] De la part de Wiehe, Ulrich 


(NSN - DE/Munich) Envoy=E9 : jeudi 28 novembre 2013 10:26 =C0 : ext Jo=
uni 


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 &=
quot;realm" this indicates to the reacting end point that the reportin=
g 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 repor=
ting end point is a server. How can the reporting end point be both agent a=
nd server?


 


Ulrich


 


-----Original Message-----


From: DiME [mailto:dime-bounc=
es@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 <=
/o:p>


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 t=
he 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 D=
iameter request that corresponds to the answer containing the OLR. My reaso=
ns 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 applica=
tion identified by the Application-Id field of the enclosing answer, the re=
alm identified by Origin-Realm, and so on. This means that the "meanin=
g" of an OLR cannot be determined from the OLR contents alone; OLRs on=
ly 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 exp=
licitly include such values in the OLR itself, for multiple reasons:


 


1) It's more complex to interpret implicit, contextual values than exp=
licit values. The consumer cannot simply look at the OLR; it must look in v=
arious other AVPs to find all the information it needs. For example, I thin=
k a common software design for overload control processing to be separated =
from application processing. The consumer cannot simply hand the OLR to tha=
t module and expect things to work. The OC module must not only parse the O=
LR, but parse any other AVPs that are relevant. As OLR contents get extende=
d (assumedly following the same strategy as the base spec), the number of &=
quot;context" avps that must be interpreted can grow large. This appro=
ach is error prone, and will likely encourage brittle, hard-to-maintain cod=
e. Self-contained OLRs would keep all the information related to overload i=
n one place. making for simpler implementations.


 


2) It's more complex for the reporting node to send implicit values th=
an explicit values. The sender cannot simply set the context to match the O=
LR--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 righ=
t answer that contains the right context before it can send the OLR. This i=
s particularly troublesome for agents, since they will typically have to in=
sert OLRs into answers created by other nodes. 


 


If the reporting node screws this up, the meaning of the OLR may chang=
e significantly. So again, implicit meaning gives us error prone implementa=
tions. 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 <=
o:p>


are distinct from those sent by a server, see Steve's agent overload <=
o:p>


draft, or my dh/dr example.)


 


OTOH, explicit values will work for all cases where we need to associa=
te some arbitrary value with an OLR.


 


4) Implicit values seriously constrain the future evolution of Diamete=
r OC standards. For example, lets say we find a good reason to allow OLRs t=
o be sent out of band, or be sent in a dedicated Diameter application. If o=
verload 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 tran=
sported, this won't work. We would have to create a new or significantly mo=
dified OLR format if we found a need to transport OLRs in different ways. S=
elf-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.iet=
f.org/mailman/listinfo/dime


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.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 q=
ue les pieces jointes. Les messages electroniques etant susceptibles d'alte=
ration, Orange decline toute responsabilite si ce message a ete altere, def=
orme ou falsifie. Merci.


 


This message and its attachments may contain confidential or 


privileged information that may be protected by law; they should not b=
e 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.iet=
f.org/mailman/listinfo/dime


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 


______________________________________________________________________=
___________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


 


This message and its attachments may contain confidential or privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
o:p>


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.iet=
f.org/mailman/listinfo/dime


 


 


______________________________________________________________________=
___________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


 


This message and its attachments may contain confidential or privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
o:p>


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.iet=
f.org/mailman/listinfo/dime




 


 


______________________________________________________________________=
___________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


 


This message and its attachments may contain confidential or privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
o:p>


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.iet=
f.org/mailman/listinfo/dime




 


 


______________________________________________________________________=
___________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


 


This message and its attachments may contain confidential or privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
o:p>


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.iet=
f.org/mailman/listinfo/dime


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 

 

--_000_A9CA33BB78081F478946E4F34BF9AAA014D2582Dxmbrcdx10ciscoc_-- From srdonovan@usdonovans.com Thu Dec 5 05:52:07 2013 Return-Path: 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 B237C1ADF33 for ; Thu, 5 Dec 2013 05:52:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no 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 rYuzoimTDm_H for ; Thu, 5 Dec 2013 05:52:03 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 1F7CD1ADF10 for ; Thu, 5 Dec 2013 05:52:03 -0800 (PST) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:61796 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1VoZLQ-0007I2-CR for dime@ietf.org; Thu, 05 Dec 2013 05:51:59 -0800 Message-ID: <52A084FA.7000803@usdonovans.com> Date: Thu, 05 Dec 2013 07:51:54 -0600 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: dime@ietf.org References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D90006681519BD31@DEMUMBX014.nsn-intra.net> <47383DC2-1A1B-4D1A-ADD5-9E3CE60B06C8@gmail.com> <8467_1385735507_5298A553_8467_17054_3_6B7134B31289DC4FAF731D844122B36E309D0D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <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> <52A07A1E.5060502@usdonovans.com> <20040_1386250088_52A07F68_20040_916_1_6B7134B31289DC4FAF731D844122B36E32B0E9@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <20040_1386250088_52A07F68_20040_916_1_6B7134B31289DC4FAF731D844122B36E32B0E9@PEXCVZYM13.corporate.adroot.infra.ftgroup> Content-Type: multipart/alternative; boundary="------------050304080301090204000000" X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 13:52:08 -0000 This is a multi-part message in MIME format. --------------050304080301090204000000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Lionel, I strongly disagree with your conclusion that there is little support for self-contained OLRs. I also object to your assessment that there are strong arguments against self-contained reports. I have yet to see a single STRONG argument. I also object to your attempting to call the question at this point in the discussion. The only arguments I see for the implicit approach is complexity, which I just sent an email refuting and schedule, about which I also just sent an email. Self contained reports work just as well and has advantages both short term in support for non application specific software layering and in the long term in allowing for the same overload report to be transported using multiple DOC solutions. I also don't agree that this has been a particularly long thread. There are multiple topics being discussed under the same subject line. If we are to pose a question at this point I would suggest -- Can everyone live with self-contained overload reports? Steve On 12/5/13 7:28 AM, lionel.morand@orange.com wrote: > > All, > > > > After this LONG thread, it seems that there are strong arguments > against the self-contained OLRs and little support. > > In the contrary, it seems that the principle of OLR related to the > application in use is technically OK for everyone. > > > > So the question is quite simple: > > > > Could everyone live/survive with the "implicit approach" with the > extensibility mechanism allowing future extensions if needed? > > > > If yes, please focus on the finalization of the current draft. > > If no, let go on the discussion. > > > > Regards, > > > > Lionel > > > > > > *De :*DiME [mailto:dime-bounces@ietf.org] *De la part de* Steve Donovan > *Envoyé :* jeudi 5 décembre 2013 14:06 > *À :* dime@ietf.org > *Objet :* Re: [Dime] DOIC: Self-Contained OLRs > > > > On the schedule question mentioned by JJacques -- any schedule > concerns can go away if everyone agrees to self contained overload > reports. This discussion would end and we could move on to other > things. :-) > > I say that somewhat in jest but please don't make the argument that > this discussion should be ended because of schedule. Or if you make > that argument, please don't assert that the person who disagrees with > you is putting the schedule at risk. > > We are striving for the best technical solution. We all understand > the schedule pressures. We need to balance the two. > > Steve > > On 12/5/13 5:14 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote: > > Hi > > > > A lot of mails on this topic...I would suggest to introduce an overload control on the Dime email threads:) > > > > > > On my side, I rely on what we have written in the draft for the "baseline" mechanism and that we have to keep as it is simple and efficient, here I join Lionel, Nirav and MCruz' positions. > > > > This thread then addresses extensions cases, I agree that we will have to address such extensions: Nirav mentioned the example with APN that if relevant would a 3GGP application case, I would add the Session Group about which we had some discussion a while ago and which is a more generic IETF case. There is also the agent overload case. Have you others? Always good to have some use cases in mind. > > > > What is important for me is that adding extensions should not modify the baseline and making it more complex when used alone. I also make a difference between principles and protocol tuning where we may have to choose between various protocol solution but addressing the same functionality or principle. > > > > About piggybacking, in the baseline, the principle is that OLRs which are addressed to sources of traffic are put in answer messages towards this traffic sources (origin Host) (even if these messages may be processed by intermediate DAs), which is simple and the OLR can be kept unchanged in the same message up to the origin Host if no specific process in intermediate DAs. To have a piggybacking allowing to put any OLR in any message (as it was in draft roach) is adding complexity that is not justified for the baseline and we have not retained it in the existing draft . > > > > About extensions, the APN or session group examples address parts of the traffic between a server and a client (so a higher granularity in the throttling than the baseline one), related OLRs are conveyed in the messages towards the origin Host so with an implicit reference to the Application, the Origin and Destination Host as for the baseline, so not requiring self contained OLRs. I also do not see the interest to send these new extensions OLR only in answers directly related to this OLR (as Ulrich proposed), eg only in an answer dealing with an APN if the OLR is related to APN throttling. The main point is that the OLR takes a direct "train" towards the right destination for a given application (as for baseline). > > > > This does not exclude that we may have other cases not entering the above examples characteristics, but as Nirav mentioned, we have to remain pragmatic and see this when such new use cases will be addressed. The extensibility possibilities of current draft give us a lot of flexibility, e.g. if some extensions need more self contained AVPs, why not, but this is outside the current draft. > > > > About extensions, I also think that they may need to be identified in the capability part, as the related OLRs should not be sent by a reacting node if the extension is not supported. > > > > Last important point, as Lionel mentioned, we have to finalize the draft soon, to be able to start Rel12 3GGP work relying on this draft. My position is that the current draft is currently well suited for the baseline and that extensions will be addressed separately > > > > Best regards > > > > JJacques > > > > > > -----Message d'origine----- > > De : DiME [mailto:dime-bounces@ietf.org] De la part de Ben Campbell > > Envoyé : mercredi 4 décembre 2013 22:55 > > À : ext lionel.morand@orange.com > > Cc : dime@ietf.org > > Objet : Re: [Dime] DOIC: Self-Contained OLRs > > > > On Dec 3, 2013, at 5:17 PM, lionel.morand@orange.com wrote: > > > > Hi Ben, > > > > I may be wrong somewhere in my summary but I think that it was the result of the discussions and agreements reached regarding existing requirements, at least from 3GPP point of view, compared to possible optimizations for future optimizations not so obvious. > > > > We are not the 3GPP. Our requirements are RFC 7068. I believe self-contained OLRs do a better job of meeting Req 31 than the contextually-defined OLRs. > > > > I've made several technical arguments here--does anyone have _technical_ arguments in favor of contextually-defined OLRs? > > > > And because the solution offers extensibility via the definition of new algo, new report type and addition of any new AVP in the existing Grouped OLR, the "limitations" of the proposed solution might be removed by someone if really required according to new requirements. > > > > > > It might be worth considering a compromise approach: Define _optional_ AVPs that allow an OLR to be self-contained. If they are not present, then the various values default to those from the enclosing Diameter message. Possibly add support for this to the list of things that reacting nodes can advertise. > > > > This could be in the base, or in a follow on extension. (If left for an extension, it's worth considering whether ReportType needs to be in the base, or this or some other extension.) > > > > > > Regards, > > > > Lionel > > > > -----Message d'origine----- > > De : Ben Campbell [mailto:ben@nostrum.com] Envoyé : mardi 3 décembre > > 2013 23:56 À : MORAND Lionel IMT/OLN Cc : Steve Donovan; dime@ietf.org > > Objet : Re: [Dime] DOIC: Self-Contained OLRs > > > > > > On Dec 2, 2013, at 10:18 AM, lionel.morand@orange.com wrote: > > > > Hi Steve, > > > > I think that is not only about few bytes in the answer. It is also about the solution principles agreed so far: > > · the current need is for an OLR bound to the application in use > > · the OLR is received from the node targeted in the request. > > · the OLR is defined per application > > > > I don't think those principles have been well tested. I don't recall any discussion of their benefits. What benefits do you see they have over self-contained OLRs? > > > > All I see from these are restrictions in the flexibility of the solution, with very little in return. > > > > So all the implicit information (application, origin-host, origin-realm) are meaningful in this context. > > And the actual solution is designed based on these assumptions. The extensibility of the solution will allow extra info if required in other use cases but it was agreed to go with a straightforward solution that will satisfy most of us. > > > > Regards, > > > > Lionel > > > > De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan > > Envoyé : lundi 2 décembre 2013 16:37 > > À : dime@ietf.org > > Objet : Re: [Dime] DOIC: Self-Contained OLRs > > > > I don't believe that Ben's proposal was to change the piggybacking assumption in the baseline mechanism. Ben's proposal is to design the solution in such a way that it is not dependent on the piggybacking transport mechanism. > > > > I share Ben's concern that we have over optimized the content of the overload report in a way that makes implementations brittle, interoperability more difficult to achieve and extensibility more complex. And what do we gain from this optimization? A few bites in answer messages. > > > > Self contained overload reports, transported using the piggybacking mechanism, is a cleaner solution. > > > > Steve > > > > On 11/29/13 8:31 AM, lionel.morand@orange.com wrote: > > I totally agree with Nirav. No need to revert at this stage the working assumption on piggybacking of OLR in application answer messages, especially when the aim is to define a basic mechanism called "reduction". > > > > Anyone would be able to further add extra info for optimization if needed but there is no need at all for the basic mechanism. > > > > Regards, > > > > Lionel > > > > -----Message d'origine----- > > De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot (nsalot) > > Envoyé : vendredi 29 novembre 2013 12:24 > > À : Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list > > Cc : Ben Campbell > > Objet : Re: [Dime] DOIC: Self-Contained OLRs > > > > Jouni, Ben, > > > > I am totally against the idea of self-contained OC-OLR specifically since we have adopted the principles of piggybacking the OC-OLR over existing application message. > > Self-contained OC-OLR - which means adding all the information which defines the scope of the OC-OLR into the OC-OLR - does not make sense in the piggybacking approach. In fact, it is adding lot of information, which is anyway available within the message containing the OC-OLR, into the OC-OLR. So it is adding lot of redundant information in a message which increases the processing requirement for the sender as well as the receiver. (And this is un-optimization, in my view). > > > > Besides, I am not convinced with the other reasons provided here: > > - One software module within a node can provide OC-OLR to another software module in the same node without passing other related info > > Within a node, based on the design, lots of information may need to be passed between two software modules and we cannot optimize those aspects by replicating unnecessary information in a protocol message. > > In summary, it is node's internal software design issue and we need not optimize that at protocol level. > > > > - Once the reporting node realizes that it is overloaded, it has to wait for right answer to send OC-OLR > > What is the point of sending OC-OLR for a context for which there is no messaging? Why should the reacting node care if it never sends a message for a context for which the reporting node is overloaded? > > So this waiting is justified since it ensures that the overload is reported only when necessary and only to the applicable reacting node. Not to all the nodes in the network. > > > > - The agent needs to wait for the answer generated by the server and the right context > > The same argument as applicable for the server applies here. The agent need not send out-of-context overload info to a node. > > Why should reacting node receive/process/store the overload info for the scope for which it is not sending any messages. > > > > - For sending OC-OLR in dedicated Diameter application??? > > Piggybacking was the first basic principle we agreed before putting other principles in place. So we may want to go back the drawing board if we decide to change this principle. > > > > Regards, > > Nirav. > > > > -----Original Message----- > > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen > > Sent: Friday, November 29, 2013 2:50 PM > > To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list > > Cc: Ben Campbell > > Subject: Re: [Dime] DOIC: Self-Contained OLRs > > > > > > > > So, are we reaching any level of consensus here? > > > > - JOuni > > > > (as a note.. that we are converging back to where we started with OLRs ;) > > > > > > > > On Nov 28, 2013, at 12:40 PM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: > > > > Hi, > > > > another question: > > > > If we go for explicit self contained OLRs, why would we then need the ReportType? > > > > The realm-type OLR would explicitly contain application-Id, Realm, but no Host whereas the host-type OLR would explicitly contain application-Id, Host, but probably (I'm not sure) no Realm. > > > > 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 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. > > > > > > _______________________________________________ > > 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. > > > > _______________________________________________ > > 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 > > > > > > _________________________________________________________________________________________________________________________ > > > > 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. > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime --------------050304080301090204000000 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Lionel,

I strongly disagree with your conclusion that there is little support for self-contained OLRs. 

I also object to your assessment that there are strong arguments against self-contained reports.  I have yet to see a single STRONG argument.

I also object to your attempting to call the question at this point in the discussion.

The only arguments I see for the implicit approach is complexity, which I just sent an email refuting and schedule, about which I also just sent an email.

Self contained reports work just as well and has advantages both short term in support for non application specific software layering and in the long term in allowing for the same overload report to be transported using multiple DOC solutions.

I also don't agree that this has been a particularly long thread.  There are multiple topics being discussed under the same subject line.

If we are to pose a question at this point I would suggest -- Can everyone live with self-contained overload reports?

Steve
On 12/5/13 7:28 AM, lionel.morand@orange.com wrote:

All,

 

After this LONG thread, it seems that there are strong arguments against the self-contained OLRs and little support.

In the contrary, it seems that the principle of OLR related to the application in use is technically OK for everyone.

 

So the question is quite simple:

 

Could everyone live/survive with the "implicit approach" with the extensibility mechanism allowing future extensions if needed?

 

If yes, please focus on the finalization of the current draft.

If no, let go on the discussion.

 

Regards,

 

Lionel

 

 

De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoyé : jeudi 5 décembre 2013 14:06
À : dime@ietf.org
Objet : Re: [Dime] DOIC: Self-Contained OLRs

 

On the schedule question mentioned by JJacques -- any schedule concerns can go away if everyone agrees to self contained overload reports.  This discussion would end and we could move on to other things.  :-)

I say that somewhat in jest but please don't make the argument that this discussion should be ended because of schedule.  Or if you make that argument, please don't assert that the person who disagrees with you is putting the schedule at risk.

We are striving for the best technical solution.  We all understand the schedule pressures.  We need to balance the two.

Steve

On 12/5/13 5:14 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:

Hi 
 
A lot of mails on this topic...I would suggest to introduce an overload control on the Dime email threads:)  
 
 
On my side, I rely on what we have written in the  draft for the "baseline" mechanism and that we have to keep as it is simple and efficient, here I join Lionel, Nirav and MCruz' positions.
 
This thread then addresses extensions  cases, I agree that we will have to address such extensions:   Nirav mentioned the example with APN that if relevant would  a 3GGP application case, I would add the Session Group about which we had some discussion a while ago and  which is a more generic IETF case. There is also the agent overload case. Have you others? Always good to have some use cases in mind.
 
What is important for me is that adding extensions should not modify the baseline and making it more complex when used alone.  I also make a difference between principles and protocol tuning where we may have to choose between various protocol solution but addressing the same functionality or principle.  
 
About piggybacking, in the baseline,  the principle is that OLRs  which  are addressed  to sources of traffic are put in answer messages towards this traffic sources (origin Host) (even if these messages  may be processed by intermediate DAs), which is simple and the OLR can be kept unchanged in the same message  up to the origin Host if no specific process in intermediate DAs.  To have a piggybacking allowing to put any OLR in any message (as it was in draft roach)  is adding complexity that is not justified for the baseline and we have not retained it in the existing draft .
 
About extensions, the APN or session group  examples address  parts of the traffic between a server and a client (so a higher granularity in the throttling than the baseline one), related OLRs are conveyed in the messages towards the origin Host so with an implicit reference to the Application, the  Origin and Destination Host as for the baseline, so not requiring self contained OLRs. I also  do not see the interest to send these new extensions OLR only in answers directly related to this OLR (as Ulrich proposed), eg only in an answer dealing with an APN if the OLR is related to APN throttling.  The main point is that the OLR takes a direct "train" towards the right destination for a given application (as for baseline).
 
This does not exclude that we may have other cases not entering the above examples characteristics, but as Nirav mentioned, we  have to remain pragmatic and see this when such new use cases will be addressed. The extensibility possibilities of  current draft give us a lot of flexibility, e.g. if some extensions need more self contained AVPs, why not, but this is outside the current draft. 
 
About extensions, I also think that they may need to be identified in the capability part, as the related OLRs should not be sent by a reacting node if the extension is not supported.
 
Last important point, as  Lionel mentioned, we have to finalize the draft soon, to be able to start Rel12 3GGP work relying on this draft. My position is that the current draft is currently well suited for the baseline and that extensions will be addressed separately  
 
Best regards
 
JJacques 
 
 
-----Message d'origine-----
De : DiME [mailto:dime-bounces@ietf.org] De la part de Ben Campbell
Envoyé : mercredi 4 décembre 2013 22:55
À : ext lionel.morand@orange.com
Cc : dime@ietf.org
Objet : Re: [Dime] DOIC: Self-Contained OLRs
 
On Dec 3, 2013, at 5:17 PM, lionel.morand@orange.com wrote:
 
Hi Ben,
 
I may be wrong somewhere in my summary but I think that it was the result of the discussions and agreements reached regarding existing requirements, at least from 3GPP point of view, compared to possible optimizations for future optimizations not so obvious.
 
We are not the 3GPP. Our requirements are RFC 7068. I believe self-contained OLRs do a better job of meeting Req 31 than the contextually-defined OLRs.
 
I've made several technical arguments here--does anyone have _technical_ arguments in favor of contextually-defined OLRs?
 
And because the solution offers extensibility via the definition of new algo, new report type and addition of any new AVP in the existing Grouped OLR, the "limitations" of the proposed solution might be removed by someone if really required according to new requirements.
 
 
It might be worth considering a compromise approach: Define _optional_ AVPs that allow an OLR to be self-contained. If they are not present, then the various values default to those from the enclosing Diameter message. Possibly add support for this to the list of things that reacting nodes can advertise.
 
This could be in the base, or in a follow on extension. (If left for an extension, it's worth considering whether ReportType needs to be in the base, or this or some other extension.) 
 
 
Regards,
 
Lionel
 
-----Message d'origine-----
De : Ben Campbell [mailto:ben@nostrum.com] Envoyé : mardi 3 décembre 
2013 23:56 À : MORAND Lionel IMT/OLN Cc : Steve Donovan; dime@ietf.org 
Objet : Re: [Dime] DOIC: Self-Contained OLRs
 
 
On Dec 2, 2013, at 10:18 AM, lionel.morand@orange.com wrote:
 
Hi Steve,
 
I think that is not only about few bytes in the answer. It is also about the solution principles agreed so far:
·         the current need is for an OLR bound to the application in use
·         the OLR is received from the node targeted in the request.
·         the OLR is defined per application
 
I don't think those principles have been well tested. I don't recall any discussion of their benefits. What benefits do you see they have over self-contained OLRs?
 
All I see from these are restrictions in the flexibility of the solution, with very little in return.
 
So all the implicit information (application, origin-host, origin-realm) are meaningful in this context.
And the actual solution is designed based on these assumptions. The extensibility of the solution will allow extra info if required in other use cases but it was agreed to go with a straightforward solution that will satisfy most of us.
 
Regards,
 
Lionel
 
De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoyé : lundi 2 décembre 2013 16:37
À : dime@ietf.org
Objet : Re: [Dime] DOIC: Self-Contained OLRs
 
I don't believe that Ben's proposal was to change the piggybacking assumption in the baseline mechanism.  Ben's proposal is to design the solution in such a way that it is not dependent on the piggybacking transport mechanism.  
 
I share Ben's concern that we have over optimized the content of the overload report in a way that makes implementations brittle, interoperability more difficult to achieve and extensibility more complex.  And what do we gain from this optimization?  A few bites in answer messages.
 
Self contained overload reports, transported using the piggybacking mechanism, is a cleaner solution.
 
Steve
 
On 11/29/13 8:31 AM, lionel.morand@orange.com wrote:
I totally agree with Nirav. No need to revert at this stage the working assumption on piggybacking of OLR in application answer messages, especially when the aim is to define a basic mechanism called "reduction".
 
Anyone would be able to further add extra info for optimization if needed but there is no need at all for the basic mechanism.
 
Regards,
 
Lionel
 
-----Message d'origine-----
De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot (nsalot)
Envoyé : vendredi 29 novembre 2013 12:24
À : Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list
Cc : Ben Campbell
Objet : Re: [Dime] DOIC: Self-Contained OLRs
 
Jouni, Ben,
 
I am totally against the idea of self-contained OC-OLR specifically since we have adopted the principles of piggybacking the OC-OLR over existing application message.
Self-contained OC-OLR - which means adding all the information which defines the scope of the OC-OLR into the OC-OLR - does not make sense in the piggybacking approach. In fact, it is adding lot of information, which is anyway available within the message containing the OC-OLR, into the OC-OLR. So it is adding lot of redundant information in a message which increases the processing requirement for the sender as well as the receiver. (And this is un-optimization, in my view).
 
Besides, I am not convinced with the other reasons provided here:
- One software module within a node can provide OC-OLR to another software module in the same node without passing other related info
  Within a node, based on the design, lots of information may need to be passed between two software modules and we cannot optimize those aspects by replicating unnecessary information in a protocol message.
  In summary, it is node's internal software design issue and we need not optimize that at protocol level.
 
- Once the reporting node realizes that it is overloaded, it has to wait for right answer to send OC-OLR
 What is the point of sending OC-OLR for a context for which there is no messaging? Why should the reacting node care if it never sends a message for a context for which the reporting node is overloaded?
 So this waiting is justified since it ensures that the overload is reported only when necessary and only to the applicable reacting node. Not to all the nodes in the network.
 
- The agent needs to wait for the answer generated by the server and the right context
  The same argument as applicable for the server applies here. The agent need not send out-of-context overload info to a node.
  Why should reacting node receive/process/store the overload info for the scope for which it is not sending any messages.
 
- For sending OC-OLR in dedicated Diameter application???
 Piggybacking was the first basic principle we agreed before putting other principles in place. So we may want to go back the drawing board if we decide to change this principle.
 
Regards,
Nirav.
 
-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen
Sent: Friday, November 29, 2013 2:50 PM
To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list
Cc: Ben Campbell
Subject: Re: [Dime] DOIC: Self-Contained OLRs
 
 
 
So, are we reaching any level of consensus here?
 
- JOuni
 
(as a note.. that we are converging back to where we started with OLRs ;)
 
 
 
On Nov 28, 2013, at 12:40 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> wrote:
 
Hi,
 
another question:
 
If we go for explicit self contained OLRs, why would we then need the ReportType?
 
The realm-type OLR would explicitly contain application-Id, Realm, but no Host whereas the host-type OLR would explicitly contain application-Id, Host, but probably (I'm not sure) no Realm.
 
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.
 
 
_______________________________________________
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.
 
_______________________________________________
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
 
 
_________________________________________________________________________________________________________________________
 
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.



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

--------------050304080301090204000000-- From ulrich.wiehe@nsn.com Thu Dec 5 05:56:02 2013 Return-Path: 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 8B8D81ADFA3 for ; Thu, 5 Dec 2013 05:56:02 -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 BLKds5og5Pej for ; Thu, 5 Dec 2013 05:56:01 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id DC01F1ADEB7 for ; Thu, 5 Dec 2013 05:56:00 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rB5Dttrh020233 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 5 Dec 2013 14:55:55 +0100 Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rB5DttBP005294 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 5 Dec 2013 14:55:55 +0100 Received: from DEMUHTC009.nsn-intra.net (10.159.42.40) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 5 Dec 2013 14:55:55 +0100 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.152]) by DEMUHTC009.nsn-intra.net ([10.159.42.40]) with mapi id 14.03.0123.003; Thu, 5 Dec 2013 14:55:54 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: "dime@ietf.org" Thread-Topic: OVLI: comments to 4.2 Thread-Index: Ac7xwbbgyJZ2adciQlahKBe5mrdwfQ== Date: Thu, 5 Dec 2013 13:55:54 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519DAA6@DEMUMBX014.nsn-intra.net> 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: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D90006681519DAA6DEMUMBX014nsnin_" 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: 3394 X-purgate-ID: 151667::1386251756-00002466-0B230171/0-0/0-0 Subject: [Dime] OVLI: comments to 4.2 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 13:56:02 -0000 --_000_5BCBA1FC2B7F0B4C9D935572D90006681519DAA6DEMUMBX014nsnin_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, here are comments to clause 4.2: 1. there is a typo in the first line: "s" should read "is". 2. Supporting OLR_DEFAULT_ALGO means different things depending on the endp= oint's role (reacting/reporting). Proposal is to expand the text to read: When this flag is set by the overload control reacting endpoint it me= ans that the default traffic abatement (loss) algorithm is supported by t= he reacting endpoint, i.e. the reacting endpont is able and willing to e= xecute the default traffic abatement algorithm if so requested by the report= ing endpoint. When this flag is set by the overload control reporting endpoint it m= eans that the reporting endpoint when overloaded is able and willing to de= mand executing the default traffic abatement algorithm from the reacting e= ndpoint. Best regards Ulrich --_000_5BCBA1FC2B7F0B4C9D935572D90006681519DAA6DEMUMBX014nsnin_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear all,
 
here are comments to clause 4.2:
 
1. there is a typo in the first line: "s" should read "= is".
 
2. Supporting OLR_DEFAULT_ALGO means different things depending on the= endpoint’s role (reacting/reporting).
Proposal is to expand the text to read:
 
 
      When this flag is set by the overload c= ontrol reacting endpoint it means
      that the default traffic abatement (los= s) algorithm is supported by the
      reacting endpoi= nt, i.e. the reacting endpont is able and willing to execute
     the default traffic = abatement algorithm if so requested by the reporting
     endpoint.
      When this flag = is set by the overload control reporting endpoint it means
     that the reporting e= ndpoint when overloaded is able and willing to demand
     executing the defaul= t traffic abatement algorithm from the reacting endpoint.
 
Best regards
Ulrich
 
 --_000_5BCBA1FC2B7F0B4C9D935572D90006681519DAA6DEMUMBX014nsnin_-- From nsalot@cisco.com Thu Dec 5 05:59:59 2013 Return-Path: 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 2E6A61AE002 for ; Thu, 5 Dec 2013 05:59:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.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 4EBlXtgKI8vi for ; Thu, 5 Dec 2013 05:59:46 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id B97C11ADF99 for ; Thu, 5 Dec 2013 05:59:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=77822; q=dns/txt; s=iport; t=1386251982; x=1387461582; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=gu3GDKAhREQO7ht8esg+RfPB4ykU+EmNo3j8+Px3kTk=; b=Scx++qmhQ1oOML1dVADcu8aP+T2zWMElIvWqjwdZRfV7Nprt/E+VLo59 /NBzSg7dN8nb+FHiMVm1XbwomhduLU6KXC9vtcGOYIqllA6bIoCWKmzXW UtFpCV3xwoKV386Y0/w7CGmMHeuIyrbYw/pMIzbkKtxPHxbMlJyuNcB+2 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8FAF2GoFKtJV2Y/2dsb2JhbABZgkNEOFO4bYEaFnSCJQEBAQMBAQEBCwwBEjgCBQIGAggHBAIBCA4DAQMBAQsWAQYHJwsUAwYIAgQBEggTh2EGDcFlEwSOHQEQAgEeLQoBBoMagRMDiQqhHYMpgio X-IronPort-AV: E=Sophos;i="4.93,833,1378857600"; d="scan'208,217";a="289534566" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP; 05 Dec 2013 13:59:39 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rB5DxdX6010470 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Dec 2013 13:59:39 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.250]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Thu, 5 Dec 2013 07:59:38 -0600 From: "Nirav Salot (nsalot)" To: Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] DOIC: Self-Contained OLRs Thread-Index: AQHO67/s/vGpiVuf2UayvwQoJbzwfZo6EVYAgACzUoCAAAFygIAAE10AgAF8EQD//7X5YIAAoQmAgATJUQCAAAuBAIACAWkAgAAGHYCAAXsigIAA31sAgAAfFACAAAZLAIAABqcA//+b/CA= Date: Thu, 5 Dec 2013 13:59:38 +0000 Message-ID: References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D90006681519BD31@DEMUMBX014.nsn-intra.net> <47383DC2-1A1B-4D1A-ADD5-9E3CE60B06C8@gmail.com> <8467_1385735507_5298A553_8467_17054_3_6B7134B31289DC4FAF731D844122B36E309D0D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <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> <52A07A1E.5060502@usdonovans.com> <20040_1386250088_52A07F68_20040_916_1_6B7134B31289DC4FAF731D844122B36E32B0E9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52A084FA.7000803@usdonovans.com> In-Reply-To: <52A084FA.7000803@usdonovans.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.234.42] Content-Type: multipart/alternative; boundary="_000_A9CA33BB78081F478946E4F34BF9AAA014D258B1xmbrcdx10ciscoc_" MIME-Version: 1.0 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 13:59:59 -0000 --_000_A9CA33BB78081F478946E4F34BF9AAA014D258B1xmbrcdx10ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Steve, > If we are to pose a question at this point I would suggest -- Can everyon= e live with self-contained overload reports? Strongly NO. I can make the same arguments as you are making - "I have yet to see a sing= le STRONG argument to justify the use of self-contained OC-OLR". All the arguments related to software layering, easy for the developers etc= . are very specific to the implementation and I don't agree to define proto= col solution suitable to a specific architecture. Regards, Nirav. From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: Thursday, December 05, 2013 7:22 PM To: dime@ietf.org Subject: Re: [Dime] DOIC: Self-Contained OLRs Lionel, I strongly disagree with your conclusion that there is little support for s= elf-contained OLRs. I also object to your assessment that there are strong arguments against se= lf-contained reports. I have yet to see a single STRONG argument. I also object to your attempting to call the question at this point in the = discussion. The only arguments I see for the implicit approach is complexity, which I j= ust sent an email refuting and schedule, about which I also just sent an em= ail. Self contained reports work just as well and has advantages both short term= in support for non application specific software layering and in the long = term in allowing for the same overload report to be transported using multi= ple DOC solutions. I also don't agree that this has been a particularly long thread. There ar= e multiple topics being discussed under the same subject line. If we are to pose a question at this point I would suggest -- Can everyone = live with self-contained overload reports? Steve On 12/5/13 7:28 AM, lionel.morand@orange.com wrote: All, After this LONG thread, it seems that there are strong arguments against th= e self-contained OLRs and little support. In the contrary, it seems that the principle of OLR related to the applicat= ion in use is technically OK for everyone. So the question is quite simple: Could everyone live/survive with the "implicit approach" with the extensibi= lity mechanism allowing future extensions if needed? If yes, please focus on the finalization of the current draft. If no, let go on the discussion. Regards, Lionel De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan Envoy=E9 : jeudi 5 d=E9cembre 2013 14:06 =C0 : dime@ietf.org Objet : Re: [Dime] DOIC: Self-Contained OLRs On the schedule question mentioned by JJacques -- any schedule concerns can= go away if everyone agrees to self contained overload reports. This discu= ssion would end and we could move on to other things. :-) I say that somewhat in jest but please don't make the argument that this di= scussion should be ended because of schedule. Or if you make that argument= , please don't assert that the person who disagrees with you is putting the= schedule at risk. We are striving for the best technical solution. We all understand the sch= edule pressures. We need to balance the two. Steve On 12/5/13 5:14 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote: Hi A lot of mails on this topic...I would suggest to introduce an overload con= trol on the Dime email threads:) On my side, I rely on what we have written in the draft for the "baseline"= mechanism and that we have to keep as it is simple and efficient, here I j= oin Lionel, Nirav and MCruz' positions. This thread then addresses extensions cases, I agree that we will have to = address such extensions: Nirav mentioned the example with APN that if rel= evant would a 3GGP application case, I would add the Session Group about w= hich we had some discussion a while ago and which is a more generic IETF c= ase. There is also the agent overload case. Have you others? Always good to= have some use cases in mind. What is important for me is that adding extensions should not modify the ba= seline and making it more complex when used alone. I also make a differenc= e between principles and protocol tuning where we may have to choose betwee= n various protocol solution but addressing the same functionality or princi= ple. About piggybacking, in the baseline, the principle is that OLRs which ar= e addressed to sources of traffic are put in answer messages towards this = traffic sources (origin Host) (even if these messages may be processed by = intermediate DAs), which is simple and the OLR can be kept unchanged in the= same message up to the origin Host if no specific process in intermediate= DAs. To have a piggybacking allowing to put any OLR in any message (as it= was in draft roach) is adding complexity that is not justified for the ba= seline and we have not retained it in the existing draft . About extensions, the APN or session group examples address parts of the = traffic between a server and a client (so a higher granularity in the throt= tling than the baseline one), related OLRs are conveyed in the messages tow= ards the origin Host so with an implicit reference to the Application, the = Origin and Destination Host as for the baseline, so not requiring self con= tained OLRs. I also do not see the interest to send these new extensions O= LR only in answers directly related to this OLR (as Ulrich proposed), eg on= ly in an answer dealing with an APN if the OLR is related to APN throttling= . The main point is that the OLR takes a direct "train" towards the right = destination for a given application (as for baseline). This does not exclude that we may have other cases not entering the above e= xamples characteristics, but as Nirav mentioned, we have to remain pragmat= ic and see this when such new use cases will be addressed. The extensibilit= y possibilities of current draft give us a lot of flexibility, e.g. if som= e extensions need more self contained AVPs, why not, but this is outside th= e current draft. About extensions, I also think that they may need to be identified in the c= apability part, as the related OLRs should not be sent by a reacting node i= f the extension is not supported. Last important point, as Lionel mentioned, we have to finalize the draft s= oon, to be able to start Rel12 3GGP work relying on this draft. My position= is that the current draft is currently well suited for the baseline and th= at extensions will be addressed separately Best regards JJacques -----Message d'origine----- De : DiME [mailto:dime-bounces@ietf.org] De la part de Ben Campbell Envoy=E9 : mercredi 4 d=E9cembre 2013 22:55 =C0 : ext lionel.morand@orange.com Cc : dime@ietf.org Objet : Re: [Dime] DOIC: Self-Contained OLRs On Dec 3, 2013, at 5:17 PM, lionel.morand@orange.com wrote: Hi Ben, I may be wrong somewhere in my summary but I think that it was the result o= f the discussions and agreements reached regarding existing requirements, a= t least from 3GPP point of view, compared to possible optimizations for fut= ure optimizations not so obvious. We are not the 3GPP. Our requirements are RFC 7068. I believe self-containe= d OLRs do a better job of meeting Req 31 than the contextually-defined OLRs= . I've made several technical arguments here--does anyone have _technical_ ar= guments in favor of contextually-defined OLRs? And because the solution offers extensibility via the definition of new alg= o, new report type and addition of any new AVP in the existing Grouped OLR,= the "limitations" of the proposed solution might be removed by someone if = really required according to new requirements. It might be worth considering a compromise approach: Define _optional_ AVPs= that allow an OLR to be self-contained. If they are not present, then the = various values default to those from the enclosing Diameter message. Possib= ly add support for this to the list of things that reacting nodes can adver= tise. This could be in the base, or in a follow on extension. (If left for an ext= ension, it's worth considering whether ReportType needs to be in the base, = or this or some other extension.) Regards, Lionel -----Message d'origine----- De : Ben Campbell [mailto:ben@nostrum.com] Envoy=E9 : mardi 3 d=E9cembre 2013 23:56 =C0 : MORAND Lionel IMT/OLN Cc : Steve Donovan; dime@ietf.org Objet : Re: [Dime] DOIC: Self-Contained OLRs On Dec 2, 2013, at 10:18 AM, lionel.morand@orange.com wrote: Hi Steve, I think that is not only about few bytes in the answer. It is also about th= e solution principles agreed so far: =B7 the current need is for an OLR bound to the application in use =B7 the OLR is received from the node targeted in the request. =B7 the OLR is defined per application I don't think those principles have been well tested. I don't recall any di= scussion of their benefits. What benefits do you see they have over self-co= ntained OLRs? All I see from these are restrictions in the flexibility of the solution, w= ith very little in return. So all the implicit information (application, origin-host, origin-realm) ar= e meaningful in this context. And the actual solution is designed based on these assumptions. The extensi= bility of the solution will allow extra info if required in other use cases= but it was agreed to go with a straightforward solution that will satisfy = most of us. Regards, Lionel De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan Envoy=E9 : lundi 2 d=E9cembre 2013 16:37 =C0 : dime@ietf.org Objet : Re: [Dime] DOIC: Self-Contained OLRs I don't believe that Ben's proposal was to change the piggybacking assumpti= on in the baseline mechanism. Ben's proposal is to design the solution in = such a way that it is not dependent on the piggybacking transport mechanism= . I share Ben's concern that we have over optimized the content of the overlo= ad report in a way that makes implementations brittle, interoperability mor= e difficult to achieve and extensibility more complex. And what do we gain= from this optimization? A few bites in answer messages. Self contained overload reports, transported using the piggybacking mechani= sm, is a cleaner solution. Steve On 11/29/13 8:31 AM, lionel.morand@orange.com wrote: I totally agree with Nirav. No need to revert at this stage the working ass= umption on piggybacking of OLR in application answer messages, especially w= hen the aim is to define a basic mechanism called "reduction". Anyone would be able to further add extra info for optimization if needed b= ut there is no need at all for the basic mechanism. Regards, Lionel -----Message d'origine----- De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot (nsalot) Envoy=E9 : vendredi 29 novembre 2013 12:24 =C0 : Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list Cc : Ben Campbell Objet : Re: [Dime] DOIC: Self-Contained OLRs Jouni, Ben, I am totally against the idea of self-contained OC-OLR specifically since w= e have adopted the principles of piggybacking the OC-OLR over existing appl= ication message. Self-contained OC-OLR - which means adding all the information which define= s the scope of the OC-OLR into the OC-OLR - does not make sense in the pigg= ybacking approach. In fact, it is adding lot of information, which is anywa= y available within the message containing the OC-OLR, into the OC-OLR. So i= t is adding lot of redundant information in a message which increases the p= rocessing requirement for the sender as well as the receiver. (And this is = un-optimization, in my view). Besides, I am not convinced with the other reasons provided here: - One software module within a node can provide OC-OLR to another software = module in the same node without passing other related info Within a node, based on the design, lots of information may need to be pa= ssed between two software modules and we cannot optimize those aspects by r= eplicating unnecessary information in a protocol message. In summary, it is node's internal software design issue and we need not o= ptimize that at protocol level. - Once the reporting node realizes that it is overloaded, it has to wait fo= r right answer to send OC-OLR What is the point of sending OC-OLR for a context for which there is no me= ssaging? Why should the reacting node care if it never sends a message for = a context for which the reporting node is overloaded? So this waiting is justified since it ensures that the overload is reporte= d only when necessary and only to the applicable reacting node. Not to all = the nodes in the network. - The agent needs to wait for the answer generated by the server and the ri= ght context The same argument as applicable for the server applies here. The agent ne= ed not send out-of-context overload info to a node. Why should reacting node receive/process/store the overload info for the = scope for which it is not sending any messages. - For sending OC-OLR in dedicated Diameter application??? Piggybacking was the first basic principle we agreed before putting other = principles in place. So we may want to go back the drawing board if we deci= de to change this principle. Regards, Nirav. -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen Sent: Friday, November 29, 2013 2:50 PM To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org li= st Cc: Ben Campbell Subject: Re: [Dime] DOIC: Self-Contained OLRs So, are we reaching any level of consensus here? - JOuni (as a note.. that we are converging back to where we started with OLRs ;) On Nov 28, 2013, at 12:40 PM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: Hi, another question: If we go for explicit self contained OLRs, why would we then need the Repor= tType? The realm-type OLR would explicitly contain application-Id, Realm, but no H= ost whereas the host-type OLR would explicitly contain application-Id, Host= , but probably (I'm not sure) no Realm. 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 stat= us. It could be provided an agent inserting this info in answers received f= rom a server behind but also from a server that would know this info by som= e internal magic. But in any case, if we assume that the client will received a successful an= swer from the server for an initial request with only Dest-Realm AVP, it sh= ould be possible to have both report types in the answer: one for the serve= r itself, one for the realm for new request sent to the realm with only Des= t-Realm AVP. Lionel -----Message d'origine----- De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN - DE/Munich) Envoy=E9 : jeudi 28 novembre 2013 10:26 =C0 : 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 a= ligned with the "endpoint principle". If the ReportType is "realm" this ind= icates 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 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 re= acting 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 Diamet= er request that corresponds to the answer containing the OLR. My reasons fo= r 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 i= dentified by Origin-Realm, and so on. This means that the "meaning" of an O= LR 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 answe= r to another, it's meaning may change completely. I think this approach is a mistake. I would greatly prefer that we explicit= ly 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 variou= s other AVPs to find all the information it needs. For example, I think a c= ommon software design for overload control processing to be separated from = application processing. The consumer cannot simply hand the OLR to that mod= ule and expect things to work. The OC module must not only parse the OLR, b= ut parse any other AVPs that are relevant. As OLR contents get extended (as= sumedly following the same strategy as the base spec), the number of "conte= xt" avps that must be interpreted can grow large. This approach is error pr= one, and will likely encourage brittle, hard-to-maintain code. Self-contain= ed OLRs would keep all the information related to overload in one place. ma= king for simpler implementations. 2) It's more complex for the reporting node to send implicit values than ex= plicit values. The sender cannot simply set the context to match the OLR--a= ll those other AVPs have application or protocol layer meanings. Once a rep= orting node realizes that it is overloade, it has to wait for the right ans= wer that contains the right context before it can send the OLR. This is par= ticularly 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 sig= nificantly. 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 so= me 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 overlo= ad reports were self-contained, one could just reuse the report format we s= pecify here. But if the meaning of an OLR depends on the way it's transport= ed, this won't work. We would have to create a new or significantly modifie= d OLR format if we found a need to transport OLRs in different ways. Self-c= ontained OLRs would allow much greater flexibility. So, in summary, I think that self-contained OLRs would lead to simpler impl= ementations, less brittle deployments, and more flexibility for future evol= ution 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 le= s pieces jointes. Les messages electroniques etant susceptibles d'alteratio= n, 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 dis= tributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te 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 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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 confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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 confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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 confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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 --_000_A9CA33BB78081F478946E4F34BF9AAA014D258B1xmbrcdx10ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Steve,<= /p>

 <= /p>

> If we are to = pose a question at this point I would suggest -- Can everyone live with sel= f-contained overload reports?<= /p>

Strongly NO.

 <= /p>

I can make the same argum= ents as you are making – "I have yet to see a single STRONG argu= ment to justify the use of self-contained OC-OLR".

 <= /p>

All the arguments related= to software layering, easy for the developers etc. are very specific to th= e implementation and I don’t agree to define protocol solution suitable to a specific architecture.

 <= /p>

Regards,

Nirav.<= /p>

 <= /p>

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: Thursday, December 05, 2013 7:22 PM
To: dime@ietf.org
Subject: Re: [Dime] DOIC: Self-Contained OLRs

 

Lionel,

I strongly disagree with your conclusion that there is little support for s= elf-contained OLRs. 

I also object to your assessment that there are strong arguments against se= lf-contained reports.  I have yet to see a single STRONG argument.

I also object to your attempting to call the question at this point in the = discussion.

The only arguments I see for the implicit approach is complexity, which I j= ust sent an email refuting and schedule, about which I also just sent an em= ail.

Self contained reports work just as well and has advantages both short term= in support for non application specific software layering and in the long = term in allowing for the same overload report to be transported using multi= ple DOC solutions.

I also don't agree that this has been a particularly long thread.  The= re are multiple topics being discussed under the same subject line.

If we are to pose a question at this point I would suggest -- Can everyone = live with self-contained overload reports?

Steve

On 12/5/13 7:28 AM, lionel.morand@orange.com wrote:

All,

 <= /p>

After this LONG thread, i= t seems that there are strong arguments against the self-contained OLRs and= little support.

In the contrary, it seems= that the principle of OLR related to the application in use is technically= OK for everyone.

 <= /p>

So the question is quite = simple:

 <= /p>

Could everyone live/survi= ve with the "implicit approach" with the extensibility mechanism = allowing future extensions if needed?

 <= /p>

If yes, please focus on t= he finalization of the current draft.

If no, let go on the disc= ussion.

 <= /p>

Regards,

 <= /p>

Lionel<= /p>

 <= /p>

 <= /p>

De := DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9 : jeudi 5 d=E9cembre 2013 14:06
=C0 : dime@ietf.org
Objet : Re: [Dime] DOIC: Self-Contained OLRs<= /p>

 

On the schedule quest= ion mentioned by JJacques -- any schedule concerns can go away if everyone = agrees to self contained overload reports.  This discussion would end = and we could move on to other things.  :-)

I say that somewhat in jest but please don't make the argument that this di= scussion should be ended because of schedule.  Or if you make that arg= ument, please don't assert that the person who disagrees with you is puttin= g the schedule at risk.

We are striving for the best technical solution.  We all understand th= e schedule pressures.  We need to balance the two.

Steve

On 12/5/13 5:14 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQ= UES) wrote:

Hi 
 
A lot of mails on this topic...I would suggest to introduce an overloa=
d control on the Dime email threads:)  
 
 
On my side, I rely on what we have written in the  draft for the =
"baseline" mechanism and that we have to keep as it is simple and=
 efficient, here I join Lionel, Nirav and MCruz' positions.

 


This thread then addresses extensions  cases, I agree that we wil=
l have to address such extensions:   Nirav mentioned the example =
with APN that if relevant would  a 3GGP application case, I would add =
the Session Group about which we had some discussion a while ago and  =
which is a more generic IETF case. There is also the agent overload case. H=
ave you others? Always good to have some use cases in mind.

 


What is important for me is that adding extensions should not modify t=
he baseline and making it more complex when used alone.  I also make a=
 difference between principles and protocol tuning where we may have to cho=
ose between various protocol solution but addressing the same functionality=
 or principle.  


 


About piggybacking, in the baseline,  the principle is that OLRs&=
nbsp; which  are addressed  to sources of traffic are put in answ=
er messages towards this traffic sources (origin Host) (even if these messa=
ges  may be processed by intermediate DAs), which is simple and the OL=
R can be kept unchanged in the same message  up to the origin Host if =
no specific process in intermediate DAs.  To have a piggybacking allow=
ing to put any OLR in any message (as it was in draft roach)  is addin=
g complexity that is not justified for the baseline and we have not retaine=
d it in the existing draft .


 


About extensions, the APN or session group  examples address =
; parts of the traffic between a server and a client (so a higher granulari=
ty in the throttling than the baseline one), related OLRs are conveyed in t=
he messages towards the origin Host so with an implicit reference to the Ap=
plication, the  Origin and Destination Host as for the baseline, so no=
t requiring self contained OLRs. I also  do not see the interest to se=
nd these new extensions OLR only in answers directly related to this OLR (a=
s Ulrich proposed), eg only in an answer dealing with an APN if the OLR is =
related to APN throttling.  The main point is that the OLR takes a dir=
ect "train" towards the right destination for a given application=
 (as for baseline).


 


This does not exclude that we may have other cases not entering the ab=
ove examples characteristics, but as Nirav mentioned, we  have to rema=
in pragmatic and see this when such new use cases will be addressed. The ex=
tensibility possibilities of  current draft give us a lot of flexibili=
ty, e.g. if some extensions need more self contained AVPs, why not, but thi=
s is outside the current draft. 


 


About extensions, I also think that they may need to be identified in =
the capability part, as the related OLRs should not be sent by a reacting n=
ode if the extension is not supported.


 


Last important point, as  Lionel mentioned, we have to finalize t=
he draft soon, to be able to start Rel12 3GGP work relying on this draft. M=
y position is that the current draft is currently well suited for the basel=
ine and that extensions will be addressed separately  

 


Best regards


 


JJacques 


 


 


-----Message d'origine-----


De : DiME [mailto:dime-b=
ounces@ietf.org] De la part de Ben Campbell


Envoy=E9 : mercredi 4 d=E9cembre 2013 22:55


=C0 : ext lionel.mora=
nd@orange.com


Cc : dime@ietf.org


Objet : Re: [Dime] DOIC: Self-Contained OLRs


 


On Dec 3, 2013, at 5:17 PM, lionel.morand@orange.com wrote:


 




Hi Ben,


 


I may be wrong somewhere in my summary but I think that it was the res=
ult of the discussions and agreements reached regarding existing requiremen=
ts, at least from 3GPP point of view, compared to possible optimizations fo=
r future optimizations not so obvious.




 


We are not the 3GPP. Our requirements are RFC 7068. I believe self-con=
tained OLRs do a better job of meeting Req 31 than the contextually-defined=
 OLRs.


 


I've made several technical arguments here--does anyone have _technica=
l_ arguments in favor of contextually-defined OLRs?


 




And because the solution offers extensibility via the definition of ne=
w algo, new report type and addition of any new AVP in the existing Grouped=
 OLR, the "limitations" of the proposed solution might be removed=
 by someone if really required according to new requirements.

 




 


It might be worth considering a compromise approach: Define _optional_=
 AVPs that allow an OLR to be self-contained. If they are not present, then=
 the various values default to those from the enclosing Diameter message. P=
ossibly add support for this to the list of things that reacting nodes can =
advertise.


 


This could be in the base, or in a follow on extension. (If left for a=
n extension, it's worth considering whether ReportType needs to be in the b=
ase, or this or some other extension.) 


 


 




Regards,


 


Lionel


 


-----Message d'origine-----


De : Ben Campbell [mailto:ben@nostr=
um.com] Envoy=E9 : mardi 3 d=E9cembre 


2013 23:56 =C0 : MORAND Lionel IMT/OLN Cc : Steve Donovan; dime@ietf.org 


Objet : Re: [Dime] DOIC: Self-Contained OLRs


 


 


On Dec 2, 2013, at 10:18 AM, lionel.morand@orange.com wrote:


 




Hi Steve,


 


I think that is not only about few bytes in the answer. It is also abo=
ut the solution principles agreed so far:


=B7         the current need i=
s for an OLR bound to the application in use


=B7         the OLR is receive=
d from the node targeted in the request.


=B7         the OLR is defined=
 per application




 


I don't think those principles have been well tested. I don't recall a=
ny discussion of their benefits. What benefits do you see they have over se=
lf-contained OLRs?


 


All I see from these are restrictions in the flexibility of the soluti=
on, with very little in return.


 




So all the implicit information (application, origin-host, origin-real=
m) are meaningful in this context.


And the actual solution is designed based on these assumptions. The ex=
tensibility of the solution will allow extra info if required in other use =
cases but it was agreed to go with a straightforward solution that will sat=
isfy most of us.


 


Regards,


 


Lionel


 


De : DiME [mailto:dime-bounce=
s@ietf.org] De la part de Steve Donovan


Envoy=E9 : lundi 2 d=E9cembre 2013 16:37


=C0 : dime@ietf.org

Objet : Re: [Dime] DOIC: Self-Contained OLRs


 


I don't believe that Ben's proposal was to change the piggybacking ass=
umption in the baseline mechanism.  Ben's proposal is to design the so=
lution in such a way that it is not dependent on the piggybacking transport=
 mechanism.  


 


I share Ben's concern that we have over optimized the content of the o=
verload report in a way that makes implementations brittle, interoperabilit=
y more difficult to achieve and extensibility more complex.  And what =
do we gain from this optimization?  A few bites in answer messages.


 


Self contained overload reports, transported using the piggybacking me=
chanism, is a cleaner solution.


 


Steve


 


On 11/29/13 8:31 AM, lione=
l.morand@orange.com wrote:


I totally agree with Nirav. No need to revert at this stage the workin=
g assumption on piggybacking of OLR in application answer messages, especia=
lly when the aim is to define a basic mechanism called "reduction"=
;.


 


Anyone would be able to further add extra info for optimization if nee=
ded but there is no need at all for the basic mechanism.


 


Regards,


 


Lionel


 


-----Message d'origine-----


De : DiME [mailto:dime-bounce=
s@ietf.org] De la part de Nirav Salot (nsalot)


Envoy=E9 : vendredi 29 novembre 2013 12:24


=C0 : Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list


Cc : Ben Campbell


Objet : Re: [Dime] DOIC: Self-Contained OLRs


 


Jouni, Ben,


 


I am totally against the idea of self-contained OC-OLR specifically si=
nce we have adopted the principles of piggybacking the OC-OLR over existing=
 application message.


Self-contained OC-OLR - which means adding all the information which d=
efines the scope of the OC-OLR into the OC-OLR - does not make sense in the=
 piggybacking approach. In fact, it is adding lot of information, which is =
anyway available within the message containing the OC-OLR, into the OC-OLR.=
 So it is adding lot of redundant information in a message which increases =
the processing requirement for the sender as well as the receiver. (And thi=
s is un-optimization, in my view).


 


Besides, I am not convinced with the other reasons provided here:=



- One software module within a node can provide OC-OLR to another soft=
ware module in the same node without passing other related info<=
/pre>

  Within a node, based on the design, lots of information may nee=
d to be passed between two software modules and we cannot optimize those as=
pects by replicating unnecessary information in a protocol message.


  In summary, it is node's internal software design issue and we =
need not optimize that at protocol level.


 


- Once the reporting node realizes that it is overloaded, it has to wa=
it for right answer to send OC-OLR


 What is the point of sending OC-OLR for a context for which there is =
no messaging? Why should the reacting node care if it never sends a message=
 for a context for which the reporting node is overloaded?


 So this waiting is justified since it ensures that the overload is re=
ported only when necessary and only to the applicable reacting node. Not to=
 all the nodes in the network.


 


- The agent needs to wait for the answer generated by the server and t=
he right context


  The same argument as applicable for the server applies here. Th=
e agent need not send out-of-context overload info to a node.

  Why should reacting node receive/process/store the overload inf=
o for the scope for which it is not sending any messages.


 


- For sending OC-OLR in dedicated Diameter application???

 Piggybacking was the first basic principle we agreed before putting o=
ther principles in place. So we may want to go back the drawing board if we=
 decide to change this principle.


 


Regards,


Nirav.


 


-----Original Message-----


From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of Jouni Korhonen


Sent: Friday, November 29, 2013 2:50 PM


To: Wiehe, Ulrich (NSN - DE/Munich); =
dime@ietf.org list


Cc: Ben Campbell


Subject: Re: [Dime] DOIC: Self-Contained OLRs


 


 


 


So, are we reaching any level of consensus here?


 


- JOuni


 


(as a note.. that we are converging back to where we started with OLRs=
 ;)


 


 


 


On Nov 28, 2013, at 12:40 PM, "Wiehe, Ulrich (NSN - DE/Munich)&qu=
ot; <ulrich.wiehe@nsn.com> wrote:


 


Hi,


 


another question:


 


If we go for explicit self contained OLRs, why would we then need the =
ReportType?


 


The realm-type OLR would explicitly contain application-Id, Realm, but=
 no Host whereas the host-type OLR would explicitly contain application-Id,=
 Host, but probably (I'm not sure) no Realm.


 


Ulrich


 


 


 


-----Original Message-----


From: ext lionel.morand@or=
ange.com [mailto:lionel.mor=
and@orange.com]


Sent: Thursday, November 28, 2013 10:31 AM


To: Wiehe, Ulrich (NSN - DE/Munich); ext Jouni Korhonen; Ben Campbell<=
o:p>


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 recei=
ved from a server behind but also from a server that would know this info b=
y some internal magic.


But in any case, if we assume that the client will received a successf=
ul 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 onl=
y Dest-Realm AVP.


 


Lionel


 


-----Message d'origine-----


De : DiME [mailto:dime-bounce=
s@ietf.org] De la part de Wiehe, Ulrich 


(NSN - DE/Munich) Envoy=E9 : jeudi 28 novembre 2013 10:26 =C0 : ext Jo=
uni 


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 &=
quot;realm" this indicates to the reacting end point that the reportin=
g 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 repor=
ting end point is a server. How can the reporting end point be both agent a=
nd server?


 


Ulrich


 


-----Original Message-----


From: DiME [mailto:dime-bounc=
es@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 <=
/o:p>


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 t=
he 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 D=
iameter request that corresponds to the answer containing the OLR. My reaso=
ns 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 applica=
tion identified by the Application-Id field of the enclosing answer, the re=
alm identified by Origin-Realm, and so on. This means that the "meanin=
g" of an OLR cannot be determined from the OLR contents alone; OLRs on=
ly 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 exp=
licitly include such values in the OLR itself, for multiple reasons:


 


1) It's more complex to interpret implicit, contextual values than exp=
licit values. The consumer cannot simply look at the OLR; it must look in v=
arious other AVPs to find all the information it needs. For example, I thin=
k a common software design for overload control processing to be separated =
from application processing. The consumer cannot simply hand the OLR to tha=
t module and expect things to work. The OC module must not only parse the O=
LR, but parse any other AVPs that are relevant. As OLR contents get extende=
d (assumedly following the same strategy as the base spec), the number of &=
quot;context" avps that must be interpreted can grow large. This appro=
ach is error prone, and will likely encourage brittle, hard-to-maintain cod=
e. Self-contained OLRs would keep all the information related to overload i=
n one place. making for simpler implementations.


 


2) It's more complex for the reporting node to send implicit values th=
an explicit values. The sender cannot simply set the context to match the O=
LR--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 righ=
t answer that contains the right context before it can send the OLR. This i=
s particularly troublesome for agents, since they will typically have to in=
sert OLRs into answers created by other nodes. 


 


If the reporting node screws this up, the meaning of the OLR may chang=
e significantly. So again, implicit meaning gives us error prone implementa=
tions. 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 <=
o:p>


are distinct from those sent by a server, see Steve's agent overload <=
o:p>


draft, or my dh/dr example.)


 


OTOH, explicit values will work for all cases where we need to associa=
te some arbitrary value with an OLR.


 


4) Implicit values seriously constrain the future evolution of Diamete=
r OC standards. For example, lets say we find a good reason to allow OLRs t=
o be sent out of band, or be sent in a dedicated Diameter application. If o=
verload 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 tran=
sported, this won't work. We would have to create a new or significantly mo=
dified OLR format if we found a need to transport OLRs in different ways. S=
elf-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.iet=
f.org/mailman/listinfo/dime


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.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 q=
ue les pieces jointes. Les messages electroniques etant susceptibles d'alte=
ration, Orange decline toute responsabilite si ce message a ete altere, def=
orme ou falsifie. Merci.


 


This message and its attachments may contain confidential or 


privileged information that may be protected by law; they should not b=
e 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.iet=
f.org/mailman/listinfo/dime


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 


______________________________________________________________________=
___________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


 


This message and its attachments may contain confidential or privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
o:p>


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.iet=
f.org/mailman/listinfo/dime


 


 


______________________________________________________________________=
___________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


 


This message and its attachments may contain confidential or privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
o:p>


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.iet=
f.org/mailman/listinfo/dime




 


 


______________________________________________________________________=
___________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


 


This message and its attachments may contain confidential or privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
o:p>


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.iet=
f.org/mailman/listinfo/dime




 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 

 

______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
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.iet=
f.org/mailman/listinfo/dime

 

--_000_A9CA33BB78081F478946E4F34BF9AAA014D258B1xmbrcdx10ciscoc_-- From lionel.morand@orange.com Thu Dec 5 06:01:28 2013 Return-Path: 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 086FD1ADFA3 for ; Thu, 5 Dec 2013 06:01:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 GSU5L2Bn382g for ; Thu, 5 Dec 2013 06:01:14 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by ietfa.amsl.com (Postfix) with ESMTP id C86351ADF99 for ; Thu, 5 Dec 2013 06:01:13 -0800 (PST) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id 8B8931B84EF for ; Thu, 5 Dec 2013 15:01:09 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 75E88384084 for ; Thu, 5 Dec 2013 15:01:09 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0158.001; Thu, 5 Dec 2013 15:01:09 +0100 From: To: "dime@ietf.org" Thread-Topic: [Dime] DOIC: Self-Contained OLRs Thread-Index: AQHO67/uo7y6FFeeaEmQ38aKczpYQJo5m/0AgACzUoCAAAFygIAAE14AgAF8EACAACKcAIAANGaAgATJUgCAAAuAAIACAWkAgAAGHYCAAXsigIAAykrggAA0JQCAABEyAP//+8AAgAARKuA= Date: Thu, 5 Dec 2013 14:01:08 +0000 Message-ID: <15604_1386252069_52A08725_15604_17630_1_6B7134B31289DC4FAF731D844122B36E32B265@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D90006681519BD31@DEMUMBX014.nsn-intra.net> <47383DC2-1A1B-4D1A-ADD5-9E3CE60B06C8@gmail.com> <8467_1385735507_5298A553_8467_17054_3_6B7134B31289DC4FAF731D844122B36E309D0D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <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> <52A07A1E.5060502@usdonovans.com> <20040_1386250088_52A07F68_20040_916_1_6B7134B31289DC4FAF731D844122B36E32B0E9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52A084FA.7000803@usdonovans.com> In-Reply-To: <52A084FA.7000803@usdonovans.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.5] Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E32B265PEXCVZYM13corpora_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.12.5.100914 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 14:01:28 -0000 --_000_6B7134B31289DC4FAF731D844122B36E32B265PEXCVZYM13corpora_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Steve, So let's go on the discussion. As individual below... De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan Envoy=E9 : jeudi 5 d=E9cembre 2013 14:52 =C0 : dime@ietf.org Objet : Re: [Dime] DOIC: Self-Contained OLRs Lionel, I strongly disagree with your conclusion that there is little support for s= elf-contained OLRs. [LM] could you point which one? I also object to your assessment that there are strong arguments against se= lf-contained reports. I have yet to see a single STRONG argument. [LM] wrong. The right sentence should be that you don't consider comments a= gainst your proposal as valid. I also object to your attempting to call the question at this point in the = discussion. [LM] just an attempt to see if we could come to a agreement based on my dis= torted summary The only arguments I see for the implicit approach is complexity, which I j= ust sent an email refuting and schedule, about which I also just sent an em= ail. Self contained reports work just as well and has advantages both short term= in support for non application specific software layering and in the long = term in allowing for the same overload report to be transported using multi= ple DOC solutions. I also don't agree that this has been a particularly long thread. There ar= e multiple topics being discussed under the same subject line. [LM] this topic is discussed fro several months, at least one year. I was n= ot referring to the current title. If we are to pose a question at this point I would suggest -- Can everyone = live with self-contained overload reports? [LM] and I would say "NO" Steve On 12/5/13 7:28 AM, lionel.morand@orange.com wrote: All, After this LONG thread, it seems that there are strong arguments against th= e self-contained OLRs and little support. In the contrary, it seems that the principle of OLR related to the applicat= ion in use is technically OK for everyone. So the question is quite simple: Could everyone live/survive with the "implicit approach" with the extensibi= lity mechanism allowing future extensions if needed? If yes, please focus on the finalization of the current draft. If no, let go on the discussion. Regards, Lionel De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan Envoy=E9 : jeudi 5 d=E9cembre 2013 14:06 =C0 : dime@ietf.org Objet : Re: [Dime] DOIC: Self-Contained OLRs On the schedule question mentioned by JJacques -- any schedule concerns can= go away if everyone agrees to self contained overload reports. This discu= ssion would end and we could move on to other things. :-) I say that somewhat in jest but please don't make the argument that this di= scussion should be ended because of schedule. Or if you make that argument= , please don't assert that the person who disagrees with you is putting the= schedule at risk. We are striving for the best technical solution. We all understand the sch= edule pressures. We need to balance the two. Steve On 12/5/13 5:14 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote: Hi A lot of mails on this topic...I would suggest to introduce an overload con= trol on the Dime email threads:) On my side, I rely on what we have written in the draft for the "baseline"= mechanism and that we have to keep as it is simple and efficient, here I j= oin Lionel, Nirav and MCruz' positions. This thread then addresses extensions cases, I agree that we will have to = address such extensions: Nirav mentioned the example with APN that if rel= evant would a 3GGP application case, I would add the Session Group about w= hich we had some discussion a while ago and which is a more generic IETF c= ase. There is also the agent overload case. Have you others? Always good to= have some use cases in mind. What is important for me is that adding extensions should not modify the ba= seline and making it more complex when used alone. I also make a differenc= e between principles and protocol tuning where we may have to choose betwee= n various protocol solution but addressing the same functionality or princi= ple. About piggybacking, in the baseline, the principle is that OLRs which ar= e addressed to sources of traffic are put in answer messages towards this = traffic sources (origin Host) (even if these messages may be processed by = intermediate DAs), which is simple and the OLR can be kept unchanged in the= same message up to the origin Host if no specific process in intermediate= DAs. To have a piggybacking allowing to put any OLR in any message (as it= was in draft roach) is adding complexity that is not justified for the ba= seline and we have not retained it in the existing draft . About extensions, the APN or session group examples address parts of the = traffic between a server and a client (so a higher granularity in the throt= tling than the baseline one), related OLRs are conveyed in the messages tow= ards the origin Host so with an implicit reference to the Application, the = Origin and Destination Host as for the baseline, so not requiring self con= tained OLRs. I also do not see the interest to send these new extensions O= LR only in answers directly related to this OLR (as Ulrich proposed), eg on= ly in an answer dealing with an APN if the OLR is related to APN throttling= . The main point is that the OLR takes a direct "train" towards the right = destination for a given application (as for baseline). This does not exclude that we may have other cases not entering the above e= xamples characteristics, but as Nirav mentioned, we have to remain pragmat= ic and see this when such new use cases will be addressed. The extensibilit= y possibilities of current draft give us a lot of flexibility, e.g. if som= e extensions need more self contained AVPs, why not, but this is outside th= e current draft. About extensions, I also think that they may need to be identified in the c= apability part, as the related OLRs should not be sent by a reacting node i= f the extension is not supported. Last important point, as Lionel mentioned, we have to finalize the draft s= oon, to be able to start Rel12 3GGP work relying on this draft. My position= is that the current draft is currently well suited for the baseline and th= at extensions will be addressed separately Best regards JJacques -----Message d'origine----- De : DiME [mailto:dime-bounces@ietf.org] De la part de Ben Campbell Envoy=E9 : mercredi 4 d=E9cembre 2013 22:55 =C0 : ext lionel.morand@orange.com Cc : dime@ietf.org Objet : Re: [Dime] DOIC: Self-Contained OLRs On Dec 3, 2013, at 5:17 PM, lionel.morand@orange.com wrote: Hi Ben, I may be wrong somewhere in my summary but I think that it was the result o= f the discussions and agreements reached regarding existing requirements, a= t least from 3GPP point of view, compared to possible optimizations for fut= ure optimizations not so obvious. We are not the 3GPP. Our requirements are RFC 7068. I believe self-containe= d OLRs do a better job of meeting Req 31 than the contextually-defined OLRs. I've made several technical arguments here--does anyone have _technical_ ar= guments in favor of contextually-defined OLRs? And because the solution offers extensibility via the definition of new alg= o, new report type and addition of any new AVP in the existing Grouped OLR,= the "limitations" of the proposed solution might be removed by someone if = really required according to new requirements. It might be worth considering a compromise approach: Define _optional_ AVPs= that allow an OLR to be self-contained. If they are not present, then the = various values default to those from the enclosing Diameter message. Possib= ly add support for this to the list of things that reacting nodes can adver= tise. This could be in the base, or in a follow on extension. (If left for an ext= ension, it's worth considering whether ReportType needs to be in the base, = or this or some other extension.) Regards, Lionel -----Message d'origine----- De : Ben Campbell [mailto:ben@nostrum.com] Envoy=E9 : mardi 3 d=E9cembre 2013 23:56 =C0 : MORAND Lionel IMT/OLN Cc : Steve Donovan; dime@ietf.org Objet : Re: [Dime] DOIC: Self-Contained OLRs On Dec 2, 2013, at 10:18 AM, lionel.morand@orange.com wrote: Hi Steve, I think that is not only about few bytes in the answer. It is also about th= e solution principles agreed so far: =B7 the current need is for an OLR bound to the application in use =B7 the OLR is received from the node targeted in the request. =B7 the OLR is defined per application I don't think those principles have been well tested. I don't recall any di= scussion of their benefits. What benefits do you see they have over self-co= ntained OLRs? All I see from these are restrictions in the flexibility of the solution, w= ith very little in return. So all the implicit information (application, origin-host, origin-realm) ar= e meaningful in this context. And the actual solution is designed based on these assumptions. The extensi= bility of the solution will allow extra info if required in other use cases= but it was agreed to go with a straightforward solution that will satisfy = most of us. Regards, Lionel De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan Envoy=E9 : lundi 2 d=E9cembre 2013 16:37 =C0 : dime@ietf.org Objet : Re: [Dime] DOIC: Self-Contained OLRs I don't believe that Ben's proposal was to change the piggybacking assumpti= on in the baseline mechanism. Ben's proposal is to design the solution in = such a way that it is not dependent on the piggybacking transport mechanism. I share Ben's concern that we have over optimized the content of the overlo= ad report in a way that makes implementations brittle, interoperability mor= e difficult to achieve and extensibility more complex. And what do we gain= from this optimization? A few bites in answer messages. Self contained overload reports, transported using the piggybacking mechani= sm, is a cleaner solution. Steve On 11/29/13 8:31 AM, lionel.morand@orange.com wrote: I totally agree with Nirav. No need to revert at this stage the working ass= umption on piggybacking of OLR in application answer messages, especially w= hen the aim is to define a basic mechanism called "reduction". Anyone would be able to further add extra info for optimization if needed b= ut there is no need at all for the basic mechanism. Regards, Lionel -----Message d'origine----- De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot (nsalot) Envoy=E9 : vendredi 29 novembre 2013 12:24 =C0 : Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list Cc : Ben Campbell Objet : Re: [Dime] DOIC: Self-Contained OLRs Jouni, Ben, I am totally against the idea of self-contained OC-OLR specifically since w= e have adopted the principles of piggybacking the OC-OLR over existing appl= ication message. Self-contained OC-OLR - which means adding all the information which define= s the scope of the OC-OLR into the OC-OLR - does not make sense in the pigg= ybacking approach. In fact, it is adding lot of information, which is anywa= y available within the message containing the OC-OLR, into the OC-OLR. So i= t is adding lot of redundant information in a message which increases the p= rocessing requirement for the sender as well as the receiver. (And this is = un-optimization, in my view). Besides, I am not convinced with the other reasons provided here: - One software module within a node can provide OC-OLR to another software = module in the same node without passing other related info Within a node, based on the design, lots of information may need to be pa= ssed between two software modules and we cannot optimize those aspects by r= eplicating unnecessary information in a protocol message. In summary, it is node's internal software design issue and we need not o= ptimize that at protocol level. - Once the reporting node realizes that it is overloaded, it has to wait fo= r right answer to send OC-OLR What is the point of sending OC-OLR for a context for which there is no me= ssaging? Why should the reacting node care if it never sends a message for = a context for which the reporting node is overloaded? So this waiting is justified since it ensures that the overload is reporte= d only when necessary and only to the applicable reacting node. Not to all = the nodes in the network. - The agent needs to wait for the answer generated by the server and the ri= ght context The same argument as applicable for the server applies here. The agent ne= ed not send out-of-context overload info to a node. Why should reacting node receive/process/store the overload info for the = scope for which it is not sending any messages. - For sending OC-OLR in dedicated Diameter application??? Piggybacking was the first basic principle we agreed before putting other = principles in place. So we may want to go back the drawing board if we deci= de to change this principle. Regards, Nirav. -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen Sent: Friday, November 29, 2013 2:50 PM To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org li= st Cc: Ben Campbell Subject: Re: [Dime] DOIC: Self-Contained OLRs So, are we reaching any level of consensus here? - JOuni (as a note.. that we are converging back to where we started with OLRs ;) On Nov 28, 2013, at 12:40 PM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: Hi, another question: If we go for explicit self contained OLRs, why would we then need the Repor= tType? The realm-type OLR would explicitly contain application-Id, Realm, but no H= ost whereas the host-type OLR would explicitly contain application-Id, Host= , but probably (I'm not sure) no Realm. 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 stat= us. It could be provided an agent inserting this info in answers received f= rom a server behind but also from a server that would know this info by som= e internal magic. But in any case, if we assume that the client will received a successful an= swer from the server for an initial request with only Dest-Realm AVP, it sh= ould be possible to have both report types in the answer: one for the serve= r itself, one for the realm for new request sent to the realm with only Des= t-Realm AVP. Lionel -----Message d'origine----- De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN - DE/Munich) Envoy=E9 : jeudi 28 novembre 2013 10:26 =C0 : 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 a= ligned with the "endpoint principle". If the ReportType is "realm" this ind= icates 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 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 re= acting 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 Diamet= er request that corresponds to the answer containing the OLR. My reasons fo= r 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 i= dentified by Origin-Realm, and so on. This means that the "meaning" of an O= LR 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 answe= r to another, it's meaning may change completely. I think this approach is a mistake. I would greatly prefer that we explicit= ly 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 variou= s other AVPs to find all the information it needs. For example, I think a c= ommon software design for overload control processing to be separated from = application processing. The consumer cannot simply hand the OLR to that mod= ule and expect things to work. The OC module must not only parse the OLR, b= ut parse any other AVPs that are relevant. As OLR contents get extended (as= sumedly following the same strategy as the base spec), the number of "conte= xt" avps that must be interpreted can grow large. This approach is error pr= one, and will likely encourage brittle, hard-to-maintain code. Self-contain= ed OLRs would keep all the information related to overload in one place. ma= king for simpler implementations. 2) It's more complex for the reporting node to send implicit values than ex= plicit values. The sender cannot simply set the context to match the OLR--a= ll those other AVPs have application or protocol layer meanings. Once a rep= orting node realizes that it is overloade, it has to wait for the right ans= wer that contains the right context before it can send the OLR. This is par= ticularly 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 sig= nificantly. 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 so= me 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 overlo= ad reports were self-contained, one could just reuse the report format we s= pecify here. But if the meaning of an OLR depends on the way it's transport= ed, this won't work. We would have to create a new or significantly modifie= d OLR format if we found a need to transport OLRs in different ways. Self-c= ontained OLRs would allow much greater flexibility. So, in summary, I think that self-contained OLRs would lead to simpler impl= ementations, less brittle deployments, and more flexibility for future evol= ution 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 le= s pieces jointes. Les messages electroniques etant susceptibles d'alteratio= n, 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 dis= tributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te 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 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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 confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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 confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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 confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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 confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. --_000_6B7134B31289DC4FAF731D844122B36E32B265PEXCVZYM13corpora_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Steve,<= o:p>

 = ;

So let's g= o on the discussion.

 = ;

As individ= ual below…

 = ;

De := DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9 : jeudi 5 d=E9cembre 2013 14:52
=C0 : dime@ietf.org
Objet : Re: [Dime] DOIC: Self-Contained OLRs<= /p>

 

Lionel,

I strongly disagree with your conclusion that there is little support for s= elf-contained OLRs. 

[LM] could you point which one?

I also object to your assessment that there are strong arguments against se= lf-contained reports.  I have yet to see a single STRONG argument.

[LM] wrong. The right sentence should be that yo= u don't consider comments against your proposal as valid.

I also object to your attempting to call the question at this point in the = discussion.<= /span>

[LM] just an attempt to see if we could come to = a agreement based on my distorted summary

The only arguments I see for the implicit approach is complexity, which I j= ust sent an email refuting and schedule, about which I also just sent an em= ail.

Self contained reports work just as well and has advantages both sho= rt term in support for non application specific software layering and in th= e long term in allowing for the same overload report to be transported usin= g multiple DOC solutions.

I also don't agree that this has been a particularly long thread.  The= re are multiple topics being discussed under the same subject line.

[LM] this topic is discussed fro several months,= at least one year. I was not referring to the current title.

If we are to pose a question at this point I would suggest -- Can everyone = live with self-contained overload reports?

[LM] and I would say "NO"

Steve

On 12/5/13 7:28 AM, lionel.morand@orange.com wrote:

All,

 

After this= LONG thread, it seems that there are strong arguments against the self-con= tained OLRs and little support.

In the con= trary, it seems that the principle of OLR related to the application in use= is technically OK for everyone.

 

So the que= stion is quite simple:

 

Could ever= yone live/survive with the "implicit approach" with the extensibi= lity mechanism allowing future extensions if needed?

 

If yes, pl= ease focus on the finalization of the current draft.

If no, let= go on the discussion.

 

Regards,

 

Lionel

 

 

De := DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9 : jeudi 5 d=E9cembre 2013 14:06
=C0 : dime@ietf.org
Objet : Re: [Dime] DOIC: Self-Contained OLRs<= /p>

 

On the schedule quest= ion mentioned by JJacques -- any schedule concerns can go away if everyone = agrees to self contained overload reports.  This discussion would end = and we could move on to other things.  :-)

I say that somewhat in jest but please don't make the argument that this di= scussion should be ended because of schedule.  Or if you make that arg= ument, please don't assert that the person who disagrees with you is puttin= g the schedule at risk.

We are striving for the best technical solution.  We all understand th= e schedule pressures.  We need to balance the two.

Steve

On 12/5/13 5:14 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQ= UES) wrote:

Hi 
 
A lot of mails on this topic...I would suggest to introduce an overloa=
d control on the Dime email threads:)  
 
 
On my side, I rely on what we have written in the  draft for the =
"baseline" mechanism and that we have to keep as it is simple and=
 efficient, here I join Lionel, Nirav and MCruz' positions.
 
This thread then addresses extensions  cases, I agree that we wil=
l have to address such extensions:   Nirav mentioned the example =
with APN that if relevant would  a 3GGP application case, I would add =
the Session Group about which we had some discussion a while ago and  =
which is a more generic IETF case. There is also the agent overload case. H=
ave you others? Always good to have some use cases in mind.
 
What is important for me is that adding extensions should not modify t=
he baseline and making it more complex when used alone.  I also make a=
 difference between principles and protocol tuning where we may have to cho=
ose between various protocol solution but addressing the same functionality=
 or principle.  
 
About piggybacking, in the baseline,  the principle is that OLRs&=
nbsp; which  are addressed  to sources of traffic are put in answ=
er messages towards this traffic sources (origin Host) (even if these messa=
ges  may be processed by intermediate DAs), which is simple and the OL=
R can be kept unchanged in the same message  up to the origin Host if =
no specific process in intermediate DAs.  To have a piggybacking allow=
ing to put any OLR in any message (as it was in draft roach)  is addin=
g complexity that is not justified for the baseline and we have not retaine=
d it in the existing draft .
 
About extensions, the APN or session group  examples address =
; parts of the traffic between a server and a client (so a higher granulari=
ty in the throttling than the baseline one), related OLRs are conveyed in t=
he messages towards the origin Host so with an implicit reference to the Ap=
plication, the  Origin and Destination Host as for the baseline, so no=
t requiring self contained OLRs. I also  do not see the interest to se=
nd these new extensions OLR only in answers directly related to this OLR (a=
s Ulrich proposed), eg only in an answer dealing with an APN if the OLR is =
related to APN throttling.  The main point is that the OLR takes a dir=
ect "train" towards the right destination for a given application=
 (as for baseline).
 
This does not exclude that we may have other cases not entering the ab=
ove examples characteristics, but as Nirav mentioned, we  have to rema=
in pragmatic and see this when such new use cases will be addressed. The ex=
tensibility possibilities of  current draft give us a lot of flexibili=
ty, e.g. if some extensions need more self contained AVPs, why not, but thi=
s is outside the current draft. 
 
About extensions, I also think that they may need to be identified in =
the capability part, as the related OLRs should not be sent by a reacting n=
ode if the extension is not supported.
 
Last important point, as  Lionel mentioned, we have to finalize t=
he draft soon, to be able to start Rel12 3GGP work relying on this draft. M=
y position is that the current draft is currently well suited for the basel=
ine and that extensions will be addressed separately  
 
Best regards
 
JJacques 
 
 
-----Message d'origine-----
De : DiME [mailto:dime-b=
ounces@ietf.org] De la part de Ben Campbell
Envoy=E9 : mercredi 4 d=E9cembre 2013 22:55
=C0 : ext lionel.mora=
nd@orange.com
Cc : dime@ietf.org
Objet : Re: [Dime] DOIC: Self-Contained OLRs
 
On Dec 3, 2013, at 5:17 PM, lionel.morand@orange.com wrote:
 
Hi Ben,
 
I may be wrong somewhere in my summary but I think that it was the res=
ult of the discussions and agreements reached regarding existing requiremen=
ts, at least from 3GPP point of view, compared to possible optimizations fo=
r future optimizations not so obvious.
 
We are not the 3GPP. Our requirements are RFC 7068. I believe self-con=
tained OLRs do a better job of meeting Req 31 than the contextually-defined=
 OLRs.
 
I've made several technical arguments here--does anyone have _technica=
l_ arguments in favor of contextually-defined OLRs?
 
And because the solution offers extensibility via the definition of ne=
w algo, new report type and addition of any new AVP in the existing Grouped=
 OLR, the "limitations" of the proposed solution might be removed=
 by someone if really required according to new requirements.

 


 
It might be worth considering a compromise approach: Define _optional_=
 AVPs that allow an OLR to be self-contained. If they are not present, then=
 the various values default to those from the enclosing Diameter message. P=
ossibly add support for this to the list of things that reacting nodes can =
advertise.
 
This could be in the base, or in a follow on extension. (If left for a=
n extension, it's worth considering whether ReportType needs to be in the b=
ase, or this or some other extension.) 
 
 
Regards,
 
Lionel
 
-----Message d'origine-----
De : Ben Campbell [mailto:ben@nostr=
um.com] Envoy=E9 : mardi 3 d=E9cembre 
2013 23:56 =C0 : MORAND Lionel IMT/OLN Cc : Steve Donovan; dime@ietf.org 
Objet : Re: [Dime] DOIC: Self-Contained OLRs
 
 
On Dec 2, 2013, at 10:18 AM, lionel.morand@orange.com wrote:
 
Hi Steve,
 
I think that is not only about few bytes in the answer. It is also abo=
ut the solution principles agreed so far:
=B7         the current need i=
s for an OLR bound to the application in use
=B7         the OLR is receive=
d from the node targeted in the request.
=B7         the OLR is defined=
 per application
 
I don't think those principles have been well tested. I don't recall a=
ny discussion of their benefits. What benefits do you see they have over se=
lf-contained OLRs?
 
All I see from these are restrictions in the flexibility of the soluti=
on, with very little in return.
 
So all the implicit information (application, origin-host, origin-real=
m) are meaningful in this context.
And the actual solution is designed based on these assumptions. The ex=
tensibility of the solution will allow extra info if required in other use =
cases but it was agreed to go with a straightforward solution that will sat=
isfy most of us.
 
Regards,
 
Lionel
 
De : DiME [mailto:dime-bounce=
s@ietf.org] De la part de Steve Donovan
Envoy=E9 : lundi 2 d=E9cembre 2013 16:37
=C0 : dime@ietf.org

Objet : Re: [Dime] DOIC: Self-Contained OLRs


 


I don't believe that Ben's proposal was to change the piggybacking ass=
umption in the baseline mechanism.  Ben's proposal is to design the so=
lution in such a way that it is not dependent on the piggybacking transport=
 mechanism.  


 


I share Ben's concern that we have over optimized the content of the o=
verload report in a way that makes implementations brittle, interoperabilit=
y more difficult to achieve and extensibility more complex.  And what =
do we gain from this optimization?  A few bites in answer messages.


 


Self contained overload reports, transported using the piggybacking me=
chanism, is a cleaner solution.


 


Steve


 


On 11/29/13 8:31 AM, lione=
l.morand@orange.com wrote:


I totally agree with Nirav. No need to revert at this stage the workin=
g assumption on piggybacking of OLR in application answer messages, especia=
lly when the aim is to define a basic mechanism called "reduction"=
;.


 


Anyone would be able to further add extra info for optimization if nee=
ded but there is no need at all for the basic mechanism.


 


Regards,


 


Lionel


 


-----Message d'origine-----


De : DiME [mailto:dime-bounce=
s@ietf.org] De la part de Nirav Salot (nsalot)


Envoy=E9 : vendredi 29 novembre 2013 12:24


=C0 : Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list


Cc : Ben Campbell


Objet : Re: [Dime] DOIC: Self-Contained OLRs


 


Jouni, Ben,


 


I am totally against the idea of self-contained OC-OLR specifically si=
nce we have adopted the principles of piggybacking the OC-OLR over existing=
 application message.


Self-contained OC-OLR - which means adding all the information which d=
efines the scope of the OC-OLR into the OC-OLR - does not make sense in the=
 piggybacking approach. In fact, it is adding lot of information, which is =
anyway available within the message containing the OC-OLR, into the OC-OLR.=
 So it is adding lot of redundant information in a message which increases =
the processing requirement for the sender as well as the receiver. (And thi=
s is un-optimization, in my view).


 


Besides, I am not convinced with the other reasons provided here:=



- One software module within a node can provide OC-OLR to another soft=
ware module in the same node without passing other related info<=
/pre>

  Within a node, based on the design, lots of information may nee=
d to be passed between two software modules and we cannot optimize those as=
pects by replicating unnecessary information in a protocol message.


  In summary, it is node's internal software design issue and we =
need not optimize that at protocol level.


 


- Once the reporting node realizes that it is overloaded, it has to wa=
it for right answer to send OC-OLR


 What is the point of sending OC-OLR for a context for which there is =
no messaging? Why should the reacting node care if it never sends a message=
 for a context for which the reporting node is overloaded?


 So this waiting is justified since it ensures that the overload is re=
ported only when necessary and only to the applicable reacting node. Not to=
 all the nodes in the network.


 


- The agent needs to wait for the answer generated by the server and t=
he right context


  The same argument as applicable for the server applies here. Th=
e agent need not send out-of-context overload info to a node.

  Why should reacting node receive/process/store the overload inf=
o for the scope for which it is not sending any messages.


 


- For sending OC-OLR in dedicated Diameter application???

 Piggybacking was the first basic principle we agreed before putting o=
ther principles in place. So we may want to go back the drawing board if we=
 decide to change this principle.


 


Regards,


Nirav.


 


-----Original Message-----


From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of Jouni Korhonen


Sent: Friday, November 29, 2013 2:50 PM


To: Wiehe, Ulrich (NSN - DE/Munich); =
dime@ietf.org list


Cc: Ben Campbell


Subject: Re: [Dime] DOIC: Self-Contained OLRs


 


 


 


So, are we reaching any level of consensus here?


 


- JOuni


 


(as a note.. that we are converging back to where we started with OLRs=
 ;)


 


 


 


On Nov 28, 2013, at 12:40 PM, "Wiehe, Ulrich (NSN - DE/Munich)&qu=
ot; <ulrich.wiehe@nsn.com> wrote:


 


Hi,


 


another question:


 


If we go for explicit self contained OLRs, why would we then need the =
ReportType?


 


The realm-type OLR would explicitly contain application-Id, Realm, but=
 no Host whereas the host-type OLR would explicitly contain application-Id,=
 Host, but probably (I'm not sure) no Realm.


 


Ulrich


 


 


 


-----Original Message-----


From: ext lionel.morand@or=
ange.com [mailto:lionel.mor=
and@orange.com]


Sent: Thursday, November 28, 2013 10:31 AM


To: Wiehe, Ulrich (NSN - DE/Munich); ext Jouni Korhonen; Ben Campbell<=
o:p>


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 recei=
ved from a server behind but also from a server that would know this info b=
y some internal magic.


But in any case, if we assume that the client will received a successf=
ul 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 onl=
y Dest-Realm AVP.


 


Lionel


 


-----Message d'origine-----


De : DiME [mailto:dime-bounce=
s@ietf.org] De la part de Wiehe, Ulrich 


(NSN - DE/Munich) Envoy=E9 : jeudi 28 novembre 2013 10:26 =C0 : ext Jo=
uni 


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 &=
quot;realm" this indicates to the reacting end point that the reportin=
g 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 repor=
ting end point is a server. How can the reporting end point be both agent a=
nd server?


 


Ulrich


 


-----Original Message-----


From: DiME [mailto:dime-bounc=
es@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 <=
/o:p>


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 t=
he 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 D=
iameter request that corresponds to the answer containing the OLR. My reaso=
ns 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 applica=
tion identified by the Application-Id field of the enclosing answer, the re=
alm identified by Origin-Realm, and so on. This means that the "meanin=
g" of an OLR cannot be determined from the OLR contents alone; OLRs on=
ly 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 exp=
licitly include such values in the OLR itself, for multiple reasons:


 


1) It's more complex to interpret implicit, contextual values than exp=
licit values. The consumer cannot simply look at the OLR; it must look in v=
arious other AVPs to find all the information it needs. For example, I thin=
k a common software design for overload control processing to be separated =
from application processing. The consumer cannot simply hand the OLR to tha=
t module and expect things to work. The OC module must not only parse the O=
LR, but parse any other AVPs that are relevant. As OLR contents get extende=
d (assumedly following the same strategy as the base spec), the number of &=
quot;context" avps that must be interpreted can grow large. This appro=
ach is error prone, and will likely encourage brittle, hard-to-maintain cod=
e. Self-contained OLRs would keep all the information related to overload i=
n one place. making for simpler implementations.


 


2) It's more complex for the reporting node to send implicit values th=
an explicit values. The sender cannot simply set the context to match the O=
LR--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 righ=
t answer that contains the right context before it can send the OLR. This i=
s particularly troublesome for agents, since they will typically have to in=
sert OLRs into answers created by other nodes. 


 


If the reporting node screws this up, the meaning of the OLR may chang=
e significantly. So again, implicit meaning gives us error prone implementa=
tions. 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 <=
o:p>


are distinct from those sent by a server, see Steve's agent overload <=
o:p>


draft, or my dh/dr example.)


 


OTOH, explicit values will work for all cases where we need to associa=
te some arbitrary value with an OLR.


 


4) Implicit values seriously constrain the future evolution of Diamete=
r OC standards. For example, lets say we find a good reason to allow OLRs t=
o be sent out of band, or be sent in a dedicated Diameter application. If o=
verload 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 tran=
sported, this won't work. We would have to create a new or significantly mo=
dified OLR format if we found a need to transport OLRs in different ways. S=
elf-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.iet=
f.org/mailman/listinfo/dime


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.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 q=
ue les pieces jointes. Les messages electroniques etant susceptibles d'alte=
ration, Orange decline toute responsabilite si ce message a ete altere, def=
orme ou falsifie. Merci.


 


This message and its attachments may contain confidential or 


privileged information that may be protected by law; they should not b=
e 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.iet=
f.org/mailman/listinfo/dime


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 


______________________________________________________________________=
___________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


 


This message and its attachments may contain confidential or privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
o:p>


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.iet=
f.org/mailman/listinfo/dime


 


 


______________________________________________________________________=
___________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


 


This message and its attachments may contain confidential or privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
o:p>


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.iet=
f.org/mailman/listinfo/dime


 
 
______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
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.iet=
f.org/mailman/listinfo/dime
 
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.iet=
f.org/mailman/listinfo/dime
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.iet=
f.org/mailman/listinfo/dime
 

 

______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
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.iet=
f.org/mailman/listinfo/dime

 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles 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 el=
ectroniques 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 inf=
ormation 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 dele=
te 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.
--_000_6B7134B31289DC4FAF731D844122B36E32B265PEXCVZYM13corpora_-- From srdonovan@usdonovans.com Thu Dec 5 06:08:39 2013 Return-Path: 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 078E81ADFE5 for ; Thu, 5 Dec 2013 06:08:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no 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 IEebcWwkSucA for ; Thu, 5 Dec 2013 06:08:33 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id A315E1ADF10 for ; Thu, 5 Dec 2013 06:08:33 -0800 (PST) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:61868 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1VoZbE-0001Hx-Jk; Thu, 05 Dec 2013 06:08:29 -0800 Message-ID: <52A088D0.2020406@usdonovans.com> Date: Thu, 05 Dec 2013 08:08:16 -0600 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "Nirav Salot (nsalot)" , "dime@ietf.org" References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <8467_1385735507_5298A553_8467_17054_3_6B7134B31289DC4FAF731D844122B36E309D0D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <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> <14594_1386204165_529FCC05_14594_12646_1_6B7134B31289DC4FAF731D844122B36E329907@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B920972CCAA@ESESSMB101.ericsson.se> <52A077CC.3000004@usdonovans.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010809030903090108090905" X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 14:08:39 -0000 This is a multi-part message in MIME format. --------------010809030903090108090905 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit I must admit that I don't understand the need for consistency. Why is it necessary to compare implicit and explicit data? If we use self contained reports then the contents of the report are what should be used, independent of the message that carries the report. Steve On 12/5/13 7:49 AM, Nirav Salot (nsalot) wrote: > > Steve, > > > > While gauging the complexity of "using the self-contained OC-OLR" It > seems you have overlooked the aspect identified by Maria-Cruz below > (and JJ earlier). > > > Duplication should be avoided, since then we need to assure > consistency, and error handing in case implicit and explicit data > values are different for any reason... what means that it may always > be required to check both implicit and explicit data. > > > > Regards, > > Nirav. > > > > *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *Steve Donovan > *Sent:* Thursday, December 05, 2013 6:26 PM > *To:* dime@ietf.org > *Subject:* Re: [Dime] DOIC: Self-Contained OLRs > > > > If we equating "complexity" with work done by a Diameter node, then > there is added "complexity" for both proposals. > > The extra work that needs to be done for the self contained report > approach is that the reporter needs to add additional AVPs to the > report. This is hardly difficult but it is extra work. > > The extra work in the implicit approach is that the reactor needs to > gather information from multiple AVPs to understand the context of the > AVP. Again, hardly difficult but more work that can be avoided in a > well layered software architecture. > > My conclusion is that the complexity argument does not apply. There > is complexity in both, its just a matter of where the work is done. > > Steve > > On 12/5/13 3:29 AM, Nirav Salot (nsalot) wrote: > > Agree with Lionel's view and Maria-Cruz's arguments below. > > > > The "self-contained OC-OLR" - which I assume contains the same information as present in the message containing the OC-OLR - adds extra complexity as highlighted by Maria-Cruz. > > The benefit highlighted can be achieved in an implementation specific way by the receiver duplicating the information into OC-OLR before passing it to the layer processing the OC-OLR. > > > > Regards, > > Nirav. > > > > -----Original Message----- > > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Maria Cruz Bartolome > > Sent: Thursday, December 05, 2013 7:53 AM > > To: dime@ietf.org > > Subject: Re: [Dime] DOIC: Self-Contained OLRs > > > > Dear all, > > > > I agree with Lionel argumentation below. > > > > A part from that, one concern with "self-contained OLRs" is that some data is duplicated. Duplication should be avoided, since then we need to assure consistency, and error handing in case implicit and explicit data values are different for any reason... what means that it may always be required to check both implicit and explicit data. > > > > Also, I think this is a pure implementation proposal. Regardless how the data is transported it could be packed in a "self-contained OLRs" within the diameter application, if for any implementation this is preferred. > > > > Regards > > /MCruz > > > > > > -----Original Message----- > > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange.com > > Sent: jueves, 05 de diciembre de 2013 1:43 > > To: Ben Campbell > > Cc: dime@ietf.org > > Subject: Re: [Dime] DOIC: Self-Contained OLRs > > > > Hi Ben, > > > > 3GPP operational requirements have triggered and driven this work, and 3GPP will be the main client for this solution (if not the only for a while...). Main parties involved in the discussions are 3GPP vendors and 3GPP operators. So instead trying to keep private preserve, we should welcome and enforce cooperative work with 3GPP on this task if we want that the solution defined in IETF will be used in 3GPP. Otherwise, 3GPP may decide not to wait for IETF and develop its own solution, as done in the past (e.g. developing 3GPP-specific Cx application instead of adopting the IETF-standard Diameter SIP application). > > > > About the technical discussion, the Req31 says: > > > > REQ 31: There are multiple situations where a Diameter node may be > > overloaded for some purposes but not others. For example, > > this can happen to an agent or server that supports multiple > > applications, or when a server depends on multiple external > > resources, some of which may become overloaded while others > > are fully available. The solution MUST allow Diameter nodes > > to indicate overload with sufficient granularity to allow > > clients to take action based on the overloaded resources > > without unreasonably forcing available capacity to go unused. > > The solution MUST support specification of overload > > information with granularities of at least "Diameter node", > > "realm", and "Diameter application" and MUST allow > > extensibility for others to be added in the future. > > > > The "MUST" part says: enough granularity with at least host/realm and application. > > And the existing solution is compliant with this requirement. If a node is supporting N applications, an OLR can be sent "per application" with a report type indicating if it is for the host or the realm. And the extensibility capability is provided by the base solution. > > > > So my technical argument is that the existing proposal fulfills the basic requirements for an overload control without compromising future extension for further granularity. > > > > Regards, > > > > Lionel > > > > -----Message d'origine----- > > De : Ben Campbell [mailto:ben@nostrum.com] Envoyé : mercredi 4 décembre 2013 22:55 À : MORAND Lionel IMT/OLN Cc : dime@ietf.org Objet : Re: [Dime] DOIC: Self-Contained OLRs > > > > On Dec 3, 2013, at 5:17 PM, lionel.morand@orange.com wrote: > > > > Hi Ben, > > > > I may be wrong somewhere in my summary but I think that it was the result of the discussions and agreements reached regarding existing requirements, at least from 3GPP point of view, compared to possible optimizations for future optimizations not so obvious. > > > > We are not the 3GPP. Our requirements are RFC 7068. I believe self-contained OLRs do a better job of meeting Req 31 than the contextually-defined OLRs. > > > > I've made several technical arguments here--does anyone have _technical_ arguments in favor of contextually-defined OLRs? > > > > And because the solution offers extensibility via the definition of new algo, new report type and addition of any new AVP in the existing Grouped OLR, the "limitations" of the proposed solution might be removed by someone if really required according to new requirements. > > > > > > It might be worth considering a compromise approach: Define _optional_ AVPs that allow an OLR to be self-contained. If they are not present, then the various values default to those from the enclosing Diameter message. Possibly add support for this to the list of things that reacting nodes can advertise. > > > > This could be in the base, or in a follow on extension. (If left for an extension, it's worth considering whether ReportType needs to be in the base, or this or some other extension.) > > > > > > Regards, > > > > Lionel > > > > -----Message d'origine----- > > De : Ben Campbell [mailto:ben@nostrum.com] Envoyé : mardi 3 décembre > > 2013 23:56 À : MORAND Lionel IMT/OLN Cc : Steve Donovan; dime@ietf.org > > Objet : Re: [Dime] DOIC: Self-Contained OLRs > > > > > > On Dec 2, 2013, at 10:18 AM, lionel.morand@orange.com wrote: > > > > Hi Steve, > > > > I think that is not only about few bytes in the answer. It is also about the solution principles agreed so far: > > · the current need is for an OLR bound to the application in use > > · the OLR is received from the node targeted in the request. > > · the OLR is defined per application > > > > I don't think those principles have been well tested. I don't recall any discussion of their benefits. What benefits do you see they have over self-contained OLRs? > > > > All I see from these are restrictions in the flexibility of the solution, with very little in return. > > > > So all the implicit information (application, origin-host, origin-realm) are meaningful in this context. > > And the actual solution is designed based on these assumptions. The extensibility of the solution will allow extra info if required in other use cases but it was agreed to go with a straightforward solution that will satisfy most of us. > > > > Regards, > > > > Lionel > > > > De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan > > Envoyé : lundi 2 décembre 2013 16:37 > > À : dime@ietf.org > > Objet : Re: [Dime] DOIC: Self-Contained OLRs > > > > I don't believe that Ben's proposal was to change the piggybacking assumption in the baseline mechanism. Ben's proposal is to design the solution in such a way that it is not dependent on the piggybacking transport mechanism. > > > > I share Ben's concern that we have over optimized the content of the overload report in a way that makes implementations brittle, interoperability more difficult to achieve and extensibility more complex. And what do we gain from this optimization? A few bites in answer messages. > > > > Self contained overload reports, transported using the piggybacking mechanism, is a cleaner solution. > > > > Steve > > > > On 11/29/13 8:31 AM, lionel.morand@orange.com wrote: > > I totally agree with Nirav. No need to revert at this stage the working assumption on piggybacking of OLR in application answer messages, especially when the aim is to define a basic mechanism called "reduction". > > > > Anyone would be able to further add extra info for optimization if needed but there is no need at all for the basic mechanism. > > > > Regards, > > > > Lionel > > > > -----Message d'origine----- > > De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot (nsalot) > > Envoyé : vendredi 29 novembre 2013 12:24 > > À : Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list > > Cc : Ben Campbell > > Objet : Re: [Dime] DOIC: Self-Contained OLRs > > > > Jouni, Ben, > > > > I am totally against the idea of self-contained OC-OLR specifically since we have adopted the principles of piggybacking the OC-OLR over existing application message. > > Self-contained OC-OLR - which means adding all the information which defines the scope of the OC-OLR into the OC-OLR - does not make sense in the piggybacking approach. In fact, it is adding lot of information, which is anyway available within the message containing the OC-OLR, into the OC-OLR. So it is adding lot of redundant information in a message which increases the processing requirement for the sender as well as the receiver. (And this is un-optimization, in my view). > > > > Besides, I am not convinced with the other reasons provided here: > > - One software module within a node can provide OC-OLR to another software module in the same node without passing other related info > > Within a node, based on the design, lots of information may need to be passed between two software modules and we cannot optimize those aspects by replicating unnecessary information in a protocol message. > > In summary, it is node's internal software design issue and we need not optimize that at protocol level. > > > > - Once the reporting node realizes that it is overloaded, it has to wait for right answer to send OC-OLR > > What is the point of sending OC-OLR for a context for which there is no messaging? Why should the reacting node care if it never sends a message for a context for which the reporting node is overloaded? > > So this waiting is justified since it ensures that the overload is reported only when necessary and only to the applicable reacting node. Not to all the nodes in the network. > > > > - The agent needs to wait for the answer generated by the server and the right context > > The same argument as applicable for the server applies here. The agent need not send out-of-context overload info to a node. > > Why should reacting node receive/process/store the overload info for the scope for which it is not sending any messages. > > > > - For sending OC-OLR in dedicated Diameter application??? > > Piggybacking was the first basic principle we agreed before putting other principles in place. So we may want to go back the drawing board if we decide to change this principle. > > > > Regards, > > Nirav. > > > > -----Original Message----- > > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen > > Sent: Friday, November 29, 2013 2:50 PM > > To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list > > Cc: Ben Campbell > > Subject: Re: [Dime] DOIC: Self-Contained OLRs > > > > > > > > So, are we reaching any level of consensus here? > > > > - JOuni > > > > (as a note.. that we are converging back to where we started with OLRs ;) > > > > > > > > On Nov 28, 2013, at 12:40 PM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: > > > > Hi, > > > > another question: > > > > If we go for explicit self contained OLRs, why would we then need the ReportType? > > > > The realm-type OLR would explicitly contain application-Id, Realm, but no Host whereas the host-type OLR would explicitly contain application-Id, Host, but probably (I'm not sure) no Realm. > > > > 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 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. > > > > > > _______________________________________________ > > 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. > > > > _______________________________________________ > > 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 > > > > > > _________________________________________________________________________________________________________________________ > > > > 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 > > > > > --------------010809030903090108090905 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I must admit that I don't understand the need for consistency.

Why is it necessary to compare implicit and explicit data?  If we use self contained reports then the contents of the report are what should be used, independent of the message that carries the report.

Steve
On 12/5/13 7:49 AM, Nirav Salot (nsalot) wrote:

Steve,

 

While gauging the complexity of "using the self-contained OC-OLR" It seems you have overlooked the aspect identified by Maria-Cruz below (and JJ earlier).

> Duplication should be avoided, since then we need to assure consistency, and error handing in case implicit and explicit data values are different for any reason... what means that it may always be required to check both implicit and explicit data.

 

Regards,

Nirav.

 

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: Thursday, December 05, 2013 6:26 PM
To: dime@ietf.org
Subject: Re: [Dime] DOIC: Self-Contained OLRs

 

If we equating "complexity" with work done by a Diameter node, then there is added "complexity" for both proposals.

The extra work that needs to be done for the self contained report approach is that the reporter needs to add additional AVPs to the report.  This is hardly difficult but it is extra work.

The extra work in the implicit approach is that the reactor needs to gather information from multiple AVPs to understand the context of the AVP.  Again, hardly difficult but more work that can be avoided in a well layered software architecture.

My conclusion is that the complexity argument does not apply.  There is complexity in both, its just a matter of where the work is done.

Steve

On 12/5/13 3:29 AM, Nirav Salot (nsalot) wrote:

Agree with Lionel's view and Maria-Cruz's arguments below.
 
The "self-contained OC-OLR" - which I assume contains the same information as present in the message containing the OC-OLR - adds extra complexity as highlighted by Maria-Cruz.
The benefit highlighted can be achieved in an implementation specific way by the receiver duplicating the information into OC-OLR before passing it to the layer processing the OC-OLR.
 
Regards,
Nirav.
 
-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Maria Cruz Bartolome
Sent: Thursday, December 05, 2013 7:53 AM
To: dime@ietf.org
Subject: Re: [Dime] DOIC: Self-Contained OLRs
 
Dear all,
 
I agree with Lionel argumentation below.
 
A part from that,  one concern with "self-contained OLRs" is that some data is duplicated. Duplication should be avoided, since then we need to assure consistency, and error handing in case implicit and explicit data values are different for any reason... what means that it may always be required to check both implicit and explicit data.
 
Also, I think this is a pure implementation proposal. Regardless how the data is transported it could be packed in a "self-contained OLRs" within the diameter application, if for any implementation this is preferred.
 
Regards
/MCruz
 
 
-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange.com
Sent: jueves, 05 de diciembre de 2013 1:43
To: Ben Campbell
Cc: dime@ietf.org
Subject: Re: [Dime] DOIC: Self-Contained OLRs
 
Hi Ben,
 
3GPP operational requirements have triggered and driven this work, and 3GPP will be the main client for this solution (if not the only for a while...). Main parties involved in the discussions are 3GPP vendors and 3GPP operators. So instead trying to keep private preserve, we should welcome and enforce cooperative work with 3GPP on this task if we want that the solution defined in IETF will be used in 3GPP. Otherwise, 3GPP may decide not to wait for IETF and develop its own solution, as done in the past (e.g. developing 3GPP-specific Cx application instead of adopting the IETF-standard Diameter SIP application).
 
About the technical discussion, the Req31 says:
 
   REQ 31: There are multiple situations where a Diameter node may be
           overloaded for some purposes but not others.  For example,
           this can happen to an agent or server that supports multiple
           applications, or when a server depends on multiple external
           resources, some of which may become overloaded while others
           are fully available.  The solution MUST allow Diameter nodes
           to indicate overload with sufficient granularity to allow
           clients to take action based on the overloaded resources
           without unreasonably forcing available capacity to go unused.
           The solution MUST support specification of overload
           information with granularities of at least "Diameter node",
           "realm", and "Diameter application" and MUST allow
           extensibility for others to be added in the future.
 
The "MUST" part says: enough granularity with at least host/realm and application.
And the existing solution is compliant with this requirement. If a node is supporting N applications, an OLR can be sent "per application" with a report type indicating if it is for the host or the realm. And the extensibility capability is provided by the base solution.
 
So my technical argument is that the existing proposal fulfills the basic requirements for an overload control without compromising future extension for further granularity.
 
Regards,
 
Lionel 
 
-----Message d'origine-----
De : Ben Campbell [mailto:ben@nostrum.com] Envoyé : mercredi 4 décembre 2013 22:55 À : MORAND Lionel IMT/OLN Cc : dime@ietf.org Objet : Re: [Dime] DOIC: Self-Contained OLRs
 
On Dec 3, 2013, at 5:17 PM, lionel.morand@orange.com wrote:
 
Hi Ben,
 
I may be wrong somewhere in my summary but I think that it was the result of the discussions and agreements reached regarding existing requirements, at least from 3GPP point of view, compared to possible optimizations for future optimizations not so obvious.
 
We are not the 3GPP. Our requirements are RFC 7068. I believe self-contained OLRs do a better job of meeting Req 31 than the contextually-defined OLRs.
 
I've made several technical arguments here--does anyone have _technical_ arguments in favor of contextually-defined OLRs?
 
And because the solution offers extensibility via the definition of new algo, new report type and addition of any new AVP in the existing Grouped OLR, the "limitations" of the proposed solution might be removed by someone if really required according to new requirements.
 
 
It might be worth considering a compromise approach: Define _optional_ AVPs that allow an OLR to be self-contained. If they are not present, then the various values default to those from the enclosing Diameter message. Possibly add support for this to the list of things that reacting nodes can advertise.
 
This could be in the base, or in a follow on extension. (If left for an extension, it's worth considering whether ReportType needs to be in the base, or this or some other extension.) 
 
 
Regards,
 
Lionel
 
-----Message d'origine-----
De : Ben Campbell [mailto:ben@nostrum.com] Envoyé : mardi 3 décembre 
2013 23:56 À : MORAND Lionel IMT/OLN Cc : Steve Donovan; dime@ietf.org 
Objet : Re: [Dime] DOIC: Self-Contained OLRs
 
 
On Dec 2, 2013, at 10:18 AM, lionel.morand@orange.com wrote:
 
Hi Steve,
 
I think that is not only about few bytes in the answer. It is also about the solution principles agreed so far:
·         the current need is for an OLR bound to the application in use
·         the OLR is received from the node targeted in the request.
·         the OLR is defined per application
 
I don't think those principles have been well tested. I don't recall any discussion of their benefits. What benefits do you see they have over self-contained OLRs?
 
All I see from these are restrictions in the flexibility of the solution, with very little in return.
 
So all the implicit information (application, origin-host, origin-realm) are meaningful in this context.
And the actual solution is designed based on these assumptions. The extensibility of the solution will allow extra info if required in other use cases but it was agreed to go with a straightforward solution that will satisfy most of us.
 
Regards,
 
Lionel
 
De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoyé : lundi 2 décembre 2013 16:37
À : dime@ietf.org
Objet : Re: [Dime] DOIC: Self-Contained OLRs
 
I don't believe that Ben's proposal was to change the piggybacking assumption in the baseline mechanism.  Ben's proposal is to design the solution in such a way that it is not dependent on the piggybacking transport mechanism.  
 
I share Ben's concern that we have over optimized the content of the overload report in a way that makes implementations brittle, interoperability more difficult to achieve and extensibility more complex.  And what do we gain from this optimization?  A few bites in answer messages.
 
Self contained overload reports, transported using the piggybacking mechanism, is a cleaner solution.
 
Steve
 
On 11/29/13 8:31 AM, lionel.morand@orange.com wrote:
I totally agree with Nirav. No need to revert at this stage the working assumption on piggybacking of OLR in application answer messages, especially when the aim is to define a basic mechanism called "reduction".
 
Anyone would be able to further add extra info for optimization if needed but there is no need at all for the basic mechanism.
 
Regards,
 
Lionel
 
-----Message d'origine-----
De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot (nsalot)
Envoyé : vendredi 29 novembre 2013 12:24
À : Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list
Cc : Ben Campbell
Objet : Re: [Dime] DOIC: Self-Contained OLRs
 
Jouni, Ben,
 
I am totally against the idea of self-contained OC-OLR specifically since we have adopted the principles of piggybacking the OC-OLR over existing application message.
Self-contained OC-OLR - which means adding all the information which defines the scope of the OC-OLR into the OC-OLR - does not make sense in the piggybacking approach. In fact, it is adding lot of information, which is anyway available within the message containing the OC-OLR, into the OC-OLR. So it is adding lot of redundant information in a message which increases the processing requirement for the sender as well as the receiver. (And this is un-optimization, in my view).
 
Besides, I am not convinced with the other reasons provided here:
- One software module within a node can provide OC-OLR to another software module in the same node without passing other related info
  Within a node, based on the design, lots of information may need to be passed between two software modules and we cannot optimize those aspects by replicating unnecessary information in a protocol message.
  In summary, it is node's internal software design issue and we need not optimize that at protocol level.
 
- Once the reporting node realizes that it is overloaded, it has to wait for right answer to send OC-OLR
 What is the point of sending OC-OLR for a context for which there is no messaging? Why should the reacting node care if it never sends a message for a context for which the reporting node is overloaded?
 So this waiting is justified since it ensures that the overload is reported only when necessary and only to the applicable reacting node. Not to all the nodes in the network.
 
- The agent needs to wait for the answer generated by the server and the right context
  The same argument as applicable for the server applies here. The agent need not send out-of-context overload info to a node.
  Why should reacting node receive/process/store the overload info for the scope for which it is not sending any messages.
 
- For sending OC-OLR in dedicated Diameter application???
 Piggybacking was the first basic principle we agreed before putting other principles in place. So we may want to go back the drawing board if we decide to change this principle.
 
Regards,
Nirav.
 
-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen
Sent: Friday, November 29, 2013 2:50 PM
To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list
Cc: Ben Campbell
Subject: Re: [Dime] DOIC: Self-Contained OLRs
 
 
 
So, are we reaching any level of consensus here?
 
- JOuni
 
(as a note.. that we are converging back to where we started with OLRs ;)
 
 
 
On Nov 28, 2013, at 12:40 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> wrote:
 
Hi,
 
another question:
 
If we go for explicit self contained OLRs, why would we then need the ReportType?
 
The realm-type OLR would explicitly contain application-Id, Realm, but no Host whereas the host-type OLR would explicitly contain application-Id, Host, but probably (I'm not sure) no Realm.
 
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.
 
 
_______________________________________________
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.
 
_______________________________________________
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
 
 
_________________________________________________________________________________________________________________________
 
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
 

 


--------------010809030903090108090905-- From srdonovan@usdonovans.com Thu Dec 5 06:15:17 2013 Return-Path: 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 2918C1ADFC1 for ; Thu, 5 Dec 2013 06:15:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no 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 N8mxv0qwwWov for ; Thu, 5 Dec 2013 06:15:06 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 2AECC1ADFBC for ; Thu, 5 Dec 2013 06:15:06 -0800 (PST) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:61934 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1VoZhh-0000bF-Rp for dime@ietf.org; Thu, 05 Dec 2013 06:15:02 -0800 Message-ID: <52A08A61.5060700@usdonovans.com> Date: Thu, 05 Dec 2013 08:14:57 -0600 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: dime@ietf.org References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <8467_1385735507_5298A553_8467_17054_3_6B7134B31289DC4FAF731D844122B36E309D0D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <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> <52A07A1E.5060502@usdonovans.com> <20040_1386250088_52A07F68_20040_916_1_6B7134B31289DC4FAF731D844122B36E32B0E9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52A084FA.7000803@usdonovans.com> <15604_1386252069_52A08725_15604_17630_1_6B7134B31289DC4FAF731D844122B36E32B265@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <15604_1386252069_52A08725_15604_17630_1_6B7134B31289DC4FAF731D844122B36E32B265@PEXCVZYM13.corporate.adroot.infra.ftgroup> Content-Type: multipart/alternative; boundary="------------000203040500050908050207" X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 14:15:17 -0000 This is a multi-part message in MIME format. --------------000203040500050908050207 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Lionel, Please see my responses inline. Steve On 12/5/13 8:01 AM, lionel.morand@orange.com wrote: > > Hi Steve, > > > > So let's go on the discussion. > > > > As individual below... > > > > *De :*DiME [mailto:dime-bounces@ietf.org] *De la part de* Steve Donovan > *Envoyé :* jeudi 5 décembre 2013 14:52 > *À :* dime@ietf.org > *Objet :* Re: [Dime] DOIC: Self-Contained OLRs > > > > Lionel, > > I strongly disagree with your conclusion that there is little support > for self-contained OLRs. > > */[LM] could you point which one?/* > SRD> I don't understand your question. The fact that this discussion has gone on as long as it has is evidence that there is support for self-contained OLRs. > > I also object to your assessment that there are strong arguments > against self-contained reports. I have yet to see a single STRONG > argument. > > */[LM] wrong. The right sentence should be that you don't consider > comments against your proposal as valid./* > SRD> No, I didn't say there were no arguments, just not strong ones. You stated the opinion that there were strong arguments. I stated the counter opinion that there are no strong arguments. Both statements are opinions. > > > I also object to your attempting to call the question at this point in > the discussion. > > */[LM] just an attempt to see if we could come to a agreement based on > my distorted summary/* > SRD> In my opinion both your motives and timing were bad. > > The only arguments I see for the implicit approach is complexity, > which I just sent an email refuting and schedule, about which I also > just sent an email. > > Self contained reports work just as well and has advantages both short > term in support for non application specific software layering and in > the long term in allowing for the same overload report to be > transported using multiple DOC solutions. > > I also don't agree that this has been a particularly long thread. > There are multiple topics being discussed under the same subject line. > > */[LM] this topic is discussed fro several months, at least one year. > I was not referring to the current title./* > SRD> Then lets work for a positive way to come to a conclusion. > > If we are to pose a question at this point I would suggest -- Can > everyone live with self-contained overload reports? > > */[LM] and I would say "NO"/* > > Steve > > On 12/5/13 7:28 AM, lionel.morand@orange.com > wrote: > > All, > > > > After this LONG thread, it seems that there are strong arguments > against the self-contained OLRs and little support. > > In the contrary, it seems that the principle of OLR related to the > application in use is technically OK for everyone. > > > > So the question is quite simple: > > > > Could everyone live/survive with the "implicit approach" with the > extensibility mechanism allowing future extensions if needed? > > > > If yes, please focus on the finalization of the current draft. > > If no, let go on the discussion. > > > > Regards, > > > > Lionel > > > > > > *De :*DiME [mailto:dime-bounces@ietf.org] *De la part de* Steve > Donovan > *Envoyé :* jeudi 5 décembre 2013 14:06 > *À :* dime@ietf.org > *Objet :* Re: [Dime] DOIC: Self-Contained OLRs > > > > On the schedule question mentioned by JJacques -- any schedule > concerns can go away if everyone agrees to self contained overload > reports. This discussion would end and we could move on to other > things. :-) > > I say that somewhat in jest but please don't make the argument > that this discussion should be ended because of schedule. Or if > you make that argument, please don't assert that the person who > disagrees with you is putting the schedule at risk. > > We are striving for the best technical solution. We all > understand the schedule pressures. We need to balance the two. > > Steve > > On 12/5/13 5:14 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote: > > Hi > > > > A lot of mails on this topic...I would suggest to introduce an overload control on the Dime email threads:) > > > > > > On my side, I rely on what we have written in the draft for the "baseline" mechanism and that we have to keep as it is simple and efficient, here I join Lionel, Nirav and MCruz' positions. > > > > This thread then addresses extensions cases, I agree that we will have to address such extensions: Nirav mentioned the example with APN that if relevant would a 3GGP application case, I would add the Session Group about which we had some discussion a while ago and which is a more generic IETF case. There is also the agent overload case. Have you others? Always good to have some use cases in mind. > > > > What is important for me is that adding extensions should not modify the baseline and making it more complex when used alone. I also make a difference between principles and protocol tuning where we may have to choose between various protocol solution but addressing the same functionality or principle. > > > > About piggybacking, in the baseline, the principle is that OLRs which are addressed to sources of traffic are put in answer messages towards this traffic sources (origin Host) (even if these messages may be processed by intermediate DAs), which is simple and the OLR can be kept unchanged in the same message up to the origin Host if no specific process in intermediate DAs. To have a piggybacking allowing to put any OLR in any message (as it was in draft roach) is adding complexity that is not justified for the baseline and we have not retained it in the existing draft . > > > > About extensions, the APN or session group examples address parts of the traffic between a server and a client (so a higher granularity in the throttling than the baseline one), related OLRs are conveyed in the messages towards the origin Host so with an implicit reference to the Application, the Origin and Destination Host as for the baseline, so not requiring self contained OLRs. I also do not see the interest to send these new extensions OLR only in answers directly related to this OLR (as Ulrich proposed), eg only in an answer dealing with an APN if the OLR is related to APN throttling. The main point is that the OLR takes a direct "train" towards the right destination for a given application (as for baseline). > > > > This does not exclude that we may have other cases not entering the above examples characteristics, but as Nirav mentioned, we have to remain pragmatic and see this when such new use cases will be addressed. The extensibility possibilities of current draft give us a lot of flexibility, e.g. if some extensions need more self contained AVPs, why not, but this is outside the current draft. > > > > About extensions, I also think that they may need to be identified in the capability part, as the related OLRs should not be sent by a reacting node if the extension is not supported. > > > > Last important point, as Lionel mentioned, we have to finalize the draft soon, to be able to start Rel12 3GGP work relying on this draft. My position is that the current draft is currently well suited for the baseline and that extensions will be addressed separately > > > > Best regards > > > > JJacques > > > > > > -----Message d'origine----- > > De : DiME [mailto:dime-bounces@ietf.org] De la part de Ben Campbell > > Envoyé : mercredi 4 décembre 2013 22:55 > > À : ext lionel.morand@orange.com > > Cc : dime@ietf.org > > Objet : Re: [Dime] DOIC: Self-Contained OLRs > > > > On Dec 3, 2013, at 5:17 PM, lionel.morand@orange.com wrote: > > > > Hi Ben, > > > > I may be wrong somewhere in my summary but I think that it was the result of the discussions and agreements reached regarding existing requirements, at least from 3GPP point of view, compared to possible optimizations for future optimizations not so obvious. > > > > We are not the 3GPP. Our requirements are RFC 7068. I believe self-contained OLRs do a better job of meeting Req 31 than the contextually-defined OLRs. > > > > I've made several technical arguments here--does anyone have _technical_ arguments in favor of contextually-defined OLRs? > > > > And because the solution offers extensibility via the definition of new algo, new report type and addition of any new AVP in the existing Grouped OLR, the "limitations" of the proposed solution might be removed by someone if really required according to new requirements. > > > > > > It might be worth considering a compromise approach: Define _optional_ AVPs that allow an OLR to be self-contained. If they are not present, then the various values default to those from the enclosing Diameter message. Possibly add support for this to the list of things that reacting nodes can advertise. > > > > This could be in the base, or in a follow on extension. (If left for an extension, it's worth considering whether ReportType needs to be in the base, or this or some other extension.) > > > > > > Regards, > > > > Lionel > > > > -----Message d'origine----- > > De : Ben Campbell [mailto:ben@nostrum.com] Envoyé : mardi 3 décembre > > 2013 23:56 À : MORAND Lionel IMT/OLN Cc : Steve Donovan; dime@ietf.org > > Objet : Re: [Dime] DOIC: Self-Contained OLRs > > > > > > On Dec 2, 2013, at 10:18 AM, lionel.morand@orange.com wrote: > > > > Hi Steve, > > > > I think that is not only about few bytes in the answer. It is also about the solution principles agreed so far: > > · the current need is for an OLR bound to the application in use > > · the OLR is received from the node targeted in the request. > > · the OLR is defined per application > > > > I don't think those principles have been well tested. I don't recall any discussion of their benefits. What benefits do you see they have over self-contained OLRs? > > > > All I see from these are restrictions in the flexibility of the solution, with very little in return. > > > > So all the implicit information (application, origin-host, origin-realm) are meaningful in this context. > > And the actual solution is designed based on these assumptions. The extensibility of the solution will allow extra info if required in other use cases but it was agreed to go with a straightforward solution that will satisfy most of us. > > > > Regards, > > > > Lionel > > > > De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan > > Envoyé : lundi 2 décembre 2013 16:37 > > À : dime@ietf.org > > Objet : Re: [Dime] DOIC: Self-Contained OLRs > > > > I don't believe that Ben's proposal was to change the piggybacking assumption in the baseline mechanism. Ben's proposal is to design the solution in such a way that it is not dependent on the piggybacking transport mechanism. > > > > I share Ben's concern that we have over optimized the content of the overload report in a way that makes implementations brittle, interoperability more difficult to achieve and extensibility more complex. And what do we gain from this optimization? A few bites in answer messages. > > > > Self contained overload reports, transported using the piggybacking mechanism, is a cleaner solution. > > > > Steve > > > > On 11/29/13 8:31 AM, lionel.morand@orange.com wrote: > > I totally agree with Nirav. No need to revert at this stage the working assumption on piggybacking of OLR in application answer messages, especially when the aim is to define a basic mechanism called "reduction". > > > > Anyone would be able to further add extra info for optimization if needed but there is no need at all for the basic mechanism. > > > > Regards, > > > > Lionel > > > > -----Message d'origine----- > > De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot (nsalot) > > Envoyé : vendredi 29 novembre 2013 12:24 > > À : Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list > > Cc : Ben Campbell > > Objet : Re: [Dime] DOIC: Self-Contained OLRs > > > > Jouni, Ben, > > > > I am totally against the idea of self-contained OC-OLR specifically since we have adopted the principles of piggybacking the OC-OLR over existing application message. > > Self-contained OC-OLR - which means adding all the information which defines the scope of the OC-OLR into the OC-OLR - does not make sense in the piggybacking approach. In fact, it is adding lot of information, which is anyway available within the message containing the OC-OLR, into the OC-OLR. So it is adding lot of redundant information in a message which increases the processing requirement for the sender as well as the receiver. (And this is un-optimization, in my view). > > > > Besides, I am not convinced with the other reasons provided here: > > - One software module within a node can provide OC-OLR to another software module in the same node without passing other related info > > Within a node, based on the design, lots of information may need to be passed between two software modules and we cannot optimize those aspects by replicating unnecessary information in a protocol message. > > In summary, it is node's internal software design issue and we need not optimize that at protocol level. > > > > - Once the reporting node realizes that it is overloaded, it has to wait for right answer to send OC-OLR > > What is the point of sending OC-OLR for a context for which there is no messaging? Why should the reacting node care if it never sends a message for a context for which the reporting node is overloaded? > > So this waiting is justified since it ensures that the overload is reported only when necessary and only to the applicable reacting node. Not to all the nodes in the network. > > > > - The agent needs to wait for the answer generated by the server and the right context > > The same argument as applicable for the server applies here. The agent need not send out-of-context overload info to a node. > > Why should reacting node receive/process/store the overload info for the scope for which it is not sending any messages. > > > > - For sending OC-OLR in dedicated Diameter application??? > > Piggybacking was the first basic principle we agreed before putting other principles in place. So we may want to go back the drawing board if we decide to change this principle. > > > > Regards, > > Nirav. > > > > -----Original Message----- > > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen > > Sent: Friday, November 29, 2013 2:50 PM > > To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list > > Cc: Ben Campbell > > Subject: Re: [Dime] DOIC: Self-Contained OLRs > > > > > > > > So, are we reaching any level of consensus here? > > > > - JOuni > > > > (as a note.. that we are converging back to where we started with OLRs ;) > > > > > > > > On Nov 28, 2013, at 12:40 PM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: > > > > Hi, > > > > another question: > > > > If we go for explicit self contained OLRs, why would we then need the ReportType? > > > > The realm-type OLR would explicitly contain application-Id, Realm, but no Host whereas the host-type OLR would explicitly contain application-Id, Host, but probably (I'm not sure) no Realm. > > > > 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 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. > > > > > > _______________________________________________ > > 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. > > > > _______________________________________________ > > 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 > > > > > > _________________________________________________________________________________________________________________________ > > > > 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. > > > > > _______________________________________________ > > 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 --------------000203040500050908050207 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Lionel,

Please see my responses inline.

Steve
On 12/5/13 8:01 AM, lionel.morand@orange.com wrote:

Hi Steve,

 

So let's go on the discussion.

 

As individual below…

 

De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoyé : jeudi 5 décembre 2013 14:52
À : dime@ietf.org
Objet : Re: [Dime] DOIC: Self-Contained OLRs

 

Lionel,

I strongly disagree with your conclusion that there is little support for self-contained OLRs. 

[LM] could you point which one?

SRD> I don't understand your question.  The fact that this discussion has gone on as long as it has is evidence that there is support for self-contained OLRs.

I also object to your assessment that there are strong arguments against self-contained reports.  I have yet to see a single STRONG argument.

[LM] wrong. The right sentence should be that you don't consider comments against your proposal as valid.

SRD> No, I didn't say there were no arguments, just not strong ones.  You stated the opinion that there were strong arguments.  I stated the counter opinion that there are no strong arguments.  Both statements are opinions.


I also object to your attempting to call the question at this point in the discussion.

[LM] just an attempt to see if we could come to a agreement based on my distorted summary

SRD> In my opinion both your motives and timing were bad.

The only arguments I see for the implicit approach is complexity, which I just sent an email refuting and schedule, about which I also just sent an email.

Self contained reports work just as well and has advantages both short term in support for non application specific software layering and in the long term in allowing for the same overload report to be transported using multiple DOC solutions.

I also don't agree that this has been a particularly long thread.  There are multiple topics being discussed under the same subject line.

[LM] this topic is discussed fro several months, at least one year. I was not referring to the current title.

SRD> Then lets work for a positive way to come to a conclusion.

If we are to pose a question at this point I would suggest -- Can everyone live with self-contained overload reports?

[LM] and I would say "NO"

Steve

On 12/5/13 7:28 AM, lionel.morand@orange.com wrote:

All,

 

After this LONG thread, it seems that there are strong arguments against the self-contained OLRs and little support.

In the contrary, it seems that the principle of OLR related to the application in use is technically OK for everyone.

 

So the question is quite simple:

 

Could everyone live/survive with the "implicit approach" with the extensibility mechanism allowing future extensions if needed?

 

If yes, please focus on the finalization of the current draft.

If no, let go on the discussion.

 

Regards,

 

Lionel

 

 

De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoyé : jeudi 5 décembre 2013 14:06
À : dime@ietf.org
Objet : Re: [Dime] DOIC: Self-Contained OLRs

 

On the schedule question mentioned by JJacques -- any schedule concerns can go away if everyone agrees to self contained overload reports.  This discussion would end and we could move on to other things.  :-)

I say that somewhat in jest but please don't make the argument that this discussion should be ended because of schedule.  Or if you make that argument, please don't assert that the person who disagrees with you is putting the schedule at risk.

We are striving for the best technical solution.  We all understand the schedule pressures.  We need to balance the two.

Steve

On 12/5/13 5:14 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:

Hi 
 
A lot of mails on this topic...I would suggest to introduce an overload control on the Dime email threads:)  
 
 
On my side, I rely on what we have written in the  draft for the "baseline" mechanism and that we have to keep as it is simple and efficient, here I join Lionel, Nirav and MCruz' positions.
 
This thread then addresses extensions  cases, I agree that we will have to address such extensions:   Nirav mentioned the example with APN that if relevant would  a 3GGP application case, I would add the Session Group about which we had some discussion a while ago and  which is a more generic IETF case. There is also the agent overload case. Have you others? Always good to have some use cases in mind.
 
What is important for me is that adding extensions should not modify the baseline and making it more complex when used alone.  I also make a difference between principles and protocol tuning where we may have to choose between various protocol solution but addressing the same functionality or principle.  
 
About piggybacking, in the baseline,  the principle is that OLRs  which  are addressed  to sources of traffic are put in answer messages towards this traffic sources (origin Host) (even if these messages  may be processed by intermediate DAs), which is simple and the OLR can be kept unchanged in the same message  up to the origin Host if no specific process in intermediate DAs.  To have a piggybacking allowing to put any OLR in any message (as it was in draft roach)  is adding complexity that is not justified for the baseline and we have not retained it in the existing draft .
 
About extensions, the APN or session group  examples address  parts of the traffic between a server and a client (so a higher granularity in the throttling than the baseline one), related OLRs are conveyed in the messages towards the origin Host so with an implicit reference to the Application, the  Origin and Destination Host as for the baseline, so not requiring self contained OLRs. I also  do not see the interest to send these new extensions OLR only in answers directly related to this OLR (as Ulrich proposed), eg only in an answer dealing with an APN if the OLR is related to APN throttling.  The main point is that the OLR takes a direct "train" towards the right destination for a given application (as for baseline).
 
This does not exclude that we may have other cases not entering the above examples characteristics, but as Nirav mentioned, we  have to remain pragmatic and see this when such new use cases will be addressed. The extensibility possibilities of  current draft give us a lot of flexibility, e.g. if some extensions need more self contained AVPs, why not, but this is outside the current draft. 
 
About extensions, I also think that they may need to be identified in the capability part, as the related OLRs should not be sent by a reacting node if the extension is not supported.
 
Last important point, as  Lionel mentioned, we have to finalize the draft soon, to be able to start Rel12 3GGP work relying on this draft. My position is that the current draft is currently well suited for the baseline and that extensions will be addressed separately  
 
Best regards
 
JJacques 
 
 
-----Message d'origine-----
De : DiME [mailto:dime-bounces@ietf.org] De la part de Ben Campbell
Envoyé : mercredi 4 décembre 2013 22:55
À : ext lionel.morand@orange.com
Cc : dime@ietf.org
Objet : Re: [Dime] DOIC: Self-Contained OLRs
 
On Dec 3, 2013, at 5:17 PM, lionel.morand@orange.com wrote:
 
Hi Ben,
 
I may be wrong somewhere in my summary but I think that it was the result of the discussions and agreements reached regarding existing requirements, at least from 3GPP point of view, compared to possible optimizations for future optimizations not so obvious.
 
We are not the 3GPP. Our requirements are RFC 7068. I believe self-contained OLRs do a better job of meeting Req 31 than the contextually-defined OLRs.
 
I've made several technical arguments here--does anyone have _technical_ arguments in favor of contextually-defined OLRs?
 
And because the solution offers extensibility via the definition of new algo, new report type and addition of any new AVP in the existing Grouped OLR, the "limitations" of the proposed solution might be removed by someone if really required according to new requirements.
 
 
It might be worth considering a compromise approach: Define _optional_ AVPs that allow an OLR to be self-contained. If they are not present, then the various values default to those from the enclosing Diameter message. Possibly add support for this to the list of things that reacting nodes can advertise.
 
This could be in the base, or in a follow on extension. (If left for an extension, it's worth considering whether ReportType needs to be in the base, or this or some other extension.) 
 
 
Regards,
 
Lionel
 
-----Message d'origine-----
De : Ben Campbell [mailto:ben@nostrum.com] Envoyé : mardi 3 décembre 
2013 23:56 À : MORAND Lionel IMT/OLN Cc : Steve Donovan; dime@ietf.org 
Objet : Re: [Dime] DOIC: Self-Contained OLRs
 
 
On Dec 2, 2013, at 10:18 AM, lionel.morand@orange.com wrote:
 
Hi Steve,
 
I think that is not only about few bytes in the answer. It is also about the solution principles agreed so far:
·         the current need is for an OLR bound to the application in use
·         the OLR is received from the node targeted in the request.
·         the OLR is defined per application
 
I don't think those principles have been well tested. I don't recall any discussion of their benefits. What benefits do you see they have over self-contained OLRs?
 
All I see from these are restrictions in the flexibility of the solution, with very little in return.
 
So all the implicit information (application, origin-host, origin-realm) are meaningful in this context.
And the actual solution is designed based on these assumptions. The extensibility of the solution will allow extra info if required in other use cases but it was agreed to go with a straightforward solution that will satisfy most of us.
 
Regards,
 
Lionel
 
De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoyé : lundi 2 décembre 2013 16:37
À : dime@ietf.org
Objet : Re: [Dime] DOIC: Self-Contained OLRs
 
I don't believe that Ben's proposal was to change the piggybacking assumption in the baseline mechanism.  Ben's proposal is to design the solution in such a way that it is not dependent on the piggybacking transport mechanism.  
 
I share Ben's concern that we have over optimized the content of the overload report in a way that makes implementations brittle, interoperability more difficult to achieve and extensibility more complex.  And what do we gain from this optimization?  A few bites in answer messages.
 
Self contained overload reports, transported using the piggybacking mechanism, is a cleaner solution.
 
Steve
 
On 11/29/13 8:31 AM, lionel.morand@orange.com wrote:
I totally agree with Nirav. No need to revert at this stage the working assumption on piggybacking of OLR in application answer messages, especially when the aim is to define a basic mechanism called "reduction".
 
Anyone would be able to further add extra info for optimization if needed but there is no need at all for the basic mechanism.
 
Regards,
 
Lionel
 
-----Message d'origine-----
De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot (nsalot)
Envoyé : vendredi 29 novembre 2013 12:24
À : Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list
Cc : Ben Campbell
Objet : Re: [Dime] DOIC: Self-Contained OLRs
 
Jouni, Ben,
 
I am totally against the idea of self-contained OC-OLR specifically since we have adopted the principles of piggybacking the OC-OLR over existing application message.
Self-contained OC-OLR - which means adding all the information which defines the scope of the OC-OLR into the OC-OLR - does not make sense in the piggybacking approach. In fact, it is adding lot of information, which is anyway available within the message containing the OC-OLR, into the OC-OLR. So it is adding lot of redundant information in a message which increases the processing requirement for the sender as well as the receiver. (And this is un-optimization, in my view).
 
Besides, I am not convinced with the other reasons provided here:
- One software module within a node can provide OC-OLR to another software module in the same node without passing other related info
  Within a node, based on the design, lots of information may need to be passed between two software modules and we cannot optimize those aspects by replicating unnecessary information in a protocol message.
  In summary, it is node's internal software design issue and we need not optimize that at protocol level.
 
- Once the reporting node realizes that it is overloaded, it has to wait for right answer to send OC-OLR
 What is the point of sending OC-OLR for a context for which there is no messaging? Why should the reacting node care if it never sends a message for a context for which the reporting node is overloaded?
 So this waiting is justified since it ensures that the overload is reported only when necessary and only to the applicable reacting node. Not to all the nodes in the network.
 
- The agent needs to wait for the answer generated by the server and the right context
  The same argument as applicable for the server applies here. The agent need not send out-of-context overload info to a node.
  Why should reacting node receive/process/store the overload info for the scope for which it is not sending any messages.
 
- For sending OC-OLR in dedicated Diameter application???
 Piggybacking was the first basic principle we agreed before putting other principles in place. So we may want to go back the drawing board if we decide to change this principle.
 
Regards,
Nirav.
 
-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen
Sent: Friday, November 29, 2013 2:50 PM
To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list
Cc: Ben Campbell
Subject: Re: [Dime] DOIC: Self-Contained OLRs
 
 
 
So, are we reaching any level of consensus here?
 
- JOuni
 
(as a note.. that we are converging back to where we started with OLRs ;)
 
 
 
On Nov 28, 2013, at 12:40 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> wrote:
 
Hi,
 
another question:
 
If we go for explicit self contained OLRs, why would we then need the ReportType?
 
The realm-type OLR would explicitly contain application-Id, Realm, but no Host whereas the host-type OLR would explicitly contain application-Id, Host, but probably (I'm not sure) no Realm.
 
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.
 
 
_______________________________________________
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.
 
_______________________________________________
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
 
 
_________________________________________________________________________________________________________________________
 
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.




_______________________________________________
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

--------------000203040500050908050207-- From nsalot@cisco.com Thu Dec 5 06:25:48 2013 Return-Path: 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 8AA581AE01E for ; Thu, 5 Dec 2013 06:25:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.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 U48mYGUVATe4 for ; Thu, 5 Dec 2013 06:25:37 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id E5D0F1AE002 for ; Thu, 5 Dec 2013 06:25:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=77983; q=dns/txt; s=iport; t=1386253534; x=1387463134; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=0mUs80RDoHuVBROQmJl6Kwyn7l7LgZHIoFK1u4F1dPk=; b=UafqJ0rQMZ4yQAFCY3Vv6aKxkq5dCtE9eli3NWYhxnUiKbT59Ho6OubQ davzqWi3J3LqWc1O1wlwRq4QOycqIJZz9XQoWXG1eUADxcGk4rH4RDwpf NxigfHeHzlKaTpvB4P/rLQQg3ThMWEaOp452Bam7psEPSLm3IdDX6gATb k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8FADSMoFKtJV2Z/2dsb2JhbABZgkNEOFO4bYEbFnSCJQEBAQMBAQEBFwESOgUCBgIIBwQCAQgOAwEDAQELFgEGBycLFAMGCAIEARIIE4dhBg3BXRMEjh0BEAIBHi0KAQaDGoETA4kKoR2DKYIq X-IronPort-AV: E=Sophos;i="4.93,833,1378857600"; d="scan'208,217";a="289565643" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 05 Dec 2013 14:25:30 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rB5EPUnk016700 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Dec 2013 14:25:30 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.250]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Thu, 5 Dec 2013 08:25:30 -0600 From: "Nirav Salot (nsalot)" To: Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] DOIC: Self-Contained OLRs Thread-Index: AQHO67/s/vGpiVuf2UayvwQoJbzwfZo6EVYAgACzUoCAAAFygIAAE10AgAF8EQD//7X5YIAAoQmAgATJUQCAAAuBAIACAWkAgAAGHYCAAXsigIAALuKAgAAb/4CAAAErgIAAr54A//+ppoCAAGqjAP//nQJw Date: Thu, 5 Dec 2013 14:25:29 +0000 Message-ID: References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <8467_1385735507_5298A553_8467_17054_3_6B7134B31289DC4FAF731D844122B36E309D0D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <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> <14594_1386204165_529FCC05_14594_12646_1_6B7134B31289DC4FAF731D844122B36E329907@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B920972CCAA@ESESSMB101.ericsson.se> <52A077CC.3000004@usdonovans.com> <52A088D0.2020406@usdonovans.com> In-Reply-To: <52A088D0.2020406@usdonovans.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.234.42] Content-Type: multipart/alternative; boundary="_000_A9CA33BB78081F478946E4F34BF9AAA014D25A08xmbrcdx10ciscoc_" MIME-Version: 1.0 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 14:25:48 -0000 --_000_A9CA33BB78081F478946E4F34BF9AAA014D25A08xmbrcdx10ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Steve, We assumed that "self-contained OC-OLR" contains the same information as th= e message containing this AVP and hence we (me, JJ, Maria-Cruz) were saying= that consistency check is needed. But now I understand that "self-contained OC-OLR" can contain information o= f any context since the AVP itself defines the context explicitly. So appli= cation-X message can carry application-Y's OC-OLR and I do not agree to thi= s. In my view, this is totally against the existing principles of Diameter bas= ed applications. And hence this requires special support at the receiving n= ode as well as the sending node since today the nodes are designed to handl= e only application specific data. In summary, "self-contained OC-OLR" puts a special architectural requiremen= t on Diameter nodes - to handle one application's data from other applicati= on's message - and hence this is a strong reason for me to object to "self-= contained OC-OLR". Regards, Nirav. From: Steve Donovan [mailto:srdonovan@usdonovans.com] Sent: Thursday, December 05, 2013 7:38 PM To: Nirav Salot (nsalot); dime@ietf.org Subject: Re: [Dime] DOIC: Self-Contained OLRs I must admit that I don't understand the need for consistency. Why is it necessary to compare implicit and explicit data? If we use self = contained reports then the contents of the report are what should be used, = independent of the message that carries the report. Steve On 12/5/13 7:49 AM, Nirav Salot (nsalot) wrote: Steve, While gauging the complexity of "using the self-contained OC-OLR" It seems = you have overlooked the aspect identified by Maria-Cruz below (and JJ earli= er). > Duplication should be avoided, since then we need to assure consistency, = and error handing in case implicit and explicit data values are different f= or any reason... what means that it may always be required to check both im= plicit and explicit data. Regards, Nirav. From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: Thursday, December 05, 2013 6:26 PM To: dime@ietf.org Subject: Re: [Dime] DOIC: Self-Contained OLRs If we equating "complexity" with work done by a Diameter node, then there i= s added "complexity" for both proposals. The extra work that needs to be done for the self contained report approach= is that the reporter needs to add additional AVPs to the report. This is = hardly difficult but it is extra work. The extra work in the implicit approach is that the reactor needs to gather= information from multiple AVPs to understand the context of the AVP. Agai= n, hardly difficult but more work that can be avoided in a well layered sof= tware architecture. My conclusion is that the complexity argument does not apply. There is com= plexity in both, its just a matter of where the work is done. Steve On 12/5/13 3:29 AM, Nirav Salot (nsalot) wrote: Agree with Lionel's view and Maria-Cruz's arguments below. The "self-contained OC-OLR" - which I assume contains the same information = as present in the message containing the OC-OLR - adds extra complexity as = highlighted by Maria-Cruz. The benefit highlighted can be achieved in an implementation specific way b= y the receiver duplicating the information into OC-OLR before passing it to= the layer processing the OC-OLR. Regards, Nirav. -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Maria Cruz Bartolome Sent: Thursday, December 05, 2013 7:53 AM To: dime@ietf.org Subject: Re: [Dime] DOIC: Self-Contained OLRs Dear all, I agree with Lionel argumentation below. A part from that, one concern with "self-contained OLRs" is that some data= is duplicated. Duplication should be avoided, since then we need to assure= consistency, and error handing in case implicit and explicit data values a= re different for any reason... what means that it may always be required to= check both implicit and explicit data. Also, I think this is a pure implementation proposal. Regardless how the da= ta is transported it could be packed in a "self-contained OLRs" within the = diameter application, if for any implementation this is preferred. Regards /MCruz -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange= .com Sent: jueves, 05 de diciembre de 2013 1:43 To: Ben Campbell Cc: dime@ietf.org Subject: Re: [Dime] DOIC: Self-Contained OLRs Hi Ben, 3GPP operational requirements have triggered and driven this work, and 3GPP= will be the main client for this solution (if not the only for a while...)= . Main parties involved in the discussions are 3GPP vendors and 3GPP operat= ors. So instead trying to keep private preserve, we should welcome and enfo= rce cooperative work with 3GPP on this task if we want that the solution de= fined in IETF will be used in 3GPP. Otherwise, 3GPP may decide not to wait = for IETF and develop its own solution, as done in the past (e.g. developing= 3GPP-specific Cx application instead of adopting the IETF-standard Diamete= r SIP application). About the technical discussion, the Req31 says: REQ 31: There are multiple situations where a Diameter node may be overloaded for some purposes but not others. For example, this can happen to an agent or server that supports multiple applications, or when a server depends on multiple external resources, some of which may become overloaded while others are fully available. The solution MUST allow Diameter nodes to indicate overload with sufficient granularity to allow clients to take action based on the overloaded resources without unreasonably forcing available capacity to go unused. The solution MUST support specification of overload information with granularities of at least "Diameter node", "realm", and "Diameter application" and MUST allow extensibility for others to be added in the future. The "MUST" part says: enough granularity with at least host/realm and appli= cation. And the existing solution is compliant with this requirement. If a node is = supporting N applications, an OLR can be sent "per application" with a repo= rt type indicating if it is for the host or the realm. And the extensibilit= y capability is provided by the base solution. So my technical argument is that the existing proposal fulfills the basic r= equirements for an overload control without compromising future extension f= or further granularity. Regards, Lionel -----Message d'origine----- De : Ben Campbell [mailto:ben@nostrum.com] Envoy=E9 : mercredi 4 d=E9cembre= 2013 22:55 =C0 : MORAND Lionel IMT/OLN Cc : dime@ietf.org Objet : Re: [Dime] DOIC: Self-Contained OLRs On Dec 3, 2013, at 5:17 PM, lionel.morand@orange.com wrote: Hi Ben, I may be wrong somewhere in my summary but I think that it was the result o= f the discussions and agreements reached regarding existing requirements, a= t least from 3GPP point of view, compared to possible optimizations for fut= ure optimizations not so obvious. We are not the 3GPP. Our requirements are RFC 7068. I believe self-containe= d OLRs do a better job of meeting Req 31 than the contextually-defined OLRs= . I've made several technical arguments here--does anyone have _technical_ ar= guments in favor of contextually-defined OLRs? And because the solution offers extensibility via the definition of new alg= o, new report type and addition of any new AVP in the existing Grouped OLR,= the "limitations" of the proposed solution might be removed by someone if = really required according to new requirements. It might be worth considering a compromise approach: Define _optional_ AVPs= that allow an OLR to be self-contained. If they are not present, then the = various values default to those from the enclosing Diameter message. Possib= ly add support for this to the list of things that reacting nodes can adver= tise. This could be in the base, or in a follow on extension. (If left for an ext= ension, it's worth considering whether ReportType needs to be in the base, = or this or some other extension.) Regards, Lionel -----Message d'origine----- De : Ben Campbell [mailto:ben@nostrum.com] Envoy=E9 : mardi 3 d=E9cembre 2013 23:56 =C0 : MORAND Lionel IMT/OLN Cc : Steve Donovan; dime@ietf.org Objet : Re: [Dime] DOIC: Self-Contained OLRs On Dec 2, 2013, at 10:18 AM, lionel.morand@orange.com wrote: Hi Steve, I think that is not only about few bytes in the answer. It is also about th= e solution principles agreed so far: =B7 the current need is for an OLR bound to the application in use =B7 the OLR is received from the node targeted in the request. =B7 the OLR is defined per application I don't think those principles have been well tested. I don't recall any di= scussion of their benefits. What benefits do you see they have over self-co= ntained OLRs? All I see from these are restrictions in the flexibility of the solution, w= ith very little in return. So all the implicit information (application, origin-host, origin-realm) ar= e meaningful in this context. And the actual solution is designed based on these assumptions. The extensi= bility of the solution will allow extra info if required in other use cases= but it was agreed to go with a straightforward solution that will satisfy = most of us. Regards, Lionel De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan Envoy=E9 : lundi 2 d=E9cembre 2013 16:37 =C0 : dime@ietf.org Objet : Re: [Dime] DOIC: Self-Contained OLRs I don't believe that Ben's proposal was to change the piggybacking assumpti= on in the baseline mechanism. Ben's proposal is to design the solution in = such a way that it is not dependent on the piggybacking transport mechanism= . I share Ben's concern that we have over optimized the content of the overlo= ad report in a way that makes implementations brittle, interoperability mor= e difficult to achieve and extensibility more complex. And what do we gain= from this optimization? A few bites in answer messages. Self contained overload reports, transported using the piggybacking mechani= sm, is a cleaner solution. Steve On 11/29/13 8:31 AM, lionel.morand@orange.com wrote: I totally agree with Nirav. No need to revert at this stage the working ass= umption on piggybacking of OLR in application answer messages, especially w= hen the aim is to define a basic mechanism called "reduction". Anyone would be able to further add extra info for optimization if needed b= ut there is no need at all for the basic mechanism. Regards, Lionel -----Message d'origine----- De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot (nsalot) Envoy=E9 : vendredi 29 novembre 2013 12:24 =C0 : Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list Cc : Ben Campbell Objet : Re: [Dime] DOIC: Self-Contained OLRs Jouni, Ben, I am totally against the idea of self-contained OC-OLR specifically since w= e have adopted the principles of piggybacking the OC-OLR over existing appl= ication message. Self-contained OC-OLR - which means adding all the information which define= s the scope of the OC-OLR into the OC-OLR - does not make sense in the pigg= ybacking approach. In fact, it is adding lot of information, which is anywa= y available within the message containing the OC-OLR, into the OC-OLR. So i= t is adding lot of redundant information in a message which increases the p= rocessing requirement for the sender as well as the receiver. (And this is = un-optimization, in my view). Besides, I am not convinced with the other reasons provided here: - One software module within a node can provide OC-OLR to another software = module in the same node without passing other related info Within a node, based on the design, lots of information may need to be pa= ssed between two software modules and we cannot optimize those aspects by r= eplicating unnecessary information in a protocol message. In summary, it is node's internal software design issue and we need not o= ptimize that at protocol level. - Once the reporting node realizes that it is overloaded, it has to wait fo= r right answer to send OC-OLR What is the point of sending OC-OLR for a context for which there is no me= ssaging? Why should the reacting node care if it never sends a message for = a context for which the reporting node is overloaded? So this waiting is justified since it ensures that the overload is reporte= d only when necessary and only to the applicable reacting node. Not to all = the nodes in the network. - The agent needs to wait for the answer generated by the server and the ri= ght context The same argument as applicable for the server applies here. The agent ne= ed not send out-of-context overload info to a node. Why should reacting node receive/process/store the overload info for the = scope for which it is not sending any messages. - For sending OC-OLR in dedicated Diameter application??? Piggybacking was the first basic principle we agreed before putting other = principles in place. So we may want to go back the drawing board if we deci= de to change this principle. Regards, Nirav. -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen Sent: Friday, November 29, 2013 2:50 PM To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org li= st Cc: Ben Campbell Subject: Re: [Dime] DOIC: Self-Contained OLRs So, are we reaching any level of consensus here? - JOuni (as a note.. that we are converging back to where we started with OLRs ;) On Nov 28, 2013, at 12:40 PM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: Hi, another question: If we go for explicit self contained OLRs, why would we then need the Repor= tType? The realm-type OLR would explicitly contain application-Id, Realm, but no H= ost whereas the host-type OLR would explicitly contain application-Id, Host= , but probably (I'm not sure) no Realm. 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 stat= us. It could be provided an agent inserting this info in answers received f= rom a server behind but also from a server that would know this info by som= e internal magic. But in any case, if we assume that the client will received a successful an= swer from the server for an initial request with only Dest-Realm AVP, it sh= ould be possible to have both report types in the answer: one for the serve= r itself, one for the realm for new request sent to the realm with only Des= t-Realm AVP. Lionel -----Message d'origine----- De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN - DE/Munich) Envoy=E9 : jeudi 28 novembre 2013 10:26 =C0 : 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 a= ligned with the "endpoint principle". If the ReportType is "realm" this ind= icates 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 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 re= acting 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 Diamet= er request that corresponds to the answer containing the OLR. My reasons fo= r 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 i= dentified by Origin-Realm, and so on. This means that the "meaning" of an O= LR 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 answe= r to another, it's meaning may change completely. I think this approach is a mistake. I would greatly prefer that we explicit= ly 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 variou= s other AVPs to find all the information it needs. For example, I think a c= ommon software design for overload control processing to be separated from = application processing. The consumer cannot simply hand the OLR to that mod= ule and expect things to work. The OC module must not only parse the OLR, b= ut parse any other AVPs that are relevant. As OLR contents get extended (as= sumedly following the same strategy as the base spec), the number of "conte= xt" avps that must be interpreted can grow large. This approach is error pr= one, and will likely encourage brittle, hard-to-maintain code. Self-contain= ed OLRs would keep all the information related to overload in one place. ma= king for simpler implementations. 2) It's more complex for the reporting node to send implicit values than ex= plicit values. The sender cannot simply set the context to match the OLR--a= ll those other AVPs have application or protocol layer meanings. Once a rep= orting node realizes that it is overloade, it has to wait for the right ans= wer that contains the right context before it can send the OLR. This is par= ticularly 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 sig= nificantly. 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 so= me 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 overlo= ad reports were self-contained, one could just reuse the report format we s= pecify here. But if the meaning of an OLR depends on the way it's transport= ed, this won't work. We would have to create a new or significantly modifie= d OLR format if we found a need to transport OLRs in different ways. Self-c= ontained OLRs would allow much greater flexibility. So, in summary, I think that self-contained OLRs would lead to simpler impl= ementations, less brittle deployments, and more flexibility for future evol= ution 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 le= s pieces jointes. Les messages electroniques etant susceptibles d'alteratio= n, 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 dis= tributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te 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 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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 confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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 confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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 confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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 --_000_A9CA33BB78081F478946E4F34BF9AAA014D25A08xmbrcdx10ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Steve,<= /p>

 <= /p>

We assumed that "sel= f-contained OC-OLR" contains the same information as the message conta= ining this AVP and hence we (me, JJ, Maria-Cruz) were saying that consistency check is needed.

 <= /p>

But now I understand that= "self-contained OC-OLR" can contain information of any context s= ince the AVP itself defines the context explicitly. So application-X message can carry application-Y's OC-OLR and I do not agree to this.<= /o:p>

In my view, this is total= ly against the existing principles of Diameter based applications. And henc= e this requires special support at the receiving node as well as the sending node since today the nodes are designed to handle only= application specific data.

 <= /p>

In summary, "self-co= ntained OC-OLR" puts a special architectural requirement on Diameter n= odes – to handle one application's data from other application's mess= age – and hence this is a strong reason for me to object to "self-c= ontained OC-OLR".

 <= /p>

Regards,

Nirav.<= /p>

 <= /p>

From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Thursday, December 05, 2013 7:38 PM
To: Nirav Salot (nsalot); dime@ietf.org
Subject: Re: [Dime] DOIC: Self-Contained OLRs

 

I must admit that I d= on't understand the need for consistency.

Why is it necessary to compare implicit and explicit data?  If we use = self contained reports then the contents of the report are what should be u= sed, independent of the message that carries the report.

Steve

On 12/5/13 7:49 AM, Nirav Salot (nsalot) wrote:=

Steve,<= /p>

 <= /p>

While gauging the complex= ity of "using the self-contained OC-OLR" It seems you have overlo= oked the aspect identified by Maria-Cruz below (and JJ earlier).

> Duplication s= hould be avoided, since then we need to assure consistency, and error handi= ng in case implicit and explicit data values are different for any reason... what means that it may always be required to check both = implicit and explicit data.

 <= /p>

Regards,

Nirav.<= /p>

 <= /p>

From: DiME [ma= ilto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: Thursday, December 05, 2013 6:26 PM
To: dime@ietf.org
Subject: Re: [Dime] DOIC: Self-Contained OLRs

 

If we equating "= complexity" with work done by a Diameter node, then there is added &qu= ot;complexity" for both proposals.

The extra work that needs to be done for the self contained report approach= is that the reporter needs to add additional AVPs to the report.  Thi= s is hardly difficult but it is extra work.

The extra work in the implicit approach is that the reactor needs to gather= information from multiple AVPs to understand the context of the AVP. = Again, hardly difficult but more work that can be avoided in a well layere= d software architecture.

My conclusion is that the complexity argument does not apply.  There i= s complexity in both, its just a matter of where the work is done.

Steve

On 12/5/13 3:29 AM, Nirav Salot (nsalot) wrote:= 

Agree with Lionel's view and Maria-Cruz's arguments below.<=
/pre>

 


The "self-contained OC-OLR" - which I assume contains the sa=
me information as present in the message containing the OC-OLR - adds extra=
 complexity as highlighted by Maria-Cruz.


The benefit highlighted can be achieved in an implementation specific =
way by the receiver duplicating the information into OC-OLR before passing =
it to the layer processing the OC-OLR.


 


Regards,


Nirav.


 


-----Original Message-----


From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of Maria Cruz Bartolome


Sent: Thursday, December 05, 2013 7:53 AM


To: dime@ietf.org

Subject: Re: [Dime] DOIC: Self-Contained OLRs


 


Dear all,


 


I agree with Lionel argumentation below.


 


A part from that,  one concern with "self-contained OLRs&quo=
t; is that some data is duplicated. Duplication should be avoided, since th=
en we need to assure consistency, and error handing in case implicit and ex=
plicit data values are different for any reason... what means that it may a=
lways be required to check both implicit and explicit data.

 


Also, I think this is a pure implementation proposal. Regardless how t=
he data is transported it could be packed in a "self-contained OLRs&qu=
ot; within the diameter application, if for any implementation this is pref=
erred.


 


Regards


/MCruz


 


 


-----Original Message-----


From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of l=
ionel.morand@orange.com


Sent: jueves, 05 de diciembre de 2013 1:43


To: Ben Campbell


Cc: dime@ietf.org

Subject: Re: [Dime] DOIC: Self-Contained OLRs


 


Hi Ben,


 


3GPP operational requirements have triggered and driven this work, and=
 3GPP will be the main client for this solution (if not the only for a whil=
e...). Main parties involved in the discussions are 3GPP vendors and 3GPP o=
perators. So instead trying to keep private preserve, we should welcome and=
 enforce cooperative work with 3GPP on this task if we want that the soluti=
on defined in IETF will be used in 3GPP. Otherwise, 3GPP may decide not to =
wait for IETF and develop its own solution, as done in the past (e.g. devel=
oping 3GPP-specific Cx application instead of adopting the IETF-standard Di=
ameter SIP application).


 


About the technical discussion, the Req31 says:


 


   REQ 31: There are multiple situations where a Diameter no=
de may be


           overloade=
d for some purposes but not others.  For example,


           this can =
happen to an agent or server that supports multiple


           applicati=
ons, or when a server depends on multiple external


           resources=
, some of which may become overloaded while others


           are fully=
 available.  The solution MUST allow Diameter nodes


           to indica=
te overload with sufficient granularity to allow


           clients t=
o take action based on the overloaded resources


           without u=
nreasonably forcing available capacity to go unused.


           The solut=
ion MUST support specification of overload


           informati=
on with granularities of at least "Diameter node",

           "rea=
lm", and "Diameter application" and MUST allow

           extensibi=
lity for others to be added in the future.


 


The "MUST" part says: enough granularity with at least host/=
realm and application.


And the existing solution is compliant with this requirement. If a nod=
e is supporting N applications, an OLR can be sent "per application&qu=
ot; with a report type indicating if it is for the host or the realm. And t=
he extensibility capability is provided by the base solution.

 


So my technical argument is that the existing proposal fulfills the ba=
sic requirements for an overload control without compromising future extens=
ion for further granularity.


 


Regards,


 


Lionel 


 


-----Message d'origine-----


De : Ben Campbell [mailto:ben@=
nostrum.com] Envoy=E9 : mercredi 4 d=E9cembre 2013 22:55 =C0 =
: MORAND Lionel IMT/OLN Cc : dime@iet=
f.org Objet : Re: [Dime] DOIC: Self-Contained OLRs

 


On Dec 3, 2013, at 5:17 PM, lionel.morand@orange.com wrote:


 




Hi Ben,


 


I may be wrong somewhere in my summary but I think that it was the res=
ult of the discussions and agreements reached regarding existing requiremen=
ts, at least from 3GPP point of view, compared to possible optimizations fo=
r future optimizations not so obvious.




 


We are not the 3GPP. Our requirements are RFC 7068. I believe self-con=
tained OLRs do a better job of meeting Req 31 than the contextually-defined=
 OLRs.


 


I've made several technical arguments here--does anyone have _technica=
l_ arguments in favor of contextually-defined OLRs?


 




And because the solution offers extensibility via the definition of ne=
w algo, new report type and addition of any new AVP in the existing Grouped=
 OLR, the "limitations" of the proposed solution might be removed=
 by someone if really required according to new requirements.

 




 


It might be worth considering a compromise approach: Define _optional_=
 AVPs that allow an OLR to be self-contained. If they are not present, then=
 the various values default to those from the enclosing Diameter message. P=
ossibly add support for this to the list of things that reacting nodes can =
advertise.


 


This could be in the base, or in a follow on extension. (If left for a=
n extension, it's worth considering whether ReportType needs to be in the b=
ase, or this or some other extension.) 


 


 




Regards,


 


Lionel


 


-----Message d'origine-----


De : Ben Campbell [mailto:ben@nostr=
um.com] Envoy=E9 : mardi 3 d=E9cembre 


2013 23:56 =C0 : MORAND Lionel IMT/OLN Cc : Steve Donovan; dime@ietf.org 


Objet : Re: [Dime] DOIC: Self-Contained OLRs


 


 


On Dec 2, 2013, at 10:18 AM, lionel.morand@orange.com wrote:


 




Hi Steve,


 


I think that is not only about few bytes in the answer. It is also abo=
ut the solution principles agreed so far:


=B7         the current need i=
s for an OLR bound to the application in use


=B7         the OLR is receive=
d from the node targeted in the request.


=B7         the OLR is defined=
 per application




 


I don't think those principles have been well tested. I don't recall a=
ny discussion of their benefits. What benefits do you see they have over se=
lf-contained OLRs?


 


All I see from these are restrictions in the flexibility of the soluti=
on, with very little in return.


 




So all the implicit information (application, origin-host, origin-real=
m) are meaningful in this context.


And the actual solution is designed based on these assumptions. The ex=
tensibility of the solution will allow extra info if required in other use =
cases but it was agreed to go with a straightforward solution that will sat=
isfy most of us.


 


Regards,


 


Lionel


 


De : DiME [mailto:dime-bounce=
s@ietf.org] De la part de Steve Donovan


Envoy=E9 : lundi 2 d=E9cembre 2013 16:37


=C0 : dime@ietf.org

Objet : Re: [Dime] DOIC: Self-Contained OLRs


 


I don't believe that Ben's proposal was to change the piggybacking ass=
umption in the baseline mechanism.  Ben's proposal is to design the so=
lution in such a way that it is not dependent on the piggybacking transport=
 mechanism.  


 


I share Ben's concern that we have over optimized the content of the o=
verload report in a way that makes implementations brittle, interoperabilit=
y more difficult to achieve and extensibility more complex.  And what =
do we gain from this optimization?  A few bites in answer messages.


 


Self contained overload reports, transported using the piggybacking me=
chanism, is a cleaner solution.


 


Steve


 


On 11/29/13 8:31 AM, lione=
l.morand@orange.com wrote:


I totally agree with Nirav. No need to revert at this stage the workin=
g assumption on piggybacking of OLR in application answer messages, especia=
lly when the aim is to define a basic mechanism called "reduction"=
;.


 


Anyone would be able to further add extra info for optimization if nee=
ded but there is no need at all for the basic mechanism.


 


Regards,


 


Lionel


 


-----Message d'origine-----


De : DiME [mailto:dime-bounce=
s@ietf.org] De la part de Nirav Salot (nsalot)


Envoy=E9 : vendredi 29 novembre 2013 12:24


=C0 : Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list


Cc : Ben Campbell


Objet : Re: [Dime] DOIC: Self-Contained OLRs


 


Jouni, Ben,


 


I am totally against the idea of self-contained OC-OLR specifically si=
nce we have adopted the principles of piggybacking the OC-OLR over existing=
 application message.


Self-contained OC-OLR - which means adding all the information which d=
efines the scope of the OC-OLR into the OC-OLR - does not make sense in the=
 piggybacking approach. In fact, it is adding lot of information, which is =
anyway available within the message containing the OC-OLR, into the OC-OLR.=
 So it is adding lot of redundant information in a message which increases =
the processing requirement for the sender as well as the receiver. (And thi=
s is un-optimization, in my view).


 


Besides, I am not convinced with the other reasons provided here:=



- One software module within a node can provide OC-OLR to another soft=
ware module in the same node without passing other related info<=
/pre>

  Within a node, based on the design, lots of information may nee=
d to be passed between two software modules and we cannot optimize those as=
pects by replicating unnecessary information in a protocol message.


  In summary, it is node's internal software design issue and we =
need not optimize that at protocol level.


 


- Once the reporting node realizes that it is overloaded, it has to wa=
it for right answer to send OC-OLR


 What is the point of sending OC-OLR for a context for which there is =
no messaging? Why should the reacting node care if it never sends a message=
 for a context for which the reporting node is overloaded?


 So this waiting is justified since it ensures that the overload is re=
ported only when necessary and only to the applicable reacting node. Not to=
 all the nodes in the network.


 


- The agent needs to wait for the answer generated by the server and t=
he right context


  The same argument as applicable for the server applies here. Th=
e agent need not send out-of-context overload info to a node.

  Why should reacting node receive/process/store the overload inf=
o for the scope for which it is not sending any messages.


 


- For sending OC-OLR in dedicated Diameter application???

 Piggybacking was the first basic principle we agreed before putting o=
ther principles in place. So we may want to go back the drawing board if we=
 decide to change this principle.


 


Regards,


Nirav.


 


-----Original Message-----


From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of Jouni Korhonen


Sent: Friday, November 29, 2013 2:50 PM


To: Wiehe, Ulrich (NSN - DE/Munich); =
dime@ietf.org list


Cc: Ben Campbell


Subject: Re: [Dime] DOIC: Self-Contained OLRs


 


 


 


So, are we reaching any level of consensus here?


 


- JOuni


 


(as a note.. that we are converging back to where we started with OLRs=
 ;)


 


 


 


On Nov 28, 2013, at 12:40 PM, "Wiehe, Ulrich (NSN - DE/Munich)&qu=
ot; <ulrich.wiehe@nsn.com> wrote:


 


Hi,


 


another question:


 


If we go for explicit self contained OLRs, why would we then need the =
ReportType?


 


The realm-type OLR would explicitly contain application-Id, Realm, but=
 no Host whereas the host-type OLR would explicitly contain application-Id,=
 Host, but probably (I'm not sure) no Realm.


 


Ulrich


 


 


 


-----Original Message-----


From: ext lionel.morand@or=
ange.com [mailto:lionel.mor=
and@orange.com]


Sent: Thursday, November 28, 2013 10:31 AM


To: Wiehe, Ulrich (NSN - DE/Munich); ext Jouni Korhonen; Ben Campbell<=
o:p>


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 recei=
ved from a server behind but also from a server that would know this info b=
y some internal magic.


But in any case, if we assume that the client will received a successf=
ul 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 onl=
y Dest-Realm AVP.


 


Lionel


 


-----Message d'origine-----


De : DiME [mailto:dime-bounce=
s@ietf.org] De la part de Wiehe, Ulrich 


(NSN - DE/Munich) Envoy=E9 : jeudi 28 novembre 2013 10:26 =C0 : ext Jo=
uni 


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 &=
quot;realm" this indicates to the reacting end point that the reportin=
g 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 repor=
ting end point is a server. How can the reporting end point be both agent a=
nd server?


 


Ulrich


 


-----Original Message-----


From: DiME [mailto:dime-bounc=
es@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 <=
/o:p>


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 t=
he 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 D=
iameter request that corresponds to the answer containing the OLR. My reaso=
ns 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 applica=
tion identified by the Application-Id field of the enclosing answer, the re=
alm identified by Origin-Realm, and so on. This means that the "meanin=
g" of an OLR cannot be determined from the OLR contents alone; OLRs on=
ly 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 exp=
licitly include such values in the OLR itself, for multiple reasons:


 


1) It's more complex to interpret implicit, contextual values than exp=
licit values. The consumer cannot simply look at the OLR; it must look in v=
arious other AVPs to find all the information it needs. For example, I thin=
k a common software design for overload control processing to be separated =
from application processing. The consumer cannot simply hand the OLR to tha=
t module and expect things to work. The OC module must not only parse the O=
LR, but parse any other AVPs that are relevant. As OLR contents get extende=
d (assumedly following the same strategy as the base spec), the number of &=
quot;context" avps that must be interpreted can grow large. This appro=
ach is error prone, and will likely encourage brittle, hard-to-maintain cod=
e. Self-contained OLRs would keep all the information related to overload i=
n one place. making for simpler implementations.


 


2) It's more complex for the reporting node to send implicit values th=
an explicit values. The sender cannot simply set the context to match the O=
LR--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 righ=
t answer that contains the right context before it can send the OLR. This i=
s particularly troublesome for agents, since they will typically have to in=
sert OLRs into answers created by other nodes. 


 


If the reporting node screws this up, the meaning of the OLR may chang=
e significantly. So again, implicit meaning gives us error prone implementa=
tions. 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 <=
o:p>


are distinct from those sent by a server, see Steve's agent overload <=
o:p>


draft, or my dh/dr example.)


 


OTOH, explicit values will work for all cases where we need to associa=
te some arbitrary value with an OLR.


 


4) Implicit values seriously constrain the future evolution of Diamete=
r OC standards. For example, lets say we find a good reason to allow OLRs t=
o be sent out of band, or be sent in a dedicated Diameter application. If o=
verload 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 tran=
sported, this won't work. We would have to create a new or significantly mo=
dified OLR format if we found a need to transport OLRs in different ways. S=
elf-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.iet=
f.org/mailman/listinfo/dime


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.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 q=
ue les pieces jointes. Les messages electroniques etant susceptibles d'alte=
ration, Orange decline toute responsabilite si ce message a ete altere, def=
orme ou falsifie. Merci.


 


This message and its attachments may contain confidential or 


privileged information that may be protected by law; they should not b=
e 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.iet=
f.org/mailman/listinfo/dime


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 


______________________________________________________________________=
___________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


 


This message and its attachments may contain confidential or privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
o:p>


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.iet=
f.org/mailman/listinfo/dime


 


 


______________________________________________________________________=
___________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


 


This message and its attachments may contain confidential or privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
o:p>


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.iet=
f.org/mailman/listinfo/dime




 


 


______________________________________________________________________=
___________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


 


This message and its attachments may contain confidential or privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
o:p>


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.iet=
f.org/mailman/listinfo/dime




 


 


______________________________________________________________________=
___________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


 


This message and its attachments may contain confidential or privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
o:p>


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.iet=
f.org/mailman/listinfo/dime


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 

 

 

--_000_A9CA33BB78081F478946E4F34BF9AAA014D25A08xmbrcdx10ciscoc_-- From srdonovan@usdonovans.com Thu Dec 5 06:37:46 2013 Return-Path: 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 C9CE51AE028 for ; Thu, 5 Dec 2013 06:37:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no 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 yRNlinuWuAcj for ; Thu, 5 Dec 2013 06:37:36 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 199431ADFD3 for ; Thu, 5 Dec 2013 06:37:36 -0800 (PST) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:62074 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1Voa3O-0001yS-VT; Thu, 05 Dec 2013 06:37:29 -0800 Message-ID: <52A08FA2.8020203@usdonovans.com> Date: Thu, 05 Dec 2013 08:37:22 -0600 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "Nirav Salot (nsalot)" , "dime@ietf.org" References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <8467_1385735507_5298A553_8467_17054_3_6B7134B31289DC4FAF731D844122B36E309D0D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <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> <52A07A1E.5060502@usdonovans.com> <20040_1386250088_52A07F68_20040_916_1_6B7134B31289DC4FAF731D844122B36E32B0E9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52A084FA.7000803@usdonovans.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040400040505010006090102" X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 14:37:47 -0000 This is a multi-part message in MIME format. --------------040400040505010006090102 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Nirav, Please see comments inline. Regards, Steve On 12/5/13 7:59 AM, Nirav Salot (nsalot) wrote: > > Steve, > > > > > If we are to pose a question at this point I would suggest -- Can > everyone live with self-contained overload reports? > > Strongly NO. > > > > I can make the same arguments as you are making -- "I have yet to see > a single STRONG argument to justify the use of self-contained OC-OLR". > SRD> Fair enough -- note that my statement was in response to Lionel's attempt to place value judgements on the quality of arguments made for and against the self contained overload report proposal. > > > > All the arguments related to software layering, easy for the > developers etc. are very specific to the implementation and I don't > agree to define protocol solution suitable to a specific architecture. > SRD> I don't see how the self-contained report approach favors any specific architecture. Implementations with cleaner layering can take advantage of the self contained reports but it is also less work for non layered implementations. All of the information can be found in one place, there is no need to go to multiple places in the message to find the necessary overload information. SRD> That said, I can make the same argument against the implicit approach. It seems that there is a push for that approach because it fits better for some specific software architectures. > > > > Regards, > > Nirav. > > > > *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *Steve Donovan > *Sent:* Thursday, December 05, 2013 7:22 PM > *To:* dime@ietf.org > *Subject:* Re: [Dime] DOIC: Self-Contained OLRs > > > > Lionel, > > I strongly disagree with your conclusion that there is little support > for self-contained OLRs. > > I also object to your assessment that there are strong arguments > against self-contained reports. I have yet to see a single STRONG > argument. > > I also object to your attempting to call the question at this point in > the discussion. > > The only arguments I see for the implicit approach is complexity, > which I just sent an email refuting and schedule, about which I also > just sent an email. > > Self contained reports work just as well and has advantages both short > term in support for non application specific software layering and in > the long term in allowing for the same overload report to be > transported using multiple DOC solutions. > > I also don't agree that this has been a particularly long thread. > There are multiple topics being discussed under the same subject line. > > If we are to pose a question at this point I would suggest -- Can > everyone live with self-contained overload reports? > > Steve > > On 12/5/13 7:28 AM, lionel.morand@orange.com > wrote: > > All, > > > > After this LONG thread, it seems that there are strong arguments > against the self-contained OLRs and little support. > > In the contrary, it seems that the principle of OLR related to the > application in use is technically OK for everyone. > > > > So the question is quite simple: > > > > Could everyone live/survive with the "implicit approach" with the > extensibility mechanism allowing future extensions if needed? > > > > If yes, please focus on the finalization of the current draft. > > If no, let go on the discussion. > > > > Regards, > > > > Lionel > > > > > > *De :*DiME [mailto:dime-bounces@ietf.org] *De la part de* Steve > Donovan > *Envoyé :* jeudi 5 décembre 2013 14:06 > *À :* dime@ietf.org > *Objet :* Re: [Dime] DOIC: Self-Contained OLRs > > > > On the schedule question mentioned by JJacques -- any schedule > concerns can go away if everyone agrees to self contained overload > reports. This discussion would end and we could move on to other > things. :-) > > I say that somewhat in jest but please don't make the argument > that this discussion should be ended because of schedule. Or if > you make that argument, please don't assert that the person who > disagrees with you is putting the schedule at risk. > > We are striving for the best technical solution. We all > understand the schedule pressures. We need to balance the two. > > Steve > > On 12/5/13 5:14 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote: > > Hi > > > > A lot of mails on this topic...I would suggest to introduce an overload control on the Dime email threads:) > > > > > > On my side, I rely on what we have written in the draft for the "baseline" mechanism and that we have to keep as it is simple and efficient, here I join Lionel, Nirav and MCruz' positions. > > > > This thread then addresses extensions cases, I agree that we will have to address such extensions: Nirav mentioned the example with APN that if relevant would a 3GGP application case, I would add the Session Group about which we had some discussion a while ago and which is a more generic IETF case. There is also the agent overload case. Have you others? Always good to have some use cases in mind. > > > > What is important for me is that adding extensions should not modify the baseline and making it more complex when used alone. I also make a difference between principles and protocol tuning where we may have to choose between various protocol solution but addressing the same functionality or principle. > > > > About piggybacking, in the baseline, the principle is that OLRs which are addressed to sources of traffic are put in answer messages towards this traffic sources (origin Host) (even if these messages may be processed by intermediate DAs), which is simple and the OLR can be kept unchanged in the same message up to the origin Host if no specific process in intermediate DAs. To have a piggybacking allowing to put any OLR in any message (as it was in draft roach) is adding complexity that is not justified for the baseline and we have not retained it in the existing draft . > > > > About extensions, the APN or session group examples address parts of the traffic between a server and a client (so a higher granularity in the throttling than the baseline one), related OLRs are conveyed in the messages towards the origin Host so with an implicit reference to the Application, the Origin and Destination Host as for the baseline, so not requiring self contained OLRs. I also do not see the interest to send these new extensions OLR only in answers directly related to this OLR (as Ulrich proposed), eg only in an answer dealing with an APN if the OLR is related to APN throttling. The main point is that the OLR takes a direct "train" towards the right destination for a given application (as for baseline). > > > > This does not exclude that we may have other cases not entering the above examples characteristics, but as Nirav mentioned, we have to remain pragmatic and see this when such new use cases will be addressed. The extensibility possibilities of current draft give us a lot of flexibility, e.g. if some extensions need more self contained AVPs, why not, but this is outside the current draft. > > > > About extensions, I also think that they may need to be identified in the capability part, as the related OLRs should not be sent by a reacting node if the extension is not supported. > > > > Last important point, as Lionel mentioned, we have to finalize the draft soon, to be able to start Rel12 3GGP work relying on this draft. My position is that the current draft is currently well suited for the baseline and that extensions will be addressed separately > > > > Best regards > > > > JJacques > > > > > > -----Message d'origine----- > > De : DiME [mailto:dime-bounces@ietf.org] De la part de Ben Campbell > > Envoyé : mercredi 4 décembre 2013 22:55 > > À : ext lionel.morand@orange.com > > Cc : dime@ietf.org > > Objet : Re: [Dime] DOIC: Self-Contained OLRs > > > > On Dec 3, 2013, at 5:17 PM, lionel.morand@orange.com wrote: > > > > Hi Ben, > > > > I may be wrong somewhere in my summary but I think that it was the result of the discussions and agreements reached regarding existing requirements, at least from 3GPP point of view, compared to possible optimizations for future optimizations not so obvious. > > > > We are not the 3GPP. Our requirements are RFC 7068. I believe self-contained OLRs do a better job of meeting Req 31 than the contextually-defined OLRs. > > > > I've made several technical arguments here--does anyone have _technical_ arguments in favor of contextually-defined OLRs? > > > > And because the solution offers extensibility via the definition of new algo, new report type and addition of any new AVP in the existing Grouped OLR, the "limitations" of the proposed solution might be removed by someone if really required according to new requirements. > > > > > > It might be worth considering a compromise approach: Define _optional_ AVPs that allow an OLR to be self-contained. If they are not present, then the various values default to those from the enclosing Diameter message. Possibly add support for this to the list of things that reacting nodes can advertise. > > > > This could be in the base, or in a follow on extension. (If left for an extension, it's worth considering whether ReportType needs to be in the base, or this or some other extension.) > > > > > > Regards, > > > > Lionel > > > > -----Message d'origine----- > > De : Ben Campbell [mailto:ben@nostrum.com] Envoyé : mardi 3 décembre > > 2013 23:56 À : MORAND Lionel IMT/OLN Cc : Steve Donovan; dime@ietf.org > > Objet : Re: [Dime] DOIC: Self-Contained OLRs > > > > > > On Dec 2, 2013, at 10:18 AM, lionel.morand@orange.com wrote: > > > > Hi Steve, > > > > I think that is not only about few bytes in the answer. It is also about the solution principles agreed so far: > > · the current need is for an OLR bound to the application in use > > · the OLR is received from the node targeted in the request. > > · the OLR is defined per application > > > > I don't think those principles have been well tested. I don't recall any discussion of their benefits. What benefits do you see they have over self-contained OLRs? > > > > All I see from these are restrictions in the flexibility of the solution, with very little in return. > > > > So all the implicit information (application, origin-host, origin-realm) are meaningful in this context. > > And the actual solution is designed based on these assumptions. The extensibility of the solution will allow extra info if required in other use cases but it was agreed to go with a straightforward solution that will satisfy most of us. > > > > Regards, > > > > Lionel > > > > De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan > > Envoyé : lundi 2 décembre 2013 16:37 > > À : dime@ietf.org > > Objet : Re: [Dime] DOIC: Self-Contained OLRs > > > > I don't believe that Ben's proposal was to change the piggybacking assumption in the baseline mechanism. Ben's proposal is to design the solution in such a way that it is not dependent on the piggybacking transport mechanism. > > > > I share Ben's concern that we have over optimized the content of the overload report in a way that makes implementations brittle, interoperability more difficult to achieve and extensibility more complex. And what do we gain from this optimization? A few bites in answer messages. > > > > Self contained overload reports, transported using the piggybacking mechanism, is a cleaner solution. > > > > Steve > > > > On 11/29/13 8:31 AM, lionel.morand@orange.com wrote: > > I totally agree with Nirav. No need to revert at this stage the working assumption on piggybacking of OLR in application answer messages, especially when the aim is to define a basic mechanism called "reduction". > > > > Anyone would be able to further add extra info for optimization if needed but there is no need at all for the basic mechanism. > > > > Regards, > > > > Lionel > > > > -----Message d'origine----- > > De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot (nsalot) > > Envoyé : vendredi 29 novembre 2013 12:24 > > À : Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list > > Cc : Ben Campbell > > Objet : Re: [Dime] DOIC: Self-Contained OLRs > > > > Jouni, Ben, > > > > I am totally against the idea of self-contained OC-OLR specifically since we have adopted the principles of piggybacking the OC-OLR over existing application message. > > Self-contained OC-OLR - which means adding all the information which defines the scope of the OC-OLR into the OC-OLR - does not make sense in the piggybacking approach. In fact, it is adding lot of information, which is anyway available within the message containing the OC-OLR, into the OC-OLR. So it is adding lot of redundant information in a message which increases the processing requirement for the sender as well as the receiver. (And this is un-optimization, in my view). > > > > Besides, I am not convinced with the other reasons provided here: > > - One software module within a node can provide OC-OLR to another software module in the same node without passing other related info > > Within a node, based on the design, lots of information may need to be passed between two software modules and we cannot optimize those aspects by replicating unnecessary information in a protocol message. > > In summary, it is node's internal software design issue and we need not optimize that at protocol level. > > > > - Once the reporting node realizes that it is overloaded, it has to wait for right answer to send OC-OLR > > What is the point of sending OC-OLR for a context for which there is no messaging? Why should the reacting node care if it never sends a message for a context for which the reporting node is overloaded? > > So this waiting is justified since it ensures that the overload is reported only when necessary and only to the applicable reacting node. Not to all the nodes in the network. > > > > - The agent needs to wait for the answer generated by the server and the right context > > The same argument as applicable for the server applies here. The agent need not send out-of-context overload info to a node. > > Why should reacting node receive/process/store the overload info for the scope for which it is not sending any messages. > > > > - For sending OC-OLR in dedicated Diameter application??? > > Piggybacking was the first basic principle we agreed before putting other principles in place. So we may want to go back the drawing board if we decide to change this principle. > > > > Regards, > > Nirav. > > > > -----Original Message----- > > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen > > Sent: Friday, November 29, 2013 2:50 PM > > To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list > > Cc: Ben Campbell > > Subject: Re: [Dime] DOIC: Self-Contained OLRs > > > > > > > > So, are we reaching any level of consensus here? > > > > - JOuni > > > > (as a note.. that we are converging back to where we started with OLRs ;) > > > > > > > > On Nov 28, 2013, at 12:40 PM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: > > > > Hi, > > > > another question: > > > > If we go for explicit self contained OLRs, why would we then need the ReportType? > > > > The realm-type OLR would explicitly contain application-Id, Realm, but no Host whereas the host-type OLR would explicitly contain application-Id, Host, but probably (I'm not sure) no Realm. > > > > 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 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. > > > > > > _______________________________________________ > > 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. > > > > _______________________________________________ > > 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 > > > > > > _________________________________________________________________________________________________________________________ > > > > 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. > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > > > --------------040400040505010006090102 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Nirav,

Please see comments inline.

Regards,

Steve
On 12/5/13 7:59 AM, Nirav Salot (nsalot) wrote:

Steve,

 

> If we are to pose a question at this point I would suggest -- Can everyone live with self-contained overload reports?

Strongly NO.

 

I can make the same arguments as you are making – "I have yet to see a single STRONG argument to justify the use of self-contained OC-OLR".

SRD> Fair enough -- note that my statement was in response to Lionel's attempt to place value judgements on the quality of arguments made for and against the self contained overload report proposal. 

 

All the arguments related to software layering, easy for the developers etc. are very specific to the implementation and I don’t agree to define protocol solution suitable to a specific architecture.

SRD> I don't see how the self-contained report approach favors any specific architecture.  Implementations with cleaner layering can take advantage of the self contained reports but it is also less work for non layered implementations.  All of the information can be found in one place, there is no need to go to multiple places in the message to find the necessary overload information.

SRD> That said, I can make the same argument against the implicit approach.  It seems that there is a push for that approach because it fits better for some specific software architectures. 

 

Regards,

Nirav.

 

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: Thursday, December 05, 2013 7:22 PM
To: dime@ietf.org
Subject: Re: [Dime] DOIC: Self-Contained OLRs

 

Lionel,

I strongly disagree with your conclusion that there is little support for self-contained OLRs. 

I also object to your assessment that there are strong arguments against self-contained reports.  I have yet to see a single STRONG argument.

I also object to your attempting to call the question at this point in the discussion.

The only arguments I see for the implicit approach is complexity, which I just sent an email refuting and schedule, about which I also just sent an email.

Self contained reports work just as well and has advantages both short term in support for non application specific software layering and in the long term in allowing for the same overload report to be transported using multiple DOC solutions.

I also don't agree that this has been a particularly long thread.  There are multiple topics being discussed under the same subject line.

If we are to pose a question at this point I would suggest -- Can everyone live with self-contained overload reports?

Steve

On 12/5/13 7:28 AM, lionel.morand@orange.com wrote:

All,

 

After this LONG thread, it seems that there are strong arguments against the self-contained OLRs and little support.

In the contrary, it seems that the principle of OLR related to the application in use is technically OK for everyone.

 

So the question is quite simple:

 

Could everyone live/survive with the "implicit approach" with the extensibility mechanism allowing future extensions if needed?

 

If yes, please focus on the finalization of the current draft.

If no, let go on the discussion.

 

Regards,

 

Lionel

 

 

De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoyé : jeudi 5 décembre 2013 14:06
À : dime@ietf.org
Objet : Re: [Dime] DOIC: Self-Contained OLRs

 

On the schedule question mentioned by JJacques -- any schedule concerns can go away if everyone agrees to self contained overload reports.  This discussion would end and we could move on to other things.  :-)

I say that somewhat in jest but please don't make the argument that this discussion should be ended because of schedule.  Or if you make that argument, please don't assert that the person who disagrees with you is putting the schedule at risk.

We are striving for the best technical solution.  We all understand the schedule pressures.  We need to balance the two.

Steve

On 12/5/13 5:14 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:

Hi 
 
A lot of mails on this topic...I would suggest to introduce an overload control on the Dime email threads:)  
 
 
On my side, I rely on what we have written in the  draft for the "baseline" mechanism and that we have to keep as it is simple and efficient, here I join Lionel, Nirav and MCruz' positions.
 
This thread then addresses extensions  cases, I agree that we will have to address such extensions:   Nirav mentioned the example with APN that if relevant would  a 3GGP application case, I would add the Session Group about which we had some discussion a while ago and  which is a more generic IETF case. There is also the agent overload case. Have you others? Always good to have some use cases in mind.
 
What is important for me is that adding extensions should not modify the baseline and making it more complex when used alone.  I also make a difference between principles and protocol tuning where we may have to choose between various protocol solution but addressing the same functionality or principle.  
 
About piggybacking, in the baseline,  the principle is that OLRs  which  are addressed  to sources of traffic are put in answer messages towards this traffic sources (origin Host) (even if these messages  may be processed by intermediate DAs), which is simple and the OLR can be kept unchanged in the same message  up to the origin Host if no specific process in intermediate DAs.  To have a piggybacking allowing to put any OLR in any message (as it was in draft roach)  is adding complexity that is not justified for the baseline and we have not retained it in the existing draft .
 
About extensions, the APN or session group  examples address  parts of the traffic between a server and a client (so a higher granularity in the throttling than the baseline one), related OLRs are conveyed in the messages towards the origin Host so with an implicit reference to the Application, the  Origin and Destination Host as for the baseline, so not requiring self contained OLRs. I also  do not see the interest to send these new extensions OLR only in answers directly related to this OLR (as Ulrich proposed), eg only in an answer dealing with an APN if the OLR is related to APN throttling.  The main point is that the OLR takes a direct "train" towards the right destination for a given application (as for baseline).
 
This does not exclude that we may have other cases not entering the above examples characteristics, but as Nirav mentioned, we  have to remain pragmatic and see this when such new use cases will be addressed. The extensibility possibilities of  current draft give us a lot of flexibility, e.g. if some extensions need more self contained AVPs, why not, but this is outside the current draft. 
 
About extensions, I also think that they may need to be identified in the capability part, as the related OLRs should not be sent by a reacting node if the extension is not supported.
 
Last important point, as  Lionel mentioned, we have to finalize the draft soon, to be able to start Rel12 3GGP work relying on this draft. My position is that the current draft is currently well suited for the baseline and that extensions will be addressed separately  
 
Best regards
 
JJacques 
 
 
-----Message d'origine-----
De : DiME [mailto:dime-bounces@ietf.org] De la part de Ben Campbell
Envoyé : mercredi 4 décembre 2013 22:55
À : ext lionel.morand@orange.com
Cc : dime@ietf.org
Objet : Re: [Dime] DOIC: Self-Contained OLRs
 
On Dec 3, 2013, at 5:17 PM, lionel.morand@orange.com wrote:
 
Hi Ben,
 
I may be wrong somewhere in my summary but I think that it was the result of the discussions and agreements reached regarding existing requirements, at least from 3GPP point of view, compared to possible optimizations for future optimizations not so obvious.
 
We are not the 3GPP. Our requirements are RFC 7068. I believe self-contained OLRs do a better job of meeting Req 31 than the contextually-defined OLRs.
 
I've made several technical arguments here--does anyone have _technical_ arguments in favor of contextually-defined OLRs?
 
And because the solution offers extensibility via the definition of new algo, new report type and addition of any new AVP in the existing Grouped OLR, the "limitations" of the proposed solution might be removed by someone if really required according to new requirements.
 
 
It might be worth considering a compromise approach: Define _optional_ AVPs that allow an OLR to be self-contained. If they are not present, then the various values default to those from the enclosing Diameter message. Possibly add support for this to the list of things that reacting nodes can advertise.
 
This could be in the base, or in a follow on extension. (If left for an extension, it's worth considering whether ReportType needs to be in the base, or this or some other extension.) 
 
 
Regards,
 
Lionel
 
-----Message d'origine-----
De : Ben Campbell [mailto:ben@nostrum.com] Envoyé : mardi 3 décembre 
2013 23:56 À : MORAND Lionel IMT/OLN Cc : Steve Donovan; dime@ietf.org 
Objet : Re: [Dime] DOIC: Self-Contained OLRs
 
 
On Dec 2, 2013, at 10:18 AM, lionel.morand@orange.com wrote:
 
Hi Steve,
 
I think that is not only about few bytes in the answer. It is also about the solution principles agreed so far:
·         the current need is for an OLR bound to the application in use
·         the OLR is received from the node targeted in the request.
·         the OLR is defined per application
 
I don't think those principles have been well tested. I don't recall any discussion of their benefits. What benefits do you see they have over self-contained OLRs?
 
All I see from these are restrictions in the flexibility of the solution, with very little in return.
 
So all the implicit information (application, origin-host, origin-realm) are meaningful in this context.
And the actual solution is designed based on these assumptions. The extensibility of the solution will allow extra info if required in other use cases but it was agreed to go with a straightforward solution that will satisfy most of us.
 
Regards,
 
Lionel
 
De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoyé : lundi 2 décembre 2013 16:37
À : dime@ietf.org
Objet : Re: [Dime] DOIC: Self-Contained OLRs
 
I don't believe that Ben's proposal was to change the piggybacking assumption in the baseline mechanism.  Ben's proposal is to design the solution in such a way that it is not dependent on the piggybacking transport mechanism.  
 
I share Ben's concern that we have over optimized the content of the overload report in a way that makes implementations brittle, interoperability more difficult to achieve and extensibility more complex.  And what do we gain from this optimization?  A few bites in answer messages.
 
Self contained overload reports, transported using the piggybacking mechanism, is a cleaner solution.
 
Steve
 
On 11/29/13 8:31 AM, lionel.morand@orange.com wrote:
I totally agree with Nirav. No need to revert at this stage the working assumption on piggybacking of OLR in application answer messages, especially when the aim is to define a basic mechanism called "reduction".
 
Anyone would be able to further add extra info for optimization if needed but there is no need at all for the basic mechanism.
 
Regards,
 
Lionel
 
-----Message d'origine-----
De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot (nsalot)
Envoyé : vendredi 29 novembre 2013 12:24
À : Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list
Cc : Ben Campbell
Objet : Re: [Dime] DOIC: Self-Contained OLRs
 
Jouni, Ben,
 
I am totally against the idea of self-contained OC-OLR specifically since we have adopted the principles of piggybacking the OC-OLR over existing application message.
Self-contained OC-OLR - which means adding all the information which defines the scope of the OC-OLR into the OC-OLR - does not make sense in the piggybacking approach. In fact, it is adding lot of information, which is anyway available within the message containing the OC-OLR, into the OC-OLR. So it is adding lot of redundant information in a message which increases the processing requirement for the sender as well as the receiver. (And this is un-optimization, in my view).
 
Besides, I am not convinced with the other reasons provided here:
- One software module within a node can provide OC-OLR to another software module in the same node without passing other related info
  Within a node, based on the design, lots of information may need to be passed between two software modules and we cannot optimize those aspects by replicating unnecessary information in a protocol message.
  In summary, it is node's internal software design issue and we need not optimize that at protocol level.
 
- Once the reporting node realizes that it is overloaded, it has to wait for right answer to send OC-OLR
 What is the point of sending OC-OLR for a context for which there is no messaging? Why should the reacting node care if it never sends a message for a context for which the reporting node is overloaded?
 So this waiting is justified since it ensures that the overload is reported only when necessary and only to the applicable reacting node. Not to all the nodes in the network.
 
- The agent needs to wait for the answer generated by the server and the right context
  The same argument as applicable for the server applies here. The agent need not send out-of-context overload info to a node.
  Why should reacting node receive/process/store the overload info for the scope for which it is not sending any messages.
 
- For sending OC-OLR in dedicated Diameter application???
 Piggybacking was the first basic principle we agreed before putting other principles in place. So we may want to go back the drawing board if we decide to change this principle.
 
Regards,
Nirav.
 
-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen
Sent: Friday, November 29, 2013 2:50 PM
To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list
Cc: Ben Campbell
Subject: Re: [Dime] DOIC: Self-Contained OLRs
 
 
 
So, are we reaching any level of consensus here?
 
- JOuni
 
(as a note.. that we are converging back to where we started with OLRs ;)
 
 
 
On Nov 28, 2013, at 12:40 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> wrote:
 
Hi,
 
another question:
 
If we go for explicit self contained OLRs, why would we then need the ReportType?
 
The realm-type OLR would explicitly contain application-Id, Realm, but no Host whereas the host-type OLR would explicitly contain application-Id, Host, but probably (I'm not sure) no Realm.
 
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.
 
 
_______________________________________________
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.
 
_______________________________________________
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
 
 
_________________________________________________________________________________________________________________________
 
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.




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

 


--------------040400040505010006090102-- From srdonovan@usdonovans.com Thu Dec 5 06:46:56 2013 Return-Path: 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 483891AE014 for ; Thu, 5 Dec 2013 06:46:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no 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 Hd1n_gbIPxL4 for ; Thu, 5 Dec 2013 06:46:46 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 89A881ADF83 for ; Thu, 5 Dec 2013 06:46:46 -0800 (PST) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:62145 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1VoaCM-0004Fi-Vz; Thu, 05 Dec 2013 06:46:42 -0800 Message-ID: <52A091CE.2000104@usdonovans.com> Date: Thu, 05 Dec 2013 08:46:38 -0600 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "Nirav Salot (nsalot)" , "dime@ietf.org" 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> <14594_1386204165_529FCC05_14594_12646_1_6B7134B31289DC4FAF731D844122B36E329907@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B920972CCAA@ESESSMB101.ericsson.se> <52A077CC.3000004@usdonovans.com> <52A088D0.2020406@usdonovans.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000900090302000804090306" X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 14:46:56 -0000 This is a multi-part message in MIME format. --------------000900090302000804090306 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Nirav, Thanks for clarifying. This is obviously one area we have been making different assumptions. It's a good thing this thread went on this long. :-) One question, maybe for Maria Cruz. If it is never ok for an overload report to apply to an application other than the application carrying the message then how does the "all applications" extension proposed by Maria Cruz work? I will come back to address the "special architectural requirement" question in a separate email. I think I understand the point you are making. I also don't think I agree this is a special architecture requirement, but this requires some thought. Steve On 12/5/13 8:25 AM, Nirav Salot (nsalot) wrote: > > Steve, > > > > We assumed that "self-contained OC-OLR" contains the same information > as the message containing this AVP and hence we (me, JJ, Maria-Cruz) > were saying that consistency check is needed. > > > > But now I understand that "self-contained OC-OLR" can contain > information of any context since the AVP itself defines the context > explicitly. So application-X message can carry application-Y's OC-OLR > and I do not agree to this. > > In my view, this is totally against the existing principles of > Diameter based applications. And hence this requires special support > at the receiving node as well as the sending node since today the > nodes are designed to handle only application specific data. > > > > In summary, "self-contained OC-OLR" puts a special architectural > requirement on Diameter nodes -- to handle one application's data from > other application's message -- and hence this is a strong reason for > me to object to "self-contained OC-OLR". > > > > Regards, > > Nirav. > > > > *From:*Steve Donovan [mailto:srdonovan@usdonovans.com] > *Sent:* Thursday, December 05, 2013 7:38 PM > *To:* Nirav Salot (nsalot); dime@ietf.org > *Subject:* Re: [Dime] DOIC: Self-Contained OLRs > > > > I must admit that I don't understand the need for consistency. > > Why is it necessary to compare implicit and explicit data? If we use > self contained reports then the contents of the report are what should > be used, independent of the message that carries the report. > > Steve > > On 12/5/13 7:49 AM, Nirav Salot (nsalot) wrote: > > Steve, > > > > While gauging the complexity of "using the self-contained OC-OLR" > It seems you have overlooked the aspect identified by Maria-Cruz > below (and JJ earlier). > > > Duplication should be avoided, since then we need to assure > consistency, and error handing in case implicit and explicit data > values are different for any reason... what means that it may > always be required to check both implicit and explicit data. > > > > Regards, > > Nirav. > > > > *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *Steve > Donovan > *Sent:* Thursday, December 05, 2013 6:26 PM > *To:* dime@ietf.org > *Subject:* Re: [Dime] DOIC: Self-Contained OLRs > > > > If we equating "complexity" with work done by a Diameter node, > then there is added "complexity" for both proposals. > > The extra work that needs to be done for the self contained report > approach is that the reporter needs to add additional AVPs to the > report. This is hardly difficult but it is extra work. > > The extra work in the implicit approach is that the reactor needs > to gather information from multiple AVPs to understand the context > of the AVP. Again, hardly difficult but more work that can be > avoided in a well layered software architecture. > > My conclusion is that the complexity argument does not apply. > There is complexity in both, its just a matter of where the work > is done. > > Steve > > On 12/5/13 3:29 AM, Nirav Salot (nsalot) wrote: > > Agree with Lionel's view and Maria-Cruz's arguments below. > > > > The "self-contained OC-OLR" - which I assume contains the same information as present in the message containing the OC-OLR - adds extra complexity as highlighted by Maria-Cruz. > > The benefit highlighted can be achieved in an implementation specific way by the receiver duplicating the information into OC-OLR before passing it to the layer processing the OC-OLR. > > > > Regards, > > Nirav. > > > > -----Original Message----- > > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Maria Cruz Bartolome > > Sent: Thursday, December 05, 2013 7:53 AM > > To: dime@ietf.org > > Subject: Re: [Dime] DOIC: Self-Contained OLRs > > > > Dear all, > > > > I agree with Lionel argumentation below. > > > > A part from that, one concern with "self-contained OLRs" is that some data is duplicated. Duplication should be avoided, since then we need to assure consistency, and error handing in case implicit and explicit data values are different for any reason... what means that it may always be required to check both implicit and explicit data. > > > > Also, I think this is a pure implementation proposal. Regardless how the data is transported it could be packed in a "self-contained OLRs" within the diameter application, if for any implementation this is preferred. > > > > Regards > > /MCruz > > > > > > -----Original Message----- > > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange.com > > Sent: jueves, 05 de diciembre de 2013 1:43 > > To: Ben Campbell > > Cc: dime@ietf.org > > Subject: Re: [Dime] DOIC: Self-Contained OLRs > > > > Hi Ben, > > > > 3GPP operational requirements have triggered and driven this work, and 3GPP will be the main client for this solution (if not the only for a while...). Main parties involved in the discussions are 3GPP vendors and 3GPP operators. So instead trying to keep private preserve, we should welcome and enforce cooperative work with 3GPP on this task if we want that the solution defined in IETF will be used in 3GPP. Otherwise, 3GPP may decide not to wait for IETF and develop its own solution, as done in the past (e.g. developing 3GPP-specific Cx application instead of adopting the IETF-standard Diameter SIP application). > > > > About the technical discussion, the Req31 says: > > > > REQ 31: There are multiple situations where a Diameter node may be > > overloaded for some purposes but not others. For example, > > this can happen to an agent or server that supports multiple > > applications, or when a server depends on multiple external > > resources, some of which may become overloaded while others > > are fully available. The solution MUST allow Diameter nodes > > to indicate overload with sufficient granularity to allow > > clients to take action based on the overloaded resources > > without unreasonably forcing available capacity to go unused. > > The solution MUST support specification of overload > > information with granularities of at least "Diameter node", > > "realm", and "Diameter application" and MUST allow > > extensibility for others to be added in the future. > > > > The "MUST" part says: enough granularity with at least host/realm and application. > > And the existing solution is compliant with this requirement. If a node is supporting N applications, an OLR can be sent "per application" with a report type indicating if it is for the host or the realm. And the extensibility capability is provided by the base solution. > > > > So my technical argument is that the existing proposal fulfills the basic requirements for an overload control without compromising future extension for further granularity. > > > > Regards, > > > > Lionel > > > > -----Message d'origine----- > > De : Ben Campbell [mailto:ben@nostrum.com] Envoyé : mercredi 4 décembre 2013 22:55 À : MORAND Lionel IMT/OLN Cc : dime@ietf.org Objet : Re: [Dime] DOIC: Self-Contained OLRs > > > > On Dec 3, 2013, at 5:17 PM, lionel.morand@orange.com wrote: > > > > Hi Ben, > > > > I may be wrong somewhere in my summary but I think that it was the result of the discussions and agreements reached regarding existing requirements, at least from 3GPP point of view, compared to possible optimizations for future optimizations not so obvious. > > > > We are not the 3GPP. Our requirements are RFC 7068. I believe self-contained OLRs do a better job of meeting Req 31 than the contextually-defined OLRs. > > > > I've made several technical arguments here--does anyone have _technical_ arguments in favor of contextually-defined OLRs? > > > > And because the solution offers extensibility via the definition of new algo, new report type and addition of any new AVP in the existing Grouped OLR, the "limitations" of the proposed solution might be removed by someone if really required according to new requirements. > > > > > > It might be worth considering a compromise approach: Define _optional_ AVPs that allow an OLR to be self-contained. If they are not present, then the various values default to those from the enclosing Diameter message. Possibly add support for this to the list of things that reacting nodes can advertise. > > > > This could be in the base, or in a follow on extension. (If left for an extension, it's worth considering whether ReportType needs to be in the base, or this or some other extension.) > > > > > > Regards, > > > > Lionel > > > > -----Message d'origine----- > > De : Ben Campbell [mailto:ben@nostrum.com] Envoyé : mardi 3 décembre > > 2013 23:56 À : MORAND Lionel IMT/OLN Cc : Steve Donovan; dime@ietf.org > > Objet : Re: [Dime] DOIC: Self-Contained OLRs > > > > > > On Dec 2, 2013, at 10:18 AM, lionel.morand@orange.com wrote: > > > > Hi Steve, > > > > I think that is not only about few bytes in the answer. It is also about the solution principles agreed so far: > > · the current need is for an OLR bound to the application in use > > · the OLR is received from the node targeted in the request. > > · the OLR is defined per application > > > > I don't think those principles have been well tested. I don't recall any discussion of their benefits. What benefits do you see they have over self-contained OLRs? > > > > All I see from these are restrictions in the flexibility of the solution, with very little in return. > > > > So all the implicit information (application, origin-host, origin-realm) are meaningful in this context. > > And the actual solution is designed based on these assumptions. The extensibility of the solution will allow extra info if required in other use cases but it was agreed to go with a straightforward solution that will satisfy most of us. > > > > Regards, > > > > Lionel > > > > De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan > > Envoyé : lundi 2 décembre 2013 16:37 > > À : dime@ietf.org > > Objet : Re: [Dime] DOIC: Self-Contained OLRs > > > > I don't believe that Ben's proposal was to change the piggybacking assumption in the baseline mechanism. Ben's proposal is to design the solution in such a way that it is not dependent on the piggybacking transport mechanism. > > > > I share Ben's concern that we have over optimized the content of the overload report in a way that makes implementations brittle, interoperability more difficult to achieve and extensibility more complex. And what do we gain from this optimization? A few bites in answer messages. > > > > Self contained overload reports, transported using the piggybacking mechanism, is a cleaner solution. > > > > Steve > > > > On 11/29/13 8:31 AM, lionel.morand@orange.com wrote: > > I totally agree with Nirav. No need to revert at this stage the working assumption on piggybacking of OLR in application answer messages, especially when the aim is to define a basic mechanism called "reduction". > > > > Anyone would be able to further add extra info for optimization if needed but there is no need at all for the basic mechanism. > > > > Regards, > > > > Lionel > > > > -----Message d'origine----- > > De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot (nsalot) > > Envoyé : vendredi 29 novembre 2013 12:24 > > À : Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list > > Cc : Ben Campbell > > Objet : Re: [Dime] DOIC: Self-Contained OLRs > > > > Jouni, Ben, > > > > I am totally against the idea of self-contained OC-OLR specifically since we have adopted the principles of piggybacking the OC-OLR over existing application message. > > Self-contained OC-OLR - which means adding all the information which defines the scope of the OC-OLR into the OC-OLR - does not make sense in the piggybacking approach. In fact, it is adding lot of information, which is anyway available within the message containing the OC-OLR, into the OC-OLR. So it is adding lot of redundant information in a message which increases the processing requirement for the sender as well as the receiver. (And this is un-optimization, in my view). > > > > Besides, I am not convinced with the other reasons provided here: > > - One software module within a node can provide OC-OLR to another software module in the same node without passing other related info > > Within a node, based on the design, lots of information may need to be passed between two software modules and we cannot optimize those aspects by replicating unnecessary information in a protocol message. > > In summary, it is node's internal software design issue and we need not optimize that at protocol level. > > > > - Once the reporting node realizes that it is overloaded, it has to wait for right answer to send OC-OLR > > What is the point of sending OC-OLR for a context for which there is no messaging? Why should the reacting node care if it never sends a message for a context for which the reporting node is overloaded? > > So this waiting is justified since it ensures that the overload is reported only when necessary and only to the applicable reacting node. Not to all the nodes in the network. > > > > - The agent needs to wait for the answer generated by the server and the right context > > The same argument as applicable for the server applies here. The agent need not send out-of-context overload info to a node. > > Why should reacting node receive/process/store the overload info for the scope for which it is not sending any messages. > > > > - For sending OC-OLR in dedicated Diameter application??? > > Piggybacking was the first basic principle we agreed before putting other principles in place. So we may want to go back the drawing board if we decide to change this principle. > > > > Regards, > > Nirav. > > > > -----Original Message----- > > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen > > Sent: Friday, November 29, 2013 2:50 PM > > To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list > > Cc: Ben Campbell > > Subject: Re: [Dime] DOIC: Self-Contained OLRs > > > > > > > > So, are we reaching any level of consensus here? > > > > - JOuni > > > > (as a note.. that we are converging back to where we started with OLRs ;) > > > > > > > > On Nov 28, 2013, at 12:40 PM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: > > > > Hi, > > > > another question: > > > > If we go for explicit self contained OLRs, why would we then need the ReportType? > > > > The realm-type OLR would explicitly contain application-Id, Realm, but no Host whereas the host-type OLR would explicitly contain application-Id, Host, but probably (I'm not sure) no Realm. > > > > 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 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. > > > > > > _______________________________________________ > > 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. > > > > _______________________________________________ > > 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 > > > > > > _________________________________________________________________________________________________________________________ > > > > 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 > > > > > > > --------------000900090302000804090306 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Nirav,

Thanks for clarifying.  This is obviously one area we have been making different assumptions.  It's a good thing  this thread went on this long. :-)

One question, maybe for Maria Cruz.  If it is never ok for an overload report to apply to an application other than the application carrying the message then how does the "all applications" extension proposed by Maria Cruz work?

I will come back to address the "special architectural requirement" question in a separate email.  I think I understand the point you are making.  I also don't think I agree this is a special architecture requirement, but this requires some thought.

Steve
On 12/5/13 8:25 AM, Nirav Salot (nsalot) wrote:

Steve,

 

We assumed that "self-contained OC-OLR" contains the same information as the message containing this AVP and hence we (me, JJ, Maria-Cruz) were saying that consistency check is needed.

 

But now I understand that "self-contained OC-OLR" can contain information of any context since the AVP itself defines the context explicitly. So application-X message can carry application-Y's OC-OLR and I do not agree to this.

In my view, this is totally against the existing principles of Diameter based applications. And hence this requires special support at the receiving node as well as the sending node since today the nodes are designed to handle only application specific data.

 

In summary, "self-contained OC-OLR" puts a special architectural requirement on Diameter nodes – to handle one application's data from other application's message – and hence this is a strong reason for me to object to "self-contained OC-OLR".

 

Regards,

Nirav.

 

From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Thursday, December 05, 2013 7:38 PM
To: Nirav Salot (nsalot); dime@ietf.org
Subject: Re: [Dime] DOIC: Self-Contained OLRs

 

I must admit that I don't understand the need for consistency.

Why is it necessary to compare implicit and explicit data?  If we use self contained reports then the contents of the report are what should be used, independent of the message that carries the report.

Steve

On 12/5/13 7:49 AM, Nirav Salot (nsalot) wrote:

Steve,

 

While gauging the complexity of "using the self-contained OC-OLR" It seems you have overlooked the aspect identified by Maria-Cruz below (and JJ earlier).

> Duplication should be avoided, since then we need to assure consistency, and error handing in case implicit and explicit data values are different for any reason... what means that it may always be required to check both implicit and explicit data.

 

Regards,

Nirav.

 

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: Thursday, December 05, 2013 6:26 PM
To: dime@ietf.org
Subject: Re: [Dime] DOIC: Self-Contained OLRs

 

If we equating "complexity" with work done by a Diameter node, then there is added "complexity" for both proposals.

The extra work that needs to be done for the self contained report approach is that the reporter needs to add additional AVPs to the report.  This is hardly difficult but it is extra work.

The extra work in the implicit approach is that the reactor needs to gather information from multiple AVPs to understand the context of the AVP.  Again, hardly difficult but more work that can be avoided in a well layered software architecture.

My conclusion is that the complexity argument does not apply.  There is complexity in both, its just a matter of where the work is done.

Steve

On 12/5/13 3:29 AM, Nirav Salot (nsalot) wrote:

Agree with Lionel's view and Maria-Cruz's arguments below.
 
The "self-contained OC-OLR" - which I assume contains the same information as present in the message containing the OC-OLR - adds extra complexity as highlighted by Maria-Cruz.
The benefit highlighted can be achieved in an implementation specific way by the receiver duplicating the information into OC-OLR before passing it to the layer processing the OC-OLR.
 
Regards,
Nirav.
 
-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Maria Cruz Bartolome
Sent: Thursday, December 05, 2013 7:53 AM
To: dime@ietf.org
Subject: Re: [Dime] DOIC: Self-Contained OLRs
 
Dear all,
 
I agree with Lionel argumentation below.
 
A part from that,  one concern with "self-contained OLRs" is that some data is duplicated. Duplication should be avoided, since then we need to assure consistency, and error handing in case implicit and explicit data values are different for any reason... what means that it may always be required to check both implicit and explicit data.
 
Also, I think this is a pure implementation proposal. Regardless how the data is transported it could be packed in a "self-contained OLRs" within the diameter application, if for any implementation this is preferred.
 
Regards
/MCruz
 
 
-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange.com
Sent: jueves, 05 de diciembre de 2013 1:43
To: Ben Campbell
Cc: dime@ietf.org
Subject: Re: [Dime] DOIC: Self-Contained OLRs
 
Hi Ben,
 
3GPP operational requirements have triggered and driven this work, and 3GPP will be the main client for this solution (if not the only for a while...). Main parties involved in the discussions are 3GPP vendors and 3GPP operators. So instead trying to keep private preserve, we should welcome and enforce cooperative work with 3GPP on this task if we want that the solution defined in IETF will be used in 3GPP. Otherwise, 3GPP may decide not to wait for IETF and develop its own solution, as done in the past (e.g. developing 3GPP-specific Cx application instead of adopting the IETF-standard Diameter SIP application).
 
About the technical discussion, the Req31 says:
 
   REQ 31: There are multiple situations where a Diameter node may be
           overloaded for some purposes but not others.  For example,
           this can happen to an agent or server that supports multiple
           applications, or when a server depends on multiple external
           resources, some of which may become overloaded while others
           are fully available.  The solution MUST allow Diameter nodes
           to indicate overload with sufficient granularity to allow
           clients to take action based on the overloaded resources
           without unreasonably forcing available capacity to go unused.
           The solution MUST support specification of overload
           information with granularities of at least "Diameter node",
           "realm", and "Diameter application" and MUST allow
           extensibility for others to be added in the future.
 
The "MUST" part says: enough granularity with at least host/realm and application.
And the existing solution is compliant with this requirement. If a node is supporting N applications, an OLR can be sent "per application" with a report type indicating if it is for the host or the realm. And the extensibility capability is provided by the base solution.
 
So my technical argument is that the existing proposal fulfills the basic requirements for an overload control without compromising future extension for further granularity.
 
Regards,
 
Lionel 
 
-----Message d'origine-----
De : Ben Campbell [mailto:ben@nostrum.com] Envoyé : mercredi 4 décembre 2013 22:55 À : MORAND Lionel IMT/OLN Cc : dime@ietf.org Objet : Re: [Dime] DOIC: Self-Contained OLRs
 
On Dec 3, 2013, at 5:17 PM, lionel.morand@orange.com wrote:
 
Hi Ben,
 
I may be wrong somewhere in my summary but I think that it was the result of the discussions and agreements reached regarding existing requirements, at least from 3GPP point of view, compared to possible optimizations for future optimizations not so obvious.
 
We are not the 3GPP. Our requirements are RFC 7068. I believe self-contained OLRs do a better job of meeting Req 31 than the contextually-defined OLRs.
 
I've made several technical arguments here--does anyone have _technical_ arguments in favor of contextually-defined OLRs?
 
And because the solution offers extensibility via the definition of new algo, new report type and addition of any new AVP in the existing Grouped OLR, the "limitations" of the proposed solution might be removed by someone if really required according to new requirements.
 
 
It might be worth considering a compromise approach: Define _optional_ AVPs that allow an OLR to be self-contained. If they are not present, then the various values default to those from the enclosing Diameter message. Possibly add support for this to the list of things that reacting nodes can advertise.
 
This could be in the base, or in a follow on extension. (If left for an extension, it's worth considering whether ReportType needs to be in the base, or this or some other extension.) 
 
 
Regards,
 
Lionel
 
-----Message d'origine-----
De : Ben Campbell [mailto:ben@nostrum.com] Envoyé : mardi 3 décembre 
2013 23:56 À : MORAND Lionel IMT/OLN Cc : Steve Donovan; dime@ietf.org 
Objet : Re: [Dime] DOIC: Self-Contained OLRs
 
 
On Dec 2, 2013, at 10:18 AM, lionel.morand@orange.com wrote:
 
Hi Steve,
 
I think that is not only about few bytes in the answer. It is also about the solution principles agreed so far:
·         the current need is for an OLR bound to the application in use
·         the OLR is received from the node targeted in the request.
·         the OLR is defined per application
 
I don't think those principles have been well tested. I don't recall any discussion of their benefits. What benefits do you see they have over self-contained OLRs?
 
All I see from these are restrictions in the flexibility of the solution, with very little in return.
 
So all the implicit information (application, origin-host, origin-realm) are meaningful in this context.
And the actual solution is designed based on these assumptions. The extensibility of the solution will allow extra info if required in other use cases but it was agreed to go with a straightforward solution that will satisfy most of us.
 
Regards,
 
Lionel
 
De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoyé : lundi 2 décembre 2013 16:37
À : dime@ietf.org
Objet : Re: [Dime] DOIC: Self-Contained OLRs
 
I don't believe that Ben's proposal was to change the piggybacking assumption in the baseline mechanism.  Ben's proposal is to design the solution in such a way that it is not dependent on the piggybacking transport mechanism.  
 
I share Ben's concern that we have over optimized the content of the overload report in a way that makes implementations brittle, interoperability more difficult to achieve and extensibility more complex.  And what do we gain from this optimization?  A few bites in answer messages.
 
Self contained overload reports, transported using the piggybacking mechanism, is a cleaner solution.
 
Steve
 
On 11/29/13 8:31 AM, lionel.morand@orange.com wrote:
I totally agree with Nirav. No need to revert at this stage the working assumption on piggybacking of OLR in application answer messages, especially when the aim is to define a basic mechanism called "reduction".
 
Anyone would be able to further add extra info for optimization if needed but there is no need at all for the basic mechanism.
 
Regards,
 
Lionel
 
-----Message d'origine-----
De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot (nsalot)
Envoyé : vendredi 29 novembre 2013 12:24
À : Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list
Cc : Ben Campbell
Objet : Re: [Dime] DOIC: Self-Contained OLRs
 
Jouni, Ben,
 
I am totally against the idea of self-contained OC-OLR specifically since we have adopted the principles of piggybacking the OC-OLR over existing application message.
Self-contained OC-OLR - which means adding all the information which defines the scope of the OC-OLR into the OC-OLR - does not make sense in the piggybacking approach. In fact, it is adding lot of information, which is anyway available within the message containing the OC-OLR, into the OC-OLR. So it is adding lot of redundant information in a message which increases the processing requirement for the sender as well as the receiver. (And this is un-optimization, in my view).
 
Besides, I am not convinced with the other reasons provided here:
- One software module within a node can provide OC-OLR to another software module in the same node without passing other related info
  Within a node, based on the design, lots of information may need to be passed between two software modules and we cannot optimize those aspects by replicating unnecessary information in a protocol message.
  In summary, it is node's internal software design issue and we need not optimize that at protocol level.
 
- Once the reporting node realizes that it is overloaded, it has to wait for right answer to send OC-OLR
 What is the point of sending OC-OLR for a context for which there is no messaging? Why should the reacting node care if it never sends a message for a context for which the reporting node is overloaded?
 So this waiting is justified since it ensures that the overload is reported only when necessary and only to the applicable reacting node. Not to all the nodes in the network.
 
- The agent needs to wait for the answer generated by the server and the right context
  The same argument as applicable for the server applies here. The agent need not send out-of-context overload info to a node.
  Why should reacting node receive/process/store the overload info for the scope for which it is not sending any messages.
 
- For sending OC-OLR in dedicated Diameter application???
 Piggybacking was the first basic principle we agreed before putting other principles in place. So we may want to go back the drawing board if we decide to change this principle.
 
Regards,
Nirav.
 
-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen
Sent: Friday, November 29, 2013 2:50 PM
To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list
Cc: Ben Campbell
Subject: Re: [Dime] DOIC: Self-Contained OLRs
 
 
 
So, are we reaching any level of consensus here?
 
- JOuni
 
(as a note.. that we are converging back to where we started with OLRs ;)
 
 
 
On Nov 28, 2013, at 12:40 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> wrote:
 
Hi,
 
another question:
 
If we go for explicit self contained OLRs, why would we then need the ReportType?
 
The realm-type OLR would explicitly contain application-Id, Realm, but no Host whereas the host-type OLR would explicitly contain application-Id, Host, but probably (I'm not sure) no Realm.
 
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.
 
 
_______________________________________________
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.
 
_______________________________________________
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
 
 
_________________________________________________________________________________________________________________________
 
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
 

 

 


--------------000900090302000804090306-- From jean-jacques.trottin@alcatel-lucent.com Thu Dec 5 07:01:30 2013 Return-Path: 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 784891ADFC4 for ; Thu, 5 Dec 2013 07:01:30 -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 syCu_IlbbTTc for ; Thu, 5 Dec 2013 07:01:19 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 5FD251AC863 for ; Thu, 5 Dec 2013 07:01:19 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id rB5F1AvS002052 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 5 Dec 2013 09:01:12 -0600 (CST) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id rB5F0wi4015968 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 5 Dec 2013 16:01:08 +0100 Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.241]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Thu, 5 Dec 2013 16:00:51 +0100 From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" To: "dime@ietf.org" Thread-Topic: [Dime] DOIC: Self-Contained OLRs Thread-Index: AQHO67/uc4Hi6cqE9USGBLWwFB86UZo5m/0AgACzUoCAAAFygIAAE14AgAF8EACAACKcAIAANGaAgATJUgCAAAuAAIACAWkAgAAGHYCAAXsigIAALuKAgAAb/4CAAHc6gIAAOZAAgAAO+4CAAAVNAIAABNCAgAAF6QCAABN00A== Date: Thu, 5 Dec 2013 15:00:50 +0000 Message-ID: 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> <14594_1386204165_529FCC05_14594_12646_1_6B7134B31289DC4FAF731D844122B36E329907@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B920972CCAA@ESESSMB101.ericsson.se> <52A077CC.3000004@usdonovans.com> <52A088D0.2020406@usdonovans.com> <52A091CE.2000104@usdonovans.com> In-Reply-To: <52A091CE.2000104@usdonovans.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_E194C2E18676714DACA9C3A2516265D201CB3FD9FR712WXCHMBA12z_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 15:01:30 -0000 --_000_E194C2E18676714DACA9C3A2516265D201CB3FD9FR712WXCHMBA12z_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Steve, Ben I come back to the few months ago discussion on the Roach-Draft where ther= e were a set of scopes quite similar to the self contained OLRs principle= you are now pushing. The self contained principle reintroduces the many= scopes approach without forgetting all the underlying combinational aspe= cts for which rules should be established on what is allowed or not allowe= d and so forth. 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 cont= ent. This decision is a strong argument that still prevails in the current= discussion So the current baseline has only one OLR with two types (Host and realm) = and an implicit reference to the application/destination/origin Host of the= conveying message which avoids the complexity of the former scope approac= h . There is no reason currently to add further complexity with self conta= ined AVPS in an OLR mixing various AVPs defining the "scope" of the OLR. The compromise is that if in the future we have a specific requirement (eg= the APN example or the session group) to introduce new OLRs with other ch= aracteristics about their appliance, we could introduce new self contained = AVPs for this, but this does not change the baseline. Steve about your sentence: On the schedule question mentioned by JJacques -- any schedule concerns can= go away if everyone agrees to self contained overload reports. This discu= ssion would end and we could move on to other things. :-) I can write On the schedule question mentioned by JJacques -- any schedule concerns can= go away if everyone agrees to the current OLR description in the draft. = This discussion would end and we could move on to other things. :-) In fact I observe by restarting this discussion we already had about the s= copes with draft roach, we may efectively endanger the schedule. Best regards JJacques De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan Envoy=E9 : jeudi 5 d=E9cembre 2013 15:47 =C0 : Nirav Salot (nsalot); dime@ietf.org Objet : Re: [Dime] DOIC: Self-Contained OLRs Nirav, Thanks for clarifying. This is obviously one area we have been making diff= erent assumptions. It's a good thing this thread went on this long. :-) One question, maybe for Maria Cruz. If it is never ok for an overload repo= rt to apply to an application other than the application carrying the messa= ge then how does the "all applications" extension proposed by Maria Cruz wo= rk? I will come back to address the "special architectural requirement" questio= n in a separate email. I think I understand the point you are making. I a= lso don't think I agree this is a special architecture requirement, but thi= s requires some thought. Steve On 12/5/13 8:25 AM, Nirav Salot (nsalot) wrote: Steve, We assumed that "self-contained OC-OLR" contains the same information as th= e message containing this AVP and hence we (me, JJ, Maria-Cruz) were saying= that consistency check is needed. But now I understand that "self-contained OC-OLR" can contain information o= f any context since the AVP itself defines the context explicitly. So appli= cation-X message can carry application-Y's OC-OLR and I do not agree to thi= s. In my view, this is totally against the existing principles of Diameter bas= ed applications. And hence this requires special support at the receiving n= ode as well as the sending node since today the nodes are designed to handl= e only application specific data. In summary, "self-contained OC-OLR" puts a special architectural requiremen= t on Diameter nodes - to handle one application's data from other applicati= on's message - and hence this is a strong reason for me to object to "self-= contained OC-OLR". Regards, Nirav. From: Steve Donovan [mailto:srdonovan@usdonovans.com] Sent: Thursday, December 05, 2013 7:38 PM To: Nirav Salot (nsalot); dime@ietf.org Subject: Re: [Dime] DOIC: Self-Contained OLRs I must admit that I don't understand the need for consistency. Why is it necessary to compare implicit and explicit data? If we use self = contained reports then the contents of the report are what should be used, = independent of the message that carries the report. Steve On 12/5/13 7:49 AM, Nirav Salot (nsalot) wrote: Steve, While gauging the complexity of "using the self-contained OC-OLR" It seems = you have overlooked the aspect identified by Maria-Cruz below (and JJ earli= er). > Duplication should be avoided, since then we need to assure consistency, = and error handing in case implicit and explicit data values are different f= or any reason... what means that it may always be required to check both im= plicit and explicit data. Regards, Nirav. From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: Thursday, December 05, 2013 6:26 PM To: dime@ietf.org Subject: Re: [Dime] DOIC: Self-Contained OLRs If we equating "complexity" with work done by a Diameter node, then there i= s added "complexity" for both proposals. The extra work that needs to be done for the self contained report approach= is that the reporter needs to add additional AVPs to the report. This is = hardly difficult but it is extra work. The extra work in the implicit approach is that the reactor needs to gather= information from multiple AVPs to understand the context of the AVP. Agai= n, hardly difficult but more work that can be avoided in a well layered sof= tware architecture. My conclusion is that the complexity argument does not apply. There is com= plexity in both, its just a matter of where the work is done. Steve On 12/5/13 3:29 AM, Nirav Salot (nsalot) wrote: Agree with Lionel's view and Maria-Cruz's arguments below. The "self-contained OC-OLR" - which I assume contains the same information = as present in the message containing the OC-OLR - adds extra complexity as = highlighted by Maria-Cruz. The benefit highlighted can be achieved in an implementation specific way b= y the receiver duplicating the information into OC-OLR before passing it to= the layer processing the OC-OLR. Regards, Nirav. -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Maria Cruz Bartolome Sent: Thursday, December 05, 2013 7:53 AM To: dime@ietf.org Subject: Re: [Dime] DOIC: Self-Contained OLRs Dear all, I agree with Lionel argumentation below. A part from that, one concern with "self-contained OLRs" is that some data= is duplicated. Duplication should be avoided, since then we need to assure= consistency, and error handing in case implicit and explicit data values a= re different for any reason... what means that it may always be required to= check both implicit and explicit data. Also, I think this is a pure implementation proposal. Regardless how the da= ta is transported it could be packed in a "self-contained OLRs" within the = diameter application, if for any implementation this is preferred. Regards /MCruz -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange= .com Sent: jueves, 05 de diciembre de 2013 1:43 To: Ben Campbell Cc: dime@ietf.org Subject: Re: [Dime] DOIC: Self-Contained OLRs Hi Ben, 3GPP operational requirements have triggered and driven this work, and 3GPP= will be the main client for this solution (if not the only for a while...)= . Main parties involved in the discussions are 3GPP vendors and 3GPP operat= ors. So instead trying to keep private preserve, we should welcome and enfo= rce cooperative work with 3GPP on this task if we want that the solution de= fined in IETF will be used in 3GPP. Otherwise, 3GPP may decide not to wait = for IETF and develop its own solution, as done in the past (e.g. developing= 3GPP-specific Cx application instead of adopting the IETF-standard Diamete= r SIP application). About the technical discussion, the Req31 says: REQ 31: There are multiple situations where a Diameter node may be overloaded for some purposes but not others. For example, this can happen to an agent or server that supports multiple applications, or when a server depends on multiple external resources, some of which may become overloaded while others are fully available. The solution MUST allow Diameter nodes to indicate overload with sufficient granularity to allow clients to take action based on the overloaded resources without unreasonably forcing available capacity to go unused. The solution MUST support specification of overload information with granularities of at least "Diameter node", "realm", and "Diameter application" and MUST allow extensibility for others to be added in the future. The "MUST" part says: enough granularity with at least host/realm and appli= cation. And the existing solution is compliant with this requirement. If a node is = supporting N applications, an OLR can be sent "per application" with a repo= rt type indicating if it is for the host or the realm. And the extensibilit= y capability is provided by the base solution. So my technical argument is that the existing proposal fulfills the basic r= equirements for an overload control without compromising future extension f= or further granularity. Regards, Lionel -----Message d'origine----- De : Ben Campbell [mailto:ben@nostrum.com] Envoy=E9 : mercredi 4 d=E9cembre= 2013 22:55 =C0 : MORAND Lionel IMT/OLN Cc : dime@ietf.org Objet : Re: [Dime] DOIC: Self-Contained OLRs On Dec 3, 2013, at 5:17 PM, lionel.morand@orange.com wrote: Hi Ben, I may be wrong somewhere in my summary but I think that it was the result o= f the discussions and agreements reached regarding existing requirements, a= t least from 3GPP point of view, compared to possible optimizations for fut= ure optimizations not so obvious. We are not the 3GPP. Our requirements are RFC 7068. I believe self-containe= d OLRs do a better job of meeting Req 31 than the contextually-defined OLRs= . I've made several technical arguments here--does anyone have _technical_ ar= guments in favor of contextually-defined OLRs? And because the solution offers extensibility via the definition of new alg= o, new report type and addition of any new AVP in the existing Grouped OLR,= the "limitations" of the proposed solution might be removed by someone if = really required according to new requirements. It might be worth considering a compromise approach: Define _optional_ AVPs= that allow an OLR to be self-contained. If they are not present, then the = various values default to those from the enclosing Diameter message. Possib= ly add support for this to the list of things that reacting nodes can adver= tise. This could be in the base, or in a follow on extension. (If left for an ext= ension, it's worth considering whether ReportType needs to be in the base, = or this or some other extension.) Regards, Lionel -----Message d'origine----- De : Ben Campbell [mailto:ben@nostrum.com] Envoy=E9 : mardi 3 d=E9cembre 2013 23:56 =C0 : MORAND Lionel IMT/OLN Cc : Steve Donovan; dime@ietf.org Objet : Re: [Dime] DOIC: Self-Contained OLRs On Dec 2, 2013, at 10:18 AM, lionel.morand@orange.com wrote: Hi Steve, I think that is not only about few bytes in the answer. It is also about th= e solution principles agreed so far: =B7 the current need is for an OLR bound to the application in use =B7 the OLR is received from the node targeted in the request. =B7 the OLR is defined per application I don't think those principles have been well tested. I don't recall any di= scussion of their benefits. What benefits do you see they have over self-co= ntained OLRs? All I see from these are restrictions in the flexibility of the solution, w= ith very little in return. So all the implicit information (application, origin-host, origin-realm) ar= e meaningful in this context. And the actual solution is designed based on these assumptions. The extensi= bility of the solution will allow extra info if required in other use cases= but it was agreed to go with a straightforward solution that will satisfy = most of us. Regards, Lionel De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan Envoy=E9 : lundi 2 d=E9cembre 2013 16:37 =C0 : dime@ietf.org Objet : Re: [Dime] DOIC: Self-Contained OLRs I don't believe that Ben's proposal was to change the piggybacking assumpti= on in the baseline mechanism. Ben's proposal is to design the solution in = such a way that it is not dependent on the piggybacking transport mechanism= . I share Ben's concern that we have over optimized the content of the overlo= ad report in a way that makes implementations brittle, interoperability mor= e difficult to achieve and extensibility more complex. And what do we gain= from this optimization? A few bites in answer messages. Self contained overload reports, transported using the piggybacking mechani= sm, is a cleaner solution. Steve On 11/29/13 8:31 AM, lionel.morand@orange.com wrote: I totally agree with Nirav. No need to revert at this stage the working ass= umption on piggybacking of OLR in application answer messages, especially w= hen the aim is to define a basic mechanism called "reduction". Anyone would be able to further add extra info for optimization if needed b= ut there is no need at all for the basic mechanism. Regards, Lionel -----Message d'origine----- De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot (nsalot) Envoy=E9 : vendredi 29 novembre 2013 12:24 =C0 : Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list Cc : Ben Campbell Objet : Re: [Dime] DOIC: Self-Contained OLRs Jouni, Ben, I am totally against the idea of self-contained OC-OLR specifically since w= e have adopted the principles of piggybacking the OC-OLR over existing appl= ication message. Self-contained OC-OLR - which means adding all the information which define= s the scope of the OC-OLR into the OC-OLR - does not make sense in the pigg= ybacking approach. In fact, it is adding lot of information, which is anywa= y available within the message containing the OC-OLR, into the OC-OLR. So i= t is adding lot of redundant information in a message which increases the p= rocessing requirement for the sender as well as the receiver. (And this is = un-optimization, in my view). Besides, I am not convinced with the other reasons provided here: - One software module within a node can provide OC-OLR to another software = module in the same node without passing other related info Within a node, based on the design, lots of information may need to be pa= ssed between two software modules and we cannot optimize those aspects by r= eplicating unnecessary information in a protocol message. In summary, it is node's internal software design issue and we need not o= ptimize that at protocol level. - Once the reporting node realizes that it is overloaded, it has to wait fo= r right answer to send OC-OLR What is the point of sending OC-OLR for a context for which there is no me= ssaging? Why should the reacting node care if it never sends a message for = a context for which the reporting node is overloaded? So this waiting is justified since it ensures that the overload is reporte= d only when necessary and only to the applicable reacting node. Not to all = the nodes in the network. - The agent needs to wait for the answer generated by the server and the ri= ght context The same argument as applicable for the server applies here. The agent ne= ed not send out-of-context overload info to a node. Why should reacting node receive/process/store the overload info for the = scope for which it is not sending any messages. - For sending OC-OLR in dedicated Diameter application??? Piggybacking was the first basic principle we agreed before putting other = principles in place. So we may want to go back the drawing board if we deci= de to change this principle. Regards, Nirav. -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen Sent: Friday, November 29, 2013 2:50 PM To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org li= st Cc: Ben Campbell Subject: Re: [Dime] DOIC: Self-Contained OLRs So, are we reaching any level of consensus here? - JOuni (as a note.. that we are converging back to where we started with OLRs ;) On Nov 28, 2013, at 12:40 PM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: Hi, another question: If we go for explicit self contained OLRs, why would we then need the Repor= tType? The realm-type OLR would explicitly contain application-Id, Realm, but no H= ost whereas the host-type OLR would explicitly contain application-Id, Host= , but probably (I'm not sure) no Realm. 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 stat= us. It could be provided an agent inserting this info in answers received f= rom a server behind but also from a server that would know this info by som= e internal magic. But in any case, if we assume that the client will received a successful an= swer from the server for an initial request with only Dest-Realm AVP, it sh= ould be possible to have both report types in the answer: one for the serve= r itself, one for the realm for new request sent to the realm with only Des= t-Realm AVP. Lionel -----Message d'origine----- De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN - DE/Munich) Envoy=E9 : jeudi 28 novembre 2013 10:26 =C0 : 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 a= ligned with the "endpoint principle". If the ReportType is "realm" this ind= icates 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 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 re= acting 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 Diamet= er request that corresponds to the answer containing the OLR. My reasons fo= r 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 i= dentified by Origin-Realm, and so on. This means that the "meaning" of an O= LR 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 answe= r to another, it's meaning may change completely. I think this approach is a mistake. I would greatly prefer that we explicit= ly 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 variou= s other AVPs to find all the information it needs. For example, I think a c= ommon software design for overload control processing to be separated from = application processing. The consumer cannot simply hand the OLR to that mod= ule and expect things to work. The OC module must not only parse the OLR, b= ut parse any other AVPs that are relevant. As OLR contents get extended (as= sumedly following the same strategy as the base spec), the number of "conte= xt" avps that must be interpreted can grow large. This approach is error pr= one, and will likely encourage brittle, hard-to-maintain code. Self-contain= ed OLRs would keep all the information related to overload in one place. ma= king for simpler implementations. 2) It's more complex for the reporting node to send implicit values than ex= plicit values. The sender cannot simply set the context to match the OLR--a= ll those other AVPs have application or protocol layer meanings. Once a rep= orting node realizes that it is overloade, it has to wait for the right ans= wer that contains the right context before it can send the OLR. This is par= ticularly 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 sig= nificantly. 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 so= me 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 overlo= ad reports were self-contained, one could just reuse the report format we s= pecify here. But if the meaning of an OLR depends on the way it's transport= ed, this won't work. We would have to create a new or significantly modifie= d OLR format if we found a need to transport OLRs in different ways. Self-c= ontained OLRs would allow much greater flexibility. So, in summary, I think that self-contained OLRs would lead to simpler impl= ementations, less brittle deployments, and more flexibility for future evol= ution 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 le= s pieces jointes. Les messages electroniques etant susceptibles d'alteratio= n, 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 dis= tributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te 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 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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 confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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 confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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 confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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 --_000_E194C2E18676714DACA9C3A2516265D201CB3FD9FR712WXCHMBA12z_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Steve, Ben

 <= /p>

I come back to the few mo= nths ago discussion  on the Roach-Draft where there were  a set o= f scopes quite similar to the self contained  OLRs principle you are now pushing. The self  contained  principle  reintroduces t= he many scopes approach without  forgetting all the underlying  c= ombinational aspects for which rules should be established  on what is= allowed or not allowed and so forth.  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 pro= ceed, which drove to the current draft content. This decision is a strong a= rgument that still prevails  in the current discussion

 <= /p>

So the current baseline h= as only one OLR with two types (Host and  realm)  and an implicit= reference to the application/destination/origin Host of the conveying message  which avoids the complexity of the former scope approach . T= here is  no reason currently to add further complexity with self conta= ined AVPS in an OLR mixing various AVPs  defining the “scopeR= 21; of the OLR.

The compromise is that if= in the future we have  a specific requirement (eg the APN example or = the session group)  to introduce new OLRs with other characteristics about their appliance, we could introduce new self contained AVPs for this= , but this does not change the baseline.

 <= /p>

 Steve about your se= ntence:

On the schedule question mentioned by JJacques -- an= y schedule concerns can go away if everyone agrees to self contained overlo= ad reports.  This discussion would end and we could move on to other t= hings.  :-)

I can write  

On the schedule question mentioned by JJacques -- an= y schedule concerns can go away if everyone agrees to the current OLR  = ;description in the draft.  This discussion would end and we could mov= e on to other things.  :-)

 

In fact I observe by rest= arting this discussion we already  had about the scopes with draft roa= ch, we may efectively endanger the schedule.

 

Best regards

 <= /p>

JJacques

  

 <= /p>

 <= /p>

De = : DiME [mailto:dime-bou= nces@ietf.org] De la part de Steve Donovan
Envoy=E9 : jeudi 5 d=E9cembre 2013 15:47
=C0 : Nirav Salot (nsalot); dime@ietf.org
Objet : Re: [Dime] DOIC: Self-Contained OLRs<= /p>

 

Nirav,

Thanks for clarifying.  This is obviously one area we have been making= different assumptions.  It's a good thing  this thread went on t= his long. :-)

One question, maybe for Maria Cruz.  If it is never ok for an overload= report to apply to an application other than the application carrying the = message then how does the "all applications" extension proposed b= y Maria Cruz work?

I will come back to address the "special architectural requirement&quo= t; question in a separate email.  I think I understand the point you a= re making.  I also don't think I agree this is a special architecture = requirement, but this requires some thought.

Steve

On 12/5/13 8:25 AM, Nirav Salot (nsalot) wrote:=

Steve,<= /p>

 <= /p>

We assumed that "sel= f-contained OC-OLR" contains the same information as the message conta= ining this AVP and hence we (me, JJ, Maria-Cruz) were saying that consistency check is needed.

 <= /p>

But now I understand that= "self-contained OC-OLR" can contain information of any context s= ince the AVP itself defines the context explicitly. So application-X message can carry application-Y's OC-OLR and I do not agree to this.

In my view, this is total= ly against the existing principles of Diameter based applications. And henc= e this requires special support at the receiving node as well as the sending node since today the nodes are designed to handle only= application specific data.

 <= /p>

In summary, "self-co= ntained OC-OLR" puts a special architectural requirement on Diameter n= odes – to handle one application's data from other application's mess= age – and hence this is a strong reason for me to object to "self-c= ontained OC-OLR".

 <= /p>

Regards,

Nirav.<= /p>

 <= /p>

From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Thursday, December 05, 2013 7:38 PM
To: Nirav Salot (nsalot); dime@ietf= .org
Subject: Re: [Dime] DOIC: Self-Contained OLRs

 

I must admit that I d= on't understand the need for consistency.

Why is it necessary to compare implicit and explicit data?  If we use = self contained reports then the contents of the report are what should be u= sed, independent of the message that carries the report.

Steve

On 12/5/13 7:49 AM, Nirav Salot (nsalot) wrote:=

Steve,<= /p>

 <= /p>

While gauging the complex= ity of "using the self-contained OC-OLR" It seems you have overlo= oked the aspect identified by Maria-Cruz below (and JJ earlier).

> Duplication s= hould be avoided, since then we need to assure consistency, and error handi= ng in case implicit and explicit data values are different for any reason... what means that it may always be required to check both = implicit and explicit data.

 <= /p>

Regards,

Nirav.<= /p>

 <= /p>

From: DiME [ma= ilto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: Thursday, December 05, 2013 6:26 PM
To: dime@ietf.org
Subject: Re: [Dime] DOIC: Self-Contained OLRs

 

If we equating "= complexity" with work done by a Diameter node, then there is added &qu= ot;complexity" for both proposals.

The extra work that needs to be done for the self contained report approach= is that the reporter needs to add additional AVPs to the report.  Thi= s is hardly difficult but it is extra work.

The extra work in the implicit approach is that the reactor needs to gather= information from multiple AVPs to understand the context of the AVP. = Again, hardly difficult but more work that can be avoided in a well layere= d software architecture.

My conclusion is that the complexity argument does not apply.  There i= s complexity in both, its just a matter of where the work is done.

Steve

On 12/5/13 3:29 AM, Nirav Salot (nsalot) wrote:= 

Agree with Lionel's view and Maria-Cruz's arguments below.<=
/pre>

 


The "self-contained OC-OLR" - which I assume contains the sa=
me information as present in the message containing the OC-OLR - adds extra=
 complexity as highlighted by Maria-Cruz.


The benefit highlighted can be achieved in an implementation specific =
way by the receiver duplicating the information into OC-OLR before passing =
it to the layer processing the OC-OLR.


 


Regards,


Nirav.


 


-----Original Message-----


From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of Maria Cruz Bartolome


Sent: Thursday, December 05, 2013 7:53 AM


To: dime@ietf.org

Subject: Re: [Dime] DOIC: Self-Contained OLRs


 


Dear all,


 


I agree with Lionel argumentation below.


 


A part from that,  one concern with "self-contained OLRs&quo=
t; is that some data is duplicated. Duplication should be avoided, since th=
en we need to assure consistency, and error handing in case implicit and ex=
plicit data values are different for any reason... what means that it may a=
lways be required to check both implicit and explicit data.

 


Also, I think this is a pure implementation proposal. Regardless how t=
he data is transported it could be packed in a "self-contained OLRs&qu=
ot; within the diameter application, if for any implementation this is pref=
erred.


 


Regards


/MCruz


 


 


-----Original Message-----


From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of l=
ionel.morand@orange.com


Sent: jueves, 05 de diciembre de 2013 1:43


To: Ben Campbell


Cc: dime@ietf.org

Subject: Re: [Dime] DOIC: Self-Contained OLRs


 


Hi Ben,


 


3GPP operational requirements have triggered and driven this work, and=
 3GPP will be the main client for this solution (if not the only for a whil=
e...). Main parties involved in the discussions are 3GPP vendors and 3GPP o=
perators. So instead trying to keep private preserve, we should welcome and=
 enforce cooperative work with 3GPP on this task if we want that the soluti=
on defined in IETF will be used in 3GPP. Otherwise, 3GPP may decide not to =
wait for IETF and develop its own solution, as done in the past (e.g. devel=
oping 3GPP-specific Cx application instead of adopting the IETF-standard Di=
ameter SIP application).


 


About the technical discussion, the Req31 says:


 


   REQ 31: There are multiple situations where a Diameter no=
de may be


           overloade=
d for some purposes but not others.  For example,


           this can =
happen to an agent or server that supports multiple


           applicati=
ons, or when a server depends on multiple external


           resources=
, some of which may become overloaded while others


           are fully=
 available.  The solution MUST allow Diameter nodes


           to indica=
te overload with sufficient granularity to allow


           clients t=
o take action based on the overloaded resources


           without u=
nreasonably forcing available capacity to go unused.


           The solut=
ion MUST support specification of overload


           informati=
on with granularities of at least "Diameter node",

           "rea=
lm", and "Diameter application" and MUST allow

           extensibi=
lity for others to be added in the future.


 


The "MUST" part says: enough granularity with at least host/=
realm and application.


And the existing solution is compliant with this requirement. If a nod=
e is supporting N applications, an OLR can be sent "per application&qu=
ot; with a report type indicating if it is for the host or the realm. And t=
he extensibility capability is provided by the base solution.

 


So my technical argument is that the existing proposal fulfills the ba=
sic requirements for an overload control without compromising future extens=
ion for further granularity.


 


Regards,


 


Lionel 


 


-----Message d'origine-----


De : Ben Campbell [mailto:ben@=
nostrum.com] Envoy=E9 : mercredi 4 d=E9cembre 2013 22:55 =C0 =
: MORAND Lionel IMT/OLN Cc : dime@iet=
f.org Objet : Re: [Dime] DOIC: Self-Contained OLRs

 


On Dec 3, 2013, at 5:17 PM, lionel.morand@orange.com wrote:


 




Hi Ben,


 


I may be wrong somewhere in my summary but I think that it was the res=
ult of the discussions and agreements reached regarding existing requiremen=
ts, at least from 3GPP point of view, compared to possible optimizations fo=
r future optimizations not so obvious.




 


We are not the 3GPP. Our requirements are RFC 7068. I believe self-con=
tained OLRs do a better job of meeting Req 31 than the contextually-defined=
 OLRs.


 


I've made several technical arguments here--does anyone have _technica=
l_ arguments in favor of contextually-defined OLRs?


 




And because the solution offers extensibility via the definition of ne=
w algo, new report type and addition of any new AVP in the existing Grouped=
 OLR, the "limitations" of the proposed solution might be removed=
 by someone if really required according to new requirements.

 




 


It might be worth considering a compromise approach: Define _optional_=
 AVPs that allow an OLR to be self-contained. If they are not present, then=
 the various values default to those from the enclosing Diameter message. P=
ossibly add support for this to the list of things that reacting nodes can =
advertise.


 


This could be in the base, or in a follow on extension. (If left for a=
n extension, it's worth considering whether ReportType needs to be in the b=
ase, or this or some other extension.) 


 


 




Regards,


 


Lionel


 


-----Message d'origine-----


De : Ben Campbell [mailto:ben@nostr=
um.com] Envoy=E9 : mardi 3 d=E9cembre 


2013 23:56 =C0 : MORAND Lionel IMT/OLN Cc : Steve Donovan; dime@ietf.org 


Objet : Re: [Dime] DOIC: Self-Contained OLRs


 


 


On Dec 2, 2013, at 10:18 AM, lionel.morand@orange.com wrote:


 




Hi Steve,


 


I think that is not only about few bytes in the answer. It is also abo=
ut the solution principles agreed so far:


=B7         the current need i=
s for an OLR bound to the application in use


=B7         the OLR is receive=
d from the node targeted in the request.


=B7         the OLR is defined=
 per application




 


I don't think those principles have been well tested. I don't recall a=
ny discussion of their benefits. What benefits do you see they have over se=
lf-contained OLRs?


 


All I see from these are restrictions in the flexibility of the soluti=
on, with very little in return.


 




So all the implicit information (application, origin-host, origin-real=
m) are meaningful in this context.


And the actual solution is designed based on these assumptions. The ex=
tensibility of the solution will allow extra info if required in other use =
cases but it was agreed to go with a straightforward solution that will sat=
isfy most of us.


 


Regards,


 


Lionel


 


De : DiME [mailto:dime-bounce=
s@ietf.org] De la part de Steve Donovan


Envoy=E9 : lundi 2 d=E9cembre 2013 16:37


=C0 : dime@ietf.org

Objet : Re: [Dime] DOIC: Self-Contained OLRs


 


I don't believe that Ben's proposal was to change the piggybacking ass=
umption in the baseline mechanism.  Ben's proposal is to design the so=
lution in such a way that it is not dependent on the piggybacking transport=
 mechanism.  


 


I share Ben's concern that we have over optimized the content of the o=
verload report in a way that makes implementations brittle, interoperabilit=
y more difficult to achieve and extensibility more complex.  And what =
do we gain from this optimization?  A few bites in answer messages.


 


Self contained overload reports, transported using the piggybacking me=
chanism, is a cleaner solution.


 


Steve


 


On 11/29/13 8:31 AM, lione=
l.morand@orange.com wrote:


I totally agree with Nirav. No need to revert at this stage the workin=
g assumption on piggybacking of OLR in application answer messages, especia=
lly when the aim is to define a basic mechanism called "reduction"=
;.


 


Anyone would be able to further add extra info for optimization if nee=
ded but there is no need at all for the basic mechanism.


 


Regards,


 


Lionel


 


-----Message d'origine-----


De : DiME [mailto:dime-bounce=
s@ietf.org] De la part de Nirav Salot (nsalot)


Envoy=E9 : vendredi 29 novembre 2013 12:24


=C0 : Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list


Cc : Ben Campbell


Objet : Re: [Dime] DOIC: Self-Contained OLRs


 


Jouni, Ben,


 


I am totally against the idea of self-contained OC-OLR specifically si=
nce we have adopted the principles of piggybacking the OC-OLR over existing=
 application message.


Self-contained OC-OLR - which means adding all the information which d=
efines the scope of the OC-OLR into the OC-OLR - does not make sense in the=
 piggybacking approach. In fact, it is adding lot of information, which is =
anyway available within the message containing the OC-OLR, into the OC-OLR.=
 So it is adding lot of redundant information in a message which increases =
the processing requirement for the sender as well as the receiver. (And thi=
s is un-optimization, in my view).


 


Besides, I am not convinced with the other reasons provided here:=



- One software module within a node can provide OC-OLR to another soft=
ware module in the same node without passing other related info<=
/pre>

  Within a node, based on the design, lots of information may nee=
d to be passed between two software modules and we cannot optimize those as=
pects by replicating unnecessary information in a protocol message.


  In summary, it is node's internal software design issue and we =
need not optimize that at protocol level.


 


- Once the reporting node realizes that it is overloaded, it has to wa=
it for right answer to send OC-OLR


 What is the point of sending OC-OLR for a context for which there is =
no messaging? Why should the reacting node care if it never sends a message=
 for a context for which the reporting node is overloaded?


 So this waiting is justified since it ensures that the overload is re=
ported only when necessary and only to the applicable reacting node. Not to=
 all the nodes in the network.


 


- The agent needs to wait for the answer generated by the server and t=
he right context


  The same argument as applicable for the server applies here. Th=
e agent need not send out-of-context overload info to a node.

  Why should reacting node receive/process/store the overload inf=
o for the scope for which it is not sending any messages.


 


- For sending OC-OLR in dedicated Diameter application???

 Piggybacking was the first basic principle we agreed before putting o=
ther principles in place. So we may want to go back the drawing board if we=
 decide to change this principle.


 


Regards,


Nirav.


 


-----Original Message-----


From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of Jouni Korhonen


Sent: Friday, November 29, 2013 2:50 PM


To: Wiehe, Ulrich (NSN - DE/Munich); =
dime@ietf.org list


Cc: Ben Campbell


Subject: Re: [Dime] DOIC: Self-Contained OLRs


 


 


 


So, are we reaching any level of consensus here?


 


- JOuni


 


(as a note.. that we are converging back to where we started with OLRs=
 ;)


 


 


 


On Nov 28, 2013, at 12:40 PM, "Wiehe, Ulrich (NSN - DE/Munich)&qu=
ot; <ulrich.wiehe@nsn.com> wrote:


 


Hi,


 


another question:


 


If we go for explicit self contained OLRs, why would we then need the =
ReportType?


 


The realm-type OLR would explicitly contain application-Id, Realm, but=
 no Host whereas the host-type OLR would explicitly contain application-Id,=
 Host, but probably (I'm not sure) no Realm.


 


Ulrich


 


 


 


-----Original Message-----


From: ext lionel.morand@or=
ange.com [mailto:lionel.mor=
and@orange.com]


Sent: Thursday, November 28, 2013 10:31 AM


To: Wiehe, Ulrich (NSN - DE/Munich); ext Jouni Korhonen; Ben Campbell<=
o:p>


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 recei=
ved from a server behind but also from a server that would know this info b=
y some internal magic.


But in any case, if we assume that the client will received a successf=
ul 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 onl=
y Dest-Realm AVP.


 


Lionel


 


-----Message d'origine-----


De : DiME [mailto:dime-bounce=
s@ietf.org] De la part de Wiehe, Ulrich 


(NSN - DE/Munich) Envoy=E9 : jeudi 28 novembre 2013 10:26 =C0 : ext Jo=
uni 


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 &=
quot;realm" this indicates to the reacting end point that the reportin=
g 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 repor=
ting end point is a server. How can the reporting end point be both agent a=
nd server?


 


Ulrich


 


-----Original Message-----


From: DiME [mailto:dime-bounc=
es@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 <=
/o:p>


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 t=
he 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 D=
iameter request that corresponds to the answer containing the OLR. My reaso=
ns 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 applica=
tion identified by the Application-Id field of the enclosing answer, the re=
alm identified by Origin-Realm, and so on. This means that the "meanin=
g" of an OLR cannot be determined from the OLR contents alone; OLRs on=
ly 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 exp=
licitly include such values in the OLR itself, for multiple reasons:


 


1) It's more complex to interpret implicit, contextual values than exp=
licit values. The consumer cannot simply look at the OLR; it must look in v=
arious other AVPs to find all the information it needs. For example, I thin=
k a common software design for overload control processing to be separated =
from application processing. The consumer cannot simply hand the OLR to tha=
t module and expect things to work. The OC module must not only parse the O=
LR, but parse any other AVPs that are relevant. As OLR contents get extende=
d (assumedly following the same strategy as the base spec), the number of &=
quot;context" avps that must be interpreted can grow large. This appro=
ach is error prone, and will likely encourage brittle, hard-to-maintain cod=
e. Self-contained OLRs would keep all the information related to overload i=
n one place. making for simpler implementations.


 


2) It's more complex for the reporting node to send implicit values th=
an explicit values. The sender cannot simply set the context to match the O=
LR--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 righ=
t answer that contains the right context before it can send the OLR. This i=
s particularly troublesome for agents, since they will typically have to in=
sert OLRs into answers created by other nodes. 


 


If the reporting node screws this up, the meaning of the OLR may chang=
e significantly. So again, implicit meaning gives us error prone implementa=
tions. 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 <=
o:p>


are distinct from those sent by a server, see Steve's agent overload <=
o:p>


draft, or my dh/dr example.)


 


OTOH, explicit values will work for all cases where we need to associa=
te some arbitrary value with an OLR.


 


4) Implicit values seriously constrain the future evolution of Diamete=
r OC standards. For example, lets say we find a good reason to allow OLRs t=
o be sent out of band, or be sent in a dedicated Diameter application. If o=
verload 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 tran=
sported, this won't work. We would have to create a new or significantly mo=
dified OLR format if we found a need to transport OLRs in different ways. S=
elf-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.iet=
f.org/mailman/listinfo/dime


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.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 q=
ue les pieces jointes. Les messages electroniques etant susceptibles d'alte=
ration, Orange decline toute responsabilite si ce message a ete altere, def=
orme ou falsifie. Merci.


 


This message and its attachments may contain confidential or 


privileged information that may be protected by law; they should not b=
e 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.iet=
f.org/mailman/listinfo/dime


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 


______________________________________________________________________=
___________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


 


This message and its attachments may contain confidential or privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
o:p>


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.iet=
f.org/mailman/listinfo/dime


 


 


______________________________________________________________________=
___________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


 


This message and its attachments may contain confidential or privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
o:p>


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.iet=
f.org/mailman/listinfo/dime




 


 


______________________________________________________________________=
___________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


 


This message and its attachments may contain confidential or privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
o:p>


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.iet=
f.org/mailman/listinfo/dime




 


 


______________________________________________________________________=
___________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


 


This message and its attachments may contain confidential or privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
o:p>


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.iet=
f.org/mailman/listinfo/dime


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 

 

 

 

--_000_E194C2E18676714DACA9C3A2516265D201CB3FD9FR712WXCHMBA12z_-- From lionel.morand@orange.com Thu Dec 5 07:14:14 2013 Return-Path: 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 E6E451AE093 for ; Thu, 5 Dec 2013 07:14:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 w9Vwm4Cdxq4K for ; Thu, 5 Dec 2013 07:13:58 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id E81661AE092 for ; Thu, 5 Dec 2013 07:13:57 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id D837A2DC2E0; Thu, 5 Dec 2013 16:13:53 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id B74584C063; Thu, 5 Dec 2013 16:13:53 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0158.001; Thu, 5 Dec 2013 16:13:53 +0100 From: To: Steve Donovan , "Nirav Salot (nsalot)" , "dime@ietf.org" Thread-Topic: [Dime] DOIC: Self-Contained OLRs Thread-Index: AQHO8HrXo7y6FFeeaEmQ38aKczpYQJpDChOAgAF7IoCAAC7igIAAKrUQgABohICAADmQAIAADvuAgAAFTgCAAATPgIAABekAgAAWtWA= Date: Thu, 5 Dec 2013 15:13:52 +0000 Message-ID: <13081_1386256433_52A09831_13081_8197_1_6B7134B31289DC4FAF731D844122B36E32B6EB@PEXCVZYM13.corporate.adroot.infra.ftgroup> 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> <14594_1386204165_529FCC05_14594_12646_1_6B7134B31289DC4FAF731D844122B36E329907@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B920972CCAA@ESESSMB101.ericsson.se> <52A077CC.3000004@usdonovans.com> <52A088D0.2020406@usdonovans.com> <52A091CE.2000104@usdonovans.com> In-Reply-To: <52A091CE.2000104@usdonovans.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.5] Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E32B6EBPEXCVZYM13corpora_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.12.5.143019 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 15:14:14 -0000 --_000_6B7134B31289DC4FAF731D844122B36E32B6EBPEXCVZYM13corpora_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Steve, "I also don't think I agree this is a special architecture requirement, but= this requires some thought." I repeat one of my comments... being able to receive an OLR for another app= lication that the one carrying the report implies that there is functional = link between the functions, either a direct link or through a kind of centr= alized overload control function (or any equivalent function). And here is = the reason for my "STRONG NO" for the self-contained OLRs, based on the exi= sting requirements regarding Diameter overload control. Lionel De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan Envoy=E9 : jeudi 5 d=E9cembre 2013 15:47 =C0 : Nirav Salot (nsalot); dime@ietf.org Objet : Re: [Dime] DOIC: Self-Contained OLRs Nirav, Thanks for clarifying. This is obviously one area we have been making diff= erent assumptions. It's a good thing this thread went on this long. :-) One question, maybe for Maria Cruz. If it is never ok for an overload repo= rt to apply to an application other than the application carrying the messa= ge then how does the "all applications" extension proposed by Maria Cruz wo= rk? I will come back to address the "special architectural requirement" questio= n in a separate email. I think I understand the point you are making. I a= lso don't think I agree this is a special architecture requirement, but thi= s requires some thought. Steve On 12/5/13 8:25 AM, Nirav Salot (nsalot) wrote: Steve, We assumed that "self-contained OC-OLR" contains the same information as th= e message containing this AVP and hence we (me, JJ, Maria-Cruz) were saying= that consistency check is needed. But now I understand that "self-contained OC-OLR" can contain information o= f any context since the AVP itself defines the context explicitly. So appli= cation-X message can carry application-Y's OC-OLR and I do not agree to thi= s. In my view, this is totally against the existing principles of Diameter bas= ed applications. And hence this requires special support at the receiving n= ode as well as the sending node since today the nodes are designed to handl= e only application specific data. In summary, "self-contained OC-OLR" puts a special architectural requiremen= t on Diameter nodes - to handle one application's data from other applicati= on's message - and hence this is a strong reason for me to object to "self-= contained OC-OLR". Regards, Nirav. From: Steve Donovan [mailto:srdonovan@usdonovans.com] Sent: Thursday, December 05, 2013 7:38 PM To: Nirav Salot (nsalot); dime@ietf.org Subject: Re: [Dime] DOIC: Self-Contained OLRs I must admit that I don't understand the need for consistency. Why is it necessary to compare implicit and explicit data? If we use self = contained reports then the contents of the report are what should be used, = independent of the message that carries the report. Steve On 12/5/13 7:49 AM, Nirav Salot (nsalot) wrote: Steve, While gauging the complexity of "using the self-contained OC-OLR" It seems = you have overlooked the aspect identified by Maria-Cruz below (and JJ earli= er). > Duplication should be avoided, since then we need to assure consistency, = and error handing in case implicit and explicit data values are different f= or any reason... what means that it may always be required to check both im= plicit and explicit data. Regards, Nirav. From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: Thursday, December 05, 2013 6:26 PM To: dime@ietf.org Subject: Re: [Dime] DOIC: Self-Contained OLRs If we equating "complexity" with work done by a Diameter node, then there i= s added "complexity" for both proposals. The extra work that needs to be done for the self contained report approach= is that the reporter needs to add additional AVPs to the report. This is = hardly difficult but it is extra work. The extra work in the implicit approach is that the reactor needs to gather= information from multiple AVPs to understand the context of the AVP. Agai= n, hardly difficult but more work that can be avoided in a well layered sof= tware architecture. My conclusion is that the complexity argument does not apply. There is com= plexity in both, its just a matter of where the work is done. Steve On 12/5/13 3:29 AM, Nirav Salot (nsalot) wrote: Agree with Lionel's view and Maria-Cruz's arguments below. The "self-contained OC-OLR" - which I assume contains the same information = as present in the message containing the OC-OLR - adds extra complexity as = highlighted by Maria-Cruz. The benefit highlighted can be achieved in an implementation specific way b= y the receiver duplicating the information into OC-OLR before passing it to= the layer processing the OC-OLR. Regards, Nirav. -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Maria Cruz Bartolome Sent: Thursday, December 05, 2013 7:53 AM To: dime@ietf.org Subject: Re: [Dime] DOIC: Self-Contained OLRs Dear all, I agree with Lionel argumentation below. A part from that, one concern with "self-contained OLRs" is that some data= is duplicated. Duplication should be avoided, since then we need to assure= consistency, and error handing in case implicit and explicit data values a= re different for any reason... what means that it may always be required to= check both implicit and explicit data. Also, I think this is a pure implementation proposal. Regardless how the da= ta is transported it could be packed in a "self-contained OLRs" within the = diameter application, if for any implementation this is preferred. Regards /MCruz -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange= .com Sent: jueves, 05 de diciembre de 2013 1:43 To: Ben Campbell Cc: dime@ietf.org Subject: Re: [Dime] DOIC: Self-Contained OLRs Hi Ben, 3GPP operational requirements have triggered and driven this work, and 3GPP= will be the main client for this solution (if not the only for a while...)= . Main parties involved in the discussions are 3GPP vendors and 3GPP operat= ors. So instead trying to keep private preserve, we should welcome and enfo= rce cooperative work with 3GPP on this task if we want that the solution de= fined in IETF will be used in 3GPP. Otherwise, 3GPP may decide not to wait = for IETF and develop its own solution, as done in the past (e.g. developing= 3GPP-specific Cx application instead of adopting the IETF-standard Diamete= r SIP application). About the technical discussion, the Req31 says: REQ 31: There are multiple situations where a Diameter node may be overloaded for some purposes but not others. For example, this can happen to an agent or server that supports multiple applications, or when a server depends on multiple external resources, some of which may become overloaded while others are fully available. The solution MUST allow Diameter nodes to indicate overload with sufficient granularity to allow clients to take action based on the overloaded resources without unreasonably forcing available capacity to go unused. The solution MUST support specification of overload information with granularities of at least "Diameter node", "realm", and "Diameter application" and MUST allow extensibility for others to be added in the future. The "MUST" part says: enough granularity with at least host/realm and appli= cation. And the existing solution is compliant with this requirement. If a node is = supporting N applications, an OLR can be sent "per application" with a repo= rt type indicating if it is for the host or the realm. And the extensibilit= y capability is provided by the base solution. So my technical argument is that the existing proposal fulfills the basic r= equirements for an overload control without compromising future extension f= or further granularity. Regards, Lionel -----Message d'origine----- De : Ben Campbell [mailto:ben@nostrum.com] Envoy=E9 : mercredi 4 d=E9cembre= 2013 22:55 =C0 : MORAND Lionel IMT/OLN Cc : dime@ietf.org Objet : Re: [Dime] DOIC: Self-Contained OLRs On Dec 3, 2013, at 5:17 PM, lionel.morand@orange.com wrote: Hi Ben, I may be wrong somewhere in my summary but I think that it was the result o= f the discussions and agreements reached regarding existing requirements, a= t least from 3GPP point of view, compared to possible optimizations for fut= ure optimizations not so obvious. We are not the 3GPP. Our requirements are RFC 7068. I believe self-containe= d OLRs do a better job of meeting Req 31 than the contextually-defined OLRs. I've made several technical arguments here--does anyone have _technical_ ar= guments in favor of contextually-defined OLRs? And because the solution offers extensibility via the definition of new alg= o, new report type and addition of any new AVP in the existing Grouped OLR,= the "limitations" of the proposed solution might be removed by someone if = really required according to new requirements. It might be worth considering a compromise approach: Define _optional_ AVPs= that allow an OLR to be self-contained. If they are not present, then the = various values default to those from the enclosing Diameter message. Possib= ly add support for this to the list of things that reacting nodes can adver= tise. This could be in the base, or in a follow on extension. (If left for an ext= ension, it's worth considering whether ReportType needs to be in the base, = or this or some other extension.) Regards, Lionel -----Message d'origine----- De : Ben Campbell [mailto:ben@nostrum.com] Envoy=E9 : mardi 3 d=E9cembre 2013 23:56 =C0 : MORAND Lionel IMT/OLN Cc : Steve Donovan; dime@ietf.org Objet : Re: [Dime] DOIC: Self-Contained OLRs On Dec 2, 2013, at 10:18 AM, lionel.morand@orange.com wrote: Hi Steve, I think that is not only about few bytes in the answer. It is also about th= e solution principles agreed so far: =B7 the current need is for an OLR bound to the application in use =B7 the OLR is received from the node targeted in the request. =B7 the OLR is defined per application I don't think those principles have been well tested. I don't recall any di= scussion of their benefits. What benefits do you see they have over self-co= ntained OLRs? All I see from these are restrictions in the flexibility of the solution, w= ith very little in return. So all the implicit information (application, origin-host, origin-realm) ar= e meaningful in this context. And the actual solution is designed based on these assumptions. The extensi= bility of the solution will allow extra info if required in other use cases= but it was agreed to go with a straightforward solution that will satisfy = most of us. Regards, Lionel De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan Envoy=E9 : lundi 2 d=E9cembre 2013 16:37 =C0 : dime@ietf.org Objet : Re: [Dime] DOIC: Self-Contained OLRs I don't believe that Ben's proposal was to change the piggybacking assumpti= on in the baseline mechanism. Ben's proposal is to design the solution in = such a way that it is not dependent on the piggybacking transport mechanism. I share Ben's concern that we have over optimized the content of the overlo= ad report in a way that makes implementations brittle, interoperability mor= e difficult to achieve and extensibility more complex. And what do we gain= from this optimization? A few bites in answer messages. Self contained overload reports, transported using the piggybacking mechani= sm, is a cleaner solution. Steve On 11/29/13 8:31 AM, lionel.morand@orange.com wrote: I totally agree with Nirav. No need to revert at this stage the working ass= umption on piggybacking of OLR in application answer messages, especially w= hen the aim is to define a basic mechanism called "reduction". Anyone would be able to further add extra info for optimization if needed b= ut there is no need at all for the basic mechanism. Regards, Lionel -----Message d'origine----- De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot (nsalot) Envoy=E9 : vendredi 29 novembre 2013 12:24 =C0 : Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list Cc : Ben Campbell Objet : Re: [Dime] DOIC: Self-Contained OLRs Jouni, Ben, I am totally against the idea of self-contained OC-OLR specifically since w= e have adopted the principles of piggybacking the OC-OLR over existing appl= ication message. Self-contained OC-OLR - which means adding all the information which define= s the scope of the OC-OLR into the OC-OLR - does not make sense in the pigg= ybacking approach. In fact, it is adding lot of information, which is anywa= y available within the message containing the OC-OLR, into the OC-OLR. So i= t is adding lot of redundant information in a message which increases the p= rocessing requirement for the sender as well as the receiver. (And this is = un-optimization, in my view). Besides, I am not convinced with the other reasons provided here: - One software module within a node can provide OC-OLR to another software = module in the same node without passing other related info Within a node, based on the design, lots of information may need to be pa= ssed between two software modules and we cannot optimize those aspects by r= eplicating unnecessary information in a protocol message. In summary, it is node's internal software design issue and we need not o= ptimize that at protocol level. - Once the reporting node realizes that it is overloaded, it has to wait fo= r right answer to send OC-OLR What is the point of sending OC-OLR for a context for which there is no me= ssaging? Why should the reacting node care if it never sends a message for = a context for which the reporting node is overloaded? So this waiting is justified since it ensures that the overload is reporte= d only when necessary and only to the applicable reacting node. Not to all = the nodes in the network. - The agent needs to wait for the answer generated by the server and the ri= ght context The same argument as applicable for the server applies here. The agent ne= ed not send out-of-context overload info to a node. Why should reacting node receive/process/store the overload info for the = scope for which it is not sending any messages. - For sending OC-OLR in dedicated Diameter application??? Piggybacking was the first basic principle we agreed before putting other = principles in place. So we may want to go back the drawing board if we deci= de to change this principle. Regards, Nirav. -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen Sent: Friday, November 29, 2013 2:50 PM To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org li= st Cc: Ben Campbell Subject: Re: [Dime] DOIC: Self-Contained OLRs So, are we reaching any level of consensus here? - JOuni (as a note.. that we are converging back to where we started with OLRs ;) On Nov 28, 2013, at 12:40 PM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: Hi, another question: If we go for explicit self contained OLRs, why would we then need the Repor= tType? The realm-type OLR would explicitly contain application-Id, Realm, but no H= ost whereas the host-type OLR would explicitly contain application-Id, Host= , but probably (I'm not sure) no Realm. 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 stat= us. It could be provided an agent inserting this info in answers received f= rom a server behind but also from a server that would know this info by som= e internal magic. But in any case, if we assume that the client will received a successful an= swer from the server for an initial request with only Dest-Realm AVP, it sh= ould be possible to have both report types in the answer: one for the serve= r itself, one for the realm for new request sent to the realm with only Des= t-Realm AVP. Lionel -----Message d'origine----- De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN - DE/Munich) Envoy=E9 : jeudi 28 novembre 2013 10:26 =C0 : 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 a= ligned with the "endpoint principle". If the ReportType is "realm" this ind= icates 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 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 re= acting 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 Diamet= er request that corresponds to the answer containing the OLR. My reasons fo= r 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 i= dentified by Origin-Realm, and so on. This means that the "meaning" of an O= LR 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 answe= r to another, it's meaning may change completely. I think this approach is a mistake. I would greatly prefer that we explicit= ly 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 variou= s other AVPs to find all the information it needs. For example, I think a c= ommon software design for overload control processing to be separated from = application processing. The consumer cannot simply hand the OLR to that mod= ule and expect things to work. The OC module must not only parse the OLR, b= ut parse any other AVPs that are relevant. As OLR contents get extended (as= sumedly following the same strategy as the base spec), the number of "conte= xt" avps that must be interpreted can grow large. This approach is error pr= one, and will likely encourage brittle, hard-to-maintain code. Self-contain= ed OLRs would keep all the information related to overload in one place. ma= king for simpler implementations. 2) It's more complex for the reporting node to send implicit values than ex= plicit values. The sender cannot simply set the context to match the OLR--a= ll those other AVPs have application or protocol layer meanings. Once a rep= orting node realizes that it is overloade, it has to wait for the right ans= wer that contains the right context before it can send the OLR. This is par= ticularly 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 sig= nificantly. 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 so= me 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 overlo= ad reports were self-contained, one could just reuse the report format we s= pecify here. But if the meaning of an OLR depends on the way it's transport= ed, this won't work. We would have to create a new or significantly modifie= d OLR format if we found a need to transport OLRs in different ways. Self-c= ontained OLRs would allow much greater flexibility. So, in summary, I think that self-contained OLRs would lead to simpler impl= ementations, less brittle deployments, and more flexibility for future evol= ution 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 le= s pieces jointes. Les messages electroniques etant susceptibles d'alteratio= n, 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 dis= tributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te 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 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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 confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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 confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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 confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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 confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. --_000_6B7134B31289DC4FAF731D844122B36E32B6EBPEXCVZYM13corpora_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Steve,

 <= /p>

"I also don't think I agree this is a special archit= ecture requirement, but this requires some thought."

 = ;

I repeat o= ne of my comments… being able to receive an OLR for another applicati= on that the one carrying the report implies that there is functional link between the functions, either a direct link or through a kind of cent= ralized overload control function (or any equivalent function). And here is= the reason for my "STRONG NO" for the self-contained OLRs, based= on the existing requirements regarding Diameter overload control.

 = ;

Lionel

 = ;

De := DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9 : jeudi 5 d=E9cembre 2013 15:47
=C0 : Nirav Salot (nsalot); dime@ietf.org
Objet : Re: [Dime] DOIC: Self-Contained OLRs<= /p>

 

Nirav,

Thanks for clarifying.  This is obviously one area we have been making= different assumptions.  It's a good thing  this thread went on t= his long. :-)

One question, maybe for Maria Cruz.  If it is never ok for an overload= report to apply to an application other than the application carrying the = message then how does the "all applications" extension proposed b= y Maria Cruz work?

I will come back to address the "special architectural requirement&quo= t; question in a separate email.  I think I understand the point you a= re making.  I also don't think I agree this is a special architecture = requirement, but this requires some thought.

Steve

On 12/5/13 8:25 AM, Nirav Salot (nsalot) wrote:=

Steve,<= /p>

 <= /p>

We assumed that "sel= f-contained OC-OLR" contains the same information as the message conta= ining this AVP and hence we (me, JJ, Maria-Cruz) were saying that consistency check is needed.

 <= /p>

But now I understand that= "self-contained OC-OLR" can contain information of any context s= ince the AVP itself defines the context explicitly. So application-X message can carry application-Y's OC-OLR and I do not agree to this.

In my view, this is total= ly against the existing principles of Diameter based applications. And henc= e this requires special support at the receiving node as well as the sending node since today the nodes are designed to handle only= application specific data.

 <= /p>

In summary, "self-co= ntained OC-OLR" puts a special architectural requirement on Diameter n= odes – to handle one application's data from other application's mess= age – and hence this is a strong reason for me to object to "self-c= ontained OC-OLR".

 <= /p>

Regards,

Nirav.<= /p>

 <= /p>

From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Thursday, December 05, 2013 7:38 PM
To: Nirav Salot (nsalot); dime@ietf= .org
Subject: Re: [Dime] DOIC: Self-Contained OLRs

 

I must admit that I d= on't understand the need for consistency.

Why is it necessary to compare implicit and explicit data?  If we use = self contained reports then the contents of the report are what should be u= sed, independent of the message that carries the report.

Steve

On 12/5/13 7:49 AM, Nirav Salot (nsalot) wrote:=

Steve,<= /p>

 <= /p>

While gauging the complex= ity of "using the self-contained OC-OLR" It seems you have overlo= oked the aspect identified by Maria-Cruz below (and JJ earlier).

> Duplication s= hould be avoided, since then we need to assure consistency, and error handi= ng in case implicit and explicit data values are different for any reason... what means that it may always be required to check both = implicit and explicit data.

 <= /p>

Regards,

Nirav.<= /p>

 <= /p>

From: DiME [ma= ilto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: Thursday, December 05, 2013 6:26 PM
To: dime@ietf.org
Subject: Re: [Dime] DOIC: Self-Contained OLRs

 

If we equating "= complexity" with work done by a Diameter node, then there is added &qu= ot;complexity" for both proposals.

The extra work that needs to be done for the self contained report approach= is that the reporter needs to add additional AVPs to the report.  Thi= s is hardly difficult but it is extra work.

The extra work in the implicit approach is that the reactor needs to gather= information from multiple AVPs to understand the context of the AVP. = Again, hardly difficult but more work that can be avoided in a well layere= d software architecture.

My conclusion is that the complexity argument does not apply.  There i= s complexity in both, its just a matter of where the work is done.

Steve

On 12/5/13 3:29 AM, Nirav Salot (nsalot) wrote:= 

Agree with Lionel's view and Maria-Cruz's arguments below.<=
/pre>

 


The "self-contained OC-OLR" - which I assume contains the sa=
me information as present in the message containing the OC-OLR - adds extra=
 complexity as highlighted by Maria-Cruz.


The benefit highlighted can be achieved in an implementation specific =
way by the receiver duplicating the information into OC-OLR before passing =
it to the layer processing the OC-OLR.


 


Regards,


Nirav.


 


-----Original Message-----


From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of Maria Cruz Bartolome


Sent: Thursday, December 05, 2013 7:53 AM


To: dime@ietf.org


Subject: Re: [Dime] DOIC: Self-Contained OLRs


 


Dear all,


 


I agree with Lionel argumentation below.


 


A part from that,  one concern with "self-contained OLRs&quo=
t; is that some data is duplicated. Duplication should be avoided, since th=
en we need to assure consistency, and error handing in case implicit and ex=
plicit data values are different for any reason... what means that it may a=
lways be required to check both implicit and explicit data.


 


Also, I think this is a pure implementation proposal. Regardless how t=
he data is transported it could be packed in a "self-contained OLRs&qu=
ot; within the diameter application, if for any implementation this is pref=
erred.


 


Regards


/MCruz


 


 


-----Original Message-----


From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of l=
ionel.morand@orange.com


Sent: jueves, 05 de diciembre de 2013 1:43


To: Ben Campbell


Cc: dime@ietf.org


Subject: Re: [Dime] DOIC: Self-Contained OLRs


 


Hi Ben,


 


3GPP operational requirements have triggered and driven this work, and=
 3GPP will be the main client for this solution (if not the only for a whil=
e...). Main parties involved in the discussions are 3GPP vendors and 3GPP o=
perators. So instead trying to keep private preserve, we should welcome and=
 enforce cooperative work with 3GPP on this task if we want that the soluti=
on defined in IETF will be used in 3GPP. Otherwise, 3GPP may decide not to =
wait for IETF and develop its own solution, as done in the past (e.g. devel=
oping 3GPP-specific Cx application instead of adopting the IETF-standard Di=
ameter SIP application).


 


About the technical discussion, the Req31 says:


 


   REQ 31: There are multiple situations where a Diameter no=
de may be


           overloade=
d for some purposes but not others.  For example,


           this can =
happen to an agent or server that supports multiple


           applicati=
ons, or when a server depends on multiple external


           resources=
, some of which may become overloaded while others


           are fully=
 available.  The solution MUST allow Diameter nodes


           to indica=
te overload with sufficient granularity to allow


           clients t=
o take action based on the overloaded resources


           without u=
nreasonably forcing available capacity to go unused.


           The solut=
ion MUST support specification of overload


           informati=
on with granularities of at least "Diameter node",

           "rea=
lm", and "Diameter application" and MUST allow

           extensibi=
lity for others to be added in the future.


 


The "MUST" part says: enough granularity with at least host/=
realm and application.


And the existing solution is compliant with this requirement. If a nod=
e is supporting N applications, an OLR can be sent "per application&qu=
ot; with a report type indicating if it is for the host or the realm. And t=
he extensibility capability is provided by the base solution.

 


So my technical argument is that the existing proposal fulfills the ba=
sic requirements for an overload control without compromising future extens=
ion for further granularity.


 


Regards,


 


Lionel 


 


-----Message d'origine-----


De : Ben Campbell [mailto:ben@=
nostrum.com] Envoy=E9 : mercredi 4 d=E9cembre 2013 22:55 =C0 =
: MORAND Lionel IMT/OLN Cc : dime@iet=
f.org Objet : Re: [Dime] DOIC: Self-Contained OLRs


 


On Dec 3, 2013, at 5:17 PM, lionel.morand@orange.com wrote:


 




Hi Ben,


 


I may be wrong somewhere in my summary but I think that it was the res=
ult of the discussions and agreements reached regarding existing requiremen=
ts, at least from 3GPP point of view, compared to possible optimizations fo=
r future optimizations not so obvious.




 


We are not the 3GPP. Our requirements are RFC 7068. I believe self-con=
tained OLRs do a better job of meeting Req 31 than the contextually-defined=
 OLRs.


 


I've made several technical arguments here--does anyone have _technica=
l_ arguments in favor of contextually-defined OLRs?


 




And because the solution offers extensibility via the definition of ne=
w algo, new report type and addition of any new AVP in the existing Grouped=
 OLR, the "limitations" of the proposed solution might be removed=
 by someone if really required according to new requirements.

 




 


It might be worth considering a compromise approach: Define _optional_=
 AVPs that allow an OLR to be self-contained. If they are not present, then=
 the various values default to those from the enclosing Diameter message. P=
ossibly add support for this to the list of things that reacting nodes can =
advertise.


 


This could be in the base, or in a follow on extension. (If left for a=
n extension, it's worth considering whether ReportType needs to be in the b=
ase, or this or some other extension.) 


 


 




Regards,


 


Lionel


 


-----Message d'origine-----


De : Ben Campbell [mailto:ben@nostr=
um.com] Envoy=E9 : mardi 3 d=E9cembre 


2013 23:56 =C0 : MORAND Lionel IMT/OLN Cc : Steve Donovan; dime@ietf.org 


Objet : Re: [Dime] DOIC: Self-Contained OLRs


 


 


On Dec 2, 2013, at 10:18 AM, lionel.morand@orange.com wrote:


 




Hi Steve,


 


I think that is not only about few bytes in the answer. It is also abo=
ut the solution principles agreed so far:


=B7         the current need i=
s for an OLR bound to the application in use


=B7         the OLR is receive=
d from the node targeted in the request.


=B7         the OLR is defined=
 per application




 


I don't think those principles have been well tested. I don't recall a=
ny discussion of their benefits. What benefits do you see they have over se=
lf-contained OLRs?


 


All I see from these are restrictions in the flexibility of the soluti=
on, with very little in return.


 




So all the implicit information (application, origin-host, origin-real=
m) are meaningful in this context.


And the actual solution is designed based on these assumptions. The ex=
tensibility of the solution will allow extra info if required in other use =
cases but it was agreed to go with a straightforward solution that will sat=
isfy most of us.


 


Regards,


 


Lionel


 


De : DiME [mailto:dime-bounce=
s@ietf.org] De la part de Steve Donovan


Envoy=E9 : lundi 2 d=E9cembre 2013 16:37


=C0 : dime@ietf.org

Objet : Re: [Dime] DOIC: Self-Contained OLRs


 


I don't believe that Ben's proposal was to change the piggybacking ass=
umption in the baseline mechanism.  Ben's proposal is to design the so=
lution in such a way that it is not dependent on the piggybacking transport=
 mechanism.  


 


I share Ben's concern that we have over optimized the content of the o=
verload report in a way that makes implementations brittle, interoperabilit=
y more difficult to achieve and extensibility more complex.  And what =
do we gain from this optimization?  A few bites in answer messages.


 


Self contained overload reports, transported using the piggybacking me=
chanism, is a cleaner solution.


 


Steve


 


On 11/29/13 8:31 AM, lione=
l.morand@orange.com wrote:


I totally agree with Nirav. No need to revert at this stage the workin=
g assumption on piggybacking of OLR in application answer messages, especia=
lly when the aim is to define a basic mechanism called "reduction"=
;.


 


Anyone would be able to further add extra info for optimization if nee=
ded but there is no need at all for the basic mechanism.


 


Regards,


 


Lionel


 


-----Message d'origine-----


De : DiME [mailto:dime-bounce=
s@ietf.org] De la part de Nirav Salot (nsalot)


Envoy=E9 : vendredi 29 novembre 2013 12:24


=C0 : Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list


Cc : Ben Campbell


Objet : Re: [Dime] DOIC: Self-Contained OLRs


 


Jouni, Ben,


 


I am totally against the idea of self-contained OC-OLR specifically si=
nce we have adopted the principles of piggybacking the OC-OLR over existing=
 application message.


Self-contained OC-OLR - which means adding all the information which d=
efines the scope of the OC-OLR into the OC-OLR - does not make sense in the=
 piggybacking approach. In fact, it is adding lot of information, which is =
anyway available within the message containing the OC-OLR, into the OC-OLR.=
 So it is adding lot of redundant information in a message which increases =
the processing requirement for the sender as well as the receiver. (And thi=
s is un-optimization, in my view).


 


Besides, I am not convinced with the other reasons provided here:=



- One software module within a node can provide OC-OLR to another soft=
ware module in the same node without passing other related info<=
/pre>

  Within a node, based on the design, lots of information may nee=
d to be passed between two software modules and we cannot optimize those as=
pects by replicating unnecessary information in a protocol message.


  In summary, it is node's internal software design issue and we =
need not optimize that at protocol level.


 


- Once the reporting node realizes that it is overloaded, it has to wa=
it for right answer to send OC-OLR


 What is the point of sending OC-OLR for a context for which there is =
no messaging? Why should the reacting node care if it never sends a message=
 for a context for which the reporting node is overloaded?


 So this waiting is justified since it ensures that the overload is re=
ported only when necessary and only to the applicable reacting node. Not to=
 all the nodes in the network.


 


- The agent needs to wait for the answer generated by the server and t=
he right context


  The same argument as applicable for the server applies here. Th=
e agent need not send out-of-context overload info to a node.

  Why should reacting node receive/process/store the overload inf=
o for the scope for which it is not sending any messages.


 


- For sending OC-OLR in dedicated Diameter application???

 Piggybacking was the first basic principle we agreed before putting o=
ther principles in place. So we may want to go back the drawing board if we=
 decide to change this principle.


 


Regards,


Nirav.


 


-----Original Message-----


From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of Jouni Korhonen


Sent: Friday, November 29, 2013 2:50 PM


To: Wiehe, Ulrich (NSN - DE/Munich); =
dime@ietf.org list


Cc: Ben Campbell


Subject: Re: [Dime] DOIC: Self-Contained OLRs


 


 


 


So, are we reaching any level of consensus here?


 


- JOuni


 


(as a note.. that we are converging back to where we started with OLRs=
 ;)


 


 


 


On Nov 28, 2013, at 12:40 PM, "Wiehe, Ulrich (NSN - DE/Munich)&qu=
ot; <ulrich.wiehe@nsn.com> wrote:


 


Hi,


 


another question:


 


If we go for explicit self contained OLRs, why would we then need the =
ReportType?


 


The realm-type OLR would explicitly contain application-Id, Realm, but=
 no Host whereas the host-type OLR would explicitly contain application-Id,=
 Host, but probably (I'm not sure) no Realm.


 


Ulrich


 


 


 


-----Original Message-----


From: ext lionel.morand@or=
ange.com [mailto:lionel.mor=
and@orange.com]


Sent: Thursday, November 28, 2013 10:31 AM


To: Wiehe, Ulrich (NSN - DE/Munich); ext Jouni Korhonen; Ben Campbell<=
o:p>


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 recei=
ved from a server behind but also from a server that would know this info b=
y some internal magic.


But in any case, if we assume that the client will received a successf=
ul 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 onl=
y Dest-Realm AVP.


 


Lionel


 


-----Message d'origine-----


De : DiME [mailto:dime-bounce=
s@ietf.org] De la part de Wiehe, Ulrich 


(NSN - DE/Munich) Envoy=E9 : jeudi 28 novembre 2013 10:26 =C0 : ext Jo=
uni 


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 &=
quot;realm" this indicates to the reacting end point that the reportin=
g 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 repor=
ting end point is a server. How can the reporting end point be both agent a=
nd server?


 


Ulrich


 


-----Original Message-----


From: DiME [mailto:dime-bounc=
es@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 <=
/o:p>


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 t=
he 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 D=
iameter request that corresponds to the answer containing the OLR. My reaso=
ns 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 applica=
tion identified by the Application-Id field of the enclosing answer, the re=
alm identified by Origin-Realm, and so on. This means that the "meanin=
g" of an OLR cannot be determined from the OLR contents alone; OLRs on=
ly 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 exp=
licitly include such values in the OLR itself, for multiple reasons:


 


1) It's more complex to interpret implicit, contextual values than exp=
licit values. The consumer cannot simply look at the OLR; it must look in v=
arious other AVPs to find all the information it needs. For example, I thin=
k a common software design for overload control processing to be separated =
from application processing. The consumer cannot simply hand the OLR to tha=
t module and expect things to work. The OC module must not only parse the O=
LR, but parse any other AVPs that are relevant. As OLR contents get extende=
d (assumedly following the same strategy as the base spec), the number of &=
quot;context" avps that must be interpreted can grow large. This appro=
ach is error prone, and will likely encourage brittle, hard-to-maintain cod=
e. Self-contained OLRs would keep all the information related to overload i=
n one place. making for simpler implementations.


 


2) It's more complex for the reporting node to send implicit values th=
an explicit values. The sender cannot simply set the context to match the O=
LR--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 righ=
t answer that contains the right context before it can send the OLR. This i=
s particularly troublesome for agents, since they will typically have to in=
sert OLRs into answers created by other nodes. 


 


If the reporting node screws this up, the meaning of the OLR may chang=
e significantly. So again, implicit meaning gives us error prone implementa=
tions. 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 <=
o:p>


are distinct from those sent by a server, see Steve's agent overload <=
o:p>


draft, or my dh/dr example.)


 


OTOH, explicit values will work for all cases where we need to associa=
te some arbitrary value with an OLR.


 


4) Implicit values seriously constrain the future evolution of Diamete=
r OC standards. For example, lets say we find a good reason to allow OLRs t=
o be sent out of band, or be sent in a dedicated Diameter application. If o=
verload 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 tran=
sported, this won't work. We would have to create a new or significantly mo=
dified OLR format if we found a need to transport OLRs in different ways. S=
elf-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.iet=
f.org/mailman/listinfo/dime


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.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 q=
ue les pieces jointes. Les messages electroniques etant susceptibles d'alte=
ration, Orange decline toute responsabilite si ce message a ete altere, def=
orme ou falsifie. Merci.


 


This message and its attachments may contain confidential or 


privileged information that may be protected by law; they should not b=
e 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.iet=
f.org/mailman/listinfo/dime


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 


______________________________________________________________________=
___________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


 


This message and its attachments may contain confidential or privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
o:p>


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.iet=
f.org/mailman/listinfo/dime


 


 


______________________________________________________________________=
___________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


 


This message and its attachments may contain confidential or privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
o:p>


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.iet=
f.org/mailman/listinfo/dime




 


 


______________________________________________________________________=
___________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


 


This message and its attachments may contain confidential or privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
o:p>


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.iet=
f.org/mailman/listinfo/dime




 


 


______________________________________________________________________=
___________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


 


This message and its attachments may contain confidential or privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
o:p>


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.iet=
f.org/mailman/listinfo/dime


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 

 

 

 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles 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 el=
ectroniques 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 inf=
ormation 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 dele=
te 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.
--_000_6B7134B31289DC4FAF731D844122B36E32B6EBPEXCVZYM13corpora_-- From ulrich.wiehe@nsn.com Thu Dec 5 07:24:08 2013 Return-Path: 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 34FB61AE06E for ; Thu, 5 Dec 2013 07:24:08 -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 gUz-thuFSg6n for ; Thu, 5 Dec 2013 07:24:05 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 0C4DF1AE06D for ; Thu, 5 Dec 2013 07:24:04 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rB5FO0VR029320 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 5 Dec 2013 16:24:00 +0100 Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rB5FO0mE011302 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 5 Dec 2013 16:24:00 +0100 Received: from DEMUHTC007.nsn-intra.net (10.159.42.38) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 5 Dec 2013 16:24:00 +0100 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.152]) by DEMUHTC007.nsn-intra.net ([10.159.42.38]) with mapi id 14.03.0123.003; Thu, 5 Dec 2013 16:24:00 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: "dime@ietf.org" Thread-Topic: OVLI: comments to 4.3 Thread-Index: Ac7xzgT7drC0NV4iSVSEGFHx9aP+WQ== Date: Thu, 5 Dec 2013 15:23:59 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519DB1B@DEMUMBX014.nsn-intra.net> 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: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D90006681519DB1BDEMUMBX014nsnin_" 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: 3269 X-purgate-ID: 151667::1386257040-00002466-91915991/0-0/0-0 Subject: [Dime] OVLI: comments to 4.3 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 15:24:08 -0000 --_000_5BCBA1FC2B7F0B4C9D935572D90006681519DB1BDEMUMBX014nsnin_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, here are comments to clause 4.3: 1. Extensions in OC-OLR must either be mutually supported or must be ignora= ble. In the first case it is not enough for the reporting node to declare s= upport of an extension in the sent OC-Feature-Vector AVP. For the second ca= se there is no need to declare (or even define) support of an extension. Proposal is to expand the second sentence as follows: OC-OLR may also be used to convey additional information about mutually = supported extensions that are declared in the OC-Feature-Vector AVPs, and may also be used to convey a= dditional ignorable information. 2. TimeStamp has been replaced with Sequence-Number. This has the negative = impact that reacting nodes must calculate the expiration time base on OLR-r= eception time. OLR reception time and OLR creation time may be significant= ly different. I don't see any reason in favour of Sequence-Number. Proposal is to replace= Sequence-Number with TimeStamp. Best regards Ulrich --_000_5BCBA1FC2B7F0B4C9D935572D90006681519DB1BDEMUMBX014nsnin_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear all,
 
here are comments to clause 4.3:
 
1. Extensions in OC-OLR must either be mutually supported or must be i= gnorable. In the first case it is not enough for the reporting node to decl= are support of an extension in the sent OC-Feature-Vector AVP. For the seco= nd case there is no need to declare (or even define) support of an extension.
Proposal is to expand the second sentence as follows:
 
   OC-OLR may also be used to convey additional information = about mutually supported extensions that are=
   declared in the OC-Feature-Vector AVPs, and ma= y also be used to convey additional ignorabl= e information.
 
2. TimeStamp has been replaced with Sequence-Number. This has the nega= tive impact that reacting nodes must calculate the expiration time base on = OLR-reception time. OLR reception time and OLR creation time  may be s= ignificantly different.
I don’t see any reason in favour of Sequence-Number. Proposal is= to replace Sequence-Number with TimeStamp.
 
Best regards
Ulrich
 
 --_000_5BCBA1FC2B7F0B4C9D935572D90006681519DB1BDEMUMBX014nsnin_-- From ulrich.wiehe@nsn.com Thu Dec 5 07:39:18 2013 Return-Path: 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 0763A1AE093 for ; Thu, 5 Dec 2013 07:39:18 -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 6sU_NrwnP1_w for ; Thu, 5 Dec 2013 07:39:16 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 633C51AE08E for ; Thu, 5 Dec 2013 07:39:16 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rB5FdBE4029114 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 5 Dec 2013 16:39:11 +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 rB5FdAST012556 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 5 Dec 2013 16:39:11 +0100 Received: from DEMUHTC007.nsn-intra.net (10.159.42.38) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 5 Dec 2013 16:39:10 +0100 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.152]) by DEMUHTC007.nsn-intra.net ([10.159.42.38]) with mapi id 14.03.0123.003; Thu, 5 Dec 2013 16:39:10 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: "dime@ietf.org" Thread-Topic: OVLI: comments to 4.4 Thread-Index: Ac7x0CP0tUfEVlihTN+iH+W0Nytwlw== Date: Thu, 5 Dec 2013 15:39:10 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519DB39@DEMUMBX014.nsn-intra.net> 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: 390 X-purgate-ID: 151667::1386257951-000030AF-B266EC5D/0-0/0-0 Subject: [Dime] OVLI: comments to 4.4 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 15:39:18 -0000 Dear all, =A0 here are comments to clause 4.4: =A0 1. Clause 4.4 is not needed when my previous comments to 4.1 and 4.3 are ac= cepted. 2. The overflow issue is solved when my previous comments to 4.1 and 4.3 ar= e accepted. 3. There is also an issue with the wording "monotonically increasing" which= will disappear when this clause is deleted. =A0 Best regards Ulrich From ulrich.wiehe@nsn.com Thu Dec 5 08:04:37 2013 Return-Path: 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 DAB651AE091 for ; Thu, 5 Dec 2013 08:04:37 -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 ZYNgWNGSJBZ7 for ; Thu, 5 Dec 2013 08:04:36 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 170ED1AE093 for ; Thu, 5 Dec 2013 08:04:35 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rB5G4VkC014156 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 5 Dec 2013 17:04:32 +0100 Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rB5G4VoK014102 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 5 Dec 2013 17:04:31 +0100 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.152]) by DEMUHTC004.nsn-intra.net ([10.159.42.35]) with mapi id 14.03.0123.003; Thu, 5 Dec 2013 17:04:31 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: "dime@ietf.org" Thread-Topic: OVLI: comments to 4.5 Thread-Index: Ac7x065WBGZ2oIAhQo2K4GQZ6Z6CDA== Date: Thu, 5 Dec 2013 16:04:30 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519DB5E@DEMUMBX014.nsn-intra.net> 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: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D90006681519DB5EDEMUMBX014nsnin_" 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: 3178 X-purgate-ID: 151667::1386259472-000030AF-859DEA1D/0-0/0-0 Subject: [Dime] OVLI: comments to 4.5 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 16:04:38 -0000 --_000_5BCBA1FC2B7F0B4C9D935572D90006681519DB5EDEMUMBX014nsnin_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, here are comments to clause 4.5: 1. (linked to a previous comment to 4.3) The first sentence should be modif= ied to read The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32 and describes the number of seconds the OC-OLR AVP and its content is valid since the creation of the OC-OLR AVP (as indicated by the OC-TimeStamp AVP). 2. A default value of 5 seconds does not make much sense when the Reduction= -Percentage is absent or takes the value 0. Proposal is to modify text as f= ollows: The default value for the OC-Validity-Duration AVP value is 5 (i.e. 5 se= conds). When the OC-Validity- Duration AVP is not present in the OC-OLR AVP, the default value applies= , unless the Reduction-Percentage AVP is absent or takes the value 0, in which cases the validity is unlimited= . Best regards Ulrich --_000_5BCBA1FC2B7F0B4C9D935572D90006681519DB5EDEMUMBX014nsnin_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear all,
 
here are comments to clause 4.5:
 
1. (linked to a previous comment to 4.3) The first sentence should be = modified to read
 
   The OC-Validity-Duration AVP (AVP code TBD4) is type of U= nsigned32
   and describes the number of seconds the OC-OLR AVP and it= s content is
   valid since the creation o= f the OC-OLR AVP (as indicated by the
   OC-TimeStamp AVP).  <= /div>
 
2. A default value of 5 seconds does not make much sense when the Redu= ction-Percentage is absent or takes the value 0. Proposal is to modify text= as follows:
 
   The default value for the OC-Validity-Duration AVP value = is 5 (i.e. 5 seconds).  When the OC-Validity-
   Duration AVP is not present in the OC-OLR AVP, the defaul= t value applies, unless the Reduction-Percentage AVP
  is absent or takes the value 0, in whi= ch cases the validity is unlimited.
 
 
Best regards
Ulrich
 
 
 
 --_000_5BCBA1FC2B7F0B4C9D935572D90006681519DB5EDEMUMBX014nsnin_-- From ben@nostrum.com Thu Dec 5 16:13:34 2013 Return-Path: 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 2FFE71ADF51 for ; Thu, 5 Dec 2013 16:13:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no 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 eaI5KonMryCV for ; Thu, 5 Dec 2013 16:13:27 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 428291AE20C for ; Thu, 5 Dec 2013 16:13:27 -0800 (PST) Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rB60DGNu068462 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 5 Dec 2013 18:13:17 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ben Campbell In-Reply-To: Date: Thu, 5 Dec 2013 18:13:15 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <17BDF052-A13C-4AC3-8D9E-E941D7F2C1E5@nostrum.com> References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <8467_1385735507_5298A553_8467_17054_3_6B7134B31289DC4FAF731D844122B36E309D0D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <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> <14594_1386204165_529FCC05_14594_12646_1_6B7134B31289DC4FAF731D844122B36E329907@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B920972CCAA@ESESSMB101.ericsson.se> <52A077CC.3000004@usdonovans.com> <52A0! 88D0.2020406@usdonovans.com> To: "Nirav Salot (nsalot)" X-Mailer: Apple Mail (2.1822) Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism) Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 00:13:34 -0000 On Dec 5, 2013, at 8:25 AM, Nirav Salot (nsalot) = wrote: > Steve, > =20 > We assumed that "self-contained OC-OLR" contains the same information = as the message containing this AVP and hence we (me, JJ, Maria-Cruz) = were saying that consistency check is needed. > =20 > But now I understand that "self-contained OC-OLR" can contain = information of any context since the AVP itself defines the context = explicitly. So application-X message can carry application-Y's OC-OLR = and I do not agree to this. > In my view, this is totally against the existing principles of = Diameter based applications. And hence this requires special support at = the receiving node as well as the sending node since today the nodes are = designed to handle only application specific data. I'm not sure what you mean by nodes handle only application specific = data. There's quite a bit of data in a Diameter message that is not = application specific. And many nodes already handle more than one = application. Relays, for example, effectively handle all applications, = and may have very little if any application specific behavior. I think this highlights a main point where our assumptions differ. I = don't think of overload information as application data. It's protocol = data. > =20 > In summary, "self-contained OC-OLR" puts a special architectural = requirement on Diameter nodes =96 to handle one application's data from = other application's message =96 and hence this is a strong reason for me = to object to "self-contained OC-OLR". I concur that self-contained OLRs are an architectural difference from = context-defined OLRs. My concern is the inverse of yours. = Context-defined OLRs put special architectural limitations on how we can = use OC. I think those limitations will lead to brittle implementations = and deployments, especially for nodes that support multiple (even many) = applications. OTOH, I take your argument to be a concern that a node might receive an = OLR for an application it doesn't support. While I think most = reporting-node implementations would not send an ORL for Application X = to a peer that didn't support Application X [1], no harm is done if it = does so. If the reacting node gets an OLR that doesn't apply to it in = some way, it can simply ignore it. [1] I can, however, imagine that badly overloaded server might choose to = send one or more broadly-scoped ORLs to every client, and let the = clients sort out whether it applies to them. > =20 > Regards, > Nirav. > =20 > From: Steve Donovan [mailto:srdonovan@usdonovans.com]=20 > Sent: Thursday, December 05, 2013 7:38 PM > To: Nirav Salot (nsalot); dime@ietf.org > Subject: Re: [Dime] DOIC: Self-Contained OLRs > =20 > I must admit that I don't understand the need for consistency. >=20 > Why is it necessary to compare implicit and explicit data? If we use = self contained reports then the contents of the report are what should = be used, independent of the message that carries the report. >=20 > Steve >=20 > On 12/5/13 7:49 AM, Nirav Salot (nsalot) wrote: > Steve, > =20 > While gauging the complexity of "using the self-contained OC-OLR" It = seems you have overlooked the aspect identified by Maria-Cruz below (and = JJ earlier). > > Duplication should be avoided, since then we need to assure = consistency, and error handing in case implicit and explicit data values = are different for any reason... what means that it may always be = required to check both implicit and explicit data. > =20 > Regards, > Nirav. > =20 > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan > Sent: Thursday, December 05, 2013 6:26 PM > To: dime@ietf.org > Subject: Re: [Dime] DOIC: Self-Contained OLRs > =20 > If we equating "complexity" with work done by a Diameter node, then = there is added "complexity" for both proposals. >=20 > The extra work that needs to be done for the self contained report = approach is that the reporter needs to add additional AVPs to the = report. This is hardly difficult but it is extra work. >=20 > The extra work in the implicit approach is that the reactor needs to = gather information from multiple AVPs to understand the context of the = AVP. Again, hardly difficult but more work that can be avoided in a = well layered software architecture. >=20 > My conclusion is that the complexity argument does not apply. There = is complexity in both, its just a matter of where the work is done. >=20 > Steve >=20 > On 12/5/13 3:29 AM, Nirav Salot (nsalot) wrote: > Agree with Lionel's view and Maria-Cruz's arguments below. > =20 > The "self-contained OC-OLR" - which I assume contains the same = information as present in the message containing the OC-OLR - adds extra = complexity as highlighted by Maria-Cruz. > The benefit highlighted can be achieved in an implementation specific = way by the receiver duplicating the information into OC-OLR before = passing it to the layer processing the OC-OLR. > =20 > Regards, > Nirav. > =20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Maria Cruz = Bartolome > Sent: Thursday, December 05, 2013 7:53 AM > To: dime@ietf.org > Subject: Re: [Dime] DOIC: Self-Contained OLRs > =20 > Dear all, > =20 > I agree with Lionel argumentation below. > =20 > A part from that, one concern with "self-contained OLRs" is that some = data is duplicated. Duplication should be avoided, since then we need to = assure consistency, and error handing in case implicit and explicit data = values are different for any reason... what means that it may always be = required to check both implicit and explicit data. > =20 > Also, I think this is a pure implementation proposal. Regardless how = the data is transported it could be packed in a "self-contained OLRs" = within the diameter application, if for any implementation this is = preferred. > =20 > Regards > /MCruz > =20 > =20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of = lionel.morand@orange.com > Sent: jueves, 05 de diciembre de 2013 1:43 > To: Ben Campbell > Cc: dime@ietf.org > Subject: Re: [Dime] DOIC: Self-Contained OLRs > =20 > Hi Ben, > =20 > 3GPP operational requirements have triggered and driven this work, and = 3GPP will be the main client for this solution (if not the only for a = while...). Main parties involved in the discussions are 3GPP vendors and = 3GPP operators. So instead trying to keep private preserve, we should = welcome and enforce cooperative work with 3GPP on this task if we want = that the solution defined in IETF will be used in 3GPP. Otherwise, 3GPP = may decide not to wait for IETF and develop its own solution, as done in = the past (e.g. developing 3GPP-specific Cx application instead of = adopting the IETF-standard Diameter SIP application). > =20 > About the technical discussion, the Req31 says: > =20 > REQ 31: There are multiple situations where a Diameter node may be > overloaded for some purposes but not others. For example, > this can happen to an agent or server that supports = multiple > applications, or when a server depends on multiple external > resources, some of which may become overloaded while others > are fully available. The solution MUST allow Diameter = nodes > to indicate overload with sufficient granularity to allow > clients to take action based on the overloaded resources > without unreasonably forcing available capacity to go = unused. > The solution MUST support specification of overload > information with granularities of at least "Diameter node", > "realm", and "Diameter application" and MUST allow > extensibility for others to be added in the future. > =20 > The "MUST" part says: enough granularity with at least host/realm and = application. > And the existing solution is compliant with this requirement. If a = node is supporting N applications, an OLR can be sent "per application" = with a report type indicating if it is for the host or the realm. And = the extensibility capability is provided by the base solution. > =20 > So my technical argument is that the existing proposal fulfills the = basic requirements for an overload control without compromising future = extension for further granularity. > =20 > Regards, > =20 > Lionel=20 > =20 > -----Message d'origine----- > De : Ben Campbell [mailto:ben@nostrum.com] Envoy=E9 : mercredi 4 = d=E9cembre 2013 22:55 =C0 : MORAND Lionel IMT/OLN Cc : dime@ietf.org = Objet : Re: [Dime] DOIC: Self-Contained OLRs > =20 > On Dec 3, 2013, at 5:17 PM, lionel.morand@orange.com wrote: > =20 > Hi Ben, > =20 > I may be wrong somewhere in my summary but I think that it was the = result of the discussions and agreements reached regarding existing = requirements, at least from 3GPP point of view, compared to possible = optimizations for future optimizations not so obvious. > =20 > We are not the 3GPP. Our requirements are RFC 7068. I believe = self-contained OLRs do a better job of meeting Req 31 than the = contextually-defined OLRs. > =20 > I've made several technical arguments here--does anyone have = _technical_ arguments in favor of contextually-defined OLRs? > =20 > And because the solution offers extensibility via the definition of = new algo, new report type and addition of any new AVP in the existing = Grouped OLR, the "limitations" of the proposed solution might be removed = by someone if really required according to new requirements. > =20 > =20 > It might be worth considering a compromise approach: Define _optional_ = AVPs that allow an OLR to be self-contained. If they are not present, = then the various values default to those from the enclosing Diameter = message. Possibly add support for this to the list of things that = reacting nodes can advertise. > =20 > This could be in the base, or in a follow on extension. (If left for = an extension, it's worth considering whether ReportType needs to be in = the base, or this or some other extension.)=20 > =20 > =20 > Regards, > =20 > Lionel > =20 > -----Message d'origine----- > De : Ben Campbell [mailto:ben@nostrum.com] Envoy=E9 : mardi 3 d=E9cembre= =20 > 2013 23:56 =C0 : MORAND Lionel IMT/OLN Cc : Steve Donovan; = dime@ietf.org=20 > Objet : Re: [Dime] DOIC: Self-Contained OLRs > =20 > =20 > On Dec 2, 2013, at 10:18 AM, lionel.morand@orange.com wrote: > =20 > Hi Steve, > =20 > I think that is not only about few bytes in the answer. It is also = about the solution principles agreed so far: > =B7 the current need is for an OLR bound to the application in = use > =B7 the OLR is received from the node targeted in the request. > =B7 the OLR is defined per application > =20 > I don't think those principles have been well tested. I don't recall = any discussion of their benefits. What benefits do you see they have = over self-contained OLRs? > =20 > All I see from these are restrictions in the flexibility of the = solution, with very little in return. > =20 > So all the implicit information (application, origin-host, = origin-realm) are meaningful in this context. > And the actual solution is designed based on these assumptions. The = extensibility of the solution will allow extra info if required in other = use cases but it was agreed to go with a straightforward solution that = will satisfy most of us. > =20 > Regards, > =20 > Lionel > =20 > De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan > Envoy=E9 : lundi 2 d=E9cembre 2013 16:37 > =C0 : dime@ietf.org > Objet : Re: [Dime] DOIC: Self-Contained OLRs > =20 > I don't believe that Ben's proposal was to change the piggybacking = assumption in the baseline mechanism. Ben's proposal is to design the = solution in such a way that it is not dependent on the piggybacking = transport mechanism. =20 > =20 > I share Ben's concern that we have over optimized the content of the = overload report in a way that makes implementations brittle, = interoperability more difficult to achieve and extensibility more = complex. And what do we gain from this optimization? A few bites in = answer messages. > =20 > Self contained overload reports, transported using the piggybacking = mechanism, is a cleaner solution. > =20 > Steve > =20 > On 11/29/13 8:31 AM, lionel.morand@orange.com wrote: > I totally agree with Nirav. No need to revert at this stage the = working assumption on piggybacking of OLR in application answer = messages, especially when the aim is to define a basic mechanism called = "reduction". > =20 > Anyone would be able to further add extra info for optimization if = needed but there is no need at all for the basic mechanism. > =20 > Regards, > =20 > Lionel > =20 > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot = (nsalot) > Envoy=E9 : vendredi 29 novembre 2013 12:24 > =C0 : Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org = list > Cc : Ben Campbell > Objet : Re: [Dime] DOIC: Self-Contained OLRs > =20 > Jouni, Ben, > =20 > I am totally against the idea of self-contained OC-OLR specifically = since we have adopted the principles of piggybacking the OC-OLR over = existing application message. > Self-contained OC-OLR - which means adding all the information which = defines the scope of the OC-OLR into the OC-OLR - does not make sense in = the piggybacking approach. In fact, it is adding lot of information, = which is anyway available within the message containing the OC-OLR, into = the OC-OLR. So it is adding lot of redundant information in a message = which increases the processing requirement for the sender as well as the = receiver. (And this is un-optimization, in my view). > =20 > Besides, I am not convinced with the other reasons provided here: > - One software module within a node can provide OC-OLR to another = software module in the same node without passing other related info > Within a node, based on the design, lots of information may need to = be passed between two software modules and we cannot optimize those = aspects by replicating unnecessary information in a protocol message. > In summary, it is node's internal software design issue and we need = not optimize that at protocol level. > =20 > - Once the reporting node realizes that it is overloaded, it has to = wait for right answer to send OC-OLR > What is the point of sending OC-OLR for a context for which there is = no messaging? Why should the reacting node care if it never sends a = message for a context for which the reporting node is overloaded? > So this waiting is justified since it ensures that the overload is = reported only when necessary and only to the applicable reacting node. = Not to all the nodes in the network. > =20 > - The agent needs to wait for the answer generated by the server and = the right context > The same argument as applicable for the server applies here. The = agent need not send out-of-context overload info to a node. > Why should reacting node receive/process/store the overload info for = the scope for which it is not sending any messages. > =20 > - For sending OC-OLR in dedicated Diameter application??? > Piggybacking was the first basic principle we agreed before putting = other principles in place. So we may want to go back the drawing board = if we decide to change this principle. > =20 > Regards, > Nirav. > =20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen > Sent: Friday, November 29, 2013 2:50 PM > To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list > Cc: Ben Campbell > Subject: Re: [Dime] DOIC: Self-Contained OLRs > =20 > =20 > =20 > So, are we reaching any level of consensus here? > =20 > - JOuni > =20 > (as a note.. that we are converging back to where we started with OLRs = ;) > =20 > =20 > =20 > On Nov 28, 2013, at 12:40 PM, "Wiehe, Ulrich (NSN - DE/Munich)" = wrote: > =20 > Hi, > =20 > another question: > =20 > If we go for explicit self contained OLRs, why would we then need the = ReportType? > =20 > The realm-type OLR would explicitly contain application-Id, Realm, but = no Host whereas the host-type OLR would explicitly contain = application-Id, Host, but probably (I'm not sure) no Realm. > =20 > Ulrich > =20 > =20 > =20 > -----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 > =20 > Hi, > =20 > 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. > =20 > Lionel > =20 > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich=20= > (NSN - DE/Munich) Envoy=E9 : jeudi 28 novembre 2013 10:26 =C0 : ext = Jouni=20 > Korhonen; Ben Campbell Cc : dime@ietf.org list Objet : Re: [Dime]=20 > DOIC: Self-Contained OLRs > =20 > Hi, > =20 > 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? > =20 > Ulrich > =20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Jouni=20 > Korhonen > Sent: Wednesday, November 27, 2013 11:44 PM > To: Ben Campbell > Cc: dime@ietf.org list > Subject: Re: [Dime] DOIC: Self-Contained OLRs > =20 > =20 > On Nov 28, 2013, at 12:27 AM, Ben Campbell wrote: > =20 > Hi, > =20 > I mentioned in another thread that I prefer putting an explicit=20 > ReportType AVP in an OLR, rather than > =20 > The more I spent time thinking/writing the actual procedures on the=20 > endpoints, the more it makes sense to me to keep the ReportType in the=20= > OC-OLR. Even if the baseline does not have agent overload etc, the=20 > ReportType fits well to the "endpoint principle" we have in the draft.=20= > It indeed gives more tools to make a host vs. realm base decision on = the reacting node and is plain more clear. > =20 > I skip the rest of the mail.. too much text ;-) > =20 > =20 > - Jouni > =20 > =20 > =20 > =20 > =20 > 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. > =20 > 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. > =20 > I think this approach is a mistake. I would greatly prefer that we = explicitly include such values in the OLR itself, for multiple reasons: > =20 > 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. > =20 > 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.=20= > =20 > 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. > =20 > 3) Implicit values don't work at all for certain problems. For=20 > example, if an agent needs to originate an OLR, it typically needs to=20= > insert that OLR into an existing Diameter answer created by a server.=20= > It can't create its own answer without affecting the application=20 > state. If the responding node assumes the OLR comes from or refers to=20= > the node identified by the Origin-Host AVP in the enclosing answer,=20 > things break. (For examples of when an agent needs to send OLRs that=20= > are distinct from those sent by a server, see Steve's agent overload=20= > draft, or my dh/dr example.) > =20 > OTOH, explicit values will work for all cases where we need to = associate some arbitrary value with an OLR. > =20 > 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. > =20 > 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. > =20 > Thanks! > =20 > Ben. > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > =20 > _______________________________________________ > 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 > =20 > ______________________________________________________________________ > ___________________________________________________ > =20 > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20= > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > 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. > =20 > This message and its attachments may contain confidential or=20 > 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. > =20 > =20 > _______________________________________________ > 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 > =20 > = __________________________________________________________________________= _______________________________________________ > =20 > 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. > =20 > 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. > =20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > =20 > =20 > = __________________________________________________________________________= _______________________________________________ > =20 > 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. > =20 > 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. > =20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > =20 > =20 > = __________________________________________________________________________= _______________________________________________ > =20 > 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. > =20 > 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. > =20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > =20 > =20 > = __________________________________________________________________________= _______________________________________________ > =20 > 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. > =20 > 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. > =20 > _______________________________________________ > 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 > =20 > =20 > =20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From ben@nostrum.com Thu Dec 5 16:23:26 2013 Return-Path: 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 E79171AE20D for ; Thu, 5 Dec 2013 16:23:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no 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 YwTf7kkiHrn6 for ; Thu, 5 Dec 2013 16:23:25 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2DAD91AE180 for ; Thu, 5 Dec 2013 16:23:25 -0800 (PST) Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rB60NJLj068861 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 5 Dec 2013 18:23:20 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ben Campbell In-Reply-To: <20040_1386250088_52A07F68_20040_916_1_6B7134B31289DC4FAF731D844122B36E32B0E9@PEXCVZYM13.corporate.adroot.infra.ftgroup> Date: Thu, 5 Dec 2013 18:23:19 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <6390_1385631044_52970D44_6390_18593_1_6B7134B31289DC4FAF731D844122B36E30748E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BD31@DEMUMBX014.nsn-intra.net> <47383DC2-1A1B-4D1A-ADD5-9E3CE60B06C8@gmail.com> <8467_1385735507_5298A553_8467_17054_3_6B7134B31289DC4FAF731D844122B36E309D0D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <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> <52A07A1E.5060502@usdonovans.com> <2004! 0_1386250088_52A07F68_20040_916_1_6B7134B31289DC4FAF731D844122B36E32B0E9@PEXCVZYM13.corporate.adroot.infra.ftgroup> To: "ext lionel.morand@orange.com" X-Mailer: Apple Mail (2.1822) Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism) Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 00:23:26 -0000 On Dec 5, 2013, at 7:28 AM, lionel.morand@orange.com wrote: > Could everyone live/survive with the "implicit approach" with the = extensibility mechanism allowing future extensions if needed? > =20 I can grudgingly "live with it", as long as our extensibility features = allow us to create future extensions that work differently.=20 But I think it is a mistake to go that route. We have a choice between a = highly constrained solution, that I think will result in tortured = deployment architectures in real-world deployments, and a considerably = more general solution.=20 think the cost of the more general solution is trivial. I think the = difference in implementation complexity between the two approaches might = be a wash for certain nodes, but favor the self-contained approach for = others (e.g. an agent than handles _many_ applications). think the complexity created when operators try to work around the = limitations of the contextual approach will be significant.= From jouni.nospam@gmail.com Fri Dec 6 02:17:10 2013 Return-Path: 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 464091ADC03 for ; Fri, 6 Dec 2013 02:17:10 -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 jVSl5E0YSKCK for ; Fri, 6 Dec 2013 02:17:08 -0800 (PST) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 4CC4D1ADBCC for ; Fri, 6 Dec 2013 02:17:08 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id z5so186294lbh.17 for ; Fri, 06 Dec 2013 02:17:04 -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=xravmpWv1NO5n8shudTpoXOUyMMGGLpf4xBhkM+ZJCY=; b=uyW3No7pES+/rYp/E06m1ZjYo1mM76Da3P+eWJm3woe5+1tsxL6vz4yZHZE3Rc6TKp rg8kMANeqIeAie9Vv1X5Jbny+uC+0HNfUln/vieLEJxzZfUE07afx2usY87xkm8cc+Y3 Uvw83xYOFo5VvUU9cqKfmNzXykKC/QzxDtANErmIl0/CFLq2eKbt0UXUXnCiItf5ZwrQ di7sarlWPWrriq6O1XSIPomc/Po06edq/w/JXHb4xemng4hk5wMCY7QJhuYLYTVxM7vu GBlt1s/qGGk1YQJ0sOr9sRTApEPYSxt1K+hUzC5/cjDATMXC8CzL9MjxkpW3vHFr3teY 0amA== X-Received: by 10.152.219.133 with SMTP id po5mr674116lac.34.1386325023969; Fri, 06 Dec 2013 02:17:03 -0800 (PST) Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id iy7sm58555423lbc.4.2013.12.06.02.16.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 06 Dec 2013 02:16:59 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681519DA3E@DEMUMBX014.nsn-intra.net> Date: Fri, 6 Dec 2013 12:17:00 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6CDCFC84-3048-40B9-91A4-1451FCC65F60@gmail.com> References: <5BCBA1FC2B7F0B4C9D935572D90006681519DA3E@DEMUMBX014.nsn-intra.net> To: "Wiehe, Ulrich (NSN - DE/Munich)" X-Mailer: Apple Mail (2.1510) Cc: "dime@ietf.org" Subject: Re: [Dime] OVLI: comments to 4.1 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 10:17:10 -0000 On Dec 5, 2013, at 3:23 PM, "Wiehe, Ulrich (NSN - DE/Munich)" = wrote: > Dear all, >=20 > here are comments to clause 4.1: >=20 > 1. The OC-Feature-Vector AVP is no longer a vector; the name of the = AVP may be misleading. Proposal is to rename it to = "OC-Supported-Features AVP" OK with me. > 2. The OC-Feature AVP is a vector of features. Proposal is to rename = it to "OC-Feature-Vector AVP" OK with me. > 3. The OC-Sequence-Number within OC-Feature-Vector only makes sense if = the receiving reporting endpoint can determine the identity of the = reacting endpoint (which is not necessarily the origin host (client), My original proposal was to have seqnr as a timestamp. Some folks argued it is no good and suggested seqnr. I still think time makes more sense = than seqnr. > it may be an agent and it may not always be the same agent), and if = the reporting endpoint is required to store the OC-Feature-Vector / = reacting-endpoint-identity pair (which I think both is not required). = The reporting endpoint can base its processing logic on the actually = received OC-Feature-Vector value, no matter whether it is brand-new or = old but stil valid. Proposal is to delete OC-Sequence-Number AVP from = OC-Feature-Vector. Do not agree removing it. > 4. The text >=20 > The reporting node that sends the answer also includes the OC- > Feature-Vector AVP that describe the capabilities it supports. The > set of capabilities advertised by the reporting node depends on = local > policies. At least one the announced capabilities MUST match > mutually. If there is no single matching capability the reacting > node MUST act as if it does not implement DOIC and cease inserting > any DOIC related AVPs into any Diameter messages with this specific > reacting node. >=20 > is not clear. Would the reporting node include the OC-Feature-Vector = AVP in the answer only if there is at least one matching capability?=20 Because then they have found a way to exchange something that both ends know how to handle it. > Mandating the reacting node to cease for all time inserting = OC-Feature-Vector AVPs if it did not get back=20 There is an obvious typo. It should say: policies. At least one the announced capabilities MUST match mutually. If there is no single matching capability the reporting node MUST act as if it does not implement DOIC and cease inserting any DOIC related AVPs into any Diameter messages with this specific reacting node. - JOuni > at least one match is also not ok. The request might have been a = realm-type request (i.e. without Destination Host) and the reacting node = cannot control whether subsequent requests will take the same path to = the same reporting node. > Even if the request contains a destination host the reacting node = cannot know wether the reacting node's capabilities have been modified = by the time a subsequent request is sent.=20 > Proposal is to keep only the first sentence and delete the rest. >=20 > Ulrich >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From jouni.nospam@gmail.com Fri Dec 6 02:19:43 2013 Return-Path: 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 EB78C1AE03F for ; Fri, 6 Dec 2013 02:19:42 -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 lqB1O6oyyQmZ for ; Fri, 6 Dec 2013 02:19:41 -0800 (PST) Received: from mail-bk0-x230.google.com (mail-bk0-x230.google.com [IPv6:2a00:1450:4008:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 1071D1ADBCC for ; Fri, 6 Dec 2013 02:19:40 -0800 (PST) Received: by mail-bk0-f48.google.com with SMTP id v10so213373bkz.7 for ; Fri, 06 Dec 2013 02:19:36 -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=I0aeO6SxAertuBzGdH769RBMKDTZoLO2YkOnYhw3tTk=; b=IO9Kz1oipUQ4Blw25rZp1PJ31mkIthGzN49pbBDlTWMnHb8W7vuCOAtw339ptL0ASz JyD3rKE3+unEyx0zeNmKto5cvRw9OsZQbOZsbEgGCRcaoitvV0bf8o+O9hMupegUQAEo 07Rn6vquL6c5Eyo9xA5+zmOye47PhIuGGg1q39AxYwFVLe0HIIGWOK2i4AD02tT8Se9P 9OqoGOKW8RMBkD4eEnpTLfOdfgobRlIZMuGe0hwVn8Tmb+S1HN3VflVB4K9+3iPBdL/P +PV5qpuBVXzjscandKYl2PAPPc0zLftgovnbTH7NhuR/1WjgHc/9S7DUohARAcXuRY9E 14bA== X-Received: by 10.204.181.134 with SMTP id by6mr25619bkb.177.1386325176872; Fri, 06 Dec 2013 02:19:36 -0800 (PST) Received: from ?IPv6:2001:1bc8:101:f101:bc2d:564c:9083:9cf9? ([2001:1bc8:101:f101:bc2d:564c:9083:9cf9]) by mx.google.com with ESMTPSA id it12sm20998461bkb.12.2013.12.06.02.19.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 06 Dec 2013 02:19:32 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681519DAA6@DEMUMBX014.nsn-intra.net> Date: Fri, 6 Dec 2013 12:19:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <01D3D8A5-2584-4D81-A010-982C8BF77614@gmail.com> References: <5BCBA1FC2B7F0B4C9D935572D90006681519DAA6@DEMUMBX014.nsn-intra.net> To: "Wiehe, Ulrich (NSN - DE/Munich)" X-Mailer: Apple Mail (2.1510) Cc: "dime@ietf.org" Subject: Re: [Dime] OVLI: comments to 4.2 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 10:19:43 -0000 On Dec 5, 2013, at 3:55 PM, "Wiehe, Ulrich (NSN - DE/Munich)" = wrote: > Dear all, > =20 > here are comments to clause 4.2: > =20 > 1. there is a typo in the first line: "s" should read "is". Ack. > =20 > 2. Supporting OLR_DEFAULT_ALGO means different things depending on the = endpoint=92s role (reacting/reporting). > Proposal is to expand the text to read: > =20 > =20 > When this flag is set by the overload control reacting endpoint = it means > that the default traffic abatement (loss) algorithm is supported = by the > reacting endpoint, i.e. the reacting endpont is able and willing = to execute > the default traffic abatement algorithm if so requested by the = reporting > endpoint. > When this flag is set by the overload control reporting endpoint = it means > that the reporting endpoint when overloaded is able and willing = to demand > executing the default traffic abatement algorithm from the = reacting endpoint. OK with me. - Jouni > =20 > Best regards > Ulrich > =20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From jouni.nospam@gmail.com Fri Dec 6 02:27:24 2013 Return-Path: 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 F14241AE307 for ; Fri, 6 Dec 2013 02:27:23 -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 AMv8_RnlNY5o for ; Fri, 6 Dec 2013 02:27:21 -0800 (PST) Received: from mail-bk0-x231.google.com (mail-bk0-x231.google.com [IPv6:2a00:1450:4008:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 62A641AC7F0 for ; Fri, 6 Dec 2013 02:27:21 -0800 (PST) Received: by mail-bk0-f49.google.com with SMTP id my13so221528bkb.22 for ; Fri, 06 Dec 2013 02:27:16 -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=Qh3s0Mr1tKwVfTnR0ZnfnqadEPSHmJShLjPSkRh5qm8=; b=IsEovcmSHrpHWk2XR7o3z68EzLUEDvOTxgEd6ZX6Ez3geDRV7HnvCMfYxJ1OTZMNgj OMFIqOn2hQrq0y5oi2QMUN3b1phKEzQ6mud6365TRZFGgxzILCamu2Bg773FmFR6n1yL /lK/j2o06oOaFZoFOolAAlxS+P/eyCjUseiot9+YHcRmw5hTccEWAf2gCIrgn6omCXT8 4ikm2QsNwydf3eBAepEf/Ke+qEjR9la8VJXT18VimPaqZyxw0GopMPQoUtYc124oVzc7 798k21XwDbXlvt3AEYBa8CeKpHQ3edxclxvrME96dCtm5OKB88yJFp1ebspeb6mfb7Wl JDEw== X-Received: by 10.205.64.209 with SMTP id xj17mr873683bkb.76.1386325636739; Fri, 06 Dec 2013 02:27:16 -0800 (PST) Received: from ?IPv6:2001:1bc8:101:f101:bc2d:564c:9083:9cf9? ([2001:1bc8:101:f101:bc2d:564c:9083:9cf9]) by mx.google.com with ESMTPSA id j6sm77266083bki.17.2013.12.06.02.27.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 06 Dec 2013 02:27:16 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681519DB1B@DEMUMBX014.nsn-intra.net> Date: Fri, 6 Dec 2013 12:27:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5BCBA1FC2B7F0B4C9D935572D90006681519DB1B@DEMUMBX014.nsn-intra.net> To: "Wiehe, Ulrich (NSN - DE/Munich)" X-Mailer: Apple Mail (2.1510) Cc: "dime@ietf.org" Subject: Re: [Dime] OVLI: comments to 4.3 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 10:27:24 -0000 On Dec 5, 2013, at 5:23 PM, "Wiehe, Ulrich (NSN - DE/Munich)" = wrote: > Dear all, > =20 > here are comments to clause 4.3: > =20 > 1. Extensions in OC-OLR must either be mutually supported or must be = ignorable. In the first case it is not enough for the reporting node to = declare support of an extension in the sent OC-Feature-Vector AVP. For = the second case there is no need to declare (or even define) support of = an extension. I am afraid I do not understand what you mean by above. > Proposal is to expand the second sentence as follows: > OC-OLR may also be used to convey additional information about = mutually supportedextensions that are > declared in the OC-Feature-Vector AVPs, and may also be used to = convey additional ignorable information. Not sure about the wording "ignorable information".. but otherwise ok = with me. > =20 > 2. TimeStamp has been replaced with Sequence-Number. This has the = negative impact that reacting nodes must calculate the expiration time = base on OLR-reception time. OLR reception time and OLR creation time = may be significantly different. > I don=92t see any reason in favour of Sequence-Number. Proposal is to = replace Sequence-Number with TimeStamp. I agree but you need to convince the others as well who favoured = sequence number. - Jouni > =20 > Best regards > Ulrich > =20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From jouni.nospam@gmail.com Fri Dec 6 02:31:40 2013 Return-Path: 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 E2CCC1AE307 for ; Fri, 6 Dec 2013 02:31:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.889 X-Spam-Level: X-Spam-Status: No, score=-0.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no 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 U0ZsLCrNgPtm for ; Fri, 6 Dec 2013 02:31:37 -0800 (PST) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) by ietfa.amsl.com (Postfix) with ESMTP id B0BF11AD694 for ; Fri, 6 Dec 2013 02:31:36 -0800 (PST) Received: by mail-lb0-f179.google.com with SMTP id l4so188016lbv.24 for ; Fri, 06 Dec 2013 02:31:32 -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=jpP638G1YiglUGLoxijLEoucdsJsgHn7uWQ9PpiK0iI=; b=0Eb5Q+rPk5fpRVuWLUXg5659pXhl/stFB8NA5FT+p5Hr/ReLJWcdIFjQJ5GGJuacpE SO9lBUKkn9wF+moLsblMT0Kd5E6Q6fwHbcIlnPJUlTXfrLSGa+FEpIqXhVKqQKlIPZ8K ET/M0qwMW0Q+VAIR9eHFPQP/UHvXFy2QjEIVx3r3ZEHwbiMOle5+xS65t+f1A3DsR8bx 8wmFIvMh+wO81sWQXT00RGwLpzGfnkTbHpFK+dVo9pvpGA0SxulCSgZTqiXs92Cfx9Tq hh5yUUU5+HLmYN2mAA0l+Y8uM0JxKkcvyN4l5gMWP7CcJN9PxagH8qblrRVniDZjSTSj W2qw== X-Received: by 10.112.89.42 with SMTP id bl10mr650258lbb.18.1386325892282; Fri, 06 Dec 2013 02:31:32 -0800 (PST) Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id e10sm110537632laa.6.2013.12.06.02.31.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 06 Dec 2013 02:31:28 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <20040_1386250088_52A07F68_20040_916_1_6B7134B31289DC4FAF731D844122B36E32B0E9@PEXCVZYM13.corporate.adroot.infra.ftgroup> Date: Fri, 6 Dec 2013 12:31:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <39597F4C-52C0-4058-9559-92752389DA47@gmail.com> References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <6390_1385631044_52970D44_6390_18593_1_6B7134B31289DC4FAF731D844122B36E30748E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BD31@DEMUMBX014.nsn-intra.net> <47383DC2-1A1B-4D1A-ADD5-9E3CE60B06C8@gmail.com> <8467_1385735507_5298A553_8467_17054_3_6B7134B31289DC4FAF731D844122B36E309D0D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <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> <52A07A1E.5060502@usdonovans.com> <20040_1386250 088_52A07F68_20040_916_1_6B7134B31289DC4FAF731D844122B36E32B0E9@PEXCVZYM13.corporate.adroot.infra.ftgroup> To: X-Mailer: Apple Mail (2.1510) Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 10:31:41 -0000 On Dec 5, 2013, at 3:28 PM, wrote: > All, > =20 > After this LONG thread, it seems that there are strong arguments = against the self-contained OLRs and little support. > In the contrary, it seems that the principle of OLR related to the = application in use is technically OK for everyone. > =20 > So the question is quite simple: > =20 > Could everyone live/survive with the "implicit approach" with the = extensibility mechanism allowing future extensions if needed? Yes for implicit. (and less text edits for me :) There is no need to mention "future extension" possibility here. Anyone is free to extend OLRs in the future using the defined approach: allocate a new feature flag and define how to use it. - JOuni > =20 > If yes, please focus on the finalization of the current draft. > If no, let go on the discussion. > =20 > Regards, > =20 > Lionel > =20 > =20 > De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan > Envoy=E9 : jeudi 5 d=E9cembre 2013 14:06 > =C0 : dime@ietf.org > Objet : Re: [Dime] DOIC: Self-Contained OLRs > =20 > On the schedule question mentioned by JJacques -- any schedule = concerns can go away if everyone agrees to self contained overload = reports. This discussion would end and we could move on to other = things. :-) >=20 > I say that somewhat in jest but please don't make the argument that = this discussion should be ended because of schedule. Or if you make = that argument, please don't assert that the person who disagrees with = you is putting the schedule at risk. >=20 > We are striving for the best technical solution. We all understand = the schedule pressures. We need to balance the two. >=20 > Steve >=20 > On 12/5/13 5:14 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote: > Hi=20 > =20 > A lot of mails on this topic...I would suggest to introduce an = overload control on the Dime email threads:) =20 > =20 > =20 > On my side, I rely on what we have written in the draft for the = "baseline" mechanism and that we have to keep as it is simple and = efficient, here I join Lionel, Nirav and MCruz' positions. > =20 > This thread then addresses extensions cases, I agree that we will = have to address such extensions: Nirav mentioned the example with APN = that if relevant would a 3GGP application case, I would add the Session = Group about which we had some discussion a while ago and which is a = more generic IETF case. There is also the agent overload case. Have you = others? Always good to have some use cases in mind. > =20 > What is important for me is that adding extensions should not modify = the baseline and making it more complex when used alone. I also make a = difference between principles and protocol tuning where we may have to = choose between various protocol solution but addressing the same = functionality or principle. =20 > =20 > About piggybacking, in the baseline, the principle is that OLRs = which are addressed to sources of traffic are put in answer messages = towards this traffic sources (origin Host) (even if these messages may = be processed by intermediate DAs), which is simple and the OLR can be = kept unchanged in the same message up to the origin Host if no specific = process in intermediate DAs. To have a piggybacking allowing to put any = OLR in any message (as it was in draft roach) is adding complexity that = is not justified for the baseline and we have not retained it in the = existing draft . > =20 > About extensions, the APN or session group examples address parts of = the traffic between a server and a client (so a higher granularity in = the throttling than the baseline one), related OLRs are conveyed in the = messages towards the origin Host so with an implicit reference to the = Application, the Origin and Destination Host as for the baseline, so = not requiring self contained OLRs. I also do not see the interest to = send these new extensions OLR only in answers directly related to this = OLR (as Ulrich proposed), eg only in an answer dealing with an APN if = the OLR is related to APN throttling. The main point is that the OLR = takes a direct "train" towards the right destination for a given = application (as for baseline). > =20 > This does not exclude that we may have other cases not entering the = above examples characteristics, but as Nirav mentioned, we have to = remain pragmatic and see this when such new use cases will be addressed. = The extensibility possibilities of current draft give us a lot of = flexibility, e.g. if some extensions need more self contained AVPs, why = not, but this is outside the current draft.=20 > =20 > About extensions, I also think that they may need to be identified in = the capability part, as the related OLRs should not be sent by a = reacting node if the extension is not supported. > =20 > Last important point, as Lionel mentioned, we have to finalize the = draft soon, to be able to start Rel12 3GGP work relying on this draft. = My position is that the current draft is currently well suited for the = baseline and that extensions will be addressed separately =20 > =20 > Best regards > =20 > JJacques=20 > =20 > =20 > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Ben Campbell > Envoy=E9 : mercredi 4 d=E9cembre 2013 22:55 > =C0 : ext lionel.morand@orange.com > Cc : dime@ietf.org > Objet : Re: [Dime] DOIC: Self-Contained OLRs > =20 > On Dec 3, 2013, at 5:17 PM, lionel.morand@orange.com wrote: > =20 > Hi Ben, > =20 > I may be wrong somewhere in my summary but I think that it was the = result of the discussions and agreements reached regarding existing = requirements, at least from 3GPP point of view, compared to possible = optimizations for future optimizations not so obvious. > =20 > We are not the 3GPP. Our requirements are RFC 7068. I believe = self-contained OLRs do a better job of meeting Req 31 than the = contextually-defined OLRs. > =20 > I've made several technical arguments here--does anyone have = _technical_ arguments in favor of contextually-defined OLRs? > =20 > And because the solution offers extensibility via the definition of = new algo, new report type and addition of any new AVP in the existing = Grouped OLR, the "limitations" of the proposed solution might be removed = by someone if really required according to new requirements. > =20 > =20 > It might be worth considering a compromise approach: Define _optional_ = AVPs that allow an OLR to be self-contained. If they are not present, = then the various values default to those from the enclosing Diameter = message. Possibly add support for this to the list of things that = reacting nodes can advertise. > =20 > This could be in the base, or in a follow on extension. (If left for = an extension, it's worth considering whether ReportType needs to be in = the base, or this or some other extension.)=20 > =20 > =20 > Regards, > =20 > Lionel > =20 > -----Message d'origine----- > De : Ben Campbell [mailto:ben@nostrum.com] Envoy=E9 : mardi 3 d=E9cembre= =20 > 2013 23:56 =C0 : MORAND Lionel IMT/OLN Cc : Steve Donovan; = dime@ietf.org=20 > Objet : Re: [Dime] DOIC: Self-Contained OLRs > =20 > =20 > On Dec 2, 2013, at 10:18 AM, lionel.morand@orange.com wrote: > =20 > Hi Steve, > =20 > I think that is not only about few bytes in the answer. It is also = about the solution principles agreed so far: > =B7 the current need is for an OLR bound to the application in = use > =B7 the OLR is received from the node targeted in the request. > =B7 the OLR is defined per application > =20 > I don't think those principles have been well tested. I don't recall = any discussion of their benefits. What benefits do you see they have = over self-contained OLRs? > =20 > All I see from these are restrictions in the flexibility of the = solution, with very little in return. > =20 > So all the implicit information (application, origin-host, = origin-realm) are meaningful in this context. > And the actual solution is designed based on these assumptions. The = extensibility of the solution will allow extra info if required in other = use cases but it was agreed to go with a straightforward solution that = will satisfy most of us. > =20 > Regards, > =20 > Lionel > =20 > De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan > Envoy=E9 : lundi 2 d=E9cembre 2013 16:37 > =C0 : dime@ietf.org > Objet : Re: [Dime] DOIC: Self-Contained OLRs > =20 > I don't believe that Ben's proposal was to change the piggybacking = assumption in the baseline mechanism. Ben's proposal is to design the = solution in such a way that it is not dependent on the piggybacking = transport mechanism. =20 > =20 > I share Ben's concern that we have over optimized the content of the = overload report in a way that makes implementations brittle, = interoperability more difficult to achieve and extensibility more = complex. And what do we gain from this optimization? A few bites in = answer messages. > =20 > Self contained overload reports, transported using the piggybacking = mechanism, is a cleaner solution. > =20 > Steve > =20 > On 11/29/13 8:31 AM, lionel.morand@orange.com wrote: > I totally agree with Nirav. No need to revert at this stage the = working assumption on piggybacking of OLR in application answer = messages, especially when the aim is to define a basic mechanism called = "reduction". > =20 > Anyone would be able to further add extra info for optimization if = needed but there is no need at all for the basic mechanism. > =20 > Regards, > =20 > Lionel > =20 > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot = (nsalot) > Envoy=E9 : vendredi 29 novembre 2013 12:24 > =C0 : Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org = list > Cc : Ben Campbell > Objet : Re: [Dime] DOIC: Self-Contained OLRs > =20 > Jouni, Ben, > =20 > I am totally against the idea of self-contained OC-OLR specifically = since we have adopted the principles of piggybacking the OC-OLR over = existing application message. > Self-contained OC-OLR - which means adding all the information which = defines the scope of the OC-OLR into the OC-OLR - does not make sense in = the piggybacking approach. In fact, it is adding lot of information, = which is anyway available within the message containing the OC-OLR, into = the OC-OLR. So it is adding lot of redundant information in a message = which increases the processing requirement for the sender as well as the = receiver. (And this is un-optimization, in my view). > =20 > Besides, I am not convinced with the other reasons provided here: > - One software module within a node can provide OC-OLR to another = software module in the same node without passing other related info > Within a node, based on the design, lots of information may need to = be passed between two software modules and we cannot optimize those = aspects by replicating unnecessary information in a protocol message. > In summary, it is node's internal software design issue and we need = not optimize that at protocol level. > =20 > - Once the reporting node realizes that it is overloaded, it has to = wait for right answer to send OC-OLR > What is the point of sending OC-OLR for a context for which there is = no messaging? Why should the reacting node care if it never sends a = message for a context for which the reporting node is overloaded? > So this waiting is justified since it ensures that the overload is = reported only when necessary and only to the applicable reacting node. = Not to all the nodes in the network. > =20 > - The agent needs to wait for the answer generated by the server and = the right context > The same argument as applicable for the server applies here. The = agent need not send out-of-context overload info to a node. > Why should reacting node receive/process/store the overload info for = the scope for which it is not sending any messages. > =20 > - For sending OC-OLR in dedicated Diameter application??? > Piggybacking was the first basic principle we agreed before putting = other principles in place. So we may want to go back the drawing board = if we decide to change this principle. > =20 > Regards, > Nirav. > =20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen > Sent: Friday, November 29, 2013 2:50 PM > To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list > Cc: Ben Campbell > Subject: Re: [Dime] DOIC: Self-Contained OLRs > =20 > =20 > =20 > So, are we reaching any level of consensus here? > =20 > - JOuni > =20 > (as a note.. that we are converging back to where we started with OLRs = ;) > =20 > =20 > =20 > On Nov 28, 2013, at 12:40 PM, "Wiehe, Ulrich (NSN - DE/Munich)" = wrote: > =20 > Hi, > =20 > another question: > =20 > If we go for explicit self contained OLRs, why would we then need the = ReportType? > =20 > The realm-type OLR would explicitly contain application-Id, Realm, but = no Host whereas the host-type OLR would explicitly contain = application-Id, Host, but probably (I'm not sure) no Realm. > =20 > Ulrich > =20 > =20 > =20 > -----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 > =20 > Hi, > =20 > 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. > =20 > Lionel > =20 > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich=20= > (NSN - DE/Munich) Envoy=E9 : jeudi 28 novembre 2013 10:26 =C0 : ext = Jouni=20 > Korhonen; Ben Campbell Cc : dime@ietf.org list Objet : Re: [Dime]=20 > DOIC: Self-Contained OLRs > =20 > Hi, > =20 > 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? > =20 > Ulrich > =20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Jouni=20 > Korhonen > Sent: Wednesday, November 27, 2013 11:44 PM > To: Ben Campbell > Cc: dime@ietf.org list > Subject: Re: [Dime] DOIC: Self-Contained OLRs > =20 > =20 > On Nov 28, 2013, at 12:27 AM, Ben Campbell wrote: > =20 > Hi, > =20 > I mentioned in another thread that I prefer putting an explicit=20 > ReportType AVP in an OLR, rather than > =20 > The more I spent time thinking/writing the actual procedures on the=20 > endpoints, the more it makes sense to me to keep the ReportType in the=20= > OC-OLR. Even if the baseline does not have agent overload etc, the=20 > ReportType fits well to the "endpoint principle" we have in the draft.=20= > It indeed gives more tools to make a host vs. realm base decision on = the reacting node and is plain more clear. > =20 > I skip the rest of the mail.. too much text ;-) > =20 > =20 > - Jouni > =20 > =20 > =20 > =20 > =20 > 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. > =20 > 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. > =20 > I think this approach is a mistake. I would greatly prefer that we = explicitly include such values in the OLR itself, for multiple reasons: > =20 > 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. > =20 > 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.=20= > =20 > 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. > =20 > 3) Implicit values don't work at all for certain problems. For=20 > example, if an agent needs to originate an OLR, it typically needs to=20= > insert that OLR into an existing Diameter answer created by a server.=20= > It can't create its own answer without affecting the application=20 > state. If the responding node assumes the OLR comes from or refers to=20= > the node identified by the Origin-Host AVP in the enclosing answer,=20 > things break. (For examples of when an agent needs to send OLRs that=20= > are distinct from those sent by a server, see Steve's agent overload=20= > draft, or my dh/dr example.) > =20 > OTOH, explicit values will work for all cases where we need to = associate some arbitrary value with an OLR. > =20 > 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. > =20 > 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. > =20 > Thanks! > =20 > Ben. > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > =20 > _______________________________________________ > 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 > =20 > ______________________________________________________________________ > ___________________________________________________ > =20 > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20= > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > 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. > =20 > This message and its attachments may contain confidential or=20 > 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. > =20 > =20 > _______________________________________________ > 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 > =20 > = __________________________________________________________________________= _______________________________________________ > =20 > 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. > =20 > 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. > =20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > =20 > =20 > = __________________________________________________________________________= _______________________________________________ > =20 > 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. > =20 > 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. > =20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > =20 > =20 > = __________________________________________________________________________= _______________________________________________ > =20 > 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. > =20 > 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. > =20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > =20 > _______________________________________________ > 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 > =20 > =20 > = __________________________________________________________________________= _______________________________________________ >=20 > 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. >=20 > 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. >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From ulrich.wiehe@nsn.com Fri Dec 6 04:10:51 2013 Return-Path: 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 12FE01AE337 for ; Fri, 6 Dec 2013 04:10:51 -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 TEk_78E9RX8x for ; Fri, 6 Dec 2013 04:10:47 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 7812E1ADED8 for ; Fri, 6 Dec 2013 04:10:47 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rB6CAgAA009570 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 6 Dec 2013 13:10:42 +0100 Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rB6CAgpq016352 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 6 Dec 2013 13:10:42 +0100 Received: from DEMUHTC014.nsn-intra.net (10.159.42.45) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 6 Dec 2013 13:10:42 +0100 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.152]) by DEMUHTC014.nsn-intra.net ([10.159.42.45]) with mapi id 14.03.0123.003; Fri, 6 Dec 2013 13:10:41 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: "dime@ietf.org" Thread-Topic: OVLI: comments to 4.6 Thread-Index: Ac7yfC5RbFsL+gV9TT6AJTwE2Xmtww== Date: Fri, 6 Dec 2013 12:10:41 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519DCBC@DEMUMBX014.nsn-intra.net> 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: 4451 X-purgate-ID: 151667::1386331842-00002466-F4EB186D/0-0/0-0 Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 12:10:51 -0000 Dear all, =A0 here are comments to clause 4.6: =A0 It has already been proposed to change the type of the OC-Report-Type AVP f= rom Enumerated to Unsinged64 in order to avoid potential extensibility prob= lems. =20 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 trea= tment should apply: For a host report-type the overload treatment should apply to all request c= ommands for which a) The request command's Application-ID matches the Application-Id of the O= C-Report-Type AVP's encapsulating answer command and b) The request command's Destination-Host is present and=20 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) and d) The request command's Destination-Host is absent and=20 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 contain= s 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 t= he overload treatment should apply only to those request commands with an Application-ID that matches the Applic= ation-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 t= he 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 t= he 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 t= he 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 t= he 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=20 1) APPLICATION_ID_MATCH and DESTINATION_HOST_PRESENT and DESTINATION_HOS= T_MATCH and 2) APPLICATION_ID_MATCH and DESTINATION_HOST_ABSENT and DESTINATION_REAL= M_MATCH require a mutually agreed extension. One extension required by 3GPP applications is the Overload Mitigation Diff= erentiation per client (see 3GPP TR 29.809 clause 6.4.7. To address this, a= new value would be needed e.g. =20 ORIGIN_HOST_MATCH (0x0000000000000020) When this flag is set by the overload reporting endpoint it means that t= he overload treatment should apply only to those request commands with an Origin-Host AVP that matches the Desti= nation-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_M= ATCH and ORIGIN_HOST_MATCH and 4) APPLICATION_ID_MATCH and DESTINATION_HOST_ABSENT and DESTINATION_REALM_M= ATCH 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 t= he overload treatment should apply only to those request commands sent to the same next hop the OC-Report-Type A= VP's encapsulating answer command was received from. Best regards Ulrich From jouni.nospam@gmail.com Fri Dec 6 04:32:55 2013 Return-Path: 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 EFC941ADF32 for ; Fri, 6 Dec 2013 04:32:54 -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 RnSmXYhp4tG9 for ; Fri, 6 Dec 2013 04:32:52 -0800 (PST) Received: from mail-bk0-x236.google.com (mail-bk0-x236.google.com [IPv6:2a00:1450:4008:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 232211ADF5E for ; Fri, 6 Dec 2013 04:32:51 -0800 (PST) Received: by mail-bk0-f54.google.com with SMTP id v16so273438bkz.13 for ; Fri, 06 Dec 2013 04:32:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Y7CzVXzr5d3tMR1HbQ0n+X9IIraIzBy1EaxdgYrUCu4=; b=LZ/G4UBHRZHYcCd+9e3KLAXR56P0zsryoTpiRrl6PE0cZKuwS7nlA0Sko0GlpH0+5l 2EuYCSt12VE9UPIVwZgW8PL0HbBtfYBK2pZ58Nq2CKmGc5J4ZxXYDRwzWnHb3RR82DSg R1IeQZxs4QMF8zSyraqoQPXFqww/baEweymNJ6EP8E4hgSEK583Gv+GubKuFnYldHRA7 tZ6c9dS7AcZ3YvDP4lbXtVoZQ3A2XFJy7HmhjNvU1inV9Sz7d6D/DF958mLnRfq2JJVi sxj7PDCZDO0N4vZba/3Fm9l2Z+cj+j3VFmz9VDALDyEpL9UA7q9j9osuwlEsnEPS+BgL YeOQ== X-Received: by 10.204.102.72 with SMTP id f8mr1076552bko.44.1386333167762; Fri, 06 Dec 2013 04:32:47 -0800 (PST) Received: from ?IPv6:2001:1bc8:101:f101:f93e:4c8d:dae9:6a68? ([2001:1bc8:101:f101:f93e:4c8d:dae9:6a68]) by mx.google.com with ESMTPSA id qe6sm87922273bkb.5.2013.12.06.04.32.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 06 Dec 2013 04:32:43 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Jouni In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681519DCBC@DEMUMBX014.nsn-intra.net> Date: Fri, 6 Dec 2013 14:32:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6950EE6B-689E-47A1-88AA-1A67C47BC82E@gmail.com> References: <5BCBA1FC2B7F0B4C9D935572D90006681519DCBC@DEMUMBX014.nsn-intra.net> To: "Wiehe, Ulrich (NSN - DE/Munich)" X-Mailer: Apple Mail (2.1283) Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 12:32:55 -0000 On Dec 6, 2013, at 2:10 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote: > Dear all, > =20 > here are comments to clause 4.6: > =20 > 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. =20 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=20= 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: >=20 > 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=20 > c) The request command's Destination-Host matches the Origin-Host of = the OC-Report-Type AVP's encapsulating answer command >=20 > For a realm report-type the overload treatment should apply to all = request commands for which > a) and > d) The request command's Destination-Host is absent and=20 > e) The request command's Destination Realm matches the Origin-Realm of = the OC-Report-Type AVP's encapsulating answer command. >=20 > The proposal now is to assign individual bits of the Unsinged64 type = to a), b), c), d), and e): >=20 > Proposed text: > 4.6 OC-Report-Type AVP >=20 > 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. >=20 > The following characteristics are defined in this document: >=20 > APPLICATION_ID_MATCH (0x0000000000000001) >=20 > 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. >=20 > DESTINATION_HOST_PRESENT (0x0000000000000002) >=20 > 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. >=20 > DESTINATION_HOST_MATCH (0x0000000000000004) >=20 > 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. >=20 > DESTINATION_HOST_ABSENT (0x0000000000000008) >=20 > 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. >=20 > DESTINATION_REALM_MATCH (0x0000000000000010) >=20 > 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. >=20 > Combinations other than=20 > 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. >=20 >=20 >=20 >=20 > 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. >=20 > ORIGIN_HOST_MATCH (0x0000000000000020) >=20 > 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. >=20 > 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 >=20 > Another potential extension is Diameter Agent Overload. To address = this, a new value would be needed e.g. >=20 > NEXT_HOP_MATCH (0x0000000000000040) >=20 > 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. >=20 >=20 > Best regards > Ulrich >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From ulrich.wiehe@nsn.com Fri Dec 6 05:03:37 2013 Return-Path: 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 5866B1AE385 for ; Fri, 6 Dec 2013 05:03: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 koc2JqXvLtRG for ; Fri, 6 Dec 2013 05:03:35 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 30B211AE34F for ; Fri, 6 Dec 2013 05:03:35 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rB6D3T4L017819 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 6 Dec 2013 14:03:29 +0100 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 rB6D3T4n016365 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 Dec 2013 14:03:29 +0100 Received: from DEMUHTC006.nsn-intra.net (10.159.42.37) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 6 Dec 2013 14:03:28 +0100 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.152]) by DEMUHTC006.nsn-intra.net ([10.159.42.37]) with mapi id 14.03.0123.003; Fri, 6 Dec 2013 14:03:28 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: ext Jouni Korhonen Thread-Topic: [Dime] OVLI: comments to 4.1 Thread-Index: Ac7xvTHHIECkLcDwSDuVAh2ACeOasAAprlMAAAaV6CA= Date: Fri, 6 Dec 2013 13:03:28 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519DCE5@DEMUMBX014.nsn-intra.net> References: <5BCBA1FC2B7F0B4C9D935572D90006681519DA3E@DEMUMBX014.nsn-intra.net> <6CDCFC84-3048-40B9-91A4-1451FCC65F60@gmail.com> In-Reply-To: <6CDCFC84-3048-40B9-91A4-1451FCC65F60@gmail.com> 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="us-ascii" 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: 3811 X-purgate-ID: 151667::1386335010-000030AF-2AA5DEF4/0-0/0-0 Cc: "dime@ietf.org" Subject: Re: [Dime] OVLI: comments to 4.1 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 13:03:37 -0000 Hi Jouni, thank you for your response. With regard to 3)=20 I still fail to see the usecase for Sequence-Number or TimeStamp within OC-= Feature-Vector. Please clarify. With regard to 4) This was not obvious to me. (The obvious typo is the missing "of" between "= one" and "the"). Best regards Ulrich -----Original Message----- From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20 Sent: Friday, December 06, 2013 11:17 AM To: Wiehe, Ulrich (NSN - DE/Munich) Cc: dime@ietf.org Subject: Re: [Dime] OVLI: comments to 4.1 On Dec 5, 2013, at 3:23 PM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: > Dear all, >=20 > here are comments to clause 4.1: >=20 > 1. The OC-Feature-Vector AVP is no longer a vector; the name of the AVP m= ay be misleading. Proposal is to rename it to "OC-Supported-Features AVP" OK with me. > 2. The OC-Feature AVP is a vector of features. Proposal is to rename it t= o "OC-Feature-Vector AVP" OK with me. > 3. The OC-Sequence-Number within OC-Feature-Vector only makes sense if th= e receiving reporting endpoint can determine the identity of the reacting e= ndpoint (which is not necessarily the origin host (client), My original proposal was to have seqnr as a timestamp. Some folks argued it is no good and suggested seqnr. I still think time makes more sense than seqnr. > it may be an agent and it may not always be the same agent), and if the r= eporting endpoint is required to store the OC-Feature-Vector / reacting-end= point-identity pair (which I think both is not required). The reporting end= point can base its processing logic on the actually received OC-Feature-Vec= tor value, no matter whether it is brand-new or old but stil valid. Proposa= l is to delete OC-Sequence-Number AVP from OC-Feature-Vector. Do not agree removing it. > 4. The text >=20 > The reporting node that sends the answer also includes the OC- > Feature-Vector AVP that describe the capabilities it supports. The > set of capabilities advertised by the reporting node depends on local > policies. At least one the announced capabilities MUST match > mutually. If there is no single matching capability the reacting > node MUST act as if it does not implement DOIC and cease inserting > any DOIC related AVPs into any Diameter messages with this specific > reacting node. >=20 > is not clear. Would the reporting node include the OC-Feature-Vector AVP= in the answer only if there is at least one matching capability?=20 Because then they have found a way to exchange something that both ends know how to handle it. > Mandating the reacting node to cease for all time inserting OC-Feature-Ve= ctor AVPs if it did not get back=20 There is an obvious typo. It should say: policies. At least one the announced capabilities MUST match mutually. If there is no single matching capability the reporting node MUST act as if it does not implement DOIC and cease inserting any DOIC related AVPs into any Diameter messages with this specific reacting node. - JOuni > at least one match is also not ok. The request might have been a realm-ty= pe request (i.e. without Destination Host) and the reacting node cannot con= trol whether subsequent requests will take the same path to the same report= ing node. > Even if the request contains a destination host the reacting node cannot = know wether the reacting node's capabilities have been modified by the time= a subsequent request is sent.=20 > Proposal is to keep only the first sentence and delete the rest. >=20 > Ulrich >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From ulrich.wiehe@nsn.com Fri Dec 6 05:39:47 2013 Return-Path: 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 4D8ED1ADFFB for ; Fri, 6 Dec 2013 05:39:47 -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 yuU9Rft_DL1j for ; Fri, 6 Dec 2013 05:39:45 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id CCC221ADFAD for ; Fri, 6 Dec 2013 05:39:44 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rB6Ddb0n032377 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 6 Dec 2013 14:39:37 +0100 Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rB6DdbcG005479 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 Dec 2013 14:39:37 +0100 Received: from DEMUHTC008.nsn-intra.net (10.159.42.39) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 6 Dec 2013 14:39:36 +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; Fri, 6 Dec 2013 14:39:36 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: ext Jouni Korhonen Thread-Topic: [Dime] OVLI: comments to 4.3 Thread-Index: Ac7xzgT7drC0NV4iSVSEGFHx9aP+WQAl1Z0AAAfOC0A= Date: Fri, 6 Dec 2013 13:39:36 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519DD2A@DEMUMBX014.nsn-intra.net> References: <5BCBA1FC2B7F0B4C9D935572D90006681519DB1B@DEMUMBX014.nsn-intra.net> In-Reply-To: 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="us-ascii" 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: 1994 X-purgate-ID: 151667::1386337177-00002466-F355CE4F/0-0/0-0 Cc: "dime@ietf.org" Subject: Re: [Dime] OVLI: comments to 4.3 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 13:39:47 -0000 Dear Jouni, thanks again.=20 Why isn't it so that others need to convince me/us? Dear others, Please let me know your arguments in favour of Sequence Number (if any). Best regards Ulrich -----Original Message----- From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20 Sent: Friday, December 06, 2013 11:27 AM To: Wiehe, Ulrich (NSN - DE/Munich) Cc: dime@ietf.org Subject: Re: [Dime] OVLI: comments to 4.3 On Dec 5, 2013, at 5:23 PM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: > Dear all, > =20 > here are comments to clause 4.3: > =20 > 1. Extensions in OC-OLR must either be mutually supported or must be igno= rable. In the first case it is not enough for the reporting node to declare= support of an extension in the sent OC-Feature-Vector AVP. For the second = case there is no need to declare (or even define) support of an extension. I am afraid I do not understand what you mean by above. > Proposal is to expand the second sentence as follows: > OC-OLR may also be used to convey additional information about mutuall= y supportedextensions that are > declared in the OC-Feature-Vector AVPs, and may also be used to convey= additional ignorable information. Not sure about the wording "ignorable information".. but otherwise ok with = me. > =20 > 2. TimeStamp has been replaced with Sequence-Number. This has the negativ= e impact that reacting nodes must calculate the expiration time base on OLR= -reception time. OLR reception time and OLR creation time may be significa= ntly different. > I don't see any reason in favour of Sequence-Number. Proposal is to repla= ce Sequence-Number with TimeStamp. I agree but you need to convince the others as well who favoured sequence n= umber. - Jouni > =20 > Best regards > Ulrich > =20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From ulrich.wiehe@nsn.com Fri Dec 6 06:18:00 2013 Return-Path: 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 5019F1ADF99 for ; Fri, 6 Dec 2013 06:18:00 -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 v-O8D7oAfFCY for ; Fri, 6 Dec 2013 06:17:57 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 353DD1AE39F for ; Fri, 6 Dec 2013 06:17:57 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rB6EHp3Z016790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 6 Dec 2013 15:17:51 +0100 Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rB6EHpQ5020346 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 Dec 2013 15:17:51 +0100 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.123.3; Fri, 6 Dec 2013 15:17:50 +0100 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.152]) by DEMUHTC013.nsn-intra.net ([10.159.42.44]) with mapi id 14.03.0123.003; Fri, 6 Dec 2013 15:17:50 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: ext Jouni Thread-Topic: [Dime] OVLI: comments to 4.6 Thread-Index: Ac7yfC5RbFsL+gV9TT6AJTwE2Xmtw///9WMA///VCNA= Date: Fri, 6 Dec 2013 14:17:50 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519DD4D@DEMUMBX014.nsn-intra.net> References: <5BCBA1FC2B7F0B4C9D935572D90006681519DCBC@DEMUMBX014.nsn-intra.net> <6950EE6B-689E-47A1-88AA-1A67C47BC82E@gmail.com> In-Reply-To: <6950EE6B-689E-47A1-88AA-1A67C47BC82E@gmail.com> 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="us-ascii" 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: 6304 X-purgate-ID: 151667::1386339471-000030AF-40D3BDEC/0-0/0-0 Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 14:18:00 -0000 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. Best regards Ulrich -----Original Message----- From: ext Jouni [mailto:jouni.nospam@gmail.com]=20 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, > =20 > here are comments to clause 4.6: > =20 > 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 pr= oblems. =20 I do not see how changing the type to unsigned would help with the extensib= ility 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 semantic= s to something like what we have on OC-Feature AVP. How the receiver of the repo= rt 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 receiv= er has no other choice than drop the OLR, since it cannot be sure how to handle th= e 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 ma= ps to a report type (that has been defined after the publication of this=20 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 le= t the reacting node know to which (future) request commands the overload tr= eatment should apply: >=20 > 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=20 > c) The request command's Destination-Host matches the Origin-Host of the = OC-Report-Type AVP's encapsulating answer command >=20 > For a realm report-type the overload treatment should apply to all reques= t commands for which > a) and > d) The request command's Destination-Host is absent and=20 > e) The request command's Destination Realm matches the Origin-Realm of th= e OC-Report-Type AVP's encapsulating answer command. >=20 > The proposal now is to assign individual bits of the Unsinged64 type to a= ), b), c), d), and e): >=20 > Proposed text: > 4.6 OC-Report-Type AVP >=20 > The OC-Report-Type AVP (AVP code TBD5) is type of Unsigned64 and contai= ns a 64 bit flags field of a request > command's characteristics. >=20 > The following characteristics are defined in this document: >=20 > APPLICATION_ID_MATCH (0x0000000000000001) >=20 > 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 Appli= cation-Id of the OC-Report-Type AVP's > encapsulating answer command. >=20 > DESTINATION_HOST_PRESENT (0x0000000000000002) >=20 > 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. >=20 > DESTINATION_HOST_MATCH (0x0000000000000004) >=20 > 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. >=20 > DESTINATION_HOST_ABSENT (0x0000000000000008) >=20 > 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. >=20 > DESTINATION_REALM_MATCH (0x0000000000000010) >=20 > 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. >=20 > Combinations other than=20 > 1) APPLICATION_ID_MATCH and DESTINATION_HOST_PRESENT and DESTINATION_HO= ST_MATCH > and > 2) APPLICATION_ID_MATCH and DESTINATION_HOST_ABSENT and DESTINATION_REA= LM_MATCH > require a mutually agreed extension. >=20 >=20 >=20 >=20 > One extension required by 3GPP applications is the Overload Mitigation Di= fferentiation per client (see 3GPP TR 29.809 clause 6.4.7. To address this,= a new value would be needed e.g. >=20 > ORIGIN_HOST_MATCH (0x0000000000000020) >=20 > 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 Dest= ination-Host of the OC-Report-Type AVP's > encapsulating answer command. >=20 > With this extension the following additional combinations would be allowe= d: > 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 >=20 > Another potential extension is Diameter Agent Overload. To address this, = a new value would be needed e.g. >=20 > NEXT_HOP_MATCH (0x0000000000000040) >=20 > 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. >=20 >=20 > Best regards > Ulrich >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From ulrich.wiehe@nsn.com Fri Dec 6 06:39:16 2013 Return-Path: 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 F3EA01AD83F for ; Fri, 6 Dec 2013 06:39:15 -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 Ll8IKlHyjntD for ; Fri, 6 Dec 2013 06:39:13 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id D7C811ADFE2 for ; Fri, 6 Dec 2013 06:39:11 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rB6Ed76d017444 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 6 Dec 2013 15:39:07 +0100 Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rB6Ed7CO003623 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 6 Dec 2013 15:39:07 +0100 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.152]) by DEMUHTC003.nsn-intra.net ([10.159.42.34]) with mapi id 14.03.0123.003; Fri, 6 Dec 2013 15:39:07 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: "dime@ietf.org" Thread-Topic: OVLI: comments to 4.5 Thread-Index: Ac7x065WBGZ2oIAhQo2K4GQZ6Z6CDAAu0f4w Date: Fri, 6 Dec 2013 14:39:06 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519DD6B@DEMUMBX014.nsn-intra.net> 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: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D90006681519DD6BDEMUMBX014nsnin_" 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: 4550 X-purgate-ID: 151667::1386340747-000030AF-CD344E5E/0-0/0-0 Subject: Re: [Dime] OVLI: comments to 4.5 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 14:39:16 -0000 --_000_5BCBA1FC2B7F0B4C9D935572D90006681519DD6BDEMUMBX014nsnin_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, here is another comment to 4.5: 3. It may be worth to clarify the meaning of a validity duration of 0 secon= ds. In my understanding it does not mean that the encapsulating OC-OLR is i= nvalid. It is valid (and therefore replaces any previous OLR with the same = report-type), but it immediately expires and hence is a way to signal "end = of overload". Best regards Ulrich _____________________________________________ From: Wiehe, Ulrich (NSN - DE/Munich) Sent: Thursday, December 05, 2013 5:05 PM To: 'dime@ietf.org' Subject: OVLI: comments to 4.5 Dear all, here are comments to clause 4.5: 1. (linked to a previous comment to 4.3) The first sentence should be modif= ied to read The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32 and describes the number of seconds the OC-OLR AVP and its content is valid since the creation of the OC-OLR AVP (as indicated by the OC-TimeStamp AVP). 2. A default value of 5 seconds does not make much sense when the Reduction= -Percentage is absent or takes the value 0. Proposal is to modify text as f= ollows: The default value for the OC-Validity-Duration AVP value is 5 (i.e. 5 se= conds). When the OC-Validity- Duration AVP is not present in the OC-OLR AVP, the default value applies= , unless the Reduction-Percentage AVP is absent or takes the value 0, in which cases the validity is unlimited= . Best regards Ulrich --_000_5BCBA1FC2B7F0B4C9D935572D90006681519DD6BDEMUMBX014nsnin_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear all,
 
here is another comment to 4.5:
 
3. It may be worth to clarify the meaning of a validity duration of 0 = seconds. In my understanding it does not mean that the encapsulating OC-OLR= is invalid. It is valid (and therefore replaces any previous OLR with the = same report-type), but it immediately expires and hence is a way to signal “end of overload”.
 
 
Best regards
Ulrich
_____________________________________________
From: Wiehe, Ulrich (NSN - DE/Munich)
Sent: Thursday, December 05, 2013 5:05 PM
To: 'dime@ietf.org'
Subject: OVLI: comments to 4.5
 
 
Dear all,
 
here are comments to clause 4.5:
 
1. (linked to a previous comment to 4.3) The first sentence should be = modified to read
 
   The OC-Validity-Duration AVP (AVP code TBD4) is type of U= nsigned32
   and describes the number of seconds the OC-OLR AVP and it= s content is
   valid since the creation o= f the OC-OLR AVP (as indicated by the
   OC-TimeStamp AVP).  <= /div>
 
2. A default value of 5 seconds does not make much sense when the Redu= ction-Percentage is absent or takes the value 0. Proposal is to modify text= as follows:
 
   The default value for the OC-Validity-Duration AVP value = is 5 (i.e. 5 seconds).  When the OC-Validity-
   Duration AVP is not present in the OC-OLR AVP, the defaul= t value applies, unless the Reduction-Percentage AV= P
   is absent or takes the value 0, i= n which cases the validity is unlimited.
 
 
Best regards
Ulrich
 
 
 
 --_000_5BCBA1FC2B7F0B4C9D935572D90006681519DD6BDEMUMBX014nsnin_-- From ulrich.wiehe@nsn.com Fri Dec 6 07:14:32 2013 Return-Path: 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 C64D51AE022 for ; Fri, 6 Dec 2013 07:14:32 -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 ns35--GEmd_D for ; Fri, 6 Dec 2013 07:14:28 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7A11ADF6E for ; Fri, 6 Dec 2013 07:14:28 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rB6FENKw006744 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 6 Dec 2013 16:14:23 +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 rB6FENa5002778 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 6 Dec 2013 16:14:23 +0100 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.152]) by DEMUHTC001.nsn-intra.net ([10.159.42.32]) with mapi id 14.03.0123.003; Fri, 6 Dec 2013 16:14:23 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: "dime@ietf.org" Thread-Topic: OVLI: comments to 5.3 Thread-Index: Ac7yldep6rW6tfoRSn+co50UY5a/Bw== Date: Fri, 6 Dec 2013 15:14:22 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519DD92@DEMUMBX014.nsn-intra.net> 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="us-ascii" 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: 372 X-purgate-ID: 151667::1386342864-000030AF-199A2AA4/0-0/0-0 Subject: [Dime] OVLI: comments to 5.3 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 15:14:32 -0000 Dear all, here are comments to clause 5.3: 1. The first sentence is incomplete (Since and , finding out whether= or .), and I have no idea what the intention is. 2. In the first sentence "...endpoint are..." should probably read "...endp= oints are..." 3. In the second sentence there is a superfluous "capability". Best regards Ulrich From ulrich.wiehe@nsn.com Fri Dec 6 08:07:40 2013 Return-Path: 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 D0C991AE388 for ; Fri, 6 Dec 2013 08:07:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MANGLED_LIST=2.3, 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 IfBvbeL82ixj for ; Fri, 6 Dec 2013 08:07:38 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id B96F11AE384 for ; Fri, 6 Dec 2013 08:07:37 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rB6G7ViL021652 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 6 Dec 2013 17:07:31 +0100 Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rB6G7VPc004181 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 6 Dec 2013 17:07:31 +0100 Received: from DEMUHTC008.nsn-intra.net (10.159.42.39) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 6 Dec 2013 17:07:30 +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; Fri, 6 Dec 2013 17:07:30 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: "dime@ietf.org" Thread-Topic: OVLI: comments to 5.3.1 Thread-Index: Ac7ynUN6ecqCUZ/BTEKoQ6BxYT0Qzw== Date: Fri, 6 Dec 2013 16:07:30 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519DDBB@DEMUMBX014.nsn-intra.net> 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: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D90006681519DDBBDEMUMBX014nsnin_" 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: 6278 X-purgate-ID: 151667::1386346052-000030AF-13E60919/0-0/0-0 Subject: [Dime] OVLI: comments to 5.3.1 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 16:07:41 -0000 --_000_5BCBA1FC2B7F0B4C9D935572D90006681519DDBBDEMUMBX014nsnin_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, here are comments to clause 5.3.1: 1. 1st sentence: The request message initiating node is always the client a= nd is not necessarily the reacting endpoint. Proposal is to modify the firs= t sentence as follows: The basic principle is that the first DOIC capable/willing Diameter node (including the client) on the path from client to server takes the role of the "reacting node" and announces its support for the overload control mechanism by inserting in the request message the OC-Feature-Vector AVP with those capabilities it supports and is willing to use for this Diameter session (or transaction in a case of a non-session state maintaining applications, see Section 3.1.2 for more details on Diameter sessions). 2. 2nd sentence: Why is it only RECOMMENDED to insert the Feature-Vector in= to every request? The reacting endpoint may not even know which remote reporting endpoint the= request will be sent to. The reporting endpoint would interpret an absent = Feature-Vector in the received request as "there is no downstream reacting = endpoint" and will not send back Feature-Vectors or OLRs. Proposal is to sa= y: The reacting endpoint MUST insert the capability announcement into every request regardless it has had prior message exchanges with the (possibly not yet) given remote endpoint. 3. 3rd sentence: Proposal: Once the reacting endpoint that inserted the capability announcement int= o the request message receives an answer message from the remote endpoint,= it can detect from the received answer message whether the remote endpoint supports the overload control solution and in a case it does, what featu= res are supported. Best regards Ulrich --_000_5BCBA1FC2B7F0B4C9D935572D90006681519DDBBDEMUMBX014nsnin_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear all,
 
here are comments to clause 5.3.1:
 
1. 1st sentence: The request message initiating node is always the cli= ent and is not necessarily the reacting endpoint. Proposal is to modify the= first sentence as follows:
 
   The basic principle is that the f= irst DOIC capable/willing Diameter
  node (including the client) on the pat= h from client to server takes
  the role of = ; the "reacting node" and announces its support for the
   overload control mechanism by ins= erting in the request message the
   OC-Feature-Vector AVP with those capabilities it supports= and is
   willing to use for this Diameter session (or transaction = in a case
   of a non-session state maintaining applications, see Sect= ion 3.1.2
   for more details on Diameter sessions).
 
2. 2nd sentence: Why is it only RECOMMENDED to insert the Feature-Vect= or into every request?
The reacting endpoint may not even know which remote reporting endpoin= t the request will be sent to. The reporting endpoint would interpret an ab= sent Feature-Vector in the received request as "there is no downstream= reacting endpoint" and will not send back Feature-Vectors or OLRs. Proposal is to say:
 
=    The reacting endpoint MUST insert the capability announcement into every
=    request regardless it has had prior message exchanges with the=
=   (possibly not yet) given remote endp= oint.
 
3. 3rd sentence: Proposal:
 
=    Once the reacting endpoint that= inserted the capabi= lity announcement into
   the request message receives an = answer message from the remote endpoint, it
=   can detect from the received answer message whether the remote endp= oint
=   supports the overload control solution and in a case it does, what = features are
=    supported. 
 
 
Best regards
Ulrich
 
 
 --_000_5BCBA1FC2B7F0B4C9D935572D90006681519DDBBDEMUMBX014nsnin_-- From ben@nostrum.com Fri Dec 6 13:31:57 2013 Return-Path: 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 B18BF1AE072 for ; Fri, 6 Dec 2013 13:31:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no 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 FFYHi5gIOK4Q for ; Fri, 6 Dec 2013 13:31:56 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 89B621AE043 for ; Fri, 6 Dec 2013 13:31:56 -0800 (PST) Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rB6LVbPW031100 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 6 Dec 2013 15:31:38 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ben Campbell In-Reply-To: <01D3D8A5-2584-4D81-A010-982C8BF77614@gmail.com> Date: Fri, 6 Dec 2013 15:31:37 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5BCBA1FC2B7F0B4C9D935572D90006681519DAA6@DEMUMBX014.nsn-intra.net> <01D3D8A5-2584-4D81-A010-982C8BF77614@gmail.com> To: Jouni Korhonen X-Mailer: Apple Mail (2.1822) Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism) Cc: "dime@ietf.org" Subject: Re: [Dime] OVLI: comments to 4.2 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 21:31:57 -0000 On Dec 6, 2013, at 4:19 AM, Jouni Korhonen = wrote: >>=20 >> 2. Supporting OLR_DEFAULT_ALGO means different things depending on = the endpoint=92s role (reacting/reporting). >> Proposal is to expand the text to read: >>=20 >>=20 >> When this flag is set by the overload control reacting endpoint = it means >> that the default traffic abatement (loss) algorithm is supported = by the >> reacting endpoint, i.e. the reacting endpont is able and willing = to execute >> the default traffic abatement algorithm if so requested by the = reporting >> endpoint. >> When this flag is set by the overload control reporting endpoint = it means >> that the reporting endpoint when overloaded is able and willing = to demand >> executing the default traffic abatement algorithm from the = reacting endpoint. >=20 > OK with me. >=20 On reflection, if that's all it means why does the reporting node need = to send it at all? It can just choose to send OLRs for the algorithm the = reacting node has advertised. Or is the reporting node declaring that = this is the algorithm it will use? > - Jouni From ben@nostrum.com Fri Dec 6 13:37:29 2013 Return-Path: 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 240781AE043 for ; Fri, 6 Dec 2013 13:37:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no 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 rGBaKCDGJDaR for ; Fri, 6 Dec 2013 13:37:28 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 406951AD8E1 for ; Fri, 6 Dec 2013 13:37:28 -0800 (PST) Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rB6LbKr6031416 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 6 Dec 2013 15:37:21 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ben Campbell In-Reply-To: <39597F4C-52C0-4058-9559-92752389DA47@gmail.com> Date: Fri, 6 Dec 2013 15:37:20 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <800D5A8D-7B09-44C0-9390-AEED2D641CB6@nostrum.com> References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <6390_1385631044_52970D44_6390_18593_1_6B7134B31289DC4FAF731D844122B36E30748E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BD31@DEMUMBX014.nsn-intra.net> <47383DC2-1A1B-4D1A-ADD5-9E3CE60B06C8@gmail.com> <8467_1385735507_5298A553_8467_17054_3_6B7134B31289DC4FAF731D844122B36E309D0D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <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> <52A07A1E.5060502@usdonovans.com> <2004! 0_1386250 088_52A07F68_20040_916_1_6B7134B31289DC4FAF731D844122B36E32B0E9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <39597F4C-52C0-4058-9559-92752389DA47@gmail.com> To: Jouni Korhonen X-Mailer: Apple Mail (2.1822) Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism) Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 21:37:29 -0000 On Dec 6, 2013, at 4:31 AM, Jouni Korhonen = wrote: >>=20 >> After this LONG thread, it seems that there are strong arguments = against the self-contained OLRs and little support. >> In the contrary, it seems that the principle of OLR related to the = application in use is technically OK for everyone. >>=20 >> So the question is quite simple: >>=20 >> Could everyone live/survive with the "implicit approach" with the = extensibility mechanism allowing future extensions if needed? >=20 > Yes for implicit. (and less text edits for me :) >=20 > There is no need to mention "future extension" possibility here. > Anyone is free to extend OLRs in the future using the defined > approach: allocate a new feature flag and define how to use it. >=20 I'm sure there are many corners we can paint ourselves into that would = prevent certain avenues of extension. I'm not saying we've done that for = this particular avenue. I don't think we have, and we don't necessarily = have to put text about it in the draft. I took the mention of = extensibility as a condition of my answers to the question. > - JOuni From ben@nostrum.com Fri Dec 6 13:45:32 2013 Return-Path: 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 2E2ED1AE0D3 for ; Fri, 6 Dec 2013 13:45:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no 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 pAx2qdcZtfbV for ; Fri, 6 Dec 2013 13:45:31 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 22CBD1ADFD6 for ; Fri, 6 Dec 2013 13:45:31 -0800 (PST) Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rB6LjAdM031818 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 6 Dec 2013 15:45:12 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ben Campbell In-Reply-To: <6CDCFC84-3048-40B9-91A4-1451FCC65F60@gmail.com> Date: Fri, 6 Dec 2013 15:45:10 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5BCBA1FC2B7F0B4C9D935572D90006681519DA3E@DEMUMBX014.nsn-intra.net> <6CDCFC84-3048-40B9-91A4-1451FCC65F60@gmail.com> To: Jouni Korhonen X-Mailer: Apple Mail (2.1822) Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism) Cc: "dime@ietf.org" Subject: Re: [Dime] OVLI: comments to 4.1 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 21:45:32 -0000 On Dec 6, 2013, at 4:17 AM, Jouni Korhonen = wrote: [...] >> 3. The OC-Sequence-Number within OC-Feature-Vector only makes sense = if the receiving reporting endpoint can determine the identity of the = reacting endpoint (which is not necessarily the origin host (client), >=20 > My original proposal was to have seqnr as a timestamp. Some folks = argued > it is no good and suggested seqnr. I still think time makes more sense = than > seqnr. >=20 Whether it's a timestamp, sequence number, or random number, we should = describe the required uniqueness properties. (i.e. unique for that = sender, unique across all senders, unique over a short period of time vs = long period of time, etc.) There may be other reasons to identify who sent the OC-Feature-Vector. = Should we consider including the sender identity? >> it may be an agent and it may not always be the same agent), and if = the reporting endpoint is required to store the OC-Feature-Vector / = reacting-endpoint-identity pair (which I think both is not required). = The reporting endpoint can base its processing logic on the actually = received OC-Feature-Vector value, no matter whether it is brand-new or = old but stil valid. Proposal is to delete OC-Sequence-Number AVP from = OC-Feature-Vector. >=20 > Do not agree removing it. I concur with Jouni. IIRC, the point of having a sequence number here = was so that if a reacting-node chooses to send the feature vector in = every request, the reacting node can easily determine if the contents = have changed, and ignore it if not. But it might be reasonable to = consider whether that saves enough work to make it worth the trouble. [...]= From ben@nostrum.com Fri Dec 6 13:50:02 2013 Return-Path: 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 122051AE105 for ; Fri, 6 Dec 2013 13:50:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no 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 vDuZLFj9savx for ; Fri, 6 Dec 2013 13:50:00 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id BBF1D1AE0FA for ; Fri, 6 Dec 2013 13:50:00 -0800 (PST) Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rB6LnnCa031988 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 6 Dec 2013 15:49:50 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ben Campbell In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681519DD2A@DEMUMBX014.nsn-intra.net> Date: Fri, 6 Dec 2013 15:49:49 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5BCBA1FC2B7F0B4C9D935572D90006681519DB1B@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681519DD2A@DEMUMBX014.nsn-intra.net> To: "Wiehe, Ulrich (NSN - DE/Munich)" X-Mailer: Apple Mail (2.1822) Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism) Cc: "dime@ietf.org" Subject: Re: [Dime] OVLI: comments to 4.3 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 21:50:02 -0000 On Dec 6, 2013, at 7:39 AM, Wiehe, Ulrich (NSN - DE/Munich) = wrote: >>=20 >> 2. TimeStamp has been replaced with Sequence-Number. This has the = negative impact that reacting nodes must calculate the expiration time = base on OLR-reception time. OLR reception time and OLR creation time = may be significantly different. >> I don't see any reason in favour of Sequence-Number. Proposal is to = replace Sequence-Number with TimeStamp. >=20 > I agree but you need to convince the others as well who favoured = sequence number. I don't think it was so much that we didn't want it to be a timestamp as = we didn't want to mandate the implementation. We need to make sure the = number changes between different versions. A time stamp is one way to do = that. A sequence number (or version number) is another. As I mentioned in a separate thread, we at list need to describe the = expected properties. For example, the scope-of-uniqueness, whether we = expect the number to always increase or just be different, etc. It's not = clear to me that any association with wall clock time is one of those = needed properties, even though a time stamp might be a perfectly = reasonable way to achieve the other needed properties. From ben@nostrum.com Fri Dec 6 13:54:05 2013 Return-Path: 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 8B2DB1AE0ED for ; Fri, 6 Dec 2013 13:54:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no 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 WiBpN3KjTK-r for ; Fri, 6 Dec 2013 13:54:04 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id A3C531ADE87 for ; Fri, 6 Dec 2013 13:54:04 -0800 (PST) Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rB6LrwTJ032206 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 6 Dec 2013 15:54:00 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ben Campbell In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681519DCBC@DEMUMBX014.nsn-intra.net> Date: Fri, 6 Dec 2013 15:53:58 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5BCBA1FC2B7F0B4C9D935572D90006681519DCBC@DEMUMBX014.nsn-intra.net> To: "Wiehe, Ulrich (NSN - DE/Munich)" X-Mailer: Apple Mail (2.1822) Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism) Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 21:54:05 -0000 On Dec 6, 2013, at 6:10 AM, Wiehe, Ulrich (NSN - DE/Munich) = wrote: > Dear all, > =20 > here are comments to clause 4.6: > =20 > 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. =20 > 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: >=20 > 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=20 > c) The request command's Destination-Host matches the Origin-Host of = the OC-Report-Type AVP's encapsulating answer command We might consider whether a Host OLR would also apply to the selection = of a next-hop peer, in cases where [B&C] were false. For example, if = relay received a Host OLR from Server A, it might apply that OLR to = requests it would ordinarily send to Server A, even if the client had = not included a Destination-Host. From ben@nostrum.com Fri Dec 6 13:57:37 2013 Return-Path: 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 3E95B1AE02E for ; Fri, 6 Dec 2013 13:57:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no 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 7YsInZ2iTp6r for ; Fri, 6 Dec 2013 13:57:36 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5C6CA1ADE87 for ; Fri, 6 Dec 2013 13:57:36 -0800 (PST) Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rB6LvUdq032415 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 6 Dec 2013 15:57:31 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ben Campbell In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681519DD6B@DEMUMBX014.nsn-intra.net> Date: Fri, 6 Dec 2013 15:57:30 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <39FA9478-3430-49F4-AB06-B83AA8129960@nostrum.com> References: <5BCBA1FC2B7F0B4C9D935572D90006681519DD6B@DEMUMBX014.nsn-intra.net> To: "Wiehe, Ulrich (NSN - DE/Munich)" X-Mailer: Apple Mail (2.1822) Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism) Cc: "dime@ietf.org" Subject: Re: [Dime] OVLI: comments to 4.5 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 21:57:37 -0000 On Dec 6, 2013, at 8:39 AM, Wiehe, Ulrich (NSN - DE/Munich) = wrote: > here is another comment to 4.5: > =20 > 3. It may be worth to clarify the meaning of a validity duration of 0 = seconds. In my understanding it does not mean that the encapsulating = OC-OLR is invalid. It is valid (and therefore replaces any previous OLR = with the same report-type), but it immediately expires and hence is a = way to signal =93end of overload=94. >=20 That's effectively the same thing as invalidating any pre-existing OLR. = I don't think we need the text to jump through hoops to try to make that = invalidation sound like a side effect. (And I note that this approach is = common in other protocols, e.g. SIP registrations and subscriptions.)= From nsalot@cisco.com Sat Dec 7 00:27:00 2013 Return-Path: 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 175641A1F71 for ; Sat, 7 Dec 2013 00:27:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.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 jTzONsJ4Xsrb for ; Sat, 7 Dec 2013 00:26:58 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id 89D7B1ADF8A for ; Sat, 7 Dec 2013 00:26:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2217; q=dns/txt; s=iport; t=1386404814; x=1387614414; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=JpxDAIR7cN6N0QnsbVjfLKOCuDERe0bRFUUAsKBrWjU=; b=RHOgVnap5lvI87IdUIcLZWE+irQblqX6SpoGeFJtGHi0uk4M0LRMk2Pd DNyUSkqFapMlncVp+VSNROg6EUPG2g2CKzGsTW8Uj8xF4Li9s5GeWBfnF y10NtXbsuc0zcgfd1tnERyqis+5f/jvDL+Rt9zKI4zmYE7Uk9SLRp0tiY g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAHXaolKtJXG8/2dsb2JhbABZgwc4U7kTgRoWdIIlAQEBBAEBATc0CwwEAgEIEQQBAQsUCQcnCxQJCAEBBA4FCId6DcBCEwSOXzEHBoMagRMDqieDKYIq X-IronPort-AV: E=Sophos;i="4.93,845,1378857600"; d="scan'208";a="5025409" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by alln-iport-6.cisco.com with ESMTP; 07 Dec 2013 08:26:54 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id rB78QsJO006503 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 7 Dec 2013 08:26:54 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.250]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Sat, 7 Dec 2013 02:26:54 -0600 From: "Nirav Salot (nsalot)" To: Ben Campbell , "Wiehe, Ulrich (NSN - DE/Munich)" Thread-Topic: [Dime] OVLI: comments to 4.3 Thread-Index: Ac7xzgT7drC0NV4iSVSEGFHx9aP+WQA0gLQAAAa3TAAAER7hgAAJZ7uQ Date: Sat, 7 Dec 2013 08:26:53 +0000 Message-ID: References: <5BCBA1FC2B7F0B4C9D935572D90006681519DB1B@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681519DD2A@DEMUMBX014.nsn-intra.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.82.104] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dime@ietf.org" Subject: Re: [Dime] OVLI: comments to 4.3 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Dec 2013 08:27:00 -0000 In my view, from the reacting point of view, Timestamp and Sequence-Number = are both the same since it is just a number defining the uniqueness/version= -Id of the OC-OLR. e.g. we can define Sequence-Number and the reporting node can use Timestamp= to populate the same.=20 The most important part is that the reacting node is not supposed to use th= is parameter for anything but finding out the newness/version-ID of the rep= ort. Beyond that, from the reporting node's point of view, I am fine to use Sequ= ence-Number or Timestamp. Regards, Nirav. -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell Sent: Saturday, December 07, 2013 3:20 AM To: Wiehe, Ulrich (NSN - DE/Munich) Cc: dime@ietf.org Subject: Re: [Dime] OVLI: comments to 4.3 On Dec 6, 2013, at 7:39 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >>=20 >> 2. TimeStamp has been replaced with Sequence-Number. This has the negati= ve impact that reacting nodes must calculate the expiration time base on OL= R-reception time. OLR reception time and OLR creation time may be signific= antly different. >> I don't see any reason in favour of Sequence-Number. Proposal is to repl= ace Sequence-Number with TimeStamp. >=20 > I agree but you need to convince the others as well who favoured sequence= number. I don't think it was so much that we didn't want it to be a timestamp as we= didn't want to mandate the implementation. We need to make sure the number= changes between different versions. A time stamp is one way to do that. A = sequence number (or version number) is another. As I mentioned in a separate thread, we at list need to describe the expect= ed properties. For example, the scope-of-uniqueness, whether we expect the = number to always increase or just be different, etc. It's not clear to me t= hat any association with wall clock time is one of those needed properties,= even though a time stamp might be a perfectly reasonable way to achieve th= e other needed properties. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From nsalot@cisco.com Sat Dec 7 00:35:29 2013 Return-Path: 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 8D7261ADF90 for ; Sat, 7 Dec 2013 00:35:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.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 kUco9UQ7AHot for ; Sat, 7 Dec 2013 00:35:26 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id 1404F1A1F71 for ; Sat, 7 Dec 2013 00:35:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15588; q=dns/txt; s=iport; t=1386405322; x=1387614922; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=wjnh3jtbeqr2R07S5wNeLiTwqKA40FHF+7WLJst8JFg=; b=aKa6Jsc7udLgSrZshQftAxKmDANxr1Vn4qhd/L74nxzUt+dMIuzw5mKf 63ghy/nZCAz2YYjDOa0Mo2Esb9azLe70MxfL3uzCVudDSSmE+y3RdejGd iv6dMBzYv/P14UyHYeqBLWyT7iCGeFjcfRhV98leL6PzAMW4+c7YTveZX I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0FAPncolKtJXG+/2dsb2JhbABZgwc4U7kTgRoWdIIlAQEBAwEBAQFrCwUHBAIBCBEEAQEBCh0HIQYLFAkIAQEEAQ0FCBOHVQMJBg25HA2HGhMEjH2BMREBHzEHBoMagRMDiQqNH45FhTmBa4E+gXE5 X-IronPort-AV: E=Sophos;i="4.93,845,1378857600"; d="scan'208";a="5026117" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by alln-iport-6.cisco.com with ESMTP; 07 Dec 2013 08:35:21 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id rB78ZLwc006587 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 7 Dec 2013 08:35:21 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.250]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Sat, 7 Dec 2013 02:35:21 -0600 From: "Nirav Salot (nsalot)" To: Jouni Korhonen , "lionel.morand@orange.com" Thread-Topic: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same type) within a response message Thread-Index: Ac7wCaL7vn3WS3V+QYqfk/QVoAmaPAANW4QAAAHTmQAAAKLfgAC3VBag Date: Sat, 7 Dec 2013 08:35:20 +0000 Message-ID: References: <5BCBA1FC2B7F0B4C9D935572D90006681519C296@DEMUMBX014.nsn-intra.net> <10558_1386067228_529DB51C_10558_2647_1_6B7134B31289DC4FAF731D844122B36E3129AA@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.82.104] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dime@ietf.org" Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same type) within a response message X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Dec 2013 08:35:29 -0000 Jouni, All, As most of you have indicated, I am fine with the assumption that when an a= pplication specific parameter is added in the OC-OLR, new Report-Type is de= fined correspondingly. However, the above does not guarantee that we will never have require multi= ple instances of OC-OLR with the same Report-Type. e.g. if a new parameter APN and Report-Type=3Dhost_and_APN is defined by a = 3GPP application. Now, the APN can take multiple values. Or in other words, the reporting nod= e may want to send different report for APN1 v/s APN2. And hence it requires to provide two instances of OC-OLR, both with Report-= Type=3D"host_and_APN" and one instance containing APN=3DAPN1 and another on= e with APN=3DAPN2. So in summary, I still believe that we should not have restriction that "mu= ltiple instances with same Report-Type is not allowed". On the other hand, I believe we should define the principles of the handlin= g of the same - in case any application extending the IETF defined OC-OLR d= efines new parameter. Regards, Nirav. -----Original Message----- From: Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20 Sent: Tuesday, December 03, 2013 4:29 PM To: lionel.morand@orange.com Cc: Wiehe, Ulrich (NSN - DE/Munich); Nirav Salot (nsalot); Maria Cruz Barto= lome; dime@ietf.org Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same type= ) within a response message On Dec 3, 2013, at 12:40 PM, lionel.morand@orange.com wrote: > Nirav, > =20 > If there are more than one OLR of the same type in the same answer, based= on what I understood from the examples given below, the client will have t= o figure out which reduction to apply only based on extra AVPs received in = the OLRs. I'm not so sure that it is something advisable from a standard po= int of view. Agree.. the implementation then needs to go into weird heuristics based on = the presence of different AVPs for the same OC-Report-Type. I have hard tim= e seeing how that would be better than having explicitly specified report t= ypes where the handling of AVPs is known. Interop across vendors would at l= east be easier to achieve. The text I wrote into -01 last week does not allow OLRs with the same repor= t type..=20 - Jouni > =20 > Regards, > =20 > Lionel > =20 > De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich=20 > (NSN - DE/Munich) Envoy=E9 : mardi 3 d=E9cembre 2013 10:48 =C0 : ext Nira= v=20 > Salot (nsalot); Maria Cruz Bartolome; dime@ietf.org Objet : Re: [Dime]=20 > DOIC: Multiple instance of OC-OLR AVP (of the same type) within a=20 > response message > =20 > Nirav, > =20 > I still do not see the need for more than one OLR in an answer. > =20 > More than one OLR means more complexity. Let's try to avoid that. > =20 > The server gets a request that either is or is not in the narrower scope.= If it is not, why shoud the server return an OLR for the narrower scope? I= t can do so when it gets a request within the narrower scope (which possibl= y never happens). > =20 > Ulrich > =20 > =20 > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Nirav Salot=20 > (nsalot) > Sent: Tuesday, December 03, 2013 10:26 AM > To: Maria Cruz Bartolome; dime@ietf.org > Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same=20 > type) within a response message > =20 > Maria-Cruz, > =20 > > we may think that we need two different OLRs with ReportType=3Dhost,=20 > > and one of them includes the extra info (AVPs) required for that=20 > > application > Yes. The above is my concern. I tried giving APN as one example AVP which= we may want to include in OC-OLR. Let me give another possible example. > As of now, the OC-OLR can indicate application + host/realm level "requir= ed-reduction-percentage". > However, for the given application (e.g. Gx) we may want to define a narr= ower scope with "session-type =3D {M2M, Others}" AVP. So basically, the Gx = nodes can advertise different "required-reduction-percentage" for M2M sessi= ons v/s other type of sessions for the same application Gx and for the same= destination-host. > =20 > So in general, if any application needs to define a different (i.e. narro= wer) scope than application + host/realm, it can do so by adding a new AVP = in OC-OLR. > And then we might have two instances of OC-OLR from the same host. > =20 > We could achieve the above by defining new Report-Type for each new AVP a= dded by each application. But would this scale or is this a reasonable appr= oach? > I am not sure and you have already identified one of my concerns below > > if we extend ReportType, does it need to be done by IETF, or could it b= e done per application by 3GPP? > =20 > In summary, in my view, we need to define the handling of multiple instan= ces with the same Report-Type as part of the DOIC draft. Or we say that mul= tiple instances with the same Report-Type is not allowed - this seems unnec= essary restriction to me. > Otherwise, if later, we realize the need to do so then we may not be able= to do so since the handling is not defined in the base solution. > =20 > Regards, > Nirav. > =20 > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Maria Cruz=20 > Bartolome > Sent: Tuesday, December 03, 2013 1:57 PM > To: dime@ietf.org > Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same=20 > type) within a response message > =20 > Nirav, > =20 > I think I understand your concern. It may occur that we need that a react= ing node should apply two different OLR when sending a request towards one = specific host. > Then, we may think that we need two different OLRs with ReportType=3Dhost= , and one of them includes the extra info (AVPs) required for that applicat= ion, I think this is your interpretation, but. we can as well consider a ne= w ReportType=3DapplicX_ReportY, that may apply e.g. for any request send to= this application, or just for this application+host, and then Host could b= e another AVP to be included in the OLR, or we could define expected behavi= our when defining this new ReportType. > =20 > Would this cover your concerns? If not, could you try to provide an examp= le that requires two OLR with ReportType=3Dhost? > =20 > A part from that, a question for all, if we extend ReportType, does it ne= ed to be done by IETF, or could it be done per application by 3GPP? > =20 > Thanks > /MCruz > =20 > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Nirav Salot=20 > (nsalot) > Sent: jueves, 28 de noviembre de 2013 17:11 > To: lionel.morand@orange.com > Cc: dime@ietf.org > Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same=20 > type) within a response message > =20 > Hi Lionel, > =20 > I am not sure if defining new ReportType for every new AVP 3GPP would add= for a specific application would be a good solution. > I thought ReportType would indicate if the corresponding OC-OLR should be= used while sending the traffic towards the host or towards the realm. > So from that point of view, all the OC-OLR generated by the server should= have ReportType=3Dhost. i.e. when the reacting node sends the traffic towa= rds that host, it should make use of the corresponding OC-OLR. Now, this OC= -OLR may contain the AVPs defined by DOIC draft as well as 3GPP application= specific AVPs. > =20 > In general, I was just thinking that it may be good idea to define some o= f the principles such as > - More than one instances of OC-OLR with ReportType=3Dhost may b= e present in the answer message if the OC-OLR definition is extended by the= application using the same. In that case, it is the responsibility of the = application to define the valid combination of OC-OLR instances in a given = message > - If the reporting node includes more than one instance of OC-OL= R, the reporting node shall always include all the active instances of OC-O= LR in a response message. > - When the reacting node receives one or more instances of OC-OL= R with the given ReportType and with new timestamp value, it should overwri= te all the existing OC-OLR of the same ReportType. > =20 > Regards, > Nirav. > =20 > From: lionel.morand@orange.com [mailto:lionel.morand@orange.com] > Sent: Thursday, November 28, 2013 7:39 PM > To: Nirav Salot (nsalot) > Cc: dime@ietf.org > Subject: RE: DOIC: Multiple instance of OC-OLR AVP (of the same type)=20 > within a response message > =20 > Hi Nirav, > =20 > The Report Type should be able to differentiate such cases. In your examp= le, I would define a specific Report type. > But difficult to appraise all the future use cases. But for me, the main = use of the report type is to differentiate OC-OLR received in the same mess= age. > And it is the reasons of my recommendation. Actually, the exact wording w= ill be a "SHOULD" saying that it is recommended but you may have serious re= asons to do otherwise. > =20 > Lionel > =20 > De : Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Envoy=E9 : jeudi 28=20 > novembre 2013 13:00 =C0 : MORAND Lionel IMT/OLN Cc : dime@ietf.org Objet= =20 > : RE: DOIC: Multiple instance of OC-OLR AVP (of the same type) within=20 > a response message > =20 > Lionel, >=20 > 3gpp may define an optional avp which can be included by the reporting no= de if it wishes to do so. E.g. APN can be additionally included by the repo= rting node to indicate APN specific overload within the given application. > In that case, the reporting node may also want to indicate application le= vel overload without including the APN (e.g. this overload report is applic= able to all other APNs). >=20 > And hence there is a possibility of including multiple instances of the o= verload report. >=20 > I am not suggesting that 3gpp will define APN (or any other avp) within o= verload report. But later, if 3gpp need to define the same, then correspond= ing handling needs to be defined within IETF now. >=20 > Regards, > Nirav. >=20 > On Nov 28, 2013 3:56 PM, "lionel.morand@orange.com" wrote: > Hi Nirav, > =20 > Not sure to understand the proposal or question. > The OLR is significant per application (piggybacking principle). So if th= e 3GPP decides to add specific AVPs in the OLR (that will be possible), wha= t would be the need to add the OLR without the specific 3GPP AVPs as the OL= R will be anyway handle by 3GPP aware entities? > =20 > Lionel > =20 > De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot=20 > (nsalot) Envoy=E9 : jeudi 28 novembre 2013 10:33 =C0 : dime@ietf.org Obje= t=20 > : [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same type)=20 > within a response message > =20 > Hi, > =20 > As I understand IETF will define the base overload control solution as pa= rt of DOIC. Then 3GPP would adopt the defined solution for each of its appl= ication. > When that happens, 3GPP might want to add 3GPP specific AVP within OC-OLR= AVP. Based on the current definition of the OC-OLR AVP this should be allo= wed since it contains "* [AVP]" in its definition. > e.g. for a given application 3GPP decides to add information into OC-OLR = which changes the scope of the OC-OLR from application level to the provide= d information level. > Additionally, the reporting may want to advertise the OC-OLR at the appli= cation level scope - i.e. the OC-OLR without any 3GPP specific info. > =20 > So if the above is allowed, we will have the possibility of the reporting= node wanting to include two instances of OC-OLR with the Report-Type=3D"ho= st". > And then we need to define the handling of multiple instances of OC-OLR i= n the DOIC draft. > =20 > So the questions are, > - Is 3GPP (or any other SDO) allowed to extend the definition of= OC-OLR by adding information into it? > - If no, can we guarantee that application level scope of OC-OLR= (which is what we have defined currently) is sufficient (and not restricti= ng) to all the applications of 3GPP? > =20 > Regards, > Nirav. > =20 > ______________________________________________________________________ > ___________________________________________________ > =20 > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci. > =20 > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not be d= istributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > ______________________________________________________________________ > ___________________________________________________ > =20 > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci. > =20 > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not be d= istributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > ______________________________________________________________________ > ___________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not be d= istributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From nsalot@cisco.com Sat Dec 7 01:44:36 2013 Return-Path: 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 0A9CB1AE290 for ; Sat, 7 Dec 2013 01:44:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.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 ftAEbk5nUv4U for ; Sat, 7 Dec 2013 01:44:33 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 170091AE27A for ; Sat, 7 Dec 2013 01:44:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7631; q=dns/txt; s=iport; t=1386409469; x=1387619069; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=JjsEDzvaw05V3M1PHzecs+ajQbY3OUAb5IwbYEjfNGM=; b=GprCltqW5f2VgOOGxoj/antyeFK1ctkjfeIsA9SdPdImdm1w5ygUYw5J Gic1a2AXUFIjWJtWqDP5UT5l592xFdn/+CeOKWqEFmovRUyvblgy116MI dQTC3TMahyefie+/ukrgb3+cJRHDlz+LD9ArqyX+NXyQXoxykHIcZnlmX k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0FADztolKtJXG8/2dsb2JhbABZgwc4U7kTgRoWdIIlAQEBAwEBAQE3NAsFBwQCAQgRBAEBCxQJByEGCxQJCAEBBAENBQiHaAMJBg25IQ2HGhMEjH2BYjEHBoMagRMDlDGBeI5FhTmDKYFqJBw X-IronPort-AV: E=Sophos;i="4.93,845,1378857600"; d="scan'208";a="289997031" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-5.cisco.com with ESMTP; 07 Dec 2013 09:44:28 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id rB79iSkm027593 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 7 Dec 2013 09:44:28 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.250]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Sat, 7 Dec 2013 03:44:28 -0600 From: "Nirav Salot (nsalot)" To: "Wiehe, Ulrich (NSN - DE/Munich)" , ext Jouni Thread-Topic: [Dime] OVLI: comments to 4.6 Thread-Index: Ac7yfC5RbFsL+gV9TT6AJTwE2XmtwwANV4kAAAOr9wAAG9aeQA== Date: Sat, 7 Dec 2013 09:44:28 +0000 Message-ID: References: <5BCBA1FC2B7F0B4C9D935572D90006681519DCBC@DEMUMBX014.nsn-intra.net> <6950EE6B-689E-47A1-88AA-1A67C47BC82E@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519DD4D@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681519DD4D@DEMUMBX014.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.82.104] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Dec 2013 09:44:36 -0000 Hi Ulrich, Instead of re-packing, I see your proposal as confusing or adding more impl= ementation complexity to the exiting simple proposal of having just two Rep= ort-Type. e.g. with your proposal, now the nodes have to validate if the combination = of Report-Type flag is correct/allowed or not and perform the error handlin= g if there is any discrepancy.=20 Besides, I do not see the need for some obvious Report-Type e.g. "APPLICATI= ON_ID_MATCH" since it is always present and/or implicit. Same is the case with "DESTINATION_HOST_PRESENT" and "DESTINATION_HOST_MATC= H". What is the use case for destination-host present but not match? In oth= er words, the reacting node should use this type of report towards which no= de/realm? I guess this time you need to convince me (at least) as why you think so ma= ny different Report-Types are needed and what is the issue with existing de= finition of Report-Type. Regards, Nirav. -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN -= DE/Munich) Sent: Friday, December 06, 2013 7:48 PM To: ext Jouni Cc: dime@ietf.org Subject: Re: [Dime] OVLI: comments to 4.6 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. Best regards Ulrich -----Original Message----- From: ext Jouni [mailto:jouni.nospam@gmail.com]=20 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, > =20 > here are comments to clause 4.6: > =20 > 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 pr= oblems. =20 I do not see how changing the type to unsigned would help with the extensib= ility 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 semantic= s to something like what we have on OC-Feature AVP. How the receiver of the repo= rt 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 receiv= er has no other choice than drop the OLR, since it cannot be sure how to handle th= e 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 ma= ps to a report type (that has been defined after the publication of this=20 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 le= t the reacting node know to which (future) request commands the overload tr= eatment should apply: >=20 > 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=20 > c) The request command's Destination-Host matches the Origin-Host of the = OC-Report-Type AVP's encapsulating answer command >=20 > For a realm report-type the overload treatment should apply to all reques= t commands for which > a) and > d) The request command's Destination-Host is absent and=20 > e) The request command's Destination Realm matches the Origin-Realm of th= e OC-Report-Type AVP's encapsulating answer command. >=20 > The proposal now is to assign individual bits of the Unsinged64 type to a= ), b), c), d), and e): >=20 > Proposed text: > 4.6 OC-Report-Type AVP >=20 > The OC-Report-Type AVP (AVP code TBD5) is type of Unsigned64 and contai= ns a 64 bit flags field of a request > command's characteristics. >=20 > The following characteristics are defined in this document: >=20 > APPLICATION_ID_MATCH (0x0000000000000001) >=20 > 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 Appli= cation-Id of the OC-Report-Type AVP's > encapsulating answer command. >=20 > DESTINATION_HOST_PRESENT (0x0000000000000002) >=20 > 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. >=20 > DESTINATION_HOST_MATCH (0x0000000000000004) >=20 > 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. >=20 > DESTINATION_HOST_ABSENT (0x0000000000000008) >=20 > 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. >=20 > DESTINATION_REALM_MATCH (0x0000000000000010) >=20 > 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. >=20 > Combinations other than=20 > 1) APPLICATION_ID_MATCH and DESTINATION_HOST_PRESENT and DESTINATION_HO= ST_MATCH > and > 2) APPLICATION_ID_MATCH and DESTINATION_HOST_ABSENT and DESTINATION_REA= LM_MATCH > require a mutually agreed extension. >=20 >=20 >=20 >=20 > One extension required by 3GPP applications is the Overload Mitigation Di= fferentiation per client (see 3GPP TR 29.809 clause 6.4.7. To address this,= a new value would be needed e.g. >=20 > ORIGIN_HOST_MATCH (0x0000000000000020) >=20 > 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 Dest= ination-Host of the OC-Report-Type AVP's > encapsulating answer command. >=20 > With this extension the following additional combinations would be allowe= d: > 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 >=20 > Another potential extension is Diameter Agent Overload. To address this, = a new value would be needed e.g. >=20 > NEXT_HOP_MATCH (0x0000000000000040) >=20 > 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. >=20 >=20 > Best regards > Ulrich >=20 >=20 > _______________________________________________ > 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 From wwwrun@rfc-editor.org Mon Dec 9 00:54:55 2013 Return-Path: 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 37FBB1ADF10; Mon, 9 Dec 2013 00:54:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 E3p6GKHDz29C; Mon, 9 Dec 2013 00:54:53 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id 9126B1ADEDC; Mon, 9 Dec 2013 00:54:53 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id E1DFA7FC15B; Mon, 9 Dec 2013 00:54:48 -0800 (PST) To: Lionel.morand@orange.com, vf0213@gmail.com, jari.arkko@ericsson.com, john.loughney@nokia.com, glenzorn@gmail.com From: RFC Errata System Message-Id: <20131209085448.E1DFA7FC15B@rfc-editor.org> Date: Mon, 9 Dec 2013 00:54:48 -0800 (PST) Cc: dime@ietf.org, iesg@ietf.org, rfc-editor@rfc-editor.org Subject: [Dime] [Errata Verified] RFC6733 (3805) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 08:54:55 -0000 The following errata report has been verified for RFC6733, "Diameter Base Protocol". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6733&eid=3805 -------------------------------------- Status: Verified Type: Technical Reported by: Lionel Date Reported: 2013-11-18 Verified by: Benoit Claise (IESG) Section: 3 Original Text ------------- Message Length The Message Length field is three octets and indicates the length of the Diameter message including the header fields and the padded AVPs. Thus, the Message Length field is always a multiple of 4. Corrected Text -------------- Message Length The Message Length field is three octets and indicates the number of octets of the Diameter message, including the header fields and the padded AVPs. Thus, the Message Length field is always a multiple of 4 octets. Notes ----- the actual text does not indicate the unit of length unit, which may lead to confusion and IOT issues, especially if someone considers bits instead of bytes. -------------------------------------- RFC6733 (draft-ietf-dime-rfc3588bis-33) -------------------------------------- Title : Diameter Base Protocol Publication Date : October 2012 Author(s) : V. Fajardo, Ed., J. Arkko, J. Loughney, G. Zorn, Ed. Category : PROPOSED STANDARD Source : Diameter Maintenance and Extensions Area : Operations and Management Stream : IETF Verifying Party : IESG From jouni.nospam@gmail.com Mon Dec 9 00:56:35 2013 Return-Path: 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 B4E551ADE84 for ; Mon, 9 Dec 2013 00:56:35 -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 xONS_mWtMgMs for ; Mon, 9 Dec 2013 00:56:33 -0800 (PST) Received: from mail-bk0-x22d.google.com (mail-bk0-x22d.google.com [IPv6:2a00:1450:4008:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 4A8DF1ADEDC for ; Mon, 9 Dec 2013 00:56:33 -0800 (PST) Received: by mail-bk0-f45.google.com with SMTP id mx13so1240290bkb.32 for ; Mon, 09 Dec 2013 00:56:28 -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=JwRtrhPn1FX7wDPCHxDLJkYUVgL/2GD+XD7l5ho8kkE=; b=De8ISM8ktbiVOOgjCDEvxkH3yxd7lTuvbiaRbrqNvu8JsfpOcSQfdTKn2X+YZxdX/W WVL+elL82DBdQHPTP92/Zingg1JnWVXzhe7RjzVZfJS/5oFaRZ0G0CGT4yKzEA5OyJ+L x/7Z5rNX9oE5wC1tX8boTUIEL59WXf3bO9WaUTqlC1hrJoCWAttKYTV8t0iJMYa53vwE qIBoRRGYWpe03HF/kC2XacTIXdhwzIv3zscOs+oi3tp2zYlZCM+gu46FpAXDLFj3QfPs jSAZbLDUY79MHOPWIh3Yegs76fB3FQdBtR9+ePgitW13fgIYuctZ23LlYCdJPrN1x2GI Byuw== X-Received: by 10.205.38.133 with SMTP id ti5mr125103bkb.179.1386579387980; Mon, 09 Dec 2013 00:56:27 -0800 (PST) Received: from ?IPv6:2001:1bc8:101:f101:a875:9b2c:596e:b87d? ([2001:1bc8:101:f101:a875:9b2c:596e:b87d]) by mx.google.com with ESMTPSA id o5sm7975146bkz.4.2013.12.09.00.56.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Dec 2013 00:56:24 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681519DD6B@DEMUMBX014.nsn-intra.net> Date: Mon, 9 Dec 2013 10:56:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5BCBA1FC2B7F0B4C9D935572D90006681519DD6B@DEMUMBX014.nsn-intra.net> To: "Wiehe, Ulrich (NSN - DE/Munich)" X-Mailer: Apple Mail (2.1510) Cc: "dime@ietf.org" Subject: Re: [Dime] OVLI: comments to 4.5 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 08:56:35 -0000 Ulrich, On Dec 6, 2013, at 4:39 PM, "Wiehe, Ulrich (NSN - DE/Munich)" = wrote: > Dear all, > =20 > here is another comment to 4.5: > =20 > 3. It may be worth to clarify the meaning of a validity duration of 0 = seconds. In my understanding it does not mean that the encapsulating = OC-OLR is invalid. It is valid (and therefore replaces any previous OLR = with the same report-type), but it immediately expires and hence is a = way to signal =93end of overload=94. Validity duration of 0 causes an immediate timeout of OLR state with an endpoint. I agree this should be clarified (it is actually discussed in Section 5.5.2. but should be mentioned here as well). - Jouni > =20 > =20 > Best regards > Ulrich > _____________________________________________ > From: Wiehe, Ulrich (NSN - DE/Munich) > Sent: Thursday, December 05, 2013 5:05 PM > To: 'dime@ietf.org' > Subject: OVLI: comments to 4.5 > =20 > =20 > Dear all, > =20 > here are comments to clause 4.5: > =20 > 1. (linked to a previous comment to 4.3) The first sentence should be = modified to read > =20 > The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32 > and describes the number of seconds the OC-OLR AVP and its content = is > valid since the creation of the OC-OLR AVP (as indicated by the > OC-TimeStamp AVP).=20 > =20 > 2. A default value of 5 seconds does not make much sense when the = Reduction-Percentage is absent or takes the value 0. Proposal is to = modify text as follows: > =20 > The default value for the OC-Validity-Duration AVP value is 5 (i.e. = 5 seconds). When the OC-Validity- > Duration AVP is not present in the OC-OLR AVP, the default value = applies, unless the Reduction-Percentage AVP > is absent or takes the value 0, in which cases the validity is = unlimited. > =20 > =20 > Best regards > Ulrich > =20 > =20 > =20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From jouni.nospam@gmail.com Mon Dec 9 00:59:30 2013 Return-Path: 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 6959E1AE227 for ; Mon, 9 Dec 2013 00:59:30 -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 z83zpU9ewdvW for ; Mon, 9 Dec 2013 00:59:28 -0800 (PST) Received: from mail-bk0-x229.google.com (mail-bk0-x229.google.com [IPv6:2a00:1450:4008:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id E4DEE1ADEDC for ; Mon, 9 Dec 2013 00:59:27 -0800 (PST) Received: by mail-bk0-f41.google.com with SMTP id v15so1249629bkz.14 for ; Mon, 09 Dec 2013 00:59:22 -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=W0dTJ9O672Hx77Z9SbR0TnmqJqRdIYdvQM0pZj7iXrA=; b=tAZWyBzZfPwWbJIiqWsMglCrejDFm3b1tFe1rc2/Lrehd2pxp/pnB+sAsF3hxD3W7B ACVn8Owo7S0wGecRU0PT0x/seVI8bs/5x78jVytZZ1Bg+kwSIrDViy2QHXz8ksNbeTtS Tp4YhR20y3/oHVAq2NIVEuYMSQieIi2Penjx8n4nefMuQ1/1Ry7KI7KoGHCLl5oR37z3 nWbVzagbZsxIDU9ETaOerDJjOFcB2tyL6bVyjF3rKjvfj6sPtdnM7y6zOPs4rosQXc7P xvi/kd3Ks6WOUyIGZgA7HYeLONd62ywal3nRTPUM1/2il2zyxte6izjIfCGB3Z1pr7va JO8Q== X-Received: by 10.204.73.5 with SMTP id o5mr5533745bkj.37.1386579562653; Mon, 09 Dec 2013 00:59:22 -0800 (PST) Received: from ?IPv6:2001:1bc8:101:f101:a875:9b2c:596e:b87d? ([2001:1bc8:101:f101:a875:9b2c:596e:b87d]) by mx.google.com with ESMTPSA id qg7sm7978756bkb.6.2013.12.09.00.59.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Dec 2013 00:59:18 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681519DD2A@DEMUMBX014.nsn-intra.net> Date: Mon, 9 Dec 2013 10:59:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <38D0E021-23B2-4DDB-BCCF-914DB11AA2EE@gmail.com> References: <5BCBA1FC2B7F0B4C9D935572D90006681519DB1B@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681519DD2A@DEMUMBX014.nsn-intra.net> To: "Wiehe, Ulrich (NSN - DE/Munich)" X-Mailer: Apple Mail (2.1510) Cc: "dime@ietf.org" Subject: Re: [Dime] OVLI: comments to 4.3 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 08:59:30 -0000 Ulrich, On Dec 6, 2013, at 3:39 PM, "Wiehe, Ulrich (NSN - DE/Munich)" = wrote: > Dear Jouni, >=20 > thanks again.=20 >=20 > Why isn't it so that others need to convince me/us? ;-) Mainly because you brought it up.. and are currently the one who wants this part to be changed. - Jouni >=20 > Dear others, > Please let me know your arguments in favour of Sequence Number (if = any). >=20 > Best regards > Ulrich >=20 >=20 >=20 > -----Original Message----- > From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20 > Sent: Friday, December 06, 2013 11:27 AM > To: Wiehe, Ulrich (NSN - DE/Munich) > Cc: dime@ietf.org > Subject: Re: [Dime] OVLI: comments to 4.3 >=20 >=20 > On Dec 5, 2013, at 5:23 PM, "Wiehe, Ulrich (NSN - DE/Munich)" = wrote: >=20 >> Dear all, >>=20 >> here are comments to clause 4.3: >>=20 >> 1. Extensions in OC-OLR must either be mutually supported or must be = ignorable. In the first case it is not enough for the reporting node to = declare support of an extension in the sent OC-Feature-Vector AVP. For = the second case there is no need to declare (or even define) support of = an extension. >=20 > I am afraid I do not understand what you mean by above. >=20 >> Proposal is to expand the second sentence as follows: >> OC-OLR may also be used to convey additional information about = mutually supportedextensions that are >> declared in the OC-Feature-Vector AVPs, and may also be used to = convey additional ignorable information. >=20 > Not sure about the wording "ignorable information".. but otherwise ok = with me. >=20 >>=20 >> 2. TimeStamp has been replaced with Sequence-Number. This has the = negative impact that reacting nodes must calculate the expiration time = base on OLR-reception time. OLR reception time and OLR creation time = may be significantly different. >> I don't see any reason in favour of Sequence-Number. Proposal is to = replace Sequence-Number with TimeStamp. >=20 > I agree but you need to convince the others as well who favoured = sequence number. >=20 > - Jouni >=20 >=20 >>=20 >> Best regards >> Ulrich >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >=20 From jouni.nospam@gmail.com Mon Dec 9 01:05:44 2013 Return-Path: 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 AB9231AE21B for ; Mon, 9 Dec 2013 01:05:44 -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 zXdCwt0UQI8w for ; Mon, 9 Dec 2013 01:05:42 -0800 (PST) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 26EA71AE225 for ; Mon, 9 Dec 2013 01:05:41 -0800 (PST) Received: by mail-la0-f43.google.com with SMTP id n7so1327310lam.2 for ; Mon, 09 Dec 2013 01:05:36 -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=1VOvB04moVVYtSZ7joEAU89rS3+ZXETQ0iGIjfgiIrQ=; b=YdJeKYk4c4lc45XO5ZUh95bGC6XooQCZawH/sHuiya5BhNOne90LFEhGvLTqw3ScxH BwI20zmd4ztl61FDIFTsCGsopUvwNzVPEXCdGJPzxs3MfvSOGAGu/4VBK357KuB7H19C faPZ7/lxmqD+Cd1OzbFm3bTpfFMCUMLPFOfmKA1aa8VRj5xio/nNYBt+e8EGb03jgHgw xEDUsLtqINH+oyM/5Mrf4w7zIf2I1twkl57hX+hVHJQagCE2eArtZiAvftR078XxKgf6 3+UnEtgr/tBuyM9ilykSSVb0uk1acN4po62+jrBgUMyDWA5UE08ALhyL37gxP4RGuCSl cKJw== X-Received: by 10.152.28.230 with SMTP id e6mr4591740lah.3.1386579936684; Mon, 09 Dec 2013 01:05:36 -0800 (PST) Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id c8sm13029922lag.3.2013.12.09.01.05.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Dec 2013 01:05:32 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: Date: Mon, 9 Dec 2013 11:05:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4BBF1C01-5729-4E3E-9244-55381E9AD437@gmail.com> References: <5BCBA1FC2B7F0B4C9D935572D90006681519DB1B@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681519DD2A@DEMUMBX014.nsn-intra.net> To: Nirav Salot (nsalot) X-Mailer: Apple Mail (2.1510) Cc: Ben Campbell , "dime@ietf.org" Subject: Re: [Dime] OVLI: comments to 4.3 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 09:05:44 -0000 =46rom the specification and implementation point of view sequence = number and timestamp _are_ different. If we choose to use timestamp we can = refer to exiting Diameter Time type, which then implies rules for NTP time. = That gives me exact guidelines how to implement overflows and such. For a = sequence number we need to define how e.g. values 0x00000001 and 0xfffffff7 = relate to each other. Is the former smaller compared to latter or a result of an = overflow. Also we need to define how initial values are picked up e.g. after a = reboot of a node. I myself do not find random numbers useful at all. They do not provide = me with ordering semantics, which I might be interested in. - Jouni On Dec 7, 2013, at 10:26 AM, Nirav Salot (nsalot) = wrote: > In my view, from the reacting point of view, Timestamp and = Sequence-Number are both the same since it is just a number defining the = uniqueness/version-Id of the OC-OLR. > e.g. we can define Sequence-Number and the reporting node can use = Timestamp to populate the same.=20 >=20 > The most important part is that the reacting node is not supposed to = use this parameter for anything but finding out the newness/version-ID = of the report. > Beyond that, from the reporting node's point of view, I am fine to use = Sequence-Number or Timestamp. >=20 > Regards, > Nirav. >=20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell > Sent: Saturday, December 07, 2013 3:20 AM > To: Wiehe, Ulrich (NSN - DE/Munich) > Cc: dime@ietf.org > Subject: Re: [Dime] OVLI: comments to 4.3 >=20 >=20 > On Dec 6, 2013, at 7:39 AM, Wiehe, Ulrich (NSN - DE/Munich) = wrote: >=20 >>>=20 >>> 2. TimeStamp has been replaced with Sequence-Number. This has the = negative impact that reacting nodes must calculate the expiration time = base on OLR-reception time. OLR reception time and OLR creation time = may be significantly different. >>> I don't see any reason in favour of Sequence-Number. Proposal is to = replace Sequence-Number with TimeStamp. >>=20 >> I agree but you need to convince the others as well who favoured = sequence number. >=20 > I don't think it was so much that we didn't want it to be a timestamp = as we didn't want to mandate the implementation. We need to make sure = the number changes between different versions. A time stamp is one way = to do that. A sequence number (or version number) is another. >=20 > As I mentioned in a separate thread, we at list need to describe the = expected properties. For example, the scope-of-uniqueness, whether we = expect the number to always increase or just be different, etc. It's not = clear to me that any association with wall clock time is one of those = needed properties, even though a time stamp might be a perfectly = reasonable way to achieve the other needed properties. >=20 >=20 >=20 > _______________________________________________ > 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 From jouni.nospam@gmail.com Mon Dec 9 01:11:10 2013 Return-Path: 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 82A991ADEC4 for ; Mon, 9 Dec 2013 01:11:10 -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 KVyM7V9GeHYy for ; Mon, 9 Dec 2013 01:11:07 -0800 (PST) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 69CD31ACCE4 for ; Mon, 9 Dec 2013 01:11:06 -0800 (PST) Received: by mail-la0-f45.google.com with SMTP id eh20so1338033lab.4 for ; Mon, 09 Dec 2013 01:11:01 -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=PtjXITfldmB6+y9agsmHKRIOeU4vrsT9WpGmDdW/tvY=; b=dfl+Xko3oE0c+6AXTIT/YdAYFlax8Ggh4kls+l7CBa38GWG28BDo1towqoRU2Rrn+Q P7paURxzj1rCl1igna8NrcAy/9A9v5DYHbgjjGGmjBanzE/rrJvJUvsA0+lTUQoKx0SN 1cTt3z9nZgNX+tg86ihrl2ks0a7l9lQJai4/gmJTBsPNxu7wyEi5vIrxoWqkNCa46tiy XNduiGgxodjWpLJ76duh80g83y6evm/6TeYdcDtasXazY8m0vXPRLenGhWJ36Zbl15wV DWxliqkqSaRgr8Vbrr8D09hjIoZ8Gt57T7eWjAriDwr5flrGM2DE2QSYdfMe5nBKeJMR vIbg== X-Received: by 10.152.22.228 with SMTP id h4mr714121laf.71.1386580260968; Mon, 09 Dec 2013 01:11:00 -0800 (PST) Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id ld10sm13062068lab.8.2013.12.09.01.10.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Dec 2013 01:10:57 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: Date: Mon, 9 Dec 2013 11:10:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <93FB21A1-CB48-4AA7-9908-3CCB96932472@gmail.com> References: <5BCBA1FC2B7F0B4C9D935572D90006681519C296@DEMUMBX014.nsn-intra.net> <10558_1386067228_529DB51C_10558_2647_1_6B7134B31289DC4FAF731D844122B36E3129AA@PEXCVZYM13.corporate.adroot.infra.ftgroup> To: Nirav Salot (nsalot) X-Mailer: Apple Mail (2.1510) Cc: "dime@ietf.org" Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same type) within a response message X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 09:11:10 -0000 Nirav, The APN example has a good point. However, in that case (assuming you = have a specific report type for it) you know exactly what additional AVP to = look=20 after. In a generic case, for example with report type "plain" host, the=20= implementation has no idea what AVPs it should consider the = differentiator and how to treat them differently.=20 Maybe these things should be clarified for the cases where new report = types are added.. if and when a new report type could make use of multiple = instance of OLRs with the same report type? - Jouni On Dec 7, 2013, at 10:35 AM, Nirav Salot (nsalot) = wrote: > Jouni, All, >=20 > As most of you have indicated, I am fine with the assumption that when = an application specific parameter is added in the OC-OLR, new = Report-Type is defined correspondingly. >=20 > However, the above does not guarantee that we will never have require = multiple instances of OC-OLR with the same Report-Type. > e.g. if a new parameter APN and Report-Type=3Dhost_and_APN is defined = by a 3GPP application. > Now, the APN can take multiple values. Or in other words, the = reporting node may want to send different report for APN1 v/s APN2. > And hence it requires to provide two instances of OC-OLR, both with = Report-Type=3D"host_and_APN" and one instance containing APN=3DAPN1 and = another one with APN=3DAPN2. >=20 > So in summary, I still believe that we should not have restriction = that "multiple instances with same Report-Type is not allowed". > On the other hand, I believe we should define the principles of the = handling of the same - in case any application extending the IETF = defined OC-OLR defines new parameter. >=20 > Regards, > Nirav. >=20 > -----Original Message----- > From: Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20 > Sent: Tuesday, December 03, 2013 4:29 PM > To: lionel.morand@orange.com > Cc: Wiehe, Ulrich (NSN - DE/Munich); Nirav Salot (nsalot); Maria Cruz = Bartolome; dime@ietf.org > Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same = type) within a response message >=20 >=20 > On Dec 3, 2013, at 12:40 PM, lionel.morand@orange.com wrote: >=20 >> Nirav, >>=20 >> If there are more than one OLR of the same type in the same answer, = based on what I understood from the examples given below, the client = will have to figure out which reduction to apply only based on extra = AVPs received in the OLRs. I'm not so sure that it is something = advisable from a standard point of view. >=20 > Agree.. the implementation then needs to go into weird heuristics = based on the presence of different AVPs for the same OC-Report-Type. I = have hard time seeing how that would be better than having explicitly = specified report types where the handling of AVPs is known. Interop = across vendors would at least be easier to achieve. >=20 > The text I wrote into -01 last week does not allow OLRs with the same = report type..=20 >=20 > - Jouni >=20 >=20 >=20 >>=20 >> Regards, >>=20 >> Lionel >>=20 >> De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich=20= >> (NSN - DE/Munich) Envoy=E9 : mardi 3 d=E9cembre 2013 10:48 =C0 : ext = Nirav=20 >> Salot (nsalot); Maria Cruz Bartolome; dime@ietf.org Objet : Re: = [Dime]=20 >> DOIC: Multiple instance of OC-OLR AVP (of the same type) within a=20 >> response message >>=20 >> Nirav, >>=20 >> I still do not see the need for more than one OLR in an answer. >>=20 >> More than one OLR means more complexity. Let's try to avoid that. >>=20 >> The server gets a request that either is or is not in the narrower = scope. If it is not, why shoud the server return an OLR for the narrower = scope? It can do so when it gets a request within the narrower scope = (which possibly never happens). >>=20 >> Ulrich >>=20 >>=20 >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Nirav = Salot=20 >> (nsalot) >> Sent: Tuesday, December 03, 2013 10:26 AM >> To: Maria Cruz Bartolome; dime@ietf.org >> Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the = same=20 >> type) within a response message >>=20 >> Maria-Cruz, >>=20 >>> we may think that we need two different OLRs with ReportType=3Dhost,=20= >>> and one of them includes the extra info (AVPs) required for that=20 >>> application >> Yes. The above is my concern. I tried giving APN as one example AVP = which we may want to include in OC-OLR. Let me give another possible = example. >> As of now, the OC-OLR can indicate application + host/realm level = "required-reduction-percentage". >> However, for the given application (e.g. Gx) we may want to define a = narrower scope with "session-type =3D {M2M, Others}" AVP. So basically, = the Gx nodes can advertise different "required-reduction-percentage" for = M2M sessions v/s other type of sessions for the same application Gx and = for the same destination-host. >>=20 >> So in general, if any application needs to define a different (i.e. = narrower) scope than application + host/realm, it can do so by adding a = new AVP in OC-OLR. >> And then we might have two instances of OC-OLR from the same host. >>=20 >> We could achieve the above by defining new Report-Type for each new = AVP added by each application. But would this scale or is this a = reasonable approach? >> I am not sure and you have already identified one of my concerns = below >>> if we extend ReportType, does it need to be done by IETF, or could = it be done per application by 3GPP? >>=20 >> In summary, in my view, we need to define the handling of multiple = instances with the same Report-Type as part of the DOIC draft. Or we say = that multiple instances with the same Report-Type is not allowed - this = seems unnecessary restriction to me. >> Otherwise, if later, we realize the need to do so then we may not be = able to do so since the handling is not defined in the base solution. >>=20 >> Regards, >> Nirav. >>=20 >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Maria Cruz=20 >> Bartolome >> Sent: Tuesday, December 03, 2013 1:57 PM >> To: dime@ietf.org >> Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the = same=20 >> type) within a response message >>=20 >> Nirav, >>=20 >> I think I understand your concern. It may occur that we need that a = reacting node should apply two different OLR when sending a request = towards one specific host. >> Then, we may think that we need two different OLRs with = ReportType=3Dhost, and one of them includes the extra info (AVPs) = required for that application, I think this is your interpretation, but. = we can as well consider a new ReportType=3DapplicX_ReportY, that may = apply e.g. for any request send to this application, or just for this = application+host, and then Host could be another AVP to be included in = the OLR, or we could define expected behaviour when defining this new = ReportType. >>=20 >> Would this cover your concerns? If not, could you try to provide an = example that requires two OLR with ReportType=3Dhost? >>=20 >> A part from that, a question for all, if we extend ReportType, does = it need to be done by IETF, or could it be done per application by 3GPP? >>=20 >> Thanks >> /MCruz >>=20 >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Nirav Salot=20 >> (nsalot) >> Sent: jueves, 28 de noviembre de 2013 17:11 >> To: lionel.morand@orange.com >> Cc: dime@ietf.org >> Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the = same=20 >> type) within a response message >>=20 >> Hi Lionel, >>=20 >> I am not sure if defining new ReportType for every new AVP 3GPP would = add for a specific application would be a good solution. >> I thought ReportType would indicate if the corresponding OC-OLR = should be used while sending the traffic towards the host or towards the = realm. >> So from that point of view, all the OC-OLR generated by the server = should have ReportType=3Dhost. i.e. when the reacting node sends the = traffic towards that host, it should make use of the corresponding = OC-OLR. Now, this OC-OLR may contain the AVPs defined by DOIC draft as = well as 3GPP application specific AVPs. >>=20 >> In general, I was just thinking that it may be good idea to define = some of the principles such as >> - More than one instances of OC-OLR with ReportType=3Dhost = may be present in the answer message if the OC-OLR definition is = extended by the application using the same. In that case, it is the = responsibility of the application to define the valid combination of = OC-OLR instances in a given message >> - If the reporting node includes more than one instance of = OC-OLR, the reporting node shall always include all the active instances = of OC-OLR in a response message. >> - When the reacting node receives one or more instances of = OC-OLR with the given ReportType and with new timestamp value, it should = overwrite all the existing OC-OLR of the same ReportType. >>=20 >> Regards, >> Nirav. >>=20 >> From: lionel.morand@orange.com [mailto:lionel.morand@orange.com] >> Sent: Thursday, November 28, 2013 7:39 PM >> To: Nirav Salot (nsalot) >> Cc: dime@ietf.org >> Subject: RE: DOIC: Multiple instance of OC-OLR AVP (of the same type)=20= >> within a response message >>=20 >> Hi Nirav, >>=20 >> The Report Type should be able to differentiate such cases. In your = example, I would define a specific Report type. >> But difficult to appraise all the future use cases. But for me, the = main use of the report type is to differentiate OC-OLR received in the = same message. >> And it is the reasons of my recommendation. Actually, the exact = wording will be a "SHOULD" saying that it is recommended but you may = have serious reasons to do otherwise. >>=20 >> Lionel >>=20 >> De : Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Envoy=E9 : jeudi = 28=20 >> novembre 2013 13:00 =C0 : MORAND Lionel IMT/OLN Cc : dime@ietf.org = Objet=20 >> : RE: DOIC: Multiple instance of OC-OLR AVP (of the same type) within=20= >> a response message >>=20 >> Lionel, >>=20 >> 3gpp may define an optional avp which can be included by the = reporting node if it wishes to do so. E.g. APN can be additionally = included by the reporting node to indicate APN specific overload within = the given application. >> In that case, the reporting node may also want to indicate = application level overload without including the APN (e.g. this overload = report is applicable to all other APNs). >>=20 >> And hence there is a possibility of including multiple instances of = the overload report. >>=20 >> I am not suggesting that 3gpp will define APN (or any other avp) = within overload report. But later, if 3gpp need to define the same, then = corresponding handling needs to be defined within IETF now. >>=20 >> Regards, >> Nirav. >>=20 >> On Nov 28, 2013 3:56 PM, "lionel.morand@orange.com" = wrote: >> Hi Nirav, >>=20 >> Not sure to understand the proposal or question. >> The OLR is significant per application (piggybacking principle). So = if the 3GPP decides to add specific AVPs in the OLR (that will be = possible), what would be the need to add the OLR without the specific = 3GPP AVPs as the OLR will be anyway handle by 3GPP aware entities? >>=20 >> Lionel >>=20 >> De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot=20 >> (nsalot) Envoy=E9 : jeudi 28 novembre 2013 10:33 =C0 : dime@ietf.org = Objet=20 >> : [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same type)=20 >> within a response message >>=20 >> Hi, >>=20 >> As I understand IETF will define the base overload control solution = as part of DOIC. Then 3GPP would adopt the defined solution for each of = its application. >> When that happens, 3GPP might want to add 3GPP specific AVP within = OC-OLR AVP. Based on the current definition of the OC-OLR AVP this = should be allowed since it contains "* [AVP]" in its definition. >> e.g. for a given application 3GPP decides to add information into = OC-OLR which changes the scope of the OC-OLR from application level to = the provided information level. >> Additionally, the reporting may want to advertise the OC-OLR at the = application level scope - i.e. the OC-OLR without any 3GPP specific = info. >>=20 >> So if the above is allowed, we will have the possibility of the = reporting node wanting to include two instances of OC-OLR with the = Report-Type=3D"host". >> And then we need to define the handling of multiple instances of = OC-OLR in the DOIC draft. >>=20 >> So the questions are, >> - Is 3GPP (or any other SDO) allowed to extend the = definition of OC-OLR by adding information into it? >> - If no, can we guarantee that application level scope of = OC-OLR (which is what we have defined currently) is sufficient (and not = restricting) to all the applications of 3GPP? >>=20 >> Regards, >> Nirav. >>=20 >> = ______________________________________________________________________ >> ___________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations=20 >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20= >> exploites ou copies sans autorisation. Si vous avez recu ce message=20= >> 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. >>=20 >> This message and its attachments may contain confidential or=20 >> 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. >> = ______________________________________________________________________ >> ___________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations=20 >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20= >> exploites ou copies sans autorisation. Si vous avez recu ce message=20= >> 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. >>=20 >> This message and its attachments may contain confidential or=20 >> 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. >> = ______________________________________________________________________ >> ___________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations=20 >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20= >> exploites ou copies sans autorisation. Si vous avez recu ce message=20= >> 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. >>=20 >> This message and its attachments may contain confidential or=20 >> 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. >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >=20 From jouni.nospam@gmail.com Mon Dec 9 01:15:18 2013 Return-Path: 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 ; 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 ; 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 ; Mon, 9 Dec 2013 01:15:15 -0800 (PST) Received: by mail-la0-f47.google.com with SMTP id ep20so1321802lab.6 for ; 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 (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 In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681519DD4D@DEMUMBX014.nsn-intra.net> Date: Mon, 9 Dec 2013 11:15:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5BCBA1FC2B7F0B4C9D935572D90006681519DCBC@DEMUMBX014.nsn-intra.net> <6950EE6B-689E-47A1-88AA-1A67C47BC82E@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519DD4D@DEMUMBX014.nsn-intra.net> To: "Wiehe, Ulrich (NSN - DE/Munich)" X-Mailer: Apple Mail (2.1510) Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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)" = wrote: > Hi Jouni, >=20 > 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. =46rom 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 >=20 > Best regards > Ulrich >=20 > -----Original Message----- > From: ext Jouni [mailto:jouni.nospam@gmail.com]=20 > 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 >=20 >=20 > On Dec 6, 2013, at 2:10 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >=20 >> Dear all, >>=20 >> here are comments to clause 4.6: >>=20 >> 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. =20 >=20 > 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. >=20 > 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=20 > spec) >=20 > Other than those, IMHO, are just repackaging the issue into different = form. >=20 >=20 > - Jouni >=20 >> 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: >>=20 >> 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=20 >> c) The request command's Destination-Host matches the Origin-Host of = the OC-Report-Type AVP's encapsulating answer command >>=20 >> For a realm report-type the overload treatment should apply to all = request commands for which >> a) and >> d) The request command's Destination-Host is absent and=20 >> e) The request command's Destination Realm matches the Origin-Realm = of the OC-Report-Type AVP's encapsulating answer command. >>=20 >> The proposal now is to assign individual bits of the Unsinged64 type = to a), b), c), d), and e): >>=20 >> Proposed text: >> 4.6 OC-Report-Type AVP >>=20 >> 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. >>=20 >> The following characteristics are defined in this document: >>=20 >> APPLICATION_ID_MATCH (0x0000000000000001) >>=20 >> 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. >>=20 >> DESTINATION_HOST_PRESENT (0x0000000000000002) >>=20 >> 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. >>=20 >> DESTINATION_HOST_MATCH (0x0000000000000004) >>=20 >> 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. >>=20 >> DESTINATION_HOST_ABSENT (0x0000000000000008) >>=20 >> 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. >>=20 >> DESTINATION_REALM_MATCH (0x0000000000000010) >>=20 >> 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. >>=20 >> Combinations other than=20 >> 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. >>=20 >>=20 >>=20 >>=20 >> 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. >>=20 >> ORIGIN_HOST_MATCH (0x0000000000000020) >>=20 >> 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. >>=20 >> 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 >>=20 >> Another potential extension is Diameter Agent Overload. To address = this, a new value would be needed e.g. >>=20 >> NEXT_HOP_MATCH (0x0000000000000040) >>=20 >> 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. >>=20 >>=20 >> Best regards >> Ulrich >>=20 >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >=20 From ulrich.wiehe@nsn.com Mon Dec 9 01:33:21 2013 Return-Path: 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 9F4A71AE156 for ; Mon, 9 Dec 2013 01:33:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MANGLED_LIST=2.3, 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 MuLmVscM-pkn for ; Mon, 9 Dec 2013 01:33:18 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 2A5811AE092 for ; Mon, 9 Dec 2013 01:33:17 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rB99XAOA032411 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 9 Dec 2013 10:33:10 +0100 Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rB99X9Ss017035 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 9 Dec 2013 10:33:10 +0100 Received: from DEMUHTC011.nsn-intra.net (10.159.42.42) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 9 Dec 2013 10:33:09 +0100 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.152]) by DEMUHTC011.nsn-intra.net ([10.159.42.42]) with mapi id 14.03.0123.003; Mon, 9 Dec 2013 10:33:09 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: "dime@ietf.org" Thread-Topic: OVLI: comments to 5.3.2 Thread-Index: Ac70wauBU5OlawLjTzGjBpbbgzQqTw== Date: Mon, 9 Dec 2013 09:33:08 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519DF07@DEMUMBX014.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.112] Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D90006681519DF07DEMUMBX014nsnin_" 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: 4152 X-purgate-ID: 151667::1386581591-00002466-873B24B9/0-0/0-0 Subject: [Dime] OVLI: comments to 5.3.2 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 09:33:21 -0000 --_000_5BCBA1FC2B7F0B4C9D935572D90006681519DF07DEMUMBX014nsnin_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, here are comments to clause 5.3.2: 1. 1st sentence: The request message initiating node is always the client b= ut is not necessarily the reacting endpoint. Proposal is to modify the firs= t sentence as follows: When a remote endpoint (i.e. a "reporting node") receives a request message in can detect whether the client or any other downstream Diameter node has support for the overload control solution based on the presence of the OC-Feature-Vector AVP. 2. 3rd sentence: OC-Feature-Vector AVP can be present in request and in ans= wer messages. The actual text here should only refer to OC-Feature-Vector A= VP as received in the request message. Furthermore the reporting node is no= t necessarily the node that initiated the answer. Proposal is to modify the= sentence as follows: Based on the content of the received OC-Feature-Vector AVP the request message receiving endpoint knows what overload control functionality the other endpoint supports and then act accordingly for the subsequent answer message it returns. Best regards Ulrich --_000_5BCBA1FC2B7F0B4C9D935572D90006681519DF07DEMUMBX014nsnin_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear all,
 
here are comments to clause 5.3.2:
 
1. 1st sentence: The request message initiating node is always the cli= ent but is not necessarily the reacting endpoint. Proposal is to modify the= first sentence as follows:
 
   When a remote endpoint (i.e. a "reporting node"= ) receives a request
   message in can detect whether the client or any other downstream
   Diameter node has support for the overload control solution based
   on the presence of the OC-Feature-Vector AVP. 
 
2. 3rd sentence: OC-Feature-Vector AVP can be present in request and in = answer messages. The actual text here should only refer to OC-Feature-Vecto= r AVP as received in the request message. Furthermore the reporting node is not necessarily the node that initiated t= he answer. Proposal is to modify the sentence as follows:
 
 
=    Based on the content of the received OC-Feature-Vector AVP the
=    request message receiving endpoint knows what overload control=
=    functionality the other endpoint supports and then act accordi= ngly
=    for the subsequent answer message it returns. 
 
 
 
Best regards
Ulrich
 
 
 
 --_000_5BCBA1FC2B7F0B4C9D935572D90006681519DF07DEMUMBX014nsnin_-- From susan.shishufeng@huawei.com Mon Dec 9 01:51:37 2013 Return-Path: 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 27DA11A1F48 for ; Mon, 9 Dec 2013 01:51:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.801 X-Spam-Level: X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 467xOf3jjH5X for ; Mon, 9 Dec 2013 01:51:23 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E3BD71ADBF7 for ; Mon, 9 Dec 2013 01:51:20 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBD89710; Mon, 09 Dec 2013 09:51:15 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 9 Dec 2013 09:51:09 +0000 Received: from SZXEMA408-HUB.china.huawei.com (10.82.72.40) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 9 Dec 2013 09:51:12 +0000 Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.155]) by SZXEMA408-HUB.china.huawei.com ([10.82.72.40]) with mapi id 14.03.0158.001; Mon, 9 Dec 2013 17:51:04 +0800 From: "Shishufeng (Susan)" To: "Nirav Salot (nsalot)" , Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] DOIC: Self-Contained OLRs Thread-Index: AQHO8cJSot3HeYq6iU+vru+Aq+dgEZpLoYvQ Date: Mon, 9 Dec 2013 09:51:03 +0000 Message-ID: <26C84DFD55BC3040A45BF70926E55F2587C1C7D8@SZXEMA512-MBX.china.huawei.com> References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D90006681519BD31@DEMUMBX014.nsn-intra.net> <47383DC2-1A1B-4D1A-ADD5-9E3CE60B06C8@gmail.com> <8467_1385735507_5298A553_8467_17054_3_6B7134B31289DC4FAF731D844122B36E309D0D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <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> <52A07A1E.5060502@usdonovans.com> <20040_1386250088_52A07F68_20040_916_1_6B7134B31289DC4FAF731D844122B36E32B0E9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52A084FA.7000803@usdonovans.com> In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.146.62.57] Content-Type: multipart/alternative; boundary="_000_26C84DFD55BC3040A45BF70926E55F2587C1C7D8SZXEMA512MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 09:51:37 -0000 --_000_26C84DFD55BC3040A45BF70926E55F2587C1C7D8SZXEMA512MBXchi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello all, I'm trying to follow up all these discussions. Firstly quick answer to Steve's following question, "Strongly No" to have s= elf-contained OC-OLR. Apart from that I agree with the arguments from Nirav= and Lionel, it is not needed anyway at this stage. Extension is allowed an= d can be defined if needed in the future. I don't even see the need to have= the report-type for 3GPP applications usage if considering the realm in 3G= PP is with PLMN granularity, but I'm not going to kick off again the discus= sion on it. I could live with it as an optional AVP and the OC-OLR applies = to the Origin-Host of the Answer when the report type is absent, exactly as= what Lionel suggested. I'll come up with other threads. Best Regards, Susan From: Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Sent: Thursday, December 05, 2013 10:00 PM To: Steve Donovan; dime@ietf.org Subject: Re: [Dime] DOIC: Self-Contained OLRs Steve, > If we are to pose a question at this point I would suggest -- Can everyon= e live with self-contained overload reports? Strongly NO. I can make the same arguments as you are making - "I have yet to see a sing= le STRONG argument to justify the use of self-contained OC-OLR". All the arguments related to software layering, easy for the developers etc= . are very specific to the implementation and I don't agree to define proto= col solution suitable to a specific architecture. Regards, Nirav. From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: Thursday, December 05, 2013 7:22 PM To: dime@ietf.org Subject: Re: [Dime] DOIC: Self-Contained OLRs Lionel, I strongly disagree with your conclusion that there is little support for s= elf-contained OLRs. I also object to your assessment that there are strong arguments against se= lf-contained reports. I have yet to see a single STRONG argument. I also object to your attempting to call the question at this point in the = discussion. The only arguments I see for the implicit approach is complexity, which I j= ust sent an email refuting and schedule, about which I also just sent an em= ail. Self contained reports work just as well and has advantages both short term= in support for non application specific software layering and in the long = term in allowing for the same overload report to be transported using multi= ple DOC solutions. I also don't agree that this has been a particularly long thread. There ar= e multiple topics being discussed under the same subject line. If we are to pose a question at this point I would suggest -- Can everyone = live with self-contained overload reports? Steve On 12/5/13 7:28 AM, lionel.morand@orange.com wrote: All, After this LONG thread, it seems that there are strong arguments against th= e self-contained OLRs and little support. In the contrary, it seems that the principle of OLR related to the applicat= ion in use is technically OK for everyone. So the question is quite simple: Could everyone live/survive with the "implicit approach" with the extensibi= lity mechanism allowing future extensions if needed? If yes, please focus on the finalization of the current draft. If no, let go on the discussion. Regards, Lionel De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan Envoy=E9 : jeudi 5 d=E9cembre 2013 14:06 =C0 : dime@ietf.org Objet : Re: [Dime] DOIC: Self-Contained OLRs On the schedule question mentioned by JJacques -- any schedule concerns can= go away if everyone agrees to self contained overload reports. This discu= ssion would end and we could move on to other things. :-) I say that somewhat in jest but please don't make the argument that this di= scussion should be ended because of schedule. Or if you make that argument= , please don't assert that the person who disagrees with you is putting the= schedule at risk. We are striving for the best technical solution. We all understand the sch= edule pressures. We need to balance the two. Steve On 12/5/13 5:14 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote: Hi A lot of mails on this topic...I would suggest to introduce an overload con= trol on the Dime email threads:) On my side, I rely on what we have written in the draft for the "baseline"= mechanism and that we have to keep as it is simple and efficient, here I j= oin Lionel, Nirav and MCruz' positions. This thread then addresses extensions cases, I agree that we will have to = address such extensions: Nirav mentioned the example with APN that if rel= evant would a 3GGP application case, I would add the Session Group about w= hich we had some discussion a while ago and which is a more generic IETF c= ase. There is also the agent overload case. Have you others? Always good to= have some use cases in mind. What is important for me is that adding extensions should not modify the ba= seline and making it more complex when used alone. I also make a differenc= e between principles and protocol tuning where we may have to choose betwee= n various protocol solution but addressing the same functionality or princi= ple. About piggybacking, in the baseline, the principle is that OLRs which ar= e addressed to sources of traffic are put in answer messages towards this = traffic sources (origin Host) (even if these messages may be processed by = intermediate DAs), which is simple and the OLR can be kept unchanged in the= same message up to the origin Host if no specific process in intermediate= DAs. To have a piggybacking allowing to put any OLR in any message (as it= was in draft roach) is adding complexity that is not justified for the ba= seline and we have not retained it in the existing draft . About extensions, the APN or session group examples address parts of the = traffic between a server and a client (so a higher granularity in the throt= tling than the baseline one), related OLRs are conveyed in the messages tow= ards the origin Host so with an implicit reference to the Application, the = Origin and Destination Host as for the baseline, so not requiring self con= tained OLRs. I also do not see the interest to send these new extensions O= LR only in answers directly related to this OLR (as Ulrich proposed), eg on= ly in an answer dealing with an APN if the OLR is related to APN throttling= . The main point is that the OLR takes a direct "train" towards the right = destination for a given application (as for baseline). This does not exclude that we may have other cases not entering the above e= xamples characteristics, but as Nirav mentioned, we have to remain pragmat= ic and see this when such new use cases will be addressed. The extensibilit= y possibilities of current draft give us a lot of flexibility, e.g. if som= e extensions need more self contained AVPs, why not, but this is outside th= e current draft. About extensions, I also think that they may need to be identified in the c= apability part, as the related OLRs should not be sent by a reacting node i= f the extension is not supported. Last important point, as Lionel mentioned, we have to finalize the draft s= oon, to be able to start Rel12 3GGP work relying on this draft. My position= is that the current draft is currently well suited for the baseline and th= at extensions will be addressed separately Best regards JJacques -----Message d'origine----- De : DiME [mailto:dime-bounces@ietf.org] De la part de Ben Campbell Envoy=E9 : mercredi 4 d=E9cembre 2013 22:55 =C0 : ext lionel.morand@orange.com Cc : dime@ietf.org Objet : Re: [Dime] DOIC: Self-Contained OLRs On Dec 3, 2013, at 5:17 PM, lionel.morand@orange.com wrote: Hi Ben, I may be wrong somewhere in my summary but I think that it was the result o= f the discussions and agreements reached regarding existing requirements, a= t least from 3GPP point of view, compared to possible optimizations for fut= ure optimizations not so obvious. We are not the 3GPP. Our requirements are RFC 7068. I believe self-containe= d OLRs do a better job of meeting Req 31 than the contextually-defined OLRs= . I've made several technical arguments here--does anyone have _technical_ ar= guments in favor of contextually-defined OLRs? And because the solution offers extensibility via the definition of new alg= o, new report type and addition of any new AVP in the existing Grouped OLR,= the "limitations" of the proposed solution might be removed by someone if = really required according to new requirements. It might be worth considering a compromise approach: Define _optional_ AVPs= that allow an OLR to be self-contained. If they are not present, then the = various values default to those from the enclosing Diameter message. Possib= ly add support for this to the list of things that reacting nodes can adver= tise. This could be in the base, or in a follow on extension. (If left for an ext= ension, it's worth considering whether ReportType needs to be in the base, = or this or some other extension.) Regards, Lionel -----Message d'origine----- De : Ben Campbell [mailto:ben@nostrum.com] Envoy=E9 : mardi 3 d=E9cembre 2013 23:56 =C0 : MORAND Lionel IMT/OLN Cc : Steve Donovan; dime@ietf.org Objet : Re: [Dime] DOIC: Self-Contained OLRs On Dec 2, 2013, at 10:18 AM, lionel.morand@orange.com wrote: Hi Steve, I think that is not only about few bytes in the answer. It is also about th= e solution principles agreed so far: =B7 the current need is for an OLR bound to the application in use =B7 the OLR is received from the node targeted in the request. =B7 the OLR is defined per application I don't think those principles have been well tested. I don't recall any di= scussion of their benefits. What benefits do you see they have over self-co= ntained OLRs? All I see from these are restrictions in the flexibility of the solution, w= ith very little in return. So all the implicit information (application, origin-host, origin-realm) ar= e meaningful in this context. And the actual solution is designed based on these assumptions. The extensi= bility of the solution will allow extra info if required in other use cases= but it was agreed to go with a straightforward solution that will satisfy = most of us. Regards, Lionel De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan Envoy=E9 : lundi 2 d=E9cembre 2013 16:37 =C0 : dime@ietf.org Objet : Re: [Dime] DOIC: Self-Contained OLRs I don't believe that Ben's proposal was to change the piggybacking assumpti= on in the baseline mechanism. Ben's proposal is to design the solution in = such a way that it is not dependent on the piggybacking transport mechanism= . I share Ben's concern that we have over optimized the content of the overlo= ad report in a way that makes implementations brittle, interoperability mor= e difficult to achieve and extensibility more complex. And what do we gain= from this optimization? A few bites in answer messages. Self contained overload reports, transported using the piggybacking mechani= sm, is a cleaner solution. Steve On 11/29/13 8:31 AM, lionel.morand@orange.com wrote: I totally agree with Nirav. No need to revert at this stage the working ass= umption on piggybacking of OLR in application answer messages, especially w= hen the aim is to define a basic mechanism called "reduction". Anyone would be able to further add extra info for optimization if needed b= ut there is no need at all for the basic mechanism. Regards, Lionel -----Message d'origine----- De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot (nsalot) Envoy=E9 : vendredi 29 novembre 2013 12:24 =C0 : Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list Cc : Ben Campbell Objet : Re: [Dime] DOIC: Self-Contained OLRs Jouni, Ben, I am totally against the idea of self-contained OC-OLR specifically since w= e have adopted the principles of piggybacking the OC-OLR over existing appl= ication message. Self-contained OC-OLR - which means adding all the information which define= s the scope of the OC-OLR into the OC-OLR - does not make sense in the pigg= ybacking approach. In fact, it is adding lot of information, which is anywa= y available within the message containing the OC-OLR, into the OC-OLR. So i= t is adding lot of redundant information in a message which increases the p= rocessing requirement for the sender as well as the receiver. (And this is = un-optimization, in my view). Besides, I am not convinced with the other reasons provided here: - One software module within a node can provide OC-OLR to another software = module in the same node without passing other related info Within a node, based on the design, lots of information may need to be pa= ssed between two software modules and we cannot optimize those aspects by r= eplicating unnecessary information in a protocol message. In summary, it is node's internal software design issue and we need not o= ptimize that at protocol level. - Once the reporting node realizes that it is overloaded, it has to wait fo= r right answer to send OC-OLR What is the point of sending OC-OLR for a context for which there is no me= ssaging? Why should the reacting node care if it never sends a message for = a context for which the reporting node is overloaded? So this waiting is justified since it ensures that the overload is reporte= d only when necessary and only to the applicable reacting node. Not to all = the nodes in the network. - The agent needs to wait for the answer generated by the server and the ri= ght context The same argument as applicable for the server applies here. The agent ne= ed not send out-of-context overload info to a node. Why should reacting node receive/process/store the overload info for the = scope for which it is not sending any messages. - For sending OC-OLR in dedicated Diameter application??? Piggybacking was the first basic principle we agreed before putting other = principles in place. So we may want to go back the drawing board if we deci= de to change this principle. Regards, Nirav. -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen Sent: Friday, November 29, 2013 2:50 PM To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org li= st Cc: Ben Campbell Subject: Re: [Dime] DOIC: Self-Contained OLRs So, are we reaching any level of consensus here? - JOuni (as a note.. that we are converging back to where we started with OLRs ;) On Nov 28, 2013, at 12:40 PM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: Hi, another question: If we go for explicit self contained OLRs, why would we then need the Repor= tType? The realm-type OLR would explicitly contain application-Id, Realm, but no H= ost whereas the host-type OLR would explicitly contain application-Id, Host= , but probably (I'm not sure) no Realm. 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 stat= us. It could be provided an agent inserting this info in answers received f= rom a server behind but also from a server that would know this info by som= e internal magic. But in any case, if we assume that the client will received a successful an= swer from the server for an initial request with only Dest-Realm AVP, it sh= ould be possible to have both report types in the answer: one for the serve= r itself, one for the realm for new request sent to the realm with only Des= t-Realm AVP. Lionel -----Message d'origine----- De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN - DE/Munich) Envoy=E9 : jeudi 28 novembre 2013 10:26 =C0 : 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 a= ligned with the "endpoint principle". If the ReportType is "realm" this ind= icates 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 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 re= acting 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 Diamet= er request that corresponds to the answer containing the OLR. My reasons fo= r 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 i= dentified by Origin-Realm, and so on. This means that the "meaning" of an O= LR 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 answe= r to another, it's meaning may change completely. I think this approach is a mistake. I would greatly prefer that we explicit= ly 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 variou= s other AVPs to find all the information it needs. For example, I think a c= ommon software design for overload control processing to be separated from = application processing. The consumer cannot simply hand the OLR to that mod= ule and expect things to work. The OC module must not only parse the OLR, b= ut parse any other AVPs that are relevant. As OLR contents get extended (as= sumedly following the same strategy as the base spec), the number of "conte= xt" avps that must be interpreted can grow large. This approach is error pr= one, and will likely encourage brittle, hard-to-maintain code. Self-contain= ed OLRs would keep all the information related to overload in one place. ma= king for simpler implementations. 2) It's more complex for the reporting node to send implicit values than ex= plicit values. The sender cannot simply set the context to match the OLR--a= ll those other AVPs have application or protocol layer meanings. Once a rep= orting node realizes that it is overloade, it has to wait for the right ans= wer that contains the right context before it can send the OLR. This is par= ticularly 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 sig= nificantly. 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 so= me 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 overlo= ad reports were self-contained, one could just reuse the report format we s= pecify here. But if the meaning of an OLR depends on the way it's transport= ed, this won't work. We would have to create a new or significantly modifie= d OLR format if we found a need to transport OLRs in different ways. Self-c= ontained OLRs would allow much greater flexibility. So, in summary, I think that self-contained OLRs would lead to simpler impl= ementations, less brittle deployments, and more flexibility for future evol= ution 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 le= s pieces jointes. Les messages electroniques etant susceptibles d'alteratio= n, 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 dis= tributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te 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 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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 confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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 confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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 confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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 --_000_26C84DFD55BC3040A45BF70926E55F2587C1C7D8SZXEMA512MBXchi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable --_000_26C84DFD55BC3040A45BF70926E55F2587C1C7D8SZXEMA512MBXchi_-- From susan.shishufeng@huawei.com Mon Dec 9 02:13:18 2013 Return-Path: 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 8AA1B1AE092 for ; Mon, 9 Dec 2013 02:13:18 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 Z-y2re-g01RU for ; Mon, 9 Dec 2013 02:13:14 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 240E61AD9AB for ; Mon, 9 Dec 2013 02:13:13 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYT66781; Mon, 09 Dec 2013 10:13:08 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 9 Dec 2013 10:13:03 +0000 Received: from SZXEMA407-HUB.china.huawei.com (10.82.72.39) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 9 Dec 2013 10:13:06 +0000 Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.155]) by SZXEMA407-HUB.china.huawei.com ([10.82.72.39]) with mapi id 14.03.0158.001; Mon, 9 Dec 2013 18:12:58 +0800 From: "Shishufeng (Susan)" To: "Nirav Salot (nsalot)" , "lionel.morand@orange.com" Thread-Topic: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same type) within a response message Thread-Index: AQHO7DRyp0pKDS+VfEyygMMnybAXTZpLsyOA Date: Mon, 9 Dec 2013 10:12:57 +0000 Message-ID: <26C84DFD55BC3040A45BF70926E55F2587C1D016@SZXEMA512-MBX.china.huawei.com> References: , <2901_1385634414_52971A6E_2901_2686_1_6B7134B31289DC4FAF731D844122B36E307743@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.146.62.57] Content-Type: multipart/alternative; boundary="_000_26C84DFD55BC3040A45BF70926E55F2587C1D016SZXEMA512MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "dime@ietf.org" Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same type) within a response message X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 10:13:18 -0000 --_000_26C84DFD55BC3040A45BF70926E55F2587C1D016SZXEMA512MBXchi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Nirav, For now, I couldn't see the need to have more than one instance of the over= load report with the same report-type, i.e. host or realm. But to allow ext= ensibility if needed in the future, whether some texts can be written in th= e IETF e.g. Multiple OC-OLR AVPs exist with different report types, if it i= s not the case, it is the application where multiple OC-OLR AVPs are allowe= d with the same report type to specify the details how to differentiate the= information contained in these OC-OLR AVPs. Thus we can move on without ha= ving to addressing the issue now in the base solution. Best Regards, Susan From: Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Sent: Thursday, November 28, 2013 8:00 PM To: lionel.morand@orange.com Cc: dime@ietf.org Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same type= ) within a response message Lionel, 3gpp may define an optional avp which can be included by the reporting node= if it wishes to do so. E.g. APN can be additionally included by the report= ing node to indicate APN specific overload within the given application. In that case, the reporting node may also want to indicate application leve= l overload without including the APN (e.g. this overload report is applicab= le to all other APNs). And hence there is a possibility of including multiple instances of the ove= rload report. I am not suggesting that 3gpp will define APN (or any other avp) within ove= rload report. But later, if 3gpp need to define the same, then correspondin= g handling needs to be defined within IETF now. Regards, Nirav. On Nov 28, 2013 3:56 PM, "lionel.morand@orange.com" > wrote= : Hi Nirav, Not sure to understand the proposal or question. The OLR is significant per application (piggybacking principle). So if the = 3GPP decides to add specific AVPs in the OLR (that will be possible), what = would be the need to add the OLR without the specific 3GPP AVPs as the OLR = will be anyway handle by 3GPP aware entities? Lionel De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot (nsalot) Envoy=E9 : jeudi 28 novembre 2013 10:33 =C0 : dime@ietf.org Objet : [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same type) wit= hin a response message Hi, As I understand IETF will define the base overload control solution as part= of DOIC. Then 3GPP would adopt the defined solution for each of its applic= ation. When that happens, 3GPP might want to add 3GPP specific AVP within OC-OLR A= VP. Based on the current definition of the OC-OLR AVP this should be allowe= d since it contains "* [AVP]" in its definition. e.g. for a given application 3GPP decides to add information into OC-OLR wh= ich changes the scope of the OC-OLR from application level to the provided = information level. Additionally, the reporting may want to advertise the OC-OLR at the applica= tion level scope - i.e. the OC-OLR without any 3GPP specific info. So if the above is allowed, we will have the possibility of the reporting n= ode wanting to include two instances of OC-OLR with the Report-Type=3D"host= ". And then we need to define the handling of multiple instances of OC-OLR in = the DOIC draft. So the questions are, - Is 3GPP (or any other SDO) allowed to extend the definition of O= C-OLR by adding information into it? - If no, can we guarantee that application level scope of OC-OLR (= which is what we have defined currently) is sufficient (and not restricting= ) to all the applications of 3GPP? Regards, Nirav. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. --_000_26C84DFD55BC3040A45BF70926E55F2587C1D016SZXEMA512MBXchi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Nirav,

 

For now, I couldn’t see the need to have more than one inst= ance of the overload report with the same report-type, i.e. host or realm. = But to allow extensibility if needed in the future, whether some texts can be written in the IETF e.g. Multiple OC-OLR= AVPs exist with different report types, if it is not the case, it is the a= pplication where multiple OC-OLR AVPs are allowed with the same report type= to specify the details how to differentiate the information contained in these OC-OLR AVPs. Thus we can move on withou= t having to addressing the issue now in the base solution.

 

Best Regards,

Susan

 

From: Nirav Salot (nsalot) [mailto:nsalot@cisco.com]
Sent: Thursday, November 28, 2013 8:00 PM
To: lionel.morand@orange.com
Cc: dime@ietf.org
Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the sa= me type) within a response message

 

Lionel,

3gpp may define an optional avp which can be included = by the reporting node if it wishes to do so. E.g. APN can be additionally i= ncluded by the reporting node to indicate APN specific overload within the = given application.
In that case, the reporting node may also want to indicate application leve= l overload without including the APN (e.g. this overload report is applicab= le to all other APNs).

And hence there is a possibility of including multiple= instances of the overload report.

I am not suggesting that 3gpp will define APN (or any = other avp) within overload report. But later, if 3gpp need to define the sa= me, then corresponding handling needs to be defined within IETF now.

Regards,
Nirav.

On Nov 28, 2013 3:56 PM,= "lionel.morand@orange.com= " <lionel.morand@or= ange.com> wrote:

Hi Nirav,<= /span>

 

Not sur= e to understand the proposal or question.

The OLR= is significant per application (piggybacking principle). So if the 3GPP de= cides to add specific AVPs in the OLR (that will be possible), what would b= e the need to add the OLR without the specific 3GPP AVPs as the OLR will be anyway handle by 3GPP aware entities= ?

 <= /span>

Lionel =

 <= /span>

De : DiME [mailto:d= ime-bounces@ietf.org] De la part de Nirav Salot (nsalot)
Envoy=E9 : jeudi 28 novembre 2013 10:33
=C0 : dime@ietf.org
Objet : [Dime] DOIC: Multiple instance of OC-OLR AVP (of the sa= me type) within a response message

 

Hi,

 =

As I understand IETF will defin= e the base overload control solution as part of DOIC. Then 3GPP would adopt= the defined solution for each of its application.=

When that happens, 3GPP might w= ant to add 3GPP specific AVP within OC-OLR AVP. Based on the current defini= tion of the OC-OLR AVP this should be allowed since it contains "* [AV= P]" in its definition.

e.g. for a given application 3G= PP decides to add information into OC-OLR which changes the scope of the OC= -OLR from application level to the provided information level.

Additionally, the reporting may= want to advertise the OC-OLR at the application level scope – i.e. t= he OC-OLR without any 3GPP specific info.

 =

So if the above is allowed, we = will have the possibility of the reporting node wanting to include two inst= ances of OC-OLR with the Report-Type=3D"host".

And then we need to define the = handling of multiple instances of OC-OLR in the DOIC draft.

 =

So the questions are,

-     &= nbsp;    Is 3GPP (or any other SDO) allowed to extend th= e definition of OC-OLR by adding information into it?

-     &= nbsp;    If no, can we guarantee that application level = scope of OC-OLR (which is what we have defined currently) is sufficient (an= d not restricting) to all the applications of 3GPP?

 =

Regards,

Nirav.=

 = 

____________________________________________________=
_____________________________________________________________________<=
/o:p>
 
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces j=
ointes. 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 confide=
ntial or privileged information that may be protected by law;
they should not be distributed, used or copied witho=
ut authorisation.
If you have received this email in error, please not=
ify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.
--_000_26C84DFD55BC3040A45BF70926E55F2587C1D016SZXEMA512MBXchi_-- From ulrich.wiehe@nsn.com Mon Dec 9 02:16:45 2013 Return-Path: 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 769B21ADEC4 for ; Mon, 9 Dec 2013 02:16:45 -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 52UzAxnnABMX for ; Mon, 9 Dec 2013 02:16:43 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 055EE1ADBF7 for ; Mon, 9 Dec 2013 02:16:42 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rB9AGa9n006443 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 9 Dec 2013 11:16:36 +0100 Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rB9AGZof007053 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Dec 2013 11:16:35 +0100 Received: from DEMUHTC005.nsn-intra.net (10.159.42.36) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 9 Dec 2013 11:16:35 +0100 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.152]) by DEMUHTC005.nsn-intra.net ([10.159.42.36]) with mapi id 14.03.0123.003; Mon, 9 Dec 2013 11:16:34 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: ext Ben Campbell , Jouni Korhonen Thread-Topic: [Dime] OVLI: comments to 4.1 Thread-Index: Ac7xvTHHIECkLcDwSDuVAh2ACeOasABD0nFyAH3U7yA= Date: Mon, 9 Dec 2013 10:16:35 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519DF3D@DEMUMBX014.nsn-intra.net> References: <5BCBA1FC2B7F0B4C9D935572D90006681519DA3E@DEMUMBX014.nsn-intra.net> <6CDCFC84-3048-40B9-91A4-1451FCC65F60@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.112] Content-Type: text/plain; charset="us-ascii" 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: 2929 X-purgate-ID: 151667::1386584196-000030AF-DED869AC/0-0/0-0 Cc: "dime@ietf.org" Subject: Re: [Dime] OVLI: comments to 4.1 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 10:16:45 -0000 For the OC-Feature-Vector AVP I still think that there is no need for anyth= ing like sequence number or timestamp (for OC-OLR things are different). Including the sender identity of the node that sent the OC-Feature-Vector i= s not needed and would add complexity. Ben wrote: "...the point of having a sequence number here was so that if a reacting-no= de chooses to send the feature vector in every request, the reacting node c= an easily determine if the contents have changed, and ignore it if not..." However, an unchanged Feature-Vector must not be ignored. It is still valid= and the receiving node must honor it. Of course it could instead honor an = identical stored Feature-Vector, but this again adds unnecessary complexity= ("check if the received feature vector has changed, if not take the stored= feature vector otherwise take the received feature vector" rather than "al= ways take the received feature vector"). Ulrich -----Original Message----- From: ext Ben Campbell [mailto:ben@nostrum.com]=20 Sent: Friday, December 06, 2013 10:45 PM To: Jouni Korhonen Cc: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org Subject: Re: [Dime] OVLI: comments to 4.1 On Dec 6, 2013, at 4:17 AM, Jouni Korhonen wrote: [...] >> 3. The OC-Sequence-Number within OC-Feature-Vector only makes sense if t= he receiving reporting endpoint can determine the identity of the reacting = endpoint (which is not necessarily the origin host (client), >=20 > My original proposal was to have seqnr as a timestamp. Some folks argued > it is no good and suggested seqnr. I still think time makes more sense th= an > seqnr. >=20 Whether it's a timestamp, sequence number, or random number, we should desc= ribe the required uniqueness properties. (i.e. unique for that sender, uniq= ue across all senders, unique over a short period of time vs long period of= time, etc.) There may be other reasons to identify who sent the OC-Feature-Vector. Shou= ld we consider including the sender identity? >> it may be an agent and it may not always be the same agent), and if the = reporting endpoint is required to store the OC-Feature-Vector / reacting-en= dpoint-identity pair (which I think both is not required). The reporting en= dpoint can base its processing logic on the actually received OC-Feature-Ve= ctor value, no matter whether it is brand-new or old but stil valid. Propos= al is to delete OC-Sequence-Number AVP from OC-Feature-Vector. >=20 > Do not agree removing it. I concur with Jouni. IIRC, the point of having a sequence number here was s= o that if a reacting-node chooses to send the feature vector in every reque= st, the reacting node can easily determine if the contents have changed, an= d ignore it if not. But it might be reasonable to consider whether that sav= es enough work to make it worth the trouble. [...] From susan.shishufeng@huawei.com Mon Dec 9 02:30:24 2013 Return-Path: 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 7C1441AE249 for ; Mon, 9 Dec 2013 02:30:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 Hjkt-NedaBPl for ; Mon, 9 Dec 2013 02:30:21 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 491221AE207 for ; Mon, 9 Dec 2013 02:30:21 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYT68669; Mon, 09 Dec 2013 10:30:13 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 9 Dec 2013 10:30:07 +0000 Received: from SZXEMA405-HUB.china.huawei.com (10.82.72.37) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 9 Dec 2013 10:30:11 +0000 Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.155]) by SZXEMA405-HUB.china.huawei.com ([10.82.72.37]) with mapi id 14.03.0158.001; Mon, 9 Dec 2013 18:29:59 +0800 From: "Shishufeng (Susan)" To: "Wiehe, Ulrich (NSN - DE/Munich)" , "ext lionel.morand@orange.com" , ext Jouni Korhonen , Ben Campbell Thread-Topic: [Dime] DOIC: Self-Contained OLRs Thread-Index: AQHO7CTaot3HeYq6iU+vru+Aq+dgEZpLuCfw Date: Mon, 9 Dec 2013 10:29:58 +0000 Message-ID: <26C84DFD55BC3040A45BF70926E55F2587C1D028@SZXEMA512-MBX.china.huawei.com> References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D90006681519BC90@DEMUMBX014.nsn-intra.net> <6390_1385631044_52970D44_6390_18593_1_6B7134B31289DC4FAF731D844122B36E30748E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BD19@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681519BD19@DEMUMBX014.nsn-intra.net> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.146.62.57] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "dime@ietf.org list" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 10:30:24 -0000 Hi Ulrich, I have different views. In any case, I think the host-type OLR should not b= e ignored by the clients. On the contrary, the realm-type OLR can be though= t as optimization, which may not even be needed at all for all cases, espec= ially in 3GPP. Here is an example of S6a, in the case the first attach requ= est comes from the UE to the MME, the MME can only derive the realm informa= tion, and sends a request without Destination-Host towards the HPLMN. Since= the subscriber corresponding to the UE belongs to a specific HSS, and the = HSS may provide its overload report to the MME, and the MME is able to know= how to react regarding the requests towards the HSS, which would be the no= rmal case. Whether Realm report will be provided by the HSS or the agent se= rving the HSS is kind of optimization which may help the MME to know how to= react on the requests towards the realm, not specific to the HSS. Best Regards, Susan -----Original Message----- From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 Sent: Thursday, November 28, 2013 6:30 PM To: ext lionel.morand@orange.com; ext Jouni Korhonen; Ben Campbell Cc: dime@ietf.org list Subject: 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 act= ual OLR created by the reporting end point and which OLR is an additional O= LR created by another node. We have two cases: a) The request sent by the client (reacting end point) contains no Destinat= ion Host. The agent (reporting node) (after forwarding the request to the s= elected server and receiving the answer) returns a realm-type OLR as the ac= tual 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 Destinat= ion 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 stat= us. It could be provided an agent inserting this info in answers received f= rom a server behind but also from a server that would know this info by som= e internal magic. But in any case, if we assume that the client will received a successful an= swer from the server for an initial request with only Dest-Realm AVP, it sh= ould be possible to have both report types in the answer: one for the serve= r itself, one for the realm for new request sent to the realm with only Des= t-Realm AVP. Lionel -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN= - DE/Munich) Envoy=E9=A0: jeudi 28 novembre 2013 10:26 =C0=A0: ext Jouni K= orhonen; Ben Campbell Cc=A0: dime@ietf.org list Objet=A0: Re: [Dime] DOIC: = Self-Contained OLRs Hi, I don't see how the possibility to send more than one OLR in an answer is a= ligned with the "endpoint principle". If the ReportType is "realm" this ind= icates 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 wrote: > Hi, >=20 > I mentioned in another thread that I prefer putting an explicit=20 > ReportType AVP in an OLR, rather than The more I spent time thinking/writing the actual procedures on the endpoin= ts, the more it makes sense to me to keep the ReportType in the OC-OLR. Eve= n if the baseline does not have agent overload etc, the ReportType fits wel= l to the "endpoint principle" we have in the draft. It indeed gives more to= ols to make a host vs. realm base decision on the reacting node and is plai= n 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 Diam= eter request that corresponds to the answer containing the OLR. My reasons = for that go beyond just ReportType, so I'm starting a separate thread. >=20 > As currently described, a consumer of an OLR must infer several things fr= om other context. In most cases, that context is in the Diameter answer tha= t carries the OLR. For example, the OLR implicitly refers to the applicatio= n 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 meani= ng in the context of the enclosing answer. If you moved an OLR from one ans= wer to another, it's meaning may change completely. >=20 > I think this approach is a mistake. I would greatly prefer that we explic= itly include such values in the OLR itself, for multiple reasons: >=20 > 1) It's more complex to interpret implicit, contextual values than explic= it values. The consumer cannot simply look at the OLR; it must look in vari= ous other AVPs to find all the information it needs. For example, I think a= common software design for overload control processing to be separated fro= m application processing. The consumer cannot simply hand the OLR to that m= odule 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 "con= text" avps that must be interpreted can grow large. This approach is error = prone, and will likely encourage brittle, hard-to-maintain code. Self-conta= ined OLRs would keep all the information related to overload in one place. = making for simpler implementations. >=20 > 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 r= eporting node realizes that it is overloade, it has to wait for the right a= nswer that contains the right context before it can send the OLR. This is p= articularly troublesome for agents, since they will typically have to inser= t OLRs into answers created by other nodes.=20 >=20 > If the reporting node screws this up, the meaning of the OLR may change s= ignificantly. So again, implicit meaning gives us error prone implementatio= ns. Self-contained OLRs are simpler to create and send. >=20 > 3) Implicit values don't work at all for certain problems. For=20 > example, if an agent needs to originate an OLR, it typically needs to=20 > insert that OLR into an existing Diameter answer created by a server.=20 > It can't create its own answer without affecting the application=20 > state. If the responding node assumes the OLR comes from or refers to=20 > the node identified by the Origin-Host AVP in the enclosing answer,=20 > things break. (For examples of when an agent needs to send OLRs that=20 > are distinct from those sent by a server, see Steve's agent overload=20 > draft, or my dh/dr example.) >=20 > OTOH, explicit values will work for all cases where we need to associate = some arbitrary value with an OLR. >=20 > 4) Implicit values seriously constrain the future evolution of Diameter O= C standards. For example, lets say we find a good reason to allow OLRs to b= e sent out of band, or be sent in a dedicated Diameter application. If over= load 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 transpo= rted, this won't work. We would have to create a new or significantly modif= ied OLR format if we found a need to transport OLRs in different ways. Self= -contained OLRs would allow much greater flexibility. >=20 > So, in summary, I think that self-contained OLRs would lead to simpler im= plementations, less brittle deployments, and more flexibility for future ev= olution of standards. >=20 > Thanks! >=20 > 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 confiden= tielles 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. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation 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 dele= te 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. From susan.shishufeng@huawei.com Mon Dec 9 02:36:14 2013 Return-Path: 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 390541AE26C for ; Mon, 9 Dec 2013 02:36:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 r6_qXpMw_e26 for ; Mon, 9 Dec 2013 02:36:11 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 53F091AE24D for ; Mon, 9 Dec 2013 02:36:10 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBD94908; Mon, 09 Dec 2013 10:36:03 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 9 Dec 2013 10:35:58 +0000 Received: from SZXEMA408-HUB.china.huawei.com (10.82.72.40) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 9 Dec 2013 10:36:01 +0000 Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.155]) by SZXEMA408-HUB.china.huawei.com ([10.82.72.40]) with mapi id 14.03.0158.001; Mon, 9 Dec 2013 18:35:52 +0800 From: "Shishufeng (Susan)" To: "Wiehe, Ulrich (NSN - DE/Munich)" , "ext Nirav Salot (nsalot)" , "ext lionel.morand@orange.com" , ext Jouni Korhonen , "Ben Campbell" Thread-Topic: [Dime] DOIC: Self-Contained OLRs Thread-Index: AQHO7uv5ot3HeYq6iU+vru+Aq+dgEZpLtnrg Date: Mon, 9 Dec 2013 10:35:51 +0000 Message-ID: <26C84DFD55BC3040A45BF70926E55F2587C1D054@SZXEMA512-MBX.china.huawei.com> References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D90006681519BC90@DEMUMBX014.nsn-intra.net> <6390_1385631044_52970D44_6390_18593_1_6B7134B31289DC4FAF731D844122B36E30748E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BD19@DEMUMBX014.nsn-intra.net> <17872_1385720008_529868C8_17872_2613_1_6B7134B31289DC4FAF731D844122B36E3096B8@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BF1B@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681519BFAE@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681519BFAE@DEMUMBX014.nsn-intra.net> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.146.62.57] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "dime@ietf.org list" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 10:36:14 -0000 Hi Ulrich, As replied in another thread, from my point of view, realm-type OLR is alwa= ys the additional information. Best Regards, Susan -----Original Message----- From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 Sent: Monday, December 02, 2013 3:38 AM To: ext Nirav Salot (nsalot); ext lionel.morand@orange.com; ext Jouni Korho= nen; 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 O= LR is out-of-context. Similary, when the client sends a request containing destination host and g= ets 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 respons= es received within the context. Best regards Ulrich=20 -----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 Joun= i 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 i= n the answer and additional OLRs (not created by the reporting endpoint) ma= y just be present as an optional optimization i.e. optionally inserted by t= he reporting endpoint and optionally ignored by the reacting endpoint. Ulrich =20 -----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 subs= equent request towards the origin-host of the answer containing the OLR. Us= ing 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.=20 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=A0: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Envoy= =E9=A0: jeudi 28 novembre 2013 11:30 =C0=A0: MORAND Lionel IMT/OLN; ext Jou= ni Korhonen; Ben Campbell Cc=A0: dime@ietf.org list Objet=A0: RE: [Dime] DO= IC: 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 act= ual OLR created by the reporting end point and which OLR is an additional O= LR created by another node. We have two cases: a) The request sent by the client (reacting end point) contains no Destinat= ion Host. The agent (reporting node) (after forwarding the request to the s= elected server and receiving the answer) returns a realm-type OLR as the ac= tual 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 Destinat= ion 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 stat= us. It could be provided an agent inserting this info in answers received f= rom a server behind but also from a server that would know this info by som= e internal magic. But in any case, if we assume that the client will received a successful an= swer from the server for an initial request with only Dest-Realm AVP, it sh= ould be possible to have both report types in the answer: one for the serve= r itself, one for the realm for new request sent to the realm with only Des= t-Realm AVP. Lionel -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN= - DE/Munich) Envoy=E9=A0: jeudi 28 novembre 2013 10:26 =C0=A0: ext Jouni K= orhonen; Ben Campbell Cc=A0: dime@ietf.org list Objet=A0: Re: [Dime] DOIC: = Self-Contained OLRs Hi, I don't see how the possibility to send more than one OLR in an answer is a= ligned with the "endpoint principle". If the ReportType is "realm" this ind= icates 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 wrote: > Hi, >=20 > I mentioned in another thread that I prefer putting an explicit=20 > ReportType AVP in an OLR, rather than The more I spent time thinking/writing the actual procedures on the endpoin= ts, the more it makes sense to me to keep the ReportType in the OC-OLR. Eve= n if the baseline does not have agent overload etc, the ReportType fits wel= l to the "endpoint principle" we have in the draft. It indeed gives more to= ols to make a host vs. realm base decision on the reacting node and is plai= n 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 Diam= eter request that corresponds to the answer containing the OLR. My reasons = for that go beyond just ReportType, so I'm starting a separate thread. >=20 > As currently described, a consumer of an OLR must infer several things fr= om other context. In most cases, that context is in the Diameter answer tha= t carries the OLR. For example, the OLR implicitly refers to the applicatio= n 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 meani= ng in the context of the enclosing answer. If you moved an OLR from one ans= wer to another, it's meaning may change completely. >=20 > I think this approach is a mistake. I would greatly prefer that we explic= itly include such values in the OLR itself, for multiple reasons: >=20 > 1) It's more complex to interpret implicit, contextual values than explic= it values. The consumer cannot simply look at the OLR; it must look in vari= ous other AVPs to find all the information it needs. For example, I think a= common software design for overload control processing to be separated fro= m application processing. The consumer cannot simply hand the OLR to that m= odule 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 "con= text" avps that must be interpreted can grow large. This approach is error = prone, and will likely encourage brittle, hard-to-maintain code. Self-conta= ined OLRs would keep all the information related to overload in one place. = making for simpler implementations. >=20 > 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 r= eporting node realizes that it is overloade, it has to wait for the right a= nswer that contains the right context before it can send the OLR. This is p= articularly troublesome for agents, since they will typically have to inser= t OLRs into answers created by other nodes.=20 >=20 > If the reporting node screws this up, the meaning of the OLR may change s= ignificantly. So again, implicit meaning gives us error prone implementatio= ns. Self-contained OLRs are simpler to create and send. >=20 > 3) Implicit values don't work at all for certain problems. For=20 > example, if an agent needs to originate an OLR, it typically needs to=20 > insert that OLR into an existing Diameter answer created by a server. > It can't create its own answer without affecting the application=20 > state. If the responding node assumes the OLR comes from or refers to=20 > the node identified by the Origin-Host AVP in the enclosing answer,=20 > things break. (For examples of when an agent needs to send OLRs that=20 > are distinct from those sent by a server, see Steve's agent overload=20 > draft, or my dh/dr example.) >=20 > OTOH, explicit values will work for all cases where we need to associate = some arbitrary value with an OLR. >=20 > 4) Implicit values seriously constrain the future evolution of Diameter O= C standards. For example, lets say we find a good reason to allow OLRs to b= e sent out of band, or be sent in a dedicated Diameter application. If over= load 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 transpo= rted, this won't work. We would have to create a new or significantly modif= ied OLR format if we found a need to transport OLRs in different ways. Self= -contained OLRs would allow much greater flexibility. >=20 > So, in summary, I think that self-contained OLRs would lead to simpler im= plementations, less brittle deployments, and more flexibility for future ev= olution of standards. >=20 > Thanks! >=20 > 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 confiden= tielles 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. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation 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 dele= te 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 confiden= tielles 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. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation 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 dele= te 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 From susan.shishufeng@huawei.com Mon Dec 9 02:38:53 2013 Return-Path: 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 ADEB21AE26B for ; Mon, 9 Dec 2013 02:38:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 PS9f00x7xyDN for ; Mon, 9 Dec 2013 02:38:51 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A5B201AE269 for ; Mon, 9 Dec 2013 02:38:50 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBD95131; Mon, 09 Dec 2013 10:38:43 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 9 Dec 2013 10:38:37 +0000 Received: from SZXEMA402-HUB.china.huawei.com (10.82.72.34) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 9 Dec 2013 10:38:40 +0000 Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.155]) by SZXEMA402-HUB.china.huawei.com ([10.82.72.34]) with mapi id 14.03.0158.001; Mon, 9 Dec 2013 18:38:29 +0800 From: "Shishufeng (Susan)" To: "Nirav Salot (nsalot)" , "Wiehe, Ulrich (NSN - DE/Munich)" , "ext lionel.morand@orange.com" , ext Jouni Korhonen , "Ben Campbell" Thread-Topic: [Dime] DOIC: Self-Contained OLRs Thread-Index: AQHO7zgIot3HeYq6iU+vru+Aq+dgEZpLtrog Date: Mon, 9 Dec 2013 10:38:29 +0000 Message-ID: <26C84DFD55BC3040A45BF70926E55F2587C1D05F@SZXEMA512-MBX.china.huawei.com> References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D90006681519BC90@DEMUMBX014.nsn-intra.net> <6390_1385631044_52970D44_6390_18593_1_6B7134B31289DC4FAF731D844122B36E30748E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BD19@DEMUMBX014.nsn-intra.net> <17872_1385720008_529868C8_17872_2613_1_6B7134B31289DC4FAF731D844122B36E3096B8@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BF1B@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681519BFAE@DEMUMBX014.nsn-intra.net> In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.146.62.57] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "dime@ietf.org list" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 10:38:54 -0000 Hi Nirav, I would agree that Report-Type AVP is kind of optimization and I'm fine wit= h Lionel's proposal if it is ok with others. Best Regards, Susan -----Original Message----- From: Nirav Salot (nsalot) [mailto:nsalot@cisco.com]=20 Sent: Monday, December 02, 2013 2:05 PM To: Wiehe, Ulrich (NSN - DE/Munich); ext lionel.morand@orange.com; ext Joun= i 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 contain= ing destination-host), it gets back answer containing origin-host (set by t= he 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.=20 On the other hand, we discussed - as part of Maria Cruz's alternative solut= ion - to define the response message's context based on the request message= . And hence if the request message was sent to destination-realm, the corre= sponding response message can only contain realm-type OLR. But this requires the client to remember the context of the request while p= rocessing the response and hence it was considered as introducing unnecessa= ry complexity.=20 If we strictly want to ensure that the realm-type OLR is not sent out-of-co= ntext, then we should agree to Lionel's alternative solution - to send real= m-type OLR only when the destination-realm based request is rejected. So ba= sically, realm-type OLR is never included in a response message which conta= ins origin-host AVP. (And I am ready to reconsider the same if we want to e= nsure the context of the response message and the OLR it contains). However, as per our current agreement, we are introducing Report-Type AVP t= o allow the inclusion of host-type and realm-type OLRs in the response mess= age. If we say that the client can ignore one of the OLRs, then what is the poin= t of including two OLRs and what is the point of defining Report-Type AVP? 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. 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 ign= ored. 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 O= LR is out-of-context. Similary, when the client sends a request containing destination host and g= ets 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 respons= es received within the context. Best regards Ulrich=20 -----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 Joun= i 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 i= n the answer and additional OLRs (not created by the reporting endpoint) ma= y just be present as an optional optimization i.e. optionally inserted by t= he reporting endpoint and optionally ignored by the reacting endpoint. Ulrich =20 -----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 subs= equent request towards the origin-host of the answer containing the OLR. Us= ing 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.=20 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=A0: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Envoy= =E9=A0: jeudi 28 novembre 2013 11:30 =C0=A0: MORAND Lionel IMT/OLN; ext Jou= ni Korhonen; Ben Campbell Cc=A0: dime@ietf.org list Objet=A0: RE: [Dime] DO= IC: 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 act= ual OLR created by the reporting end point and which OLR is an additional O= LR created by another node. We have two cases: a) The request sent by the client (reacting end point) contains no Destinat= ion Host. The agent (reporting node) (after forwarding the request to the s= elected server and receiving the answer) returns a realm-type OLR as the ac= tual 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 Destinat= ion 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 stat= us. It could be provided an agent inserting this info in answers received f= rom a server behind but also from a server that would know this info by som= e internal magic. But in any case, if we assume that the client will received a successful an= swer from the server for an initial request with only Dest-Realm AVP, it sh= ould be possible to have both report types in the answer: one for the serve= r itself, one for the realm for new request sent to the realm with only Des= t-Realm AVP. Lionel -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN= - DE/Munich) Envoy=E9=A0: jeudi 28 novembre 2013 10:26 =C0=A0: ext Jouni K= orhonen; Ben Campbell Cc=A0: dime@ietf.org list Objet=A0: Re: [Dime] DOIC: = Self-Contained OLRs Hi, I don't see how the possibility to send more than one OLR in an answer is a= ligned with the "endpoint principle". If the ReportType is "realm" this ind= icates 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 wrote: > Hi, >=20 > I mentioned in another thread that I prefer putting an explicit=20 > ReportType AVP in an OLR, rather than The more I spent time thinking/writing the actual procedures on the endpoin= ts, the more it makes sense to me to keep the ReportType in the OC-OLR. Eve= n if the baseline does not have agent overload etc, the ReportType fits wel= l to the "endpoint principle" we have in the draft. It indeed gives more to= ols to make a host vs. realm base decision on the reacting node and is plai= n 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 Diam= eter request that corresponds to the answer containing the OLR. My reasons = for that go beyond just ReportType, so I'm starting a separate thread. >=20 > As currently described, a consumer of an OLR must infer several things fr= om other context. In most cases, that context is in the Diameter answer tha= t carries the OLR. For example, the OLR implicitly refers to the applicatio= n 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 meani= ng in the context of the enclosing answer. If you moved an OLR from one ans= wer to another, it's meaning may change completely. >=20 > I think this approach is a mistake. I would greatly prefer that we explic= itly include such values in the OLR itself, for multiple reasons: >=20 > 1) It's more complex to interpret implicit, contextual values than explic= it values. The consumer cannot simply look at the OLR; it must look in vari= ous other AVPs to find all the information it needs. For example, I think a= common software design for overload control processing to be separated fro= m application processing. The consumer cannot simply hand the OLR to that m= odule 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 "con= text" avps that must be interpreted can grow large. This approach is error = prone, and will likely encourage brittle, hard-to-maintain code. Self-conta= ined OLRs would keep all the information related to overload in one place. = making for simpler implementations. >=20 > 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 r= eporting node realizes that it is overloade, it has to wait for the right a= nswer that contains the right context before it can send the OLR. This is p= articularly troublesome for agents, since they will typically have to inser= t OLRs into answers created by other nodes.=20 >=20 > If the reporting node screws this up, the meaning of the OLR may change s= ignificantly. So again, implicit meaning gives us error prone implementatio= ns. Self-contained OLRs are simpler to create and send. >=20 > 3) Implicit values don't work at all for certain problems. For=20 > example, if an agent needs to originate an OLR, it typically needs to=20 > insert that OLR into an existing Diameter answer created by a server. > It can't create its own answer without affecting the application=20 > state. If the responding node assumes the OLR comes from or refers to=20 > the node identified by the Origin-Host AVP in the enclosing answer,=20 > things break. (For examples of when an agent needs to send OLRs that=20 > are distinct from those sent by a server, see Steve's agent overload=20 > draft, or my dh/dr example.) >=20 > OTOH, explicit values will work for all cases where we need to associate = some arbitrary value with an OLR. >=20 > 4) Implicit values seriously constrain the future evolution of Diameter O= C standards. For example, lets say we find a good reason to allow OLRs to b= e sent out of band, or be sent in a dedicated Diameter application. If over= load 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 transpo= rted, this won't work. We would have to create a new or significantly modif= ied OLR format if we found a need to transport OLRs in different ways. Self= -contained OLRs would allow much greater flexibility. >=20 > So, in summary, I think that self-contained OLRs would lead to simpler im= plementations, less brittle deployments, and more flexibility for future ev= olution of standards. >=20 > Thanks! >=20 > 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 confiden= tielles 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. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation 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 dele= te 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 confiden= tielles 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. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation 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 dele= te 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 From susan.shishufeng@huawei.com Mon Dec 9 02:46:35 2013 Return-Path: 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 3F1B21AD8F2 for ; Mon, 9 Dec 2013 02:46:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 DD0Q13QjV7Cj for ; Mon, 9 Dec 2013 02:46:31 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 04BDE1ADEC4 for ; Mon, 9 Dec 2013 02:46:30 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYT70391; Mon, 09 Dec 2013 10:46:24 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 9 Dec 2013 10:46:07 +0000 Received: from SZXEMA401-HUB.china.huawei.com (10.82.72.33) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 9 Dec 2013 10:46:10 +0000 Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.155]) by SZXEMA401-HUB.china.huawei.com ([10.82.72.33]) with mapi id 14.03.0158.001; Mon, 9 Dec 2013 18:46:01 +0800 From: "Shishufeng (Susan)" To: Maria Cruz Bartolome , "dime@ietf.org" Thread-Topic: [Dime] DOIC: Self-Contained OLRs Thread-Index: AQHO73dAot3HeYq6iU+vru+Aq+dgEZpLt4UQ Date: Mon, 9 Dec 2013 10:46:00 +0000 Message-ID: <26C84DFD55BC3040A45BF70926E55F2587C1D086@SZXEMA512-MBX.china.huawei.com> References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D90006681519BC90@DEMUMBX014.nsn-intra.net> <6390_1385631044_52970D44_6390_18593_1_6B7134B31289DC4FAF731D844122B36E30748E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BD31@DEMUMBX014.nsn-intra.net> <47383DC2-1A1B-4D1A-ADD5-9E3CE60B06C8@gmail.com> <8467_1385735507_5298A553_8467_17054_3_6B7134B31289DC4FAF731D844122B36E309D0D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B920972B9BE@ESESSMB101.ericsson.se> In-Reply-To: <087A34937E64E74E848732CFF8354B920972B9BE@ESESSMB101.ericsson.se> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.146.62.57] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 10:46:35 -0000 Dear all, I share the same views as Nirav, Lionel, JJ and MCruz. And I don't see the = value to reopen the discussion on it and revert the principles we reached. Best Regards, Susan -----Original Message----- From: Maria Cruz Bartolome [mailto:maria.cruz.bartolome@ericsson.com]=20 Sent: Monday, December 02, 2013 11:58 PM To: dime@ietf.org Subject: Re: [Dime] DOIC: Self-Contained OLRs Dear all, About self-contained OLRs, I agree with Nirav, Lionel and JJ. Duplication of information should be avoided, once we have considered piggy= backing as the overload info conveyance mechanism. Best regards /MCruz -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE= S (JEAN-JACQUES) Sent: viernes, 29 de noviembre de 2013 16:05 To: dime@ietf.org Subject: Re: [Dime] DOIC: Self-Contained OLRs Dear all In the baseline mechanism as currently defined in the draft, the OLR conten= t is simple, and is related to the message conveying it in particular appli= cation origin host/realm and destination to which the OLR is sent back. As= Lionel indicated, it is not so important to know which node inserts the OL= R or to have other information. =20 There is a performance aspect to consider: the OLRs defined in the baseline= may be frequently sent (in particular to compensate possible message los= ses and to manage the loopback to the reporting node ensuring the quick con= vergence towards the optimal throughput). So we have to minimize the proces= sing of these OLRs. As OLRs are piggybacked in the relevant messages, the= y may be simply forwarded in the same message by the DAs on the path except= if there are particular reasons a DA to act on them. =20 I am cautious about duplication of information, it always means additional = checks to ensure consistency. If the OLR has an application id and origin= host different from the message conveying it, what to do with this OLR, i= s it an error case? or should it be put in another message in the path? Our= current piggybacking mechanism allows the OLR to remain in the same messag= e from the reporting node to the reacting node.=20 An important point is extensibility, as we may have to introduce other typ= e of OLRs, additional AVPs, more sophisticated processing, but these extens= ions should not impact the baseline mechanism by making the baseline more = complex. the current draft allows extensions without impacting the baseline= . Currently I do not see drawbacks on the OLRs defined for the baseline mecha= nism. So my comments join the Nirav and Lionel's ones. Best regards=20 JJacques=20 -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de lionel.morand@oran= ge.com Envoy=E9=A0: vendredi 29 novembre 2013 15:32 =C0=A0: Nirav Salot (ns= alot); Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list = Cc=A0: Ben Campbell Objet=A0: Re: [Dime] DOIC: Self-Contained OLRs I totally agree with Nirav. No need to revert at this stage the working ass= umption on piggybacking of OLR in application answer messages, especially w= hen the aim is to define a basic mechanism called "reduction". Anyone would be able to further add extra info for optimization if needed b= ut there is no need at all for the basic mechanism. Regards, Lionel -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot (nsalo= t) Envoy=E9=A0: vendredi 29 novembre 2013 12:24 =C0=A0: Jouni Korhonen; Wie= he, Ulrich (NSN - DE/Munich); dime@ietf.org list Cc=A0: Ben Campbell Objet= =A0: Re: [Dime] DOIC: Self-Contained OLRs Jouni, Ben, I am totally against the idea of self-contained OC-OLR specifically since w= e have adopted the principles of piggybacking the OC-OLR over existing appl= ication message. Self-contained OC-OLR - which means adding all the information which define= s the scope of the OC-OLR into the OC-OLR - does not make sense in the pigg= ybacking approach. In fact, it is adding lot of information, which is anywa= y available within the message containing the OC-OLR, into the OC-OLR. So i= t is adding lot of redundant information in a message which increases the p= rocessing requirement for the sender as well as the receiver. (And this is = un-optimization, in my view). Besides, I am not convinced with the other reasons provided here: - One software module within a node can provide OC-OLR to another software = module in the same node without passing other related info Within a node, based on the design, lots of information may need to be p= assed between two software modules and we cannot optimize those aspects by = replicating unnecessary information in a protocol message. In summary, it is node's internal software design issue and we need not = optimize that at protocol level. - Once the reporting node realizes that it is overloaded, it has to wait fo= r right answer to send OC-OLR What is the point of sending OC-OLR for a context for which there is no m= essaging? Why should the reacting node care if it never sends a message for= a context for which the reporting node is overloaded? So this waiting is justified since it ensures that the overload is report= ed only when necessary and only to the applicable reacting node. Not to all= the nodes in the network. - The agent needs to wait for the answer generated by the server and the ri= ght context The same argument as applicable for the server applies here. The agent n= eed not send out-of-context overload info to a node. Why should reacting node receive/process/store the overload info for the= scope for which it is not sending any messages. - For sending OC-OLR in dedicated Diameter application??? Piggybacking was the first basic principle we agreed before putting other= principles in place. So we may want to go back the drawing board if we dec= ide to change this principle. Regards, Nirav. -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen Sent: Friday, November 29, 2013 2:50 PM To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list Cc: Ben Campbell Subject: Re: [Dime] DOIC: Self-Contained OLRs So, are we reaching any level of consensus here? - JOuni (as a note.. that we are converging back to where we started with OLRs ;) On Nov 28, 2013, at 12:40 PM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: > Hi, >=20 > another question: >=20 > If we go for explicit self contained OLRs, why would we then need the Rep= ortType? >=20 > The realm-type OLR would explicitly contain application-Id, Realm, but no= Host whereas the host-type OLR would explicitly contain application-Id, Ho= st, but probably (I'm not sure) no Realm. >=20 > Ulrich >=20 >=20 >=20 > -----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 >=20 > Hi, >=20 > There is no assumption on which entity is providing the realm overload st= atus. 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 s= ome 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 ser= ver itself, one for the realm for new request sent to the realm with only D= est-Realm AVP. >=20 > Lionel >=20 > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich=20 > (NSN - DE/Munich) Envoy=E9 : jeudi 28 novembre 2013 10:26 =C0 : ext Jouni= =20 > Korhonen; Ben Campbell Cc : dime@ietf.org list Objet : Re: [Dime] > DOIC: Self-Contained OLRs >=20 > Hi, >=20 > 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 i= ndicates 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 indicate= s to the reacting end point that the reporting end point is a server. How c= an the reporting end point be both agent and server? >=20 > Ulrich >=20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Jouni=20 > Korhonen > Sent: Wednesday, November 27, 2013 11:44 PM > To: Ben Campbell > Cc: dime@ietf.org list > Subject: Re: [Dime] DOIC: Self-Contained OLRs >=20 >=20 > On Nov 28, 2013, at 12:27 AM, Ben Campbell wrote: >=20 >> Hi, >>=20 >> I mentioned in another thread that I prefer putting an explicit=20 >> ReportType AVP in an OLR, rather than >=20 > The more I spent time thinking/writing the actual procedures on the=20 > endpoints, the more it makes sense to me to keep the ReportType in the=20 > OC-OLR. Even if the baseline does not have agent overload etc, the=20 > 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. >=20 > I skip the rest of the mail.. too much text ;-) >=20 >=20 > - Jouni >=20 >=20 >=20 >=20 >=20 >> making a responding node infer the type or meaning of the OLR from a Dia= meter request that corresponds to the answer containing the OLR. My reasons= for that go beyond just ReportType, so I'm starting a separate thread. >>=20 >> As currently described, a consumer of an OLR must infer several things f= rom other context. In most cases, that context is in the Diameter answer th= at carries the OLR. For example, the OLR implicitly refers to the applicati= on identified by the Application-Id field of the enclosing answer, the real= m identified by Origin-Realm, and so on. This means that the "meaning" of a= n OLR cannot be determined from the OLR contents alone; OLRs only have mean= ing in the context of the enclosing answer. If you moved an OLR from one an= swer to another, it's meaning may change completely. >>=20 >> I think this approach is a mistake. I would greatly prefer that we expli= citly include such values in the OLR itself, for multiple reasons: >>=20 >> 1) It's more complex to interpret implicit, contextual values than expli= cit values. The consumer cannot simply look at the OLR; it must look in var= ious other AVPs to find all the information it needs. For example, I think = a common software design for overload control processing to be separated fr= om 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 "co= ntext" avps that must be interpreted can grow large. This approach is error= prone, and will likely encourage brittle, hard-to-maintain code. Self-cont= ained OLRs would keep all the information related to overload in one place.= making for simpler implementations. >>=20 >> 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 inse= rt OLRs into answers created by other nodes.=20 >>=20 >> If the reporting node screws this up, the meaning of the OLR may change = significantly. So again, implicit meaning gives us error prone implementati= ons. Self-contained OLRs are simpler to create and send. >>=20 >> 3) Implicit values don't work at all for certain problems. For=20 >> example, if an agent needs to originate an OLR, it typically needs to=20 >> insert that OLR into an existing Diameter answer created by a server. >> It can't create its own answer without affecting the application=20 >> state. If the responding node assumes the OLR comes from or refers to=20 >> the node identified by the Origin-Host AVP in the enclosing answer,=20 >> things break. (For examples of when an agent needs to send OLRs that=20 >> are distinct from those sent by a server, see Steve's agent overload=20 >> draft, or my dh/dr example.) >>=20 >> OTOH, explicit values will work for all cases where we need to associate= some arbitrary value with an OLR. >>=20 >> 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 ove= rload reports were self-contained, one could just reuse the report format w= e specify here. But if the meaning of an OLR depends on the way it's transp= orted, this won't work. We would have to create a new or significantly modi= fied OLR format if we found a need to transport OLRs in different ways. Sel= f-contained OLRs would allow much greater flexibility. >>=20 >> So, in summary, I think that self-contained OLRs would lead to simpler i= mplementations, less brittle deployments, and more flexibility for future e= volution of standards. >>=20 >> Thanks! >>=20 >> Ben. >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >=20 > _______________________________________________ > 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 >=20 > ______________________________________________________________________ > ___________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not be d= istributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 _______________________________________________ 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 confiden= tielles 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. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation 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 dele= te 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 From susan.shishufeng@huawei.com Mon Dec 9 02:47:51 2013 Return-Path: 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 BD2561AD8F2 for ; Mon, 9 Dec 2013 02:47:51 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 rJrQNS5oO1q0 for ; Mon, 9 Dec 2013 02:47:44 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 37F441AD7C0 for ; Mon, 9 Dec 2013 02:47:43 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBD96175; Mon, 09 Dec 2013 10:47:37 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 9 Dec 2013 10:47:23 +0000 Received: from SZXEMA406-HUB.china.huawei.com (10.82.72.38) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 9 Dec 2013 10:47:16 +0000 Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.155]) by SZXEMA406-HUB.china.huawei.com ([10.82.72.38]) with mapi id 14.03.0158.001; Mon, 9 Dec 2013 18:47:04 +0800 From: "Shishufeng (Susan)" To: Maria Cruz Bartolome , "dime@ietf.org" Thread-Topic: [Dime] open issues #1 in DOIC Thread-Index: AQHO73l4260z2Ls5/Ee769d3/J4X5ZpLuOdA Date: Mon, 9 Dec 2013 10:47:04 +0000 Message-ID: <26C84DFD55BC3040A45BF70926E55F2587C1D091@SZXEMA512-MBX.china.huawei.com> References: <5E28C8B7-2E5E-41E8-9592-24A19AD76826@gmail.com> <9889_1385714340_529852A4_9889_16410_1_6B7134B31289DC4FAF731D844122B36E3093B0@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52EDD6D4-71CD-439F-9D2D-439CC656C3CC@gmail.com> <3468_1385718494_529862DE_3468_4222_1_6B7134B31289DC4FAF731D844122B36E309600@PEXCVZYM13.corporate.adroot.infra.ftgroup> <529CAAF4.6070708@usdonovans.com> <087A34937E64E74E848732CFF8354B920972BA1E@ESESSMB101.ericsson.se> In-Reply-To: <087A34937E64E74E848732CFF8354B920972BA1E@ESESSMB101.ericsson.se> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.146.62.57] Content-Type: multipart/alternative; boundary="_000_26C84DFD55BC3040A45BF70926E55F2587C1D091SZXEMA512MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [Dime] open issues #1 in DOIC X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 10:47:52 -0000 --_000_26C84DFD55BC3040A45BF70926E55F2587C1D091SZXEMA512MBXchi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Fine for me. Best Regards, Susan From: Maria Cruz Bartolome [mailto:maria.cruz.bartolome@ericsson.com] Sent: Tuesday, December 03, 2013 12:13 AM To: dime@ietf.org Subject: Re: [Dime] open issues #1 in DOIC Looks fine to me MCruz From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: lunes, 02 de diciembre de 2013 16:45 To: dime@ietf.org Subject: Re: [Dime] open issues #1 in DOIC Agreed, looks good. Steve On 11/29/13 4:04 AM, Jouni Korhonen wrote: Would work for me. - Jouni On Nov 29, 2013, at 11:48 AM, lionel.morand@orange.com wrote: Actually, I realized that we are redefining something somehow already in us= e in RFC 6733: 9.6. Correlation of Accounting Records If an application uses accounting messages, it can correlate accounting records with a specific application session by using the Session-Id of the particular application session in the accounting messages. Accounting messages MAY also use a different Session-Id from that of the application sessions, in which case, other session- related information is needed to perform correlation. We could maybe reuse the same type of wording to simplify the definition: Pseudo-session applications are applications that do not rely on the Session-Id AVP for correlation of application messages related to the same session but use another session-related information for this purpose. The 3GPP defined Cx application [3GPP.29.229] is an example of a pseudo-session application. OK? Regards, Lionel -----Message d'origine----- De : Jouni Korhonen [mailto:jouni.nospam@gmail.com] Envoy=E9 : vendredi 29 novembre 2013 10:01 =C0 : MORAND Lionel IMT/OLN Cc : dime@ietf.org list Objet : Re: [Dime] open issues #1 in DOIC Pseudo-session applications: While this class of application does not use the Diameter Session-ID AVP to correlate requests, there is an implied ordering of transactions defined by the application and except for the Session-ID differences pseudo-session based applications are generally assumed to behave like session-based application. The 3GPP defined Cx application [3GPP.29.229] is an example of a pseudo-session application. Would this suffice? - Jouni On Nov 29, 2013, at 10:38 AM, lionel.morand@orange.com wrote: Hi, For me, "pseudo-session" refers to session-based oriented applications that= do not rely on the session-id for message correlations but on something el= se e.g. user-name. So it is implied that the same server is contacted by th= e client managing the session. In the Cx example, the same origin-host will= be used in the client-initiated requests after the initial exchange and th= e server discovery phase. Regards, Lionel -----Message d'origine----- De : DiME [mailto:dime-bounces@ietf.org] De la part de Jouni Korhonen Envoy=E9 : vendredi 29 novembre 2013 09:30 =C0 : dime@ietf.org list Objet : [Dime] open issues #1 in DOIC Folks, [OpenIssue: Do we assume that all requests in a pseudo-session typically need to go to the same server?] The example here is in context of Cx. Not that I am expert on Cx (or anythi= ng) but based on the CCF the requests _may_ have destination-host. Thus, I assu= me that it is an implementation issue whether pseudo-sessions need to go to th= e same server.. I guess we cannot have such firm requirement. Correct? - Jouni _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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 confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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 --_000_26C84DFD55BC3040A45BF70926E55F2587C1D091SZXEMA512MBXchi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Fine for m= e.

 = ;

Best Regar= ds,

Susan=

 = ;

From:= Maria Cruz Bartolom= e [mailto:maria.cruz.bartolome@ericsson.com]
Sent: Tuesday, December 03, 2013 12:13 AM
To: dime@ietf.org
Subject: Re: [Dime] open issues #1 in DOIC

 

Looks fine= to me

 

MCruz

 

From:= DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: lunes, 02 de diciembre de 2013 16:45
To: dime@ietf.org
Subject: Re: [Dime] open issues #1 in DOIC

 

= Agreed, looks good.

Steve

On 11/29/13 4:04 AM, Jouni Korh= onen wrote:

 
Would work for me.
 
- Jouni
 
On Nov 29, 2013, at 11:48 AM, lionel.morand@orange.com wrote:
 
Actually, I realized that we are redefining somet=
hing somehow already in use in RFC 6733:
 
9.6. Correlation of Accounting Records=

 
 
  If an application uses accounting messages=
, it can correlate
  accounting records with a specific applica=
tion session by using the
  Session-Id of the particular application s=
ession in the accounting
  messages.  Accounting messages MAY al=
so use a different Session-Id
  from that of the application sessions, in =
which case, other session-
  related information is needed to perform c=
orrelation.
 
We could maybe reuse the same type of wording to =
simplify the definition:
 
Pseudo-session applications are applications that=

do not rely on the Session-Id AVP for correlation=
 
of application messages related to the same sessi=
on
but use another session-related information for t=
his
purpose. The 3GPP defined Cx application [3GPP.29=
.229]
is an example of a pseudo-session application.
 
OK?
 
Regards,
 
Lionel
 
-----Message d'origine-----

De : Jouni Korhonen [mailto:jouni.nospam@gmail.com] 


Envoy=E9 : vendredi 29 novembre 2013 10:01


=C0 : MORAND Lionel IMT/OLN

Cc : dime@ietf.o=
rg list


Objet : Re: [Dime] open issues #1 in DOIC


 


 


  Pseudo-session applications:


 


     While this class of appl=
ication does not use the Diameter


     Session-ID AVP to correl=
ate requests, there is an implied ordering


     of transactions defined =
by the application and except for the


     Session-ID differences p=
seudo-session based applications are


     generally assumed to beh=
ave like session-based application.  The


     3GPP defined Cx applicat=
ion [3GPP.29.229] is an example of a


     pseudo-session applicati=
on.


 


 


Would this suffice?


 


- Jouni


 


 


 


On Nov 29, 2013, at 10:38 AM, lionel.morand@orange.com wrote:


 




Hi,


 


For me, "pseudo-session" refers to sess=
ion-based oriented applications that do not rely on the session-id for mess=
age correlations but on something else e.g. user-name. So it is implied tha=
t the same server is contacted by the client managing the session. In the C=
x example, the same origin-host will be used in the client-initiated reques=
ts after the initial exchange and the server discovery phase.


 


Regards,


 


Lionel 


 


-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de Jouni Korhonen


Envoy=E9 : vendredi 29 novembre 2013 09:30


=C0 : dime@ietf.=
org list


Objet : [Dime] open issues #1 in DOIC<=
/span>


 


Folks,


 


         =
[OpenIssue: Do we assume that all requests in a pseudo-session


         =
typically need to go to the same server?]


 


 


The example here is in context of Cx. Not that I =
am expert on Cx (or anything)


but based on the CCF the requests _may_ have dest=
ination-host. Thus, I assume


that it is an implementation issue whether pseudo=
-sessions need to go to the


same server.. I guess we cannot have such firm re=
quirement. Correct?


 


- Jouni


_______________________________________________


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 autor=
isation. Si vous avez recu ce message par erreur, veuillez le signaler=



a l'expediteur et le detruire ainsi que les piece=
s 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 conf=
idential or privileged information that may be protected by law;=



they should not be distributed, used or copied wi=
thout 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 fo=
r 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 autor=
isation. Si vous avez recu ce message par erreur, veuillez le signaler=



a l'expediteur et le detruire ainsi que les piece=
s 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 conf=
idential or privileged information that may be protected by law;=



they should not be distributed, used or copied wi=
thout 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 fo=
r messages that have been modified, changed or falsified.=



Thank you.


 


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

 

 

--_000_26C84DFD55BC3040A45BF70926E55F2587C1D091SZXEMA512MBXchi_-- From susan.shishufeng@huawei.com Mon Dec 9 02:49:16 2013 Return-Path: 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 ED8D11AD8F2 for ; Mon, 9 Dec 2013 02:49:15 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 VVsVZ4jckTTF for ; Mon, 9 Dec 2013 02:49:11 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8181A1AE274 for ; Mon, 9 Dec 2013 02:49:05 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYT70707; Mon, 09 Dec 2013 10:49:00 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 9 Dec 2013 10:48:41 +0000 Received: from SZXEMA402-HUB.china.huawei.com (10.82.72.34) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 9 Dec 2013 10:48:44 +0000 Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.155]) by SZXEMA402-HUB.china.huawei.com ([10.82.72.34]) with mapi id 14.03.0158.001; Mon, 9 Dec 2013 18:48:35 +0800 From: "Shishufeng (Susan)" To: "lionel.morand@orange.com" , Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] DOIC: Self-Contained OLRs Thread-Index: AQHO73ovot3HeYq6iU+vru+Aq+dgEZpLuS+Q Date: Mon, 9 Dec 2013 10:48:35 +0000 Message-ID: <26C84DFD55BC3040A45BF70926E55F2587C1D0BA@SZXEMA512-MBX.china.huawei.com> References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D90006681519BC90@DEMUMBX014.nsn-intra.net> <6390_1385631044_52970D44_6390_18593_1_6B7134B31289DC4FAF731D844122B36E30748E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BD31@DEMUMBX014.nsn-intra.net> <47383DC2-1A1B-4D1A-ADD5-9E3CE60B06C8@gmail.com> <8467_1385735507_5298A553_8467_17054_3_6B7134B31289DC4FAF731D844122B36E309D0D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <529CA930.4030006@usdonovans.com> <13482_1386001111_529CB2D7_13482_11387_1_6B7134B31289DC4FAF731D844122B36E311068@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <13482_1386001111_529CB2D7_13482_11387_1_6B7134B31289DC4FAF731D844122B36E311068@PEXCVZYM13.corporate.adroot.infra.ftgroup> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.146.62.57] Content-Type: multipart/alternative; boundary="_000_26C84DFD55BC3040A45BF70926E55F2587C1D0BASZXEMA512MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 10:49:16 -0000 --_000_26C84DFD55BC3040A45BF70926E55F2587C1D0BASZXEMA512MBXchi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I totally agree with Lionel. Best Regards, Susan From: lionel.morand@orange.com [mailto:lionel.morand@orange.com] Sent: Tuesday, December 03, 2013 12:19 AM To: Steve Donovan; dime@ietf.org Subject: Re: [Dime] DOIC: Self-Contained OLRs Hi Steve, I think that is not only about few bytes in the answer. It is also about th= e solution principles agreed so far: =B7 the current need is for an OLR bound to the application in use =B7 the OLR is received from the node targeted in the request. =B7 the OLR is defined per application So all the implicit information (application, origin-host, origin-realm) ar= e meaningful in this context. And the actual solution is designed based on these assumptions. The extensi= bility of the solution will allow extra info if required in other use cases= but it was agreed to go with a straightforward solution that will satisfy = most of us. Regards, Lionel De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan Envoy=E9 : lundi 2 d=E9cembre 2013 16:37 =C0 : dime@ietf.org Objet : Re: [Dime] DOIC: Self-Contained OLRs I don't believe that Ben's proposal was to change the piggybacking assumpti= on in the baseline mechanism. Ben's proposal is to design the solution in = such a way that it is not dependent on the piggybacking transport mechanism= . I share Ben's concern that we have over optimized the content of the overlo= ad report in a way that makes implementations brittle, interoperability mor= e difficult to achieve and extensibility more complex. And what do we gain= from this optimization? A few bites in answer messages. Self contained overload reports, transported using the piggybacking mechani= sm, is a cleaner solution. Steve On 11/29/13 8:31 AM, lionel.morand@orange.com wrote: I totally agree with Nirav. No need to revert at this stage the working ass= umption on piggybacking of OLR in application answer messages, especially w= hen the aim is to define a basic mechanism called "reduction". Anyone would be able to further add extra info for optimization if needed b= ut there is no need at all for the basic mechanism. Regards, Lionel -----Message d'origine----- De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot (nsalot) Envoy=E9 : vendredi 29 novembre 2013 12:24 =C0 : Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list Cc : Ben Campbell Objet : Re: [Dime] DOIC: Self-Contained OLRs Jouni, Ben, I am totally against the idea of self-contained OC-OLR specifically since w= e have adopted the principles of piggybacking the OC-OLR over existing appl= ication message. Self-contained OC-OLR - which means adding all the information which define= s the scope of the OC-OLR into the OC-OLR - does not make sense in the pigg= ybacking approach. In fact, it is adding lot of information, which is anywa= y available within the message containing the OC-OLR, into the OC-OLR. So i= t is adding lot of redundant information in a message which increases the p= rocessing requirement for the sender as well as the receiver. (And this is = un-optimization, in my view). Besides, I am not convinced with the other reasons provided here: - One software module within a node can provide OC-OLR to another software = module in the same node without passing other related info Within a node, based on the design, lots of information may need to be p= assed between two software modules and we cannot optimize those aspects by = replicating unnecessary information in a protocol message. In summary, it is node's internal software design issue and we need not = optimize that at protocol level. - Once the reporting node realizes that it is overloaded, it has to wait fo= r right answer to send OC-OLR What is the point of sending OC-OLR for a context for which there is no m= essaging? Why should the reacting node care if it never sends a message for= a context for which the reporting node is overloaded? So this waiting is justified since it ensures that the overload is report= ed only when necessary and only to the applicable reacting node. Not to all= the nodes in the network. - The agent needs to wait for the answer generated by the server and the ri= ght context The same argument as applicable for the server applies here. The agent n= eed not send out-of-context overload info to a node. Why should reacting node receive/process/store the overload info for the= scope for which it is not sending any messages. - For sending OC-OLR in dedicated Diameter application??? Piggybacking was the first basic principle we agreed before putting other= principles in place. So we may want to go back the drawing board if we dec= ide to change this principle. Regards, Nirav. -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen Sent: Friday, November 29, 2013 2:50 PM To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org li= st Cc: Ben Campbell Subject: Re: [Dime] DOIC: Self-Contained OLRs So, are we reaching any level of consensus here? - JOuni (as a note.. that we are converging back to where we started with OLRs ;) On Nov 28, 2013, at 12:40 PM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: Hi, another question: If we go for explicit self contained OLRs, why would we then need the Repor= tType? The realm-type OLR would explicitly contain application-Id, Realm, but no H= ost whereas the host-type OLR would explicitly contain application-Id, Host= , but probably (I'm not sure) no Realm. 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 stat= us. It could be provided an agent inserting this info in answers received f= rom a server behind but also from a server that would know this info by som= e internal magic. But in any case, if we assume that the client will received a successful an= swer from the server for an initial request with only Dest-Realm AVP, it sh= ould be possible to have both report types in the answer: one for the serve= r itself, one for the realm for new request sent to the realm with only Des= t-Realm AVP. Lionel -----Message d'origine----- De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN - DE/Munich) Envoy=E9 : jeudi 28 novembre 2013 10:26 =C0 : 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 a= ligned with the "endpoint principle". If the ReportType is "realm" this ind= icates 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 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 re= acting 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 Diamet= er request that corresponds to the answer containing the OLR. My reasons fo= r 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 i= dentified by Origin-Realm, and so on. This means that the "meaning" of an O= LR 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 answe= r to another, it's meaning may change completely. I think this approach is a mistake. I would greatly prefer that we explicit= ly 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 variou= s other AVPs to find all the information it needs. For example, I think a c= ommon software design for overload control processing to be separated from = application processing. The consumer cannot simply hand the OLR to that mod= ule and expect things to work. The OC module must not only parse the OLR, b= ut parse any other AVPs that are relevant. As OLR contents get extended (as= sumedly following the same strategy as the base spec), the number of "conte= xt" avps that must be interpreted can grow large. This approach is error pr= one, and will likely encourage brittle, hard-to-maintain code. Self-contain= ed OLRs would keep all the information related to overload in one place. ma= king for simpler implementations. 2) It's more complex for the reporting node to send implicit values than ex= plicit values. The sender cannot simply set the context to match the OLR--a= ll those other AVPs have application or protocol layer meanings. Once a rep= orting node realizes that it is overloade, it has to wait for the right ans= wer that contains the right context before it can send the OLR. This is par= ticularly 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 sig= nificantly. 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 so= me 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 overlo= ad reports were self-contained, one could just reuse the report format we s= pecify here. But if the meaning of an OLR depends on the way it's transport= ed, this won't work. We would have to create a new or significantly modifie= d OLR format if we found a need to transport OLRs in different ways. Self-c= ontained OLRs would allow much greater flexibility. So, in summary, I think that self-contained OLRs would lead to simpler impl= ementations, less brittle deployments, and more flexibility for future evol= ution 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 le= s pieces jointes. Les messages electroniques etant susceptibles d'alteratio= n, 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 dis= tributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te 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 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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 confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. --_000_26C84DFD55BC3040A45BF70926E55F2587C1D0BASZXEMA512MBXchi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I totally = agree with Lionel.

 = ;

Best Regar= ds,

Susan=

 = ;

From:= lionel.morand@orang= e.com [mailto:lionel.morand@orange.com]
Sent: Tuesday, December 03, 2013 12:19 AM
To: Steve Donovan; dime@ietf.org
Subject: Re: [Dime] DOIC: Self-Contained OLRs

 

Hi Steve,

 

I think th= at is not only about few bytes in the answer. It is also about the solution= principles agreed so far:

=B7    =      th= e current need is for an OLR bound to the application in use

=B7    =      th= e OLR is received from the node targeted in the request.<= /p>

=B7    =      th= e OLR is defined per application

So all the= implicit information (application, origin-host, origin-realm) are meaningf= ul in this context.

And the ac= tual solution is designed based on these assumptions. The extensibility of = the solution will allow extra info if required in other use cases but it was agreed to go with a straightforward solution that will sa= tisfy most of us.

 = ;

Regards,

 = ;

Lionel

 = ;

De = : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9 : lundi 2 d=E9cembre 2013 16:37
=C0 : dime@ietf.org
Objet : Re: [Dime] DOIC: Self-Contained OLRs<= /p>

 

I d= on't believe that Ben's proposal was to change the piggybacking assumption = in the baseline mechanism.  Ben's proposal is to design the solution i= n such a way that it is not dependent on the piggybacking transport mechanism. 

I share Ben's concern that we have over optimized the content of the overlo= ad report in a way that makes implementations brittle, interoperability mor= e difficult to achieve and extensibility more complex.  And what do we= gain from this optimization?  A few bites in answer messages.

Self contained overload reports, transported using the piggybacking mechani= sm, is a cleaner solution.

Steve

On 11/29/13 8:31 AM, lionel.morand@orange.com wrote:

I totally agree with Nirav. No need to revert at thi=
s stage the working assumption on piggybacking of OLR in application answer=
 messages, especially when the aim is to define a basic mechanism called &q=
uot;reduction".
 
Anyone would be able to further add extra info for o=
ptimization if needed but there is no need at all for the basic mechanism.<=
o:p>
 
Regards,
 
Lionel
 
-----Message d'origine-----
De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot (nsalot)
Envoy=E9 : vendredi 29 novembre 2013 12:24=

=C0 : Jouni Korhonen; Wiehe, Ulrich (NSN - DE/M=
unich); dime@ietf.org list<=
/span>
Cc : Ben Campbell
Objet : Re: [Dime] DOIC: Self-Contained OLRs
 
Jouni, Ben,
 
I am totally against the idea of self-contained OC-O=
LR specifically since we have adopted the principles of piggybacking the OC=
-OLR over existing application message.
Self-contained OC-OLR - which means adding all the i=
nformation which defines the scope of the OC-OLR into the OC-OLR - does not=
 make sense in the piggybacking approach. In fact, it is adding lot of info=
rmation, which is anyway available within the message containing the OC-OLR=
, into the OC-OLR. So it is adding lot of redundant information in a messag=
e which increases the processing requirement for the sender as well as the =
receiver. (And this is un-optimization, in my view).

 


Besides, I am not convinced with the other reasons p=
rovided here:


- One software module within a node can provide OC-O=
LR to another software module in the same node without passing other relate=
d info


   Within a node, based on the design, lot=
s of information may need to be passed between two software modules and we =
cannot optimize those aspects by replicating unnecessary information in a p=
rotocol message.


   In summary, it is node's internal softw=
are design issue and we need not optimize that at protocol level.


 


- Once the reporting node realizes that it is overlo=
aded, it has to wait for right answer to send OC-OLR

  What is the point of sending OC-OLR for a con=
text for which there is no messaging? Why should the reacting node care if =
it never sends a message for a context for which the reporting node is over=
loaded?


  So this waiting is justified since it ensures=
 that the overload is reported only when necessary and only to the applicab=
le reacting node. Not to all the nodes in the network.

 


- The agent needs to wait for the answer generated b=
y the server and the right context


   The same argument as applicable for the=
 server applies here. The agent need not send out-of-context overload info =
to a node.


   Why should reacting node receive/proces=
s/store the overload info for the scope for which it is not sending any mes=
sages.


 


- For sending OC-OLR in dedicated Diameter applicati=
on???


  Piggybacking was the first basic principle we=
 agreed before putting other principles in place. So we may want to go back=
 the drawing board if we decide to change this principle.=



 


Regards,


Nirav.


 


-----Original Message-----


From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen


Sent: Friday, November 29, 2013 2:50 PM


To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list


Cc: Ben Campbell


Subject: Re: [Dime] DOIC: Self-Contained OLRs


 


 


 


So, are we reaching any level of consensus here?


 


- JOuni


 


(as a note.. that we are converging back to where we=
 started with OLRs ;)


 


 


 


On Nov 28, 2013, at 12:40 PM, "Wiehe, Ulrich (N=
SN - DE/Munich)" <ulrich.wi=
ehe@nsn.com> wrote:


 




Hi,


 


another question:


 


If we go for explicit self contained OLRs, why would=
 we then need the ReportType?


 


The realm-type OLR would explicitly contain applicat=
ion-Id, Realm, but no Host whereas the host-type OLR would explicitly conta=
in application-Id, Host, but probably (I'm not sure) no Realm.


 


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 Korho=
nen; 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 inf=
o in answers received from a server behind but also from a server that woul=
d know this info by some internal magic.


But in any case, if we assume that the client will r=
eceived a successful answer from the server for an initial request with onl=
y Dest-Realm AVP, it should be possible to have both report types in the an=
swer: 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=E9 : jeudi 28 novembre 2013 =
10:26 =C0 : 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 on=
e OLR in an answer is aligned with the "endpoint principle". If t=
he 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 po=
int that the reporting end point is a server. How can the reporting end poi=
nt 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 pr=
ocedures 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 ove=
rload 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 o=
f 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 in=
fer several things from other context. In most cases, that context is in th=
e Diameter answer that carries the OLR. For example, the OLR implicitly ref=
ers to the application identified by the Application-Id field of the enclos=
ing answer, the realm identified by Origin-Realm, and so on. This means tha=
t the "meaning" of an OLR cannot be determined from the OLR conte=
nts alone; OLRs only have meaning in the context of the enclosing answer. I=
f you moved an OLR from one answer to another, it's meaning may change comp=
letely.


 


I think this approach is a mistake. I would greatly =
prefer that we explicitly include such values in the OLR itself, for multip=
le reasons:


 


1) It's more complex to interpret implicit, contextu=
al 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. F=
or example, I think a common software design for overload control processin=
g to be separated from application processing. The consumer cannot simply h=
and the OLR to that module and expect things to work. The OC module must no=
t only parse the OLR, but parse any other AVPs that are relevant. As OLR co=
ntents 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, ha=
rd-to-maintain code. Self-contained OLRs would keep all the information rel=
ated 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 cont=
ext to match the OLR--all those other AVPs have application or protocol lay=
er 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 se=
nd the OLR. This is particularly troublesome for agents, since they will ty=
pically 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 erro=
r prone implementations. Self-contained OLRs are simpler to create and send=
.


 


3) Implicit values don't work at all for certain pro=
blems. For 


example, if an agent needs to originate an OLR, it t=
ypically needs to 


insert that OLR into an existing Diameter answer cre=
ated 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 en=
closing answer, 


things break. (For examples of when an agent needs t=
o 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 ev=
olution of Diameter OC standards. For example, lets say we find a good reas=
on 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 o=
r significantly modified OLR format if we found a need to transport OLRs in=
 different ways. Self-contained OLRs would allow much greater flexibility.<=
o:p>


 


So, in summary, I think that self-contained OLRs wou=
ld lead to simpler implementations, less brittle deployments, and more flex=
ibility 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


 


____________________________________________________=
__________________


___________________________________________________<=
o:p>


 


Ce message et ses pieces jointes peuvent contenir de=
s informations 


confidentielles ou privilegiees et ne doivent donc p=
as etre diffuses, 


exploites ou copies sans autorisation. Si vous avez =
recu ce message 


par erreur, veuillez le signaler a l'expediteur et l=
e detruire ainsi que les pieces jointes. Les messages electroniques etant s=
usceptibles d'alteration, Orange decline toute responsabilite si ce message=
 a ete altere, deforme ou falsifie. Merci.


 


This message and its attachments may contain confide=
ntial 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 not=
ify the sender and delete this message and its attachments.


As emails may be altered, Orange is not liable for m=
essages 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


 


____________________________________________________=
_____________________________________________________________________<=
/o:p>


 


Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc


pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler


a l'expediteur et le detruire ainsi que les pieces j=
ointes. 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 confide=
ntial or privileged information that may be protected by law;


they should not be distributed, used or copied witho=
ut authorisation.


If you have received this email in error, please not=
ify the sender and delete this message and its attachments.


As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.


 


_______________________________________________=



DiME mailing list


DiME@ietf.org


https://www.ietf.org/mailman/listinfo/dime


 

 

____________________________________________________=
_____________________________________________________________________<=
/o:p>
 
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces j=
ointes. 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 confide=
ntial or privileged information that may be protected by law;
they should not be distributed, used or copied witho=
ut authorisation.
If you have received this email in error, please not=
ify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.
--_000_26C84DFD55BC3040A45BF70926E55F2587C1D0BASZXEMA512MBXchi_-- From maria.cruz.bartolome@ericsson.com Mon Dec 9 02:51:11 2013 Return-Path: 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 322221AE271 for ; Mon, 9 Dec 2013 02:51:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, 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 zgxCXhhe6_4k for ; Mon, 9 Dec 2013 02:51:00 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id C5EC21AD8F2 for ; Mon, 9 Dec 2013 02:50:58 -0800 (PST) X-AuditID: c1b4fb25-b7eff8e000000eda-9a-52a5a08c30cd Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 74.CD.03802.C80A5A25; Mon, 9 Dec 2013 11:50:53 +0100 (CET) Received: from ESESSMB101.ericsson.se ([169.254.1.197]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.02.0347.000; Mon, 9 Dec 2013 11:50:52 +0100 From: Maria Cruz Bartolome To: "dime@ietf.org" Thread-Topic: [Dime] DOIC: Self-Contained OLRs Thread-Index: AQHO8HrX2PaAGa/GgUyaCwjRxXVUh5pDChOAgAF7IoCAAC7igIAAKrUQgABohICAADmQAIAADvuAgAAFTgCAAATPgIAABekAgAAHnACABg+IwA== Date: Mon, 9 Dec 2013 10:50:52 +0000 Message-ID: <087A34937E64E74E848732CFF8354B9209739738@ESESSMB101.ericsson.se> 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> <14594_1386204165_529FCC05_14594_12646_1_6B7134B31289DC4FAF731D844122B36E329907@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B920972CCAA@ESESSMB101.ericsson.se> <52A077CC.3000004@usdonovans.com> <52A088D0.2020406@usdonovans.com> <52A091CE.2000104@usdonovans.com> <13081_1386256433_52A09831_13081_8197_1_6B7134B31289DC4FAF731D844122B36E32B6EB@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <13081_1386256433_52A09831_13081_8197_1_6B7134B31289DC4FAF731D844122B36E32B6EB@PEXCVZYM13.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: multipart/alternative; boundary="_000_087A34937E64E74E848732CFF8354B9209739738ESESSMB101erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrELMWRmVeSWpSXmKPExsUyM+JvrW7vgqVBBmcPcFjM7V3B5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujBftrxkLjrxhr1jSsI+xgfHYZ7YuRk4OCQETifVvtrJC2GIS F+6tB4pzcQgJHGKU2Lz8KJSzmFHi0u8GsCo2ATuJS6dfMHUxcnCICChLnP7lABIWFtCV2Hbq AzOILSKgJ/Hi5EomCLtOYsqCX4wgNouAisSPtefZQWxeAV+Jf1MeskDM38EhcWhbJzOIwynQ xijxfuZOsEmMQCd9P7UGbBKzgLjErSfzmSBOFZBYsuc8M4QtKvHy8T+oFxQldp5tZ4aoz5fY 9HQeM8Q2QYmTM5+wTGAUmYVk1CwkZbOQlEHE9SRuTJ3CBmFrSyxb+JoZwtaVmPHvEAuy+AJG 9lWM7LmJmTnp5UabGIHxcnDLb9UdjHfOiRxilOZgURLn/fDWOUhIID2xJDU7NbUgtSi+qDQn tfgQIxMHp1QDY6jckuk1E2fmBxy8/86/5f69nCS7H5ea5KR/KFe4CfTv+LZy2Z1ZZrXJ2mni vEZH9v6YesXqr0/xMV3LJ4VT/27oElvPuuU8M8/nhR++iuwvn7zq1qcfrGeUX504ZyRXaOcq vDnONiWjTdLPPr1Oc0LTwUvHG8Ve2DFzNZTFfyhM1I7T0rjcocRSnJFoqMVcVJwIANGFA29l AgAA 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 10:51:11 -0000 --_000_087A34937E64E74E848732CFF8354B9209739738ESESSMB101erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, Trying to focus on getting conclusions here. I totally agree with Nirav and Lionel: against to "self-contained" OLRs. /MCruz From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange= .com Sent: jueves, 05 de diciembre de 2013 16:14 To: Steve Donovan; Nirav Salot (nsalot); dime@ietf.org Subject: Re: [Dime] DOIC: Self-Contained OLRs Hi Steve, "I also don't think I agree this is a special architecture requirement, but= this requires some thought." I repeat one of my comments... being able to receive an OLR for another app= lication that the one carrying the report implies that there is functional = link between the functions, either a direct link or through a kind of centr= alized overload control function (or any equivalent function). And here is = the reason for my "STRONG NO" for the self-contained OLRs, based on the exi= sting requirements regarding Diameter overload control. Lionel De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan Envoy=E9 : jeudi 5 d=E9cembre 2013 15:47 =C0 : Nirav Salot (nsalot); dime@ietf.org Objet : Re: [Dime] DOIC: Self-Contained OLRs Nirav, Thanks for clarifying. This is obviously one area we have been making diff= erent assumptions. It's a good thing this thread went on this long. :-) One question, maybe for Maria Cruz. If it is never ok for an overload repo= rt to apply to an application other than the application carrying the messa= ge then how does the "all applications" extension proposed by Maria Cruz wo= rk? I will come back to address the "special architectural requirement" questio= n in a separate email. I think I understand the point you are making. I a= lso don't think I agree this is a special architecture requirement, but thi= s requires some thought. Steve On 12/5/13 8:25 AM, Nirav Salot (nsalot) wrote: Steve, We assumed that "self-contained OC-OLR" contains the same information as th= e message containing this AVP and hence we (me, JJ, Maria-Cruz) were saying= that consistency check is needed. But now I understand that "self-contained OC-OLR" can contain information o= f any context since the AVP itself defines the context explicitly. So appli= cation-X message can carry application-Y's OC-OLR and I do not agree to thi= s. In my view, this is totally against the existing principles of Diameter bas= ed applications. And hence this requires special support at the receiving n= ode as well as the sending node since today the nodes are designed to handl= e only application specific data. In summary, "self-contained OC-OLR" puts a special architectural requiremen= t on Diameter nodes - to handle one application's data from other applicati= on's message - and hence this is a strong reason for me to object to "self-= contained OC-OLR". Regards, Nirav. From: Steve Donovan [mailto:srdonovan@usdonovans.com] Sent: Thursday, December 05, 2013 7:38 PM To: Nirav Salot (nsalot); dime@ietf.org Subject: Re: [Dime] DOIC: Self-Contained OLRs I must admit that I don't understand the need for consistency. Why is it necessary to compare implicit and explicit data? If we use self = contained reports then the contents of the report are what should be used, = independent of the message that carries the report. Steve On 12/5/13 7:49 AM, Nirav Salot (nsalot) wrote: Steve, While gauging the complexity of "using the self-contained OC-OLR" It seems = you have overlooked the aspect identified by Maria-Cruz below (and JJ earli= er). > Duplication should be avoided, since then we need to assure consistency, = and error handing in case implicit and explicit data values are different f= or any reason... what means that it may always be required to check both im= plicit and explicit data. Regards, Nirav. From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: Thursday, December 05, 2013 6:26 PM To: dime@ietf.org Subject: Re: [Dime] DOIC: Self-Contained OLRs If we equating "complexity" with work done by a Diameter node, then there i= s added "complexity" for both proposals. The extra work that needs to be done for the self contained report approach= is that the reporter needs to add additional AVPs to the report. This is = hardly difficult but it is extra work. The extra work in the implicit approach is that the reactor needs to gather= information from multiple AVPs to understand the context of the AVP. Agai= n, hardly difficult but more work that can be avoided in a well layered sof= tware architecture. My conclusion is that the complexity argument does not apply. There is com= plexity in both, its just a matter of where the work is done. Steve On 12/5/13 3:29 AM, Nirav Salot (nsalot) wrote: Agree with Lionel's view and Maria-Cruz's arguments below. The "self-contained OC-OLR" - which I assume contains the same information = as present in the message containing the OC-OLR - adds extra complexity as = highlighted by Maria-Cruz. The benefit highlighted can be achieved in an implementation specific way b= y the receiver duplicating the information into OC-OLR before passing it to= the layer processing the OC-OLR. Regards, Nirav. -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Maria Cruz Bartolome Sent: Thursday, December 05, 2013 7:53 AM To: dime@ietf.org Subject: Re: [Dime] DOIC: Self-Contained OLRs Dear all, I agree with Lionel argumentation below. A part from that, one concern with "self-contained OLRs" is that some data= is duplicated. Duplication should be avoided, since then we need to assure= consistency, and error handing in case implicit and explicit data values a= re different for any reason... what means that it may always be required to= check both implicit and explicit data. Also, I think this is a pure implementation proposal. Regardless how the da= ta is transported it could be packed in a "self-contained OLRs" within the = diameter application, if for any implementation this is preferred. Regards /MCruz -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange= .com Sent: jueves, 05 de diciembre de 2013 1:43 To: Ben Campbell Cc: dime@ietf.org Subject: Re: [Dime] DOIC: Self-Contained OLRs Hi Ben, 3GPP operational requirements have triggered and driven this work, and 3GPP= will be the main client for this solution (if not the only for a while...)= . Main parties involved in the discussions are 3GPP vendors and 3GPP operat= ors. So instead trying to keep private preserve, we should welcome and enfo= rce cooperative work with 3GPP on this task if we want that the solution de= fined in IETF will be used in 3GPP. Otherwise, 3GPP may decide not to wait = for IETF and develop its own solution, as done in the past (e.g. developing= 3GPP-specific Cx application instead of adopting the IETF-standard Diamete= r SIP application). About the technical discussion, the Req31 says: REQ 31: There are multiple situations where a Diameter node may be overloaded for some purposes but not others. For example, this can happen to an agent or server that supports multiple applications, or when a server depends on multiple external resources, some of which may become overloaded while others are fully available. The solution MUST allow Diameter nodes to indicate overload with sufficient granularity to allow clients to take action based on the overloaded resources without unreasonably forcing available capacity to go unused. The solution MUST support specification of overload information with granularities of at least "Diameter node", "realm", and "Diameter application" and MUST allow extensibility for others to be added in the future. The "MUST" part says: enough granularity with at least host/realm and appli= cation. And the existing solution is compliant with this requirement. If a node is = supporting N applications, an OLR can be sent "per application" with a repo= rt type indicating if it is for the host or the realm. And the extensibilit= y capability is provided by the base solution. So my technical argument is that the existing proposal fulfills the basic r= equirements for an overload control without compromising future extension f= or further granularity. Regards, Lionel -----Message d'origine----- De : Ben Campbell [mailto:ben@nostrum.com] Envoy=E9 : mercredi 4 d=E9cembre= 2013 22:55 =C0 : MORAND Lionel IMT/OLN Cc : dime@ietf.org Objet : Re: [Dime] DOIC: Self-Contained OLRs On Dec 3, 2013, at 5:17 PM, lionel.morand@orange.com wrote: Hi Ben, I may be wrong somewhere in my summary but I think that it was the result o= f the discussions and agreements reached regarding existing requirements, a= t least from 3GPP point of view, compared to possible optimizations for fut= ure optimizations not so obvious. We are not the 3GPP. Our requirements are RFC 7068. I believe self-containe= d OLRs do a better job of meeting Req 31 than the contextually-defined OLRs= . I've made several technical arguments here--does anyone have _technical_ ar= guments in favor of contextually-defined OLRs? And because the solution offers extensibility via the definition of new alg= o, new report type and addition of any new AVP in the existing Grouped OLR,= the "limitations" of the proposed solution might be removed by someone if = really required according to new requirements. It might be worth considering a compromise approach: Define _optional_ AVPs= that allow an OLR to be self-contained. If they are not present, then the = various values default to those from the enclosing Diameter message. Possib= ly add support for this to the list of things that reacting nodes can adver= tise. This could be in the base, or in a follow on extension. (If left for an ext= ension, it's worth considering whether ReportType needs to be in the base, = or this or some other extension.) Regards, Lionel -----Message d'origine----- De : Ben Campbell [mailto:ben@nostrum.com] Envoy=E9 : mardi 3 d=E9cembre 2013 23:56 =C0 : MORAND Lionel IMT/OLN Cc : Steve Donovan; dime@ietf.org Objet : Re: [Dime] DOIC: Self-Contained OLRs On Dec 2, 2013, at 10:18 AM, lionel.morand@orange.com wrote: Hi Steve, I think that is not only about few bytes in the answer. It is also about th= e solution principles agreed so far: =B7 the current need is for an OLR bound to the application in use =B7 the OLR is received from the node targeted in the request. =B7 the OLR is defined per application I don't think those principles have been well tested. I don't recall any di= scussion of their benefits. What benefits do you see they have over self-co= ntained OLRs? All I see from these are restrictions in the flexibility of the solution, w= ith very little in return. So all the implicit information (application, origin-host, origin-realm) ar= e meaningful in this context. And the actual solution is designed based on these assumptions. The extensi= bility of the solution will allow extra info if required in other use cases= but it was agreed to go with a straightforward solution that will satisfy = most of us. Regards, Lionel De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan Envoy=E9 : lundi 2 d=E9cembre 2013 16:37 =C0 : dime@ietf.org Objet : Re: [Dime] DOIC: Self-Contained OLRs I don't believe that Ben's proposal was to change the piggybacking assumpti= on in the baseline mechanism. Ben's proposal is to design the solution in = such a way that it is not dependent on the piggybacking transport mechanism= . I share Ben's concern that we have over optimized the content of the overlo= ad report in a way that makes implementations brittle, interoperability mor= e difficult to achieve and extensibility more complex. And what do we gain= from this optimization? A few bites in answer messages. Self contained overload reports, transported using the piggybacking mechani= sm, is a cleaner solution. Steve On 11/29/13 8:31 AM, lionel.morand@orange.com wrote: I totally agree with Nirav. No need to revert at this stage the working ass= umption on piggybacking of OLR in application answer messages, especially w= hen the aim is to define a basic mechanism called "reduction". Anyone would be able to further add extra info for optimization if needed b= ut there is no need at all for the basic mechanism. Regards, Lionel -----Message d'origine----- De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot (nsalot) Envoy=E9 : vendredi 29 novembre 2013 12:24 =C0 : Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list Cc : Ben Campbell Objet : Re: [Dime] DOIC: Self-Contained OLRs Jouni, Ben, I am totally against the idea of self-contained OC-OLR specifically since w= e have adopted the principles of piggybacking the OC-OLR over existing appl= ication message. Self-contained OC-OLR - which means adding all the information which define= s the scope of the OC-OLR into the OC-OLR - does not make sense in the pigg= ybacking approach. In fact, it is adding lot of information, which is anywa= y available within the message containing the OC-OLR, into the OC-OLR. So i= t is adding lot of redundant information in a message which increases the p= rocessing requirement for the sender as well as the receiver. (And this is = un-optimization, in my view). Besides, I am not convinced with the other reasons provided here: - One software module within a node can provide OC-OLR to another software = module in the same node without passing other related info Within a node, based on the design, lots of information may need to be pa= ssed between two software modules and we cannot optimize those aspects by r= eplicating unnecessary information in a protocol message. In summary, it is node's internal software design issue and we need not o= ptimize that at protocol level. - Once the reporting node realizes that it is overloaded, it has to wait fo= r right answer to send OC-OLR What is the point of sending OC-OLR for a context for which there is no me= ssaging? Why should the reacting node care if it never sends a message for = a context for which the reporting node is overloaded? So this waiting is justified since it ensures that the overload is reporte= d only when necessary and only to the applicable reacting node. Not to all = the nodes in the network. - The agent needs to wait for the answer generated by the server and the ri= ght context The same argument as applicable for the server applies here. The agent ne= ed not send out-of-context overload info to a node. Why should reacting node receive/process/store the overload info for the = scope for which it is not sending any messages. - For sending OC-OLR in dedicated Diameter application??? Piggybacking was the first basic principle we agreed before putting other = principles in place. So we may want to go back the drawing board if we deci= de to change this principle. Regards, Nirav. -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen Sent: Friday, November 29, 2013 2:50 PM To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org li= st Cc: Ben Campbell Subject: Re: [Dime] DOIC: Self-Contained OLRs So, are we reaching any level of consensus here? - JOuni (as a note.. that we are converging back to where we started with OLRs ;) On Nov 28, 2013, at 12:40 PM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: Hi, another question: If we go for explicit self contained OLRs, why would we then need the Repor= tType? The realm-type OLR would explicitly contain application-Id, Realm, but no H= ost whereas the host-type OLR would explicitly contain application-Id, Host= , but probably (I'm not sure) no Realm. 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 stat= us. It could be provided an agent inserting this info in answers received f= rom a server behind but also from a server that would know this info by som= e internal magic. But in any case, if we assume that the client will received a successful an= swer from the server for an initial request with only Dest-Realm AVP, it sh= ould be possible to have both report types in the answer: one for the serve= r itself, one for the realm for new request sent to the realm with only Des= t-Realm AVP. Lionel -----Message d'origine----- De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN - DE/Munich) Envoy=E9 : jeudi 28 novembre 2013 10:26 =C0 : 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 a= ligned with the "endpoint principle". If the ReportType is "realm" this ind= icates 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 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 re= acting 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 Diamet= er request that corresponds to the answer containing the OLR. My reasons fo= r 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 i= dentified by Origin-Realm, and so on. This means that the "meaning" of an O= LR 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 answe= r to another, it's meaning may change completely. I think this approach is a mistake. I would greatly prefer that we explicit= ly 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 variou= s other AVPs to find all the information it needs. For example, I think a c= ommon software design for overload control processing to be separated from = application processing. The consumer cannot simply hand the OLR to that mod= ule and expect things to work. The OC module must not only parse the OLR, b= ut parse any other AVPs that are relevant. As OLR contents get extended (as= sumedly following the same strategy as the base spec), the number of "conte= xt" avps that must be interpreted can grow large. This approach is error pr= one, and will likely encourage brittle, hard-to-maintain code. Self-contain= ed OLRs would keep all the information related to overload in one place. ma= king for simpler implementations. 2) It's more complex for the reporting node to send implicit values than ex= plicit values. The sender cannot simply set the context to match the OLR--a= ll those other AVPs have application or protocol layer meanings. Once a rep= orting node realizes that it is overloade, it has to wait for the right ans= wer that contains the right context before it can send the OLR. This is par= ticularly 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 sig= nificantly. 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 so= me 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 overlo= ad reports were self-contained, one could just reuse the report format we s= pecify here. But if the meaning of an OLR depends on the way it's transport= ed, this won't work. We would have to create a new or significantly modifie= d OLR format if we found a need to transport OLRs in different ways. Self-c= ontained OLRs would allow much greater flexibility. So, in summary, I think that self-contained OLRs would lead to simpler impl= ementations, less brittle deployments, and more flexibility for future evol= ution 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 le= s pieces jointes. Les messages electroniques etant susceptibles d'alteratio= n, 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 dis= tributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te 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 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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 confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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 confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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 confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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 confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. --_000_087A34937E64E74E848732CFF8354B9209739738ESESSMB101erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello,<= /p>

 <= /p>

Trying to focus on gettin= g conclusions here.

I totally agree with Nira= v and Lionel: against to “self-contained” OLRs.

 <= /p>

/MCruz<= /p>

 <= /p>

 <= /p>

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange.com
Sent: jueves, 05 de diciembre de 2013 16:14
To: Steve Donovan; Nirav Salot (nsalot); dime@ietf.org
Subject: Re: [Dime] DOIC: Self-Contained OLRs

 

Hi Steve,

 

"I also don't= think I agree this is a special architecture requirement, but this require= s some thought."

 <= /p>

I repeat one of my commen= ts… being able to receive an OLR for another application that the one= carrying the report implies that there is functional link between the functions, either a direct link or through a kind of centralized overl= oad control function (or any equivalent function). And here is the reason f= or my "STRONG NO" for the self-contained OLRs, based on the exist= ing requirements regarding Diameter overload control.

 <= /p>

Lionel<= /p>

 <= /p>

De = : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9 : jeudi 5 d=E9cembre 2013 15:47
=C0 : Nirav Salot (nsalot); di= me@ietf.org
Objet : Re: [Dime] DOIC: Self-Contained OLRs<= /p>

 

Nir= av,

Thanks for clarifying.  This is obviously one area we have been making= different assumptions.  It's a good thing  this thread went on t= his long. :-)

One question, maybe for Maria Cruz.  If it is never ok for an overload= report to apply to an application other than the application carrying the = message then how does the "all applications" extension proposed b= y Maria Cruz work?

I will come back to address the "special architectural requirement&quo= t; question in a separate email.  I think I understand the point you a= re making.  I also don't think I agree this is a special architecture = requirement, but this requires some thought.

Steve

On 12/5/13 8:25 AM, Nirav Salot (n= salot) wrote:

Steve,=

 =

We assumed th= at "self-contained OC-OLR" contains the same information as the m= essage containing this AVP and hence we (me, JJ, Maria-Cruz) were saying that consistency check is needed.

 =

But now I und= erstand that "self-contained OC-OLR" can contain information of a= ny context since the AVP itself defines the context explicitly. So applicat= ion-X message can carry application-Y's OC-OLR and I do not agree to this.

In my view, t= his is totally against the existing principles of Diameter based applicatio= ns. And hence this requires special support at the receiving node as well as the sending node since today the nodes are designed to han= dle only application specific data.

 =

In summary, &= quot;self-contained OC-OLR" puts a special architectural requirement o= n Diameter nodes – to handle one application's data from other applic= ation's message – and hence this is a strong reason for me to object to &quo= t;self-contained OC-OLR".

 =

Regards,

Nirav.=

 =

From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Thursday, December 05, 2013 7:38 PM
To: Nirav Salot (nsalot); dime@ietf= .org
Subject: Re: [Dime] DOIC: Self-Contained OLRs

 

I m= ust admit that I don't understand the need for consistency.

Why is it necessary to compare implicit and explicit data?  If we use = self contained reports then the contents of the report are what should be u= sed, independent of the message that carries the report.

Steve

On 12/5/13 7:49 AM, Nirav Salot (n= salot) wrote:

Steve,=

 =

While gauging= the complexity of "using the self-contained OC-OLR" It seems you= have overlooked the aspect identified by Maria-Cruz below (and JJ earlier)= .

> Duplication should be avoided, since then we need to assur= e consistency, and error handing in case implicit and explicit data values are different for any reason... what means that it may always = be required to check both implicit and explicit data.

 =

Regards,

Nirav.=

 =

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: Thursday, December 05, 2013 6:26 PM
To: dime@ietf.org
Subject: Re: [Dime] DOIC: Self-Contained OLRs

 

If = we equating "complexity" with work done by a Diameter node, then = there is added "complexity" for both proposals.

The extra work that needs to be done for the self contained report approach= is that the reporter needs to add additional AVPs to the report.  Thi= s is hardly difficult but it is extra work.

The extra work in the implicit approach is that the reactor needs to gather= information from multiple AVPs to understand the context of the AVP. = Again, hardly difficult but more work that can be avoided in a well layere= d software architecture.

My conclusion is that the complexity argument does not apply.  There i= s complexity in both, its just a matter of where the work is done.

Steve

On 12/5/13 3:29 AM, Nirav Salot (n= salot) wrote:

Agree with Lionel's view and Maria-Cruz's arguments below.<=
/o:p>
 
The "self-contained OC-OLR" - which I assume contains =
the same information as present in the message containing the OC-OLR - adds=
 extra complexity as highlighted by Maria-Cruz.
The benefit highlighted can be achieved in an implementation spe=
cific way by the receiver duplicating the information into OC-OLR before pa=
ssing it to the layer processing the OC-OLR.
 
Regards,
Nirav.
 
-----Original Message-----
From: DiME [mailto:dime=
-bounces@ietf.org] On Behalf Of Maria Cruz Bartolome<=
/pre>

Sent: Thursday, December 05, 2013 7:53 AM

To: dime@ietf.org


Subject: Re: [Dime] DOIC: Self-Contained OLRs<=
/pre>

 


Dear all,


 


I agree with Lionel argumentation below.


 


A part from that,  one concern with "self-contained OL=
Rs" is that some data is duplicated. Duplication should be avoided, si=
nce then we need to assure consistency, and error handing in case implicit =
and explicit data values are different for any reason... what means that it=
 may always be required to check both implicit and explicit data.


 


Also, I think this is a pure implementation proposal. Regardless=
 how the data is transported it could be packed in a "self-contained O=
LRs" within the diameter application, if for any implementation this i=
s preferred.


 


Regards


/MCruz


 


 


-----Original Message-----


From: DiME [mailto:dime=
-bounces@ietf.org] On Behalf Of lionel.morand@orange.com


Sent: jueves, 05 de diciembre de 2013 1:43

To: Ben Campbell


Cc: dime@ietf.org


Subject: Re: [Dime] DOIC: Self-Contained OLRs<=
/pre>

 


Hi Ben,


 


3GPP operational requirements have triggered and driven this wor=
k, and 3GPP will be the main client for this solution (if not the only for =
a while...). Main parties involved in the discussions are 3GPP vendors and =
3GPP operators. So instead trying to keep private preserve, we should welco=
me and enforce cooperative work with 3GPP on this task if we want that the =
solution defined in IETF will be used in 3GPP. Otherwise, 3GPP may decide n=
ot to wait for IETF and develop its own solution, as done in the past (e.g.=
 developing 3GPP-specific Cx application instead of adopting the IETF-stand=
ard Diameter SIP application).


 


About the technical discussion, the Req31 says:


 


   REQ 31: There are multiple situations where a Diame=
ter node may be


           ove=
rloaded for some purposes but not others.  For example,


           thi=
s can happen to an agent or server that supports multiple=



           app=
lications, or when a server depends on multiple external<=
/pre>

           res=
ources, some of which may become overloaded while others<=
/pre>

           are=
 fully available.  The solution MUST allow Diameter nodes


           to =
indicate overload with sufficient granularity to allow

           cli=
ents to take action based on the overloaded resources

           wit=
hout unreasonably forcing available capacity to go unused.


           The=
 solution MUST support specification of overload


           inf=
ormation with granularities of at least "Diameter node",


           &qu=
ot;realm", and "Diameter application" and MUST allow


           ext=
ensibility for others to be added in the future.


 


The "MUST" part says: enough granularity with at least=
 host/realm and application.


And the existing solution is compliant with this requirement. If=
 a node is supporting N applications, an OLR can be sent "per applicat=
ion" with a report type indicating if it is for the host or the realm.=
 And the extensibility capability is provided by the base solution.


 


So my technical argument is that the existing proposal fulfills =
the basic requirements for an overload control without compromising future =
extension for further granularity.


 


Regards,


 


Lionel 


 


-----Message d'origine-----


De : Ben Campbell [mailt=
o:ben@nostrum.com] Envoy=E9 : mercredi 4 d=E9cembre 2013 22:55 =C0=
 : MORAND Lionel IMT/OLN Cc : di=
me@ietf.org Objet : Re: [Dime] DOIC: Self-Contained OLRs


 


On Dec 3, 2013, at 5:17 PM, lionel.morand@orange.com wrote:


 




Hi Ben,


 


I may be wrong somewhere in my summary but I think that it was t=
he result of the discussions and agreements reached regarding existing requ=
irements, at least from 3GPP point of view, compared to possible optimizati=
ons for future optimizations not so obvious.




 


We are not the 3GPP. Our requirements are RFC 7068. I believe se=
lf-contained OLRs do a better job of meeting Req 31 than the contextually-d=
efined OLRs.


 


I've made several technical arguments here--does anyone have _te=
chnical_ arguments in favor of contextually-defined OLRs?=



 




And because the solution offers extensibility via the definition=
 of new algo, new report type and addition of any new AVP in the existing G=
rouped OLR, the "limitations" of the proposed solution might be r=
emoved by someone if really required according to new requirements.


 




 


It might be worth considering a compromise approach: Define _opt=
ional_ AVPs that allow an OLR to be self-contained. If they are not present=
, then the various values default to those from the enclosing Diameter mess=
age. Possibly add support for this to the list of things that reacting node=
s can advertise.


 


This could be in the base, or in a follow on extension. (If left=
 for an extension, it's worth considering whether ReportType needs to be in=
 the base, or this or some other extension.) 


 


 




Regards,


 


Lionel


 


-----Message d'origine-----


De : Ben Campbell [mailto:ben=
@nostrum.com] Envoy=E9 : mardi 3 d=E9cembre 


2013 23:56 =C0 : MORAND Lionel IMT/OLN Cc : Steve Donovan; dime@ietf.org 


Objet : Re: [Dime] DOIC: Self-Contained OLRs

 


 


On Dec 2, 2013, at 10:18 AM, lionel.morand@orange.com wrote:


 




Hi Steve,


 


I think that is not only about few bytes in the answer. It is al=
so about the solution principles agreed so far:


=B7         the current =
need is for an OLR bound to the application in use


=B7         the OLR is r=
eceived from the node targeted in the request.


=B7         the OLR is d=
efined per application




 


I don't think those principles have been well tested. I don't re=
call any discussion of their benefits. What benefits do you see they have o=
ver self-contained OLRs?


 


All I see from these are restrictions in the flexibility of the =
solution, with very little in return.


 




So all the implicit information (application, origin-host, origi=
n-realm) are meaningful in this context.


And the actual solution is designed based on these assumptions. =
The extensibility of the solution will allow extra info if required in othe=
r use cases but it was agreed to go with a straightforward solution that wi=
ll satisfy most of us.


 


Regards,


 


Lionel


 


De : DiME [mailto:dime-=
bounces@ietf.org] De la part de Steve Donovan


Envoy=E9 : lundi 2 d=E9cembre 2013 16:37


=C0 : dime@ietf.org


Objet : Re: [Dime] DOIC: Self-Contained OLRs

 


I don't believe that Ben's proposal was to change the piggybacki=
ng assumption in the baseline mechanism.  Ben's proposal is to design =
the solution in such a way that it is not dependent on the piggybacking tra=
nsport mechanism.  


 


I share Ben's concern that we have over optimized the content of=
 the overload report in a way that makes implementations brittle, interoper=
ability more difficult to achieve and extensibility more complex.  And=
 what do we gain from this optimization?  A few bites in answer messag=
es.


 


Self contained overload reports, transported using the piggyback=
ing mechanism, is a cleaner solution.


 


Steve


 


On 11/29/13 8:31 AM, lionel.morand@orange.com wrote:


I totally agree with Nirav. No need to revert at this stage the =
working assumption on piggybacking of OLR in application answer messages, e=
specially when the aim is to define a basic mechanism called "reductio=
n".


 


Anyone would be able to further add extra info for optimization =
if needed but there is no need at all for the basic mechanism.


 


Regards,


 


Lionel


 


-----Message d'origine-----


De : DiME [mailto:dime-=
bounces@ietf.org] De la part de Nirav Salot (nsalot)<=
/pre>

Envoy=E9 : vendredi 29 novembre 2013 12:24

=C0 : Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list


Cc : Ben Campbell


Objet : Re: [Dime] DOIC: Self-Contained OLRs

 


Jouni, Ben,


 


I am totally against the idea of self-contained OC-OLR specifica=
lly since we have adopted the principles of piggybacking the OC-OLR over ex=
isting application message.


Self-contained OC-OLR - which means adding all the information w=
hich defines the scope of the OC-OLR into the OC-OLR - does not make sense =
in the piggybacking approach. In fact, it is adding lot of information, whi=
ch is anyway available within the message containing the OC-OLR, into the O=
C-OLR. So it is adding lot of redundant information in a message which incr=
eases the processing requirement for the sender as well as the receiver. (A=
nd this is un-optimization, in my view).


 


Besides, I am not convinced with the other reasons provided here=
:


- One software module within a node can provide OC-OLR to anothe=
r software module in the same node without passing other related info<=
/o:p>


  Within a node, based on the design, lots of information m=
ay need to be passed between two software modules and we cannot optimize th=
ose aspects by replicating unnecessary information in a protocol message.


  In summary, it is node's internal software design issue a=
nd we need not optimize that at protocol level.


 


- Once the reporting node realizes that it is overloaded, it has=
 to wait for right answer to send OC-OLR


 What is the point of sending OC-OLR for a context for which the=
re is no messaging? Why should the reacting node care if it never sends a m=
essage for a context for which the reporting node is overloaded?=



 So this waiting is justified since it ensures that the overload=
 is reported only when necessary and only to the applicable reacting node. =
Not to all the nodes in the network.


 


- The agent needs to wait for the answer generated by the server=
 and the right context


  The same argument as applicable for the server applies he=
re. The agent need not send out-of-context overload info to a node.


  Why should reacting node receive/process/store the overlo=
ad info for the scope for which it is not sending any messages.<=
/span>


 


- For sending OC-OLR in dedicated Diameter application???


 Piggybacking was the first basic principle we agreed before put=
ting other principles in place. So we may want to go back the drawing board=
 if we decide to change this principle.


 


Regards,


Nirav.


 


-----Original Message-----


From: DiME [mailto:dime=
-bounces@ietf.org] On Behalf Of Jouni Korhonen


Sent: Friday, November 29, 2013 2:50 PM


To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list


Cc: Ben Campbell


Subject: Re: [Dime] DOIC: Self-Contained OLRs<=
/pre>

 


 


 


So, are we reaching any level of consensus here?


 


- JOuni


 


(as a note.. that we are converging back to where we started wit=
h OLRs ;)


 


 


 


On Nov 28, 2013, at 12:40 PM, "Wiehe, Ulrich (NSN - DE/Muni=
ch)" <ulrich.wiehe@nsn.com&=
gt; wrote:


 


Hi,


 


another question:


 


If we go for explicit self contained OLRs, why would we then nee=
d the ReportType?


 


The realm-type OLR would explicitly contain application-Id, Real=
m, but no Host whereas the host-type OLR would explicitly contain applicati=
on-Id, Host, but probably (I'm not sure) no Realm.


 


Ulrich


 


 


 


-----Original Message-----


From: ext lionel.mor=
and@orange.com [mailto:lion=
el.morand@orange.com]


Sent: Thursday, November 28, 2013 10:31 AM

To: Wiehe, Ulrich (NSN - DE/Munich); ext Jouni Korhonen; Ben Cam=
pbell


Cc: dime@ietf.org list=



Subject: RE: [Dime] DOIC: Self-Contained OLRs<=
/pre>

 


Hi,


 


There is no assumption on which entity is providing the realm ov=
erload 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 su=
ccessful 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 fo=
r the server itself, one for the realm for new request sent to the realm wi=
th 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=E9 : jeudi 28 novembre 2013 10:26 =C0 : =
ext Jouni 


Korhonen; Ben Campbell Cc : dim=
e@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 ReportTyp=
e is "realm" this indicates to the reacting end point that the re=
porting end point is an agent (e.g. SFE) rather than a server. If the Repor=
tType 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 a=
gent 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<=
/pre>

 


 


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, t=
he 


ReportType fits well to the "endpoint principle" we ha=
ve in the draft. 


It indeed gives more tools to make a host vs. realm base decisio=
n 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 fr=
om 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 thr=
ead.


 


As currently described, a consumer of an OLR must infer several =
things from other context. In most cases, that context is in the Diameter a=
nswer that carries the OLR. For example, the OLR implicitly refers to the a=
pplication 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; O=
LRs 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:<=
o:p>


 


1) It's more complex to interpret implicit, contextual values th=
an explicit values. The consumer cannot simply look at the OLR; it must loo=
k 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 sepa=
rated 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 e=
xtended (assumedly following the same strategy as the base spec), the numbe=
r of "context" avps that must be interpreted can grow large. This=
 approach is error prone, and will likely encourage brittle, hard-to-mainta=
in code. Self-contained OLRs would keep all the information related to over=
load in one place. making for simpler implementations.

 


2) It's more complex for the reporting node to send implicit val=
ues 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 th=
e 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 impl=
ementations. Self-contained OLRs are simpler to create and send.=



 


3) Implicit values don't work at all for certain problems. For <=
o:p>


example, if an agent needs to originate an OLR, it typically nee=
ds to 


insert that OLR into an existing Diameter answer created by a se=
rver. 


It can't create its own answer without affecting the application=
 


state. If the responding node assumes the OLR comes from or refe=
rs to 


the node identified by the Origin-Host AVP in the enclosing answ=
er, 


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 over=
load 


draft, or my dh/dr example.)


 


OTOH, explicit values will work for all cases where we need to a=
ssociate some arbitrary value with an OLR.


 


4) Implicit values seriously constrain the future evolution of D=
iameter 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 significan=
tly modified OLR format if we found a need to transport OLRs in different w=
ays. Self-contained OLRs would allow much greater flexibility.


 


So, in summary, I think that self-contained OLRs would lead to s=
impler implementations, less brittle deployments, and more flexibility for =
future evolution of standards.


 


Thanks!


 


Ben.


_______________________________________________


DiME mailing list


DiME@ietf.org


https://w=
ww.ietf.org/mailman/listinfo/dime


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://w=
ww.ietf.org/mailman/listinfo/dime


_______________________________________________


DiME mailing list


DiME@ietf.org


https://w=
ww.ietf.org/mailman/listinfo/dime


 


________________________________________________________________=
______


___________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informatio=
ns 


confidentielles ou privilegiees et ne doivent donc pas etre diff=
uses, 


exploites ou copies sans autorisation. Si vous avez recu ce mess=
age 


par erreur, veuillez le signaler a l'expediteur et le detruire a=
insi que les pieces jointes. Les messages electroniques etant susceptibles =
d'alteration, Orange decline toute responsabilite si ce message a ete alter=
e, 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 send=
er 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://w=
ww.ietf.org/mailman/listinfo/dime


_______________________________________________


DiME mailing list


DiME@ietf.org


https://w=
ww.ietf.org/mailman/listinfo/dime


 


________________________________________________________________=
_________________________________________________________=



 


Ce message et ses pieces jointes peuvent contenir des informatio=
ns confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vou=
s 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 pri=
vileged information that may be protected by law;


they should not be distributed, used or copied without authorisa=
tion.


If you have received this email in error, please notify the send=
er 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://w=
ww.ietf.org/mailman/listinfo/dime


 


 


________________________________________________________________=
_________________________________________________________=



 


Ce message et ses pieces jointes peuvent contenir des informatio=
ns confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vou=
s 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 pri=
vileged information that may be protected by law;


they should not be distributed, used or copied without authorisa=
tion.


If you have received this email in error, please notify the send=
er 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://w=
ww.ietf.org/mailman/listinfo/dime




 


 


________________________________________________________________=
_________________________________________________________=



 


Ce message et ses pieces jointes peuvent contenir des informatio=
ns confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vou=
s 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 pri=
vileged information that may be protected by law;


they should not be distributed, used or copied without authorisa=
tion.


If you have received this email in error, please notify the send=
er 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://w=
ww.ietf.org/mailman/listinfo/dime




 


 


________________________________________________________________=
_________________________________________________________=



 


Ce message et ses pieces jointes peuvent contenir des informatio=
ns confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vou=
s 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 pri=
vileged information that may be protected by law;


they should not be distributed, used or copied without authorisa=
tion.


If you have received this email in error, please notify the send=
er 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://w=
ww.ietf.org/mailman/listinfo/dime


_______________________________________________


DiME mailing list


DiME@ietf.org


https://w=
ww.ietf.org/mailman/listinfo/dime


_______________________________________________


DiME mailing list


DiME@ietf.org


https://w=
ww.ietf.org/mailman/listinfo/dime


 

 

 

 

________________________________________________________________=
_________________________________________________________=

 
Ce message et ses pieces jointes peuvent contenir des informatio=
ns confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vou=
s 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 pri=
vileged information that may be protected by law;


they should not be distributed, used or copied without authorisa=
tion.


If you have received this email in error, please notify the send=
er 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.
--_000_087A34937E64E74E848732CFF8354B9209739738ESESSMB101erics_-- From susan.shishufeng@huawei.com Mon Dec 9 02:52:57 2013 Return-Path: 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 5E6681AD8F2 for ; Mon, 9 Dec 2013 02:52:57 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 kQ0zkDyrcHUA for ; Mon, 9 Dec 2013 02:52:54 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6947A1AE272 for ; Mon, 9 Dec 2013 02:52:52 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBD96696; Mon, 09 Dec 2013 10:52:46 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 9 Dec 2013 10:52:25 +0000 Received: from SZXEMA405-HUB.china.huawei.com (10.82.72.37) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 9 Dec 2013 10:52:29 +0000 Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.155]) by SZXEMA405-HUB.china.huawei.com ([10.82.72.37]) with mapi id 14.03.0158.001; Mon, 9 Dec 2013 18:52:18 +0800 From: "Shishufeng (Susan)" To: Maria Cruz Bartolome , "dime@ietf.org" Thread-Topic: [Dime] OLR applicable for any/all applications Thread-Index: AQHO8AhKXZeJPtoJpkKNcVZUfn/T85pLuGcg Date: Mon, 9 Dec 2013 10:52:17 +0000 Message-ID: <26C84DFD55BC3040A45BF70926E55F2587C1D0F1@SZXEMA512-MBX.china.huawei.com> References: <087A34937E64E74E848732CFF8354B920972BE0C@ESESSMB101.ericsson.se> In-Reply-To: <087A34937E64E74E848732CFF8354B920972BE0C@ESESSMB101.ericsson.se> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.146.62.57] Content-Type: multipart/alternative; boundary="_000_26C84DFD55BC3040A45BF70926E55F2587C1D0F1SZXEMA512MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [Dime] OLR applicable for any/all applications X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 10:52:57 -0000 --_000_26C84DFD55BC3040A45BF70926E55F2587C1D0F1SZXEMA512MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi MCruz, I don't see any use case at least in 3GPP for this. There is no more than o= ne application between two nodes so far. And even the case is valid, it cou= ld be reached by multiple sending of the overload report per application, w= hich could be seen as an optimization in the future if there is clear scena= rio for such an optimization. Best Regards, Susan From: Maria Cruz Bartolome [mailto:maria.cruz.bartolome@ericsson.com] Sent: Tuesday, December 03, 2013 4:43 PM To: dime@ietf.org Subject: [Dime] OLR applicable for any/all applications Dear all, There may be a need by a reporting node to request traffic reduction for al= l traffic, application independent, e.g. if an operator's network becomes s= everely overloaded, it may be of interest to signal directly general overlo= ad to the client. In this case, since reacting node obtains affected application from the app= lication message, we may need to extend OLR. At least we got following options: A) Define a new optional AVP that could be included into OLR, like e.g.= : OC-OLR ::=3D < AVP Header: TBD2 > < TimeStamp > [ Reduction-Percentage ] [ ValidityDuration ] [ ReportType ] [All applications] * [ AVP ] B) Extend ReportTypes like e.g.: 3 Destination-Host All Applications report. Similar to Destination-Hos= t report but it would apply to any application regardless the application m= essage this report is received within. 4 Realm (aggregated) All Applications report. Similar to Realm report = but it would apply to any application regardless the application message th= is report is received within. I tend to prefer option A, but let me know your opinions and preferences. Best regards /MCruz --_000_26C84DFD55BC3040A45BF70926E55F2587C1D0F1SZXEMA512MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi MCruz,

 

I don’t see any use case at least in 3GPP for this. There i= s no more than one application between two nodes so far. And even the case = is valid, it could be reached by multiple sending of the overload report per application, which could be seen as an optimiza= tion in the future if there is clear scenario for such an optimization.

 

Best Regards,

Susan

 

From: Maria Cruz Bartolome [mailto:maria.cruz.bartolome@eri= csson.com]
Sent: Tuesday, December 03, 2013 4:43 PM
To: dime@ietf.org
Subject: [Dime] OLR applicable for any/all applications

 

 

Dear all,

 

= There may be a need by a reporting node to request traffic reduction for al= l traffic, application independent, e.g. if an operator’s network bec= omes severely overloaded, it may be of interest to signal directly general overload to the client. 

In this case, since reacting no= de obtains affected application from the application message, we may need t= o extend OLR.

 

At least we got following optio= ns:

 

 

A= )   &= nbsp; Define a new optional A= VP that could be included into OLR, like e.g.:

   OC-OLR ::=3D < AVP Header: TBD2 &g=
t;
        &n=
bsp;     < TimeStamp >
        &n=
bsp;     [ Reduction-Percentage ]

        &n=
bsp;     [ ValidityDuration ]


        &n=
bsp;     [ ReportType ]


        &n=
bsp;     [All applications]


        &n=
bsp;   * [ AVP ]


 


 



B=
)   &=
nbsp; 
Extend  ReportType=
s like e.g.:


 


   3  Destination-Host
All Applications
report.  Similar to Destination-Host repor=
t but it would apply to any application regardless the application message =
this report is received within.


 


   4  Realm (aggregated)
All Applications repo=
rt.  Similar to Realm report but it would apply to any application
 regardless the application message this report is received within.<=
span lang=3D"EN-US">


 


 


 


I tend to prefer option A, but =
let me know your opinions and preferences.


Best regards<=
/p>

/MCruz


 


 
--_000_26C84DFD55BC3040A45BF70926E55F2587C1D0F1SZXEMA512MBXchi_-- From maria.cruz.bartolome@ericsson.com Mon Dec 9 02:55:12 2013 Return-Path: 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 19DAC1AE272 for ; Mon, 9 Dec 2013 02:55:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.239 X-Spam-Level: X-Spam-Status: No, score=-1.239 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 mlZmuCK5mM4S for ; Mon, 9 Dec 2013 02:55:10 -0800 (PST) Received: from sesbmg21.mgmt.ericsson.se (sesbmg21.ericsson.net [193.180.251.49]) by ietfa.amsl.com (Postfix) with ESMTP id 368161AE271 for ; Mon, 9 Dec 2013 02:55:08 -0800 (PST) X-AuditID: c1b4fb31-b7fa78e0000005dd-b1-52a5a1872e4f Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg21.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 3E.EC.01501.781A5A25; Mon, 9 Dec 2013 11:55:03 +0100 (CET) Received: from ESESSMB101.ericsson.se ([169.254.1.197]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.02.0347.000; Mon, 9 Dec 2013 11:55:02 +0100 From: Maria Cruz Bartolome To: "dime@ietf.org" Thread-Topic: [Dime] OLR applicable for any/all applications Thread-Index: Ac7wA2nX03YOMS5NT1qqOpqV4/v8iQEwO5OAAAImNvA= Date: Mon, 9 Dec 2013 10:55:02 +0000 Message-ID: <087A34937E64E74E848732CFF8354B9209739774@ESESSMB101.ericsson.se> References: <087A34937E64E74E848732CFF8354B920972BE0C@ESESSMB101.ericsson.se> <26C84DFD55BC3040A45BF70926E55F2587C1D0F1@SZXEMA512-MBX.china.huawei.com> In-Reply-To: <26C84DFD55BC3040A45BF70926E55F2587C1D0F1@SZXEMA512-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: multipart/alternative; boundary="_000_087A34937E64E74E848732CFF8354B9209739774ESESSMB101erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM+JvrW77wqVBBi8e61rM7V3B5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujKdzj7IWLO5jrGh8uoOtgfFXXRcjB4eEgInEjYlRXYycQKaY xIV769m6GLk4hAROMEo0Lm9jh3AWM0p0flrFDFLFJmAncen0CyaQZhEBZYnTvxxAwsIC1hKf Ll1iA7FFBGwkVv5bwgxhW0n8nfmJBcRmEVCReLRjHiuIzSvgK7GvbSMjxPyZjBLH7j8HK+IU CJNYu2AeWDMj0EXfT61hArGZBcQlbj2ZzwRxqYDEkj3nmSFsUYmXj/+xQtiKEjvPtjND1OdL dDyCOIhXQFDi5MwnLBMYRWYhGTULSdksJGUQcR2JBbs/sUHY2hLLFr5mhrHPHHjMhCy+gJF9 FaNkcWpxUm66kaFebnpuiV5qUWZycXF+nl5x6iZGYDQd3PLbcAfjxGv2hxilOViUxHkZpncG CQmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamDs4EpzFjrXP6+Gce3H8qcWGUu71z+Y67y4neHh uShJG1ODZZcM934M6dmmuGLemol3uaN6vpxeatUTPe/QRdlj75b0Bp5s//BascTtra3Aix92 39z7bnv7yufvj9aJZcwoWf/g43/3vhbbo9dOnWvcsW5a+Z3O1C7vz9vM2hZy35fdxe9gXbFS iaU4I9FQi7moOBEA1W8FyXQCAAA= Subject: Re: [Dime] OLR applicable for any/all applications X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 10:55:12 -0000 --_000_087A34937E64E74E848732CFF8354B9209739774ESESSMB101erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, Yes, I agree with comments received, this could be considered an optimizati= on. Then I agree about do not including this in the baseline document. Best regards /MCruz From: Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com] Sent: lunes, 09 de diciembre de 2013 11:52 To: Maria Cruz Bartolome; dime@ietf.org Subject: RE: [Dime] OLR applicable for any/all applications Hi MCruz, I don't see any use case at least in 3GPP for this. There is no more than o= ne application between two nodes so far. And even the case is valid, it cou= ld be reached by multiple sending of the overload report per application, w= hich could be seen as an optimization in the future if there is clear scena= rio for such an optimization. Best Regards, Susan From: Maria Cruz Bartolome [mailto:maria.cruz.bartolome@ericsson.com] Sent: Tuesday, December 03, 2013 4:43 PM To: dime@ietf.org Subject: [Dime] OLR applicable for any/all applications Dear all, There may be a need by a reporting node to request traffic reduction for al= l traffic, application independent, e.g. if an operator's network becomes s= everely overloaded, it may be of interest to signal directly general overlo= ad to the client. In this case, since reacting node obtains affected application from the app= lication message, we may need to extend OLR. At least we got following options: A) Define a new optional AVP that could be included into OLR, like e.g.= : OC-OLR ::=3D < AVP Header: TBD2 > < TimeStamp > [ Reduction-Percentage ] [ ValidityDuration ] [ ReportType ] [All applications] * [ AVP ] B) Extend ReportTypes like e.g.: 3 Destination-Host All Applications report. Similar to Destination-Hos= t report but it would apply to any application regardless the application m= essage this report is received within. 4 Realm (aggregated) All Applications report. Similar to Realm report = but it would apply to any application regardless the application message th= is report is received within. I tend to prefer option A, but let me know your opinions and preferences. Best regards /MCruz --_000_087A34937E64E74E848732CFF8354B9209739774ESESSMB101erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

Yes, I agree with comm= ents received, this could be considered an optimization.<= /p>

Then I agree about do = not including this in the baseline document.

 

Best regards

/MCruz

 

From: Shishufe= ng (Susan) [mailto:susan.shishufeng@huawei.com]
Sent: lunes, 09 de diciembre de 2013 11:52
To: Maria Cruz Bartolome; dime@ietf.org
Subject: RE: [Dime] OLR applicable for any/all applications

 

Hi MCruz,

 

I don’t see any use case at least in 3GPP for t= his. There is no more than one application between two nodes so far. And ev= en the case is valid, it could be reached by multiple sending of the overload report per application, which could be= seen as an optimization in the future if there is clear scenario for such = an optimization.

 

Best Regards,

Susan

 

From: Maria Cruz Bartolome [mailto:maria.cruz.bartolome@e= ricsson.com]
Sent: Tuesday, December 03, 2013 4:43 PM
To: dime@ietf.org
Subject: [Dime] OLR applicable for any/all applications

&nbs= p;

 

Dear all,=

&nbs= p;

There may be a need by a reporting node to request tr= affic reduction for all traffic, application independent, e.g. if an operat= or’s network becomes severely overloaded, it may be of interest to signal directly general overload to the client.&n= bsp;

In this c= ase, since reacting node obtains affected application from the application = message, we may need to extend OLR.

&nbs= p;

At least = we got following options:

&nbs= p;

&nbs= p;

A)     D= efine a new optional AVP that could be included into OLR, like e.g.:

&n=
bsp;  OC-OLR ::=3D < AVP Header: TBD2 >
&n=
bsp;            =
; < TimeStamp >
&n=
bsp;            =
; [ Reduction-Percentage ]
&n=
bsp;            =
; [ ValidityDuration ]
&n=
bsp;            =
; [ ReportType ]
&n=
bsp;             [All applications]
&n=
bsp;           * [ AVP ]<=
o:p>

&nbs= p;

&nbs= p;

B)      E= xtend  ReportTypes like e.g.:

&nbs= p;

   3  Destination-Host All Applications report.  Similar to Destinatio= n-Host report but it would apply to any application regardless the applicat= ion message this report is received within.

 

   4  Realm (aggregated) All Applications report.  Similar to Realm report but it would apply to any application regardless the application message this = report is received within.

&nbs= p;

&nbs= p;

&nbs= p;

I tend to= prefer option A, but let me know your opinions and preferences.=

Best rega= rds

/MCruz

&nbs= p;

&nbs= p;

--_000_087A34937E64E74E848732CFF8354B9209739774ESESSMB101erics_-- From ulrich.wiehe@nsn.com Mon Dec 9 02:55:23 2013 Return-Path: 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 CCDC61AE283 for ; Mon, 9 Dec 2013 02:55:23 -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 SxxitPR0PxaN for ; Mon, 9 Dec 2013 02:55:21 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 126D41AE27E for ; Mon, 9 Dec 2013 02:55:20 -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 rB9AtCe3014525 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 9 Dec 2013 11:55:12 +0100 Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rB9AtBGg020973 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Dec 2013 11:55:11 +0100 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.152]) by DEMUHTC003.nsn-intra.net ([10.159.42.34]) with mapi id 14.03.0123.003; Mon, 9 Dec 2013 11:55:11 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: "ext Nirav Salot (nsalot)" , Ben Campbell Thread-Topic: [Dime] OVLI: comments to 4.3 Thread-Index: Ac7xzgT7drC0NV4iSVSEGFHx9aP+WQAl1Z0AAAfOC0AAEAghgAAWP9KAAGrqkFA= Date: Mon, 9 Dec 2013 10:55:11 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519DF8A@DEMUMBX014.nsn-intra.net> References: <5BCBA1FC2B7F0B4C9D935572D90006681519DB1B@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681519DD2A@DEMUMBX014.nsn-intra.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.112] Content-Type: text/plain; charset="us-ascii" 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: 3130 X-purgate-ID: 151667::1386586512-00002466-D5233FC1/0-0/0-0 Cc: "dime@ietf.org" Subject: Re: [Dime] OVLI: comments to 4.3 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 10:55:24 -0000 Nirav, it is also an important part that the reacting node calculates the expiry t= ime of an OLR based on the included timestamp and duration and not based on= the reception time and the included duration. It is much simpler for repor= ting nodes to include a pre-calculated OLR into the answer rather than to = adjust the validity-duration in the OLR in dependency of the time when the = OLR is included into the answer. The reporting node may want the OLR to be = valid starting from creation time (t0) for the validity-duration (d), i.e. = until t0+d independent from the point in time (t0, t0+1,...,t0+d-1) when th= e OLR is sent. Ulrich =20 -----Original Message----- From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com]=20 Sent: Saturday, December 07, 2013 9:27 AM To: Ben Campbell; Wiehe, Ulrich (NSN - DE/Munich) Cc: dime@ietf.org Subject: RE: [Dime] OVLI: comments to 4.3 In my view, from the reacting point of view, Timestamp and Sequence-Number = are both the same since it is just a number defining the uniqueness/version= -Id of the OC-OLR. e.g. we can define Sequence-Number and the reporting node can use Timestamp= to populate the same.=20 The most important part is that the reacting node is not supposed to use th= is parameter for anything but finding out the newness/version-ID of the rep= ort. Beyond that, from the reporting node's point of view, I am fine to use Sequ= ence-Number or Timestamp. Regards, Nirav. -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell Sent: Saturday, December 07, 2013 3:20 AM To: Wiehe, Ulrich (NSN - DE/Munich) Cc: dime@ietf.org Subject: Re: [Dime] OVLI: comments to 4.3 On Dec 6, 2013, at 7:39 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >>=20 >> 2. TimeStamp has been replaced with Sequence-Number. This has the negati= ve impact that reacting nodes must calculate the expiration time base on OL= R-reception time. OLR reception time and OLR creation time may be signific= antly different. >> I don't see any reason in favour of Sequence-Number. Proposal is to repl= ace Sequence-Number with TimeStamp. >=20 > I agree but you need to convince the others as well who favoured sequence= number. I don't think it was so much that we didn't want it to be a timestamp as we= didn't want to mandate the implementation. We need to make sure the number= changes between different versions. A time stamp is one way to do that. A = sequence number (or version number) is another. As I mentioned in a separate thread, we at list need to describe the expect= ed properties. For example, the scope-of-uniqueness, whether we expect the = number to always increase or just be different, etc. It's not clear to me t= hat any association with wall clock time is one of those needed properties,= even though a time stamp might be a perfectly reasonable way to achieve th= e other needed properties. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From susan.shishufeng@huawei.com Mon Dec 9 03:07:21 2013 Return-Path: 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 919451ADEC4 for ; Mon, 9 Dec 2013 03:07:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 FAawNiCzQbDL for ; Mon, 9 Dec 2013 03:07:19 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E42781ADDD0 for ; Mon, 9 Dec 2013 03:07:18 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYT72631; Mon, 09 Dec 2013 11:07:12 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 9 Dec 2013 11:06:49 +0000 Received: from SZXEMA406-HUB.china.huawei.com (10.82.72.38) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 9 Dec 2013 11:06:53 +0000 Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.155]) by SZXEMA406-HUB.china.huawei.com ([10.82.72.38]) with mapi id 14.03.0158.001; Mon, 9 Dec 2013 19:06:43 +0800 From: "Shishufeng (Susan)" To: Jouni Korhonen , "Wiehe, Ulrich (NSN - DE/Munich)" Thread-Topic: [Dime] OVLI: comments to 4.3 Thread-Index: AQHO8m5jPDv7eVfk202jvUV7iJhvo5pLt7dw Date: Mon, 9 Dec 2013 11:06:42 +0000 Message-ID: <26C84DFD55BC3040A45BF70926E55F2587C1D11A@SZXEMA512-MBX.china.huawei.com> References: <5BCBA1FC2B7F0B4C9D935572D90006681519DB1B@DEMUMBX014.nsn-intra.net> In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.146.62.57] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "dime@ietf.org" Subject: Re: [Dime] OVLI: comments to 4.3 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 11:07:21 -0000 Hello all, I have no strong opinion on the Sequence-Number or TimeStamp. The key point= is to uniquely identify the OLR, both work. Maybe we can add TimeStamp as = an example which can be implemented as kind of Sequence-Number. Best Regards, Susan -----Original Message----- From: Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20 Sent: Friday, December 06, 2013 6:27 PM To: Wiehe, Ulrich (NSN - DE/Munich) Cc: dime@ietf.org Subject: Re: [Dime] OVLI: comments to 4.3 On Dec 5, 2013, at 5:23 PM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: > Dear all, > =20 > here are comments to clause 4.3: > =20 > 1. Extensions in OC-OLR must either be mutually supported or must be igno= rable. In the first case it is not enough for the reporting node to declare= support of an extension in the sent OC-Feature-Vector AVP. For the second = case there is no need to declare (or even define) support of an extension. I am afraid I do not understand what you mean by above. > Proposal is to expand the second sentence as follows: > OC-OLR may also be used to convey additional information about mutuall= y supportedextensions that are > declared in the OC-Feature-Vector AVPs, and may also be used to convey= additional ignorable information. Not sure about the wording "ignorable information".. but otherwise ok with = me. > =20 > 2. TimeStamp has been replaced with Sequence-Number. This has the negativ= e impact that reacting nodes must calculate the expiration time base on OLR= -reception time. OLR reception time and OLR creation time may be significa= ntly different. > I don't see any reason in favour of Sequence-Number. Proposal is to repla= ce Sequence-Number with TimeStamp. I agree but you need to convince the others as well who favoured sequence n= umber. - Jouni > =20 > Best regards > Ulrich > =20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From jouni.nospam@gmail.com Mon Dec 9 03:09:29 2013 Return-Path: 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 A232F1AE273 for ; Mon, 9 Dec 2013 03:09:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.889 X-Spam-Level: X-Spam-Status: No, score=-0.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no 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 WOAXE2THocT4 for ; Mon, 9 Dec 2013 03:09:25 -0800 (PST) Received: from mail-bk0-x231.google.com (mail-bk0-x231.google.com [IPv6:2a00:1450:4008:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 78E691ADEC4 for ; Mon, 9 Dec 2013 03:09:24 -0800 (PST) Received: by mail-bk0-f49.google.com with SMTP id my13so1313351bkb.22 for ; Mon, 09 Dec 2013 03:09:19 -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 :content-transfer-encoding:message-id:references:to; bh=/dm43JKkEQECEjLdowduclevN5/ETYFEt+VvEgdl658=; b=rOjwbXoC7wNESxqgsBEsW+6glmXxPzMgZVholV0DjCIgp9be3ZKJrqwnz6H1M6y0XW 2l8S2SsasjpiKdI777X73EoentUiDaFLre6ZIRNklQ6WMPWlAkT+RyTTfM9S22oj5Y0S xJM2zQIb6Ml6N5tXUkJ1a3e1HXc8zosCYR76zw7oDQapYQVEgkAAPiaP6c+kzJ8bIs8f ePfxZbY7vJq6fZZFLJT3YRQ1oSYPlxs7G0Z2X7IN+1FQlBzCLwrYk8nxWNP2Y08l9YiA BJ5IgvozT7GKKosUnhNsw/w3gqxOVAzrofx8kLL/S2rrVveKrV2PFLWYiQ1mAHoTVJik E2uw== X-Received: by 10.205.15.7 with SMTP id ps7mr2047355bkb.106.1386587359099; Mon, 09 Dec 2013 03:09:19 -0800 (PST) Received: from ?IPv6:2001:1bc8:101:f101:3c66:e081:e506:53b3? ([2001:1bc8:101:f101:3c66:e081:e506:53b3]) by mx.google.com with ESMTPSA id a4sm8319425bko.11.2013.12.09.03.09.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Dec 2013 03:09:16 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <087A34937E64E74E848732CFF8354B9209739738@ESESSMB101.ericsson.se> Date: Mon, 9 Dec 2013 13:09:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: 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> <14594_1386204165_529FCC05_14594_12646_1_6B7134B31289DC4FAF731D844122B36E329907@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B920972CCAA@ESESSMB101.ericsson.se> <52A077CC.3000004@usdonovans.com> <52A088D0.2020406@usdonovans.com> <52A091CE.2000104@usdonovans.com> <13081_1386256433_52A09831_13081_8197_1_6B7134B31289DC4FAF731D84412 2B36E32B6EB@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B9209739738@ESESSMB101.ericsson.se> To: Maria Cruz Bartolome , "dime@ietf.org list" X-Mailer: Apple Mail (2.1510) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 11:09:29 -0000 OK. Lets call this thread concluded then. I keep the old OC-OLR = semantics regarding its information context then unmodified. - Jouni On Dec 9, 2013, at 12:50 PM, Maria Cruz Bartolome = wrote: > Hello, > =20 > Trying to focus on getting conclusions here. > I totally agree with Nirav and Lionel: against to =93self-contained=94 = OLRs. > =20 > /MCruz > =20 > =20 > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of = lionel.morand@orange.com > Sent: jueves, 05 de diciembre de 2013 16:14 > To: Steve Donovan; Nirav Salot (nsalot); dime@ietf.org > Subject: Re: [Dime] DOIC: Self-Contained OLRs > =20 > Hi Steve, > =20 > "I also don't think I agree this is a special architecture = requirement, but this requires some thought." > =20 > I repeat one of my comments=85 being able to receive an OLR for = another application that the one carrying the report implies that there = is functional link between the functions, either a direct link or = through a kind of centralized overload control function (or any = equivalent function). And here is the reason for my "STRONG NO" for the = self-contained OLRs, based on the existing requirements regarding = Diameter overload control. > =20 > Lionel > =20 > De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan > Envoy=E9 : jeudi 5 d=E9cembre 2013 15:47 > =C0 : Nirav Salot (nsalot); dime@ietf.org > Objet : Re: [Dime] DOIC: Self-Contained OLRs > =20 > Nirav, >=20 > Thanks for clarifying. This is obviously one area we have been making = different assumptions. It's a good thing this thread went on this = long. :-) >=20 > One question, maybe for Maria Cruz. If it is never ok for an overload = report to apply to an application other than the application carrying = the message then how does the "all applications" extension proposed by = Maria Cruz work? >=20 > I will come back to address the "special architectural requirement" = question in a separate email. I think I understand the point you are = making. I also don't think I agree this is a special architecture = requirement, but this requires some thought. >=20 > Steve >=20 > On 12/5/13 8:25 AM, Nirav Salot (nsalot) wrote: > Steve, > =20 > We assumed that "self-contained OC-OLR" contains the same information = as the message containing this AVP and hence we (me, JJ, Maria-Cruz) = were saying that consistency check is needed. > =20 > But now I understand that "self-contained OC-OLR" can contain = information of any context since the AVP itself defines the context = explicitly. So application-X message can carry application-Y's OC-OLR = and I do not agree to this. > In my view, this is totally against the existing principles of = Diameter based applications. And hence this requires special support at = the receiving node as well as the sending node since today the nodes are = designed to handle only application specific data. > =20 > In summary, "self-contained OC-OLR" puts a special architectural = requirement on Diameter nodes =96 to handle one application's data from = other application's message =96 and hence this is a strong reason for me = to object to "self-contained OC-OLR". > =20 > Regards, > Nirav. > =20 > From: Steve Donovan [mailto:srdonovan@usdonovans.com]=20 > Sent: Thursday, December 05, 2013 7:38 PM > To: Nirav Salot (nsalot); dime@ietf.org > Subject: Re: [Dime] DOIC: Self-Contained OLRs > =20 > I must admit that I don't understand the need for consistency. >=20 > Why is it necessary to compare implicit and explicit data? If we use = self contained reports then the contents of the report are what should = be used, independent of the message that carries the report. >=20 > Steve >=20 > On 12/5/13 7:49 AM, Nirav Salot (nsalot) wrote: > Steve, > =20 > While gauging the complexity of "using the self-contained OC-OLR" It = seems you have overlooked the aspect identified by Maria-Cruz below (and = JJ earlier). > > Duplication should be avoided, since then we need to assure = consistency, and error handing in case implicit and explicit data values = are different for any reason... what means that it may always be = required to check both implicit and explicit data. > =20 > Regards, > Nirav. > =20 > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan > Sent: Thursday, December 05, 2013 6:26 PM > To: dime@ietf.org > Subject: Re: [Dime] DOIC: Self-Contained OLRs > =20 > If we equating "complexity" with work done by a Diameter node, then = there is added "complexity" for both proposals. >=20 > The extra work that needs to be done for the self contained report = approach is that the reporter needs to add additional AVPs to the = report. This is hardly difficult but it is extra work. >=20 > The extra work in the implicit approach is that the reactor needs to = gather information from multiple AVPs to understand the context of the = AVP. Again, hardly difficult but more work that can be avoided in a = well layered software architecture. >=20 > My conclusion is that the complexity argument does not apply. There = is complexity in both, its just a matter of where the work is done. >=20 > Steve >=20 > On 12/5/13 3:29 AM, Nirav Salot (nsalot) wrote: > Agree with Lionel's view and Maria-Cruz's arguments below. > =20 > The "self-contained OC-OLR" - which I assume contains the same = information as present in the message containing the OC-OLR - adds extra = complexity as highlighted by Maria-Cruz. > The benefit highlighted can be achieved in an implementation specific = way by the receiver duplicating the information into OC-OLR before = passing it to the layer processing the OC-OLR. > =20 > Regards, > Nirav. > =20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Maria Cruz = Bartolome > Sent: Thursday, December 05, 2013 7:53 AM > To: dime@ietf.org > Subject: Re: [Dime] DOIC: Self-Contained OLRs > =20 > Dear all, > =20 > I agree with Lionel argumentation below. > =20 > A part from that, one concern with "self-contained OLRs" is that some = data is duplicated. Duplication should be avoided, since then we need to = assure consistency, and error handing in case implicit and explicit data = values are different for any reason... what means that it may always be = required to check both implicit and explicit data. > =20 > Also, I think this is a pure implementation proposal. Regardless how = the data is transported it could be packed in a "self-contained OLRs" = within the diameter application, if for any implementation this is = preferred. > =20 > Regards > /MCruz > =20 > =20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of = lionel.morand@orange.com > Sent: jueves, 05 de diciembre de 2013 1:43 > To: Ben Campbell > Cc: dime@ietf.org > Subject: Re: [Dime] DOIC: Self-Contained OLRs > =20 > Hi Ben, > =20 > 3GPP operational requirements have triggered and driven this work, and = 3GPP will be the main client for this solution (if not the only for a = while...). Main parties involved in the discussions are 3GPP vendors and = 3GPP operators. So instead trying to keep private preserve, we should = welcome and enforce cooperative work with 3GPP on this task if we want = that the solution defined in IETF will be used in 3GPP. Otherwise, 3GPP = may decide not to wait for IETF and develop its own solution, as done in = the past (e.g. developing 3GPP-specific Cx application instead of = adopting the IETF-standard Diameter SIP application). > =20 > About the technical discussion, the Req31 says: > =20 > REQ 31: There are multiple situations where a Diameter node may be > overloaded for some purposes but not others. For example, > this can happen to an agent or server that supports = multiple > applications, or when a server depends on multiple external > resources, some of which may become overloaded while others > are fully available. The solution MUST allow Diameter = nodes > to indicate overload with sufficient granularity to allow > clients to take action based on the overloaded resources > without unreasonably forcing available capacity to go = unused. > The solution MUST support specification of overload > information with granularities of at least "Diameter node", > "realm", and "Diameter application" and MUST allow > extensibility for others to be added in the future. > =20 > The "MUST" part says: enough granularity with at least host/realm and = application. > And the existing solution is compliant with this requirement. If a = node is supporting N applications, an OLR can be sent "per application" = with a report type indicating if it is for the host or the realm. And = the extensibility capability is provided by the base solution. > =20 > So my technical argument is that the existing proposal fulfills the = basic requirements for an overload control without compromising future = extension for further granularity. > =20 > Regards, > =20 > Lionel=20 > =20 > -----Message d'origine----- > De : Ben Campbell [mailto:ben@nostrum.com] Envoy=E9 : mercredi 4 = d=E9cembre 2013 22:55 =C0 : MORAND Lionel IMT/OLN Cc : dime@ietf.org = Objet : Re: [Dime] DOIC: Self-Contained OLRs > =20 > On Dec 3, 2013, at 5:17 PM, lionel.morand@orange.com wrote: > =20 > Hi Ben, > =20 > I may be wrong somewhere in my summary but I think that it was the = result of the discussions and agreements reached regarding existing = requirements, at least from 3GPP point of view, compared to possible = optimizations for future optimizations not so obvious. > =20 > We are not the 3GPP. Our requirements are RFC 7068. I believe = self-contained OLRs do a better job of meeting Req 31 than the = contextually-defined OLRs. > =20 > I've made several technical arguments here--does anyone have = _technical_ arguments in favor of contextually-defined OLRs? > =20 > And because the solution offers extensibility via the definition of = new algo, new report type and addition of any new AVP in the existing = Grouped OLR, the "limitations" of the proposed solution might be removed = by someone if really required according to new requirements. > =20 > =20 > It might be worth considering a compromise approach: Define _optional_ = AVPs that allow an OLR to be self-contained. If they are not present, = then the various values default to those from the enclosing Diameter = message. Possibly add support for this to the list of things that = reacting nodes can advertise. > =20 > This could be in the base, or in a follow on extension. (If left for = an extension, it's worth considering whether ReportType needs to be in = the base, or this or some other extension.)=20 > =20 > =20 > Regards, > =20 > Lionel > =20 > -----Message d'origine----- > De : Ben Campbell [mailto:ben@nostrum.com] Envoy=E9 : mardi 3 d=E9cembre= =20 > 2013 23:56 =C0 : MORAND Lionel IMT/OLN Cc : Steve Donovan; = dime@ietf.org=20 > Objet : Re: [Dime] DOIC: Self-Contained OLRs > =20 > =20 > On Dec 2, 2013, at 10:18 AM, lionel.morand@orange.com wrote: > =20 > Hi Steve, > =20 > I think that is not only about few bytes in the answer. It is also = about the solution principles agreed so far: > =B7 the current need is for an OLR bound to the application in = use > =B7 the OLR is received from the node targeted in the request. > =B7 the OLR is defined per application > =20 > I don't think those principles have been well tested. I don't recall = any discussion of their benefits. What benefits do you see they have = over self-contained OLRs? > =20 > All I see from these are restrictions in the flexibility of the = solution, with very little in return. > =20 > So all the implicit information (application, origin-host, = origin-realm) are meaningful in this context. > And the actual solution is designed based on these assumptions. The = extensibility of the solution will allow extra info if required in other = use cases but it was agreed to go with a straightforward solution that = will satisfy most of us. > =20 > Regards, > =20 > Lionel > =20 > De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan > Envoy=E9 : lundi 2 d=E9cembre 2013 16:37 > =C0 : dime@ietf.org > Objet : Re: [Dime] DOIC: Self-Contained OLRs > =20 > I don't believe that Ben's proposal was to change the piggybacking = assumption in the baseline mechanism. Ben's proposal is to design the = solution in such a way that it is not dependent on the piggybacking = transport mechanism. =20 > =20 > I share Ben's concern that we have over optimized the content of the = overload report in a way that makes implementations brittle, = interoperability more difficult to achieve and extensibility more = complex. And what do we gain from this optimization? A few bites in = answer messages. > =20 > Self contained overload reports, transported using the piggybacking = mechanism, is a cleaner solution. > =20 > Steve > =20 > On 11/29/13 8:31 AM, lionel.morand@orange.com wrote: > I totally agree with Nirav. No need to revert at this stage the = working assumption on piggybacking of OLR in application answer = messages, especially when the aim is to define a basic mechanism called = "reduction". > =20 > Anyone would be able to further add extra info for optimization if = needed but there is no need at all for the basic mechanism. > =20 > Regards, > =20 > Lionel > =20 > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot = (nsalot) > Envoy=E9 : vendredi 29 novembre 2013 12:24 > =C0 : Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org = list > Cc : Ben Campbell > Objet : Re: [Dime] DOIC: Self-Contained OLRs > =20 > Jouni, Ben, > =20 > I am totally against the idea of self-contained OC-OLR specifically = since we have adopted the principles of piggybacking the OC-OLR over = existing application message. > Self-contained OC-OLR - which means adding all the information which = defines the scope of the OC-OLR into the OC-OLR - does not make sense in = the piggybacking approach. In fact, it is adding lot of information, = which is anyway available within the message containing the OC-OLR, into = the OC-OLR. So it is adding lot of redundant information in a message = which increases the processing requirement for the sender as well as the = receiver. (And this is un-optimization, in my view). > =20 > Besides, I am not convinced with the other reasons provided here: > - One software module within a node can provide OC-OLR to another = software module in the same node without passing other related info > Within a node, based on the design, lots of information may need to = be passed between two software modules and we cannot optimize those = aspects by replicating unnecessary information in a protocol message. > In summary, it is node's internal software design issue and we need = not optimize that at protocol level. > =20 > - Once the reporting node realizes that it is overloaded, it has to = wait for right answer to send OC-OLR > What is the point of sending OC-OLR for a context for which there is = no messaging? Why should the reacting node care if it never sends a = message for a context for which the reporting node is overloaded? > So this waiting is justified since it ensures that the overload is = reported only when necessary and only to the applicable reacting node. = Not to all the nodes in the network. > =20 > - The agent needs to wait for the answer generated by the server and = the right context > The same argument as applicable for the server applies here. The = agent need not send out-of-context overload info to a node. > Why should reacting node receive/process/store the overload info for = the scope for which it is not sending any messages. > =20 > - For sending OC-OLR in dedicated Diameter application??? > Piggybacking was the first basic principle we agreed before putting = other principles in place. So we may want to go back the drawing board = if we decide to change this principle. > =20 > Regards, > Nirav. > =20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen > Sent: Friday, November 29, 2013 2:50 PM > To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list > Cc: Ben Campbell > Subject: Re: [Dime] DOIC: Self-Contained OLRs > =20 > =20 > =20 > So, are we reaching any level of consensus here? > =20 > - JOuni > =20 > (as a note.. that we are converging back to where we started with OLRs = ;) > =20 > =20 > =20 > On Nov 28, 2013, at 12:40 PM, "Wiehe, Ulrich (NSN - DE/Munich)" = wrote: > =20 > Hi, > =20 > another question: > =20 > If we go for explicit self contained OLRs, why would we then need the = ReportType? > =20 > The realm-type OLR would explicitly contain application-Id, Realm, but = no Host whereas the host-type OLR would explicitly contain = application-Id, Host, but probably (I'm not sure) no Realm. > =20 > Ulrich > =20 > =20 > =20 > -----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 > =20 > Hi, > =20 > 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. > =20 > Lionel > =20 > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich=20= > (NSN - DE/Munich) Envoy=E9 : jeudi 28 novembre 2013 10:26 =C0 : ext = Jouni=20 > Korhonen; Ben Campbell Cc : dime@ietf.org list Objet : Re: [Dime]=20 > DOIC: Self-Contained OLRs > =20 > Hi, > =20 > 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? > =20 > Ulrich > =20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Jouni=20 > Korhonen > Sent: Wednesday, November 27, 2013 11:44 PM > To: Ben Campbell > Cc: dime@ietf.org list > Subject: Re: [Dime] DOIC: Self-Contained OLRs > =20 > =20 > On Nov 28, 2013, at 12:27 AM, Ben Campbell wrote: > =20 > Hi, > =20 > I mentioned in another thread that I prefer putting an explicit=20 > ReportType AVP in an OLR, rather than > =20 > The more I spent time thinking/writing the actual procedures on the=20 > endpoints, the more it makes sense to me to keep the ReportType in the=20= > OC-OLR. Even if the baseline does not have agent overload etc, the=20 > ReportType fits well to the "endpoint principle" we have in the draft.=20= > It indeed gives more tools to make a host vs. realm base decision on = the reacting node and is plain more clear. > =20 > I skip the rest of the mail.. too much text ;-) > =20 > =20 > - Jouni > =20 > =20 > =20 > =20 > =20 > 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. > =20 > 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. > =20 > I think this approach is a mistake. I would greatly prefer that we = explicitly include such values in the OLR itself, for multiple reasons: > =20 > 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. > =20 > 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.=20= > =20 > 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. > =20 > 3) Implicit values don't work at all for certain problems. For=20 > example, if an agent needs to originate an OLR, it typically needs to=20= > insert that OLR into an existing Diameter answer created by a server.=20= > It can't create its own answer without affecting the application=20 > state. If the responding node assumes the OLR comes from or refers to=20= > the node identified by the Origin-Host AVP in the enclosing answer,=20 > things break. (For examples of when an agent needs to send OLRs that=20= > are distinct from those sent by a server, see Steve's agent overload=20= > draft, or my dh/dr example.) > =20 > OTOH, explicit values will work for all cases where we need to = associate some arbitrary value with an OLR. > =20 > 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. > =20 > 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. > =20 > Thanks! > =20 > Ben. > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > =20 > _______________________________________________ > 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 > =20 > ______________________________________________________________________ > ___________________________________________________ > =20 > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20= > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > 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. > =20 > This message and its attachments may contain confidential or=20 > 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. > =20 > =20 > _______________________________________________ > 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 > =20 > = __________________________________________________________________________= _______________________________________________ > =20 > 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. > =20 > 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. > =20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > =20 > =20 > = __________________________________________________________________________= _______________________________________________ > =20 > 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. > =20 > 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. > =20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > =20 > =20 > = __________________________________________________________________________= _______________________________________________ > =20 > 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. > =20 > 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. > =20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > =20 > =20 > = __________________________________________________________________________= _______________________________________________ > =20 > 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. > =20 > 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. > =20 > _______________________________________________ > 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 > =20 > =20 > =20 > =20 > = __________________________________________________________________________= _______________________________________________ > =20 > 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. > =20 > 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 From jouni.nospam@gmail.com Mon Dec 9 03:37:28 2013 Return-Path: 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 6AB271AE279 for ; Mon, 9 Dec 2013 03:37:28 -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 754szpFrDfG1 for ; Mon, 9 Dec 2013 03:37:27 -0800 (PST) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id F37391ADF23 for ; Mon, 9 Dec 2013 03:37:26 -0800 (PST) Received: by mail-la0-f42.google.com with SMTP id ec20so1481635lab.29 for ; Mon, 09 Dec 2013 03:37:21 -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 :content-transfer-encoding:message-id:references:to; bh=Q94a/y85YlpMfovh1C3jNEJsSzkWKFquQevrs/7XIe4=; b=eOmFZO+1hWcUJN3Z0JldU4jHR+DHOfof65FgSsJ8MH2PEYe6yAezBFdJPCQuRI0Ekj U+ejC9aKncutjpEfJJxBdd01l0J/wAIExxVDF6TaZdNZWcnCvLVR/DY1nCl9dj5rSzjy IIOvyxJXN1rn7cB1guSdi45ua8HIQmTWPeLb/Bdkh0H60b+vBdUChhg1t7RGh7CclHJF OxEWAcRH6hb3bqzKT2/UVWPOJNpnGtfCWQrTA6Zy3kbuvDYo6QgzOPpYX7pPuAHm+HXb xDBmvli7O0wnobbUmuietASyauiWsujzyIx/7RCzARdJyC1WwDefDN1H1OeSGylc8Ruy cYzg== X-Received: by 10.152.180.104 with SMTP id dn8mr2103304lac.48.1386589041480; Mon, 09 Dec 2013 03:37:21 -0800 (PST) Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id di11sm13917413lac.0.2013.12.09.03.37.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Dec 2013 03:37:20 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681519DB1B@DEMUMBX014.nsn-intra.net> Date: Mon, 9 Dec 2013 13:37:19 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <5BCBA1FC2B7F0B4C9D935572D90006681519DB1B@DEMUMBX014.nsn-intra.net> To: "dime@ietf.org list" X-Mailer: Apple Mail (2.1510) Subject: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 11:37:28 -0000 Folks Could we conclude on the sequence number vs. time stamp vs. something else? We got more important places to spend our energy than this ;) My proposal is the following (based on the original pre-00 design): o We change the OC-Sequence-Number to OC-Time-Stamp in all occurrences in the -01. o We use RFC6733 Time type for the OC-Time-Stamp. RFC6733 gives us already exact definition how to handle the AVP. o Define that the OC-Time-Stamp is the time of the creation of the "original" AVP within whose context the time stamp is present. o The OC-Time-Stamp AVP uniqueness is still considered to be in scope of the communicating endpoints. o The time stamp can be used to quickly determine if the content of the encapsulating AVP context has changed (among other properties). This would be useful specifically in the future when the encapsulating grouped AVPs grow in size and functionality. - Jouni From ulrich.wiehe@nsn.com Mon Dec 9 03:43:46 2013 Return-Path: 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 450001AD72A for ; Mon, 9 Dec 2013 03:43:46 -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 yCR4WgM3ejIn for ; Mon, 9 Dec 2013 03:43:43 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 6A6A71ADF23 for ; Mon, 9 Dec 2013 03:43:41 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rB9BhSSv002145 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 9 Dec 2013 12:43:28 +0100 Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rB9BhRLT022488 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Dec 2013 12:43:28 +0100 Received: from DEMUHTC011.nsn-intra.net (10.159.42.42) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 9 Dec 2013 12:43:27 +0100 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.152]) by DEMUHTC011.nsn-intra.net ([10.159.42.42]) with mapi id 14.03.0123.003; Mon, 9 Dec 2013 12:43:27 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: "ext Shishufeng (Susan)" , "ext lionel.morand@orange.com" , ext Jouni Korhonen , Ben Campbell Thread-Topic: [Dime] DOIC: Self-Contained OLRs Thread-Index: AQHO67/t2PaAGa/GgUyaCwjRxXVUh5o5m/0AgAC8o/D///ghgIAAFu+wgBFDRACAABmHcA== Date: Mon, 9 Dec 2013 11:43:26 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519DFC0@DEMUMBX014.nsn-intra.net> References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D90006681519BC90@DEMUMBX014.nsn-intra.net> <6390_1385631044_52970D44_6390_18593_1_6B7134B31289DC4FAF731D844122B36E30748E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BD19@DEMUMBX014.nsn-intra.net> <26C84DFD55BC3040A45BF70926E55F2587C1D028@SZXEMA512-MBX.china.huawei.com> In-Reply-To: <26C84DFD55BC3040A45BF70926E55F2587C1D028@SZXEMA512-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.112] 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: 11720 X-purgate-ID: 151667::1386589409-00002466-8BBA80A0/0-0/0-0 Cc: "dime@ietf.org list" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 11:43:46 -0000 Hi Susan, let me come back to your S6a example. The MME (C) sends a request without Destination-Host towards the HPLMN (rea= lm). There must be an agent (A) in the HPLMN (realm) that selects the HSS (= S).=20 We would have two distinct DOIC associations: one between C and A, another = between A and S (see figure 5 in clause 5.1). The two DOIC associations may= have different supported/negotiated features. An OLR sent from S to A base= d on supported/negotiated features valid for the DOIC association between A= and S is at least problematic (out-of context) when sent from A to C. When the MME (C) sends a subsequent request with Destination-Host towards t= he HSS (S), there is no agent that selects the HSS (as the HSS is already s= elected). For this session there is only one DOIC association between C and= S (see figure 3 in clause 5.1) and OLRs sent from S to C are not problemat= ic. Best regards Ulrich -----Original Message----- From: ext Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]=20 Sent: Monday, December 09, 2013 11:30 AM To: Wiehe, Ulrich (NSN - DE/Munich); ext lionel.morand@orange.com; ext Joun= i Korhonen; Ben Campbell Cc: dime@ietf.org list Subject: RE: [Dime] DOIC: Self-Contained OLRs Hi Ulrich, I have different views. In any case, I think the host-type OLR should not b= e ignored by the clients. On the contrary, the realm-type OLR can be though= t as optimization, which may not even be needed at all for all cases, espec= ially in 3GPP. Here is an example of S6a, in the case the first attach requ= est comes from the UE to the MME, the MME can only derive the realm informa= tion, and sends a request without Destination-Host towards the HPLMN. Since= the subscriber corresponding to the UE belongs to a specific HSS, and the = HSS may provide its overload report to the MME, and the MME is able to know= how to react regarding the requests towards the HSS, which would be the no= rmal case. Whether Realm report will be provided by the HSS or the agent se= rving the HSS is kind of optimization which may help the MME to know how to= react on the requests towards the realm, not specific to the HSS. Best Regards, Susan -----Original Message----- From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 Sent: Thursday, November 28, 2013 6:30 PM To: ext lionel.morand@orange.com; ext Jouni Korhonen; Ben Campbell Cc: dime@ietf.org list Subject: 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 act= ual OLR created by the reporting end point and which OLR is an additional O= LR created by another node. We have two cases: a) The request sent by the client (reacting end point) contains no Destinat= ion Host. The agent (reporting node) (after forwarding the request to the s= elected server and receiving the answer) returns a realm-type OLR as the ac= tual 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 Destinat= ion 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 stat= us. It could be provided an agent inserting this info in answers received f= rom a server behind but also from a server that would know this info by som= e internal magic. But in any case, if we assume that the client will received a successful an= swer from the server for an initial request with only Dest-Realm AVP, it sh= ould be possible to have both report types in the answer: one for the serve= r itself, one for the realm for new request sent to the realm with only Des= t-Realm AVP. Lionel -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN= - DE/Munich) Envoy=E9=A0: jeudi 28 novembre 2013 10:26 =C0=A0: ext Jouni K= orhonen; Ben Campbell Cc=A0: dime@ietf.org list Objet=A0: Re: [Dime] DOIC: = Self-Contained OLRs Hi, I don't see how the possibility to send more than one OLR in an answer is a= ligned with the "endpoint principle". If the ReportType is "realm" this ind= icates 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 wrote: > Hi, >=20 > I mentioned in another thread that I prefer putting an explicit=20 > ReportType AVP in an OLR, rather than The more I spent time thinking/writing the actual procedures on the endpoin= ts, the more it makes sense to me to keep the ReportType in the OC-OLR. Eve= n if the baseline does not have agent overload etc, the ReportType fits wel= l to the "endpoint principle" we have in the draft. It indeed gives more to= ols to make a host vs. realm base decision on the reacting node and is plai= n 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 Diam= eter request that corresponds to the answer containing the OLR. My reasons = for that go beyond just ReportType, so I'm starting a separate thread. >=20 > As currently described, a consumer of an OLR must infer several things fr= om other context. In most cases, that context is in the Diameter answer tha= t carries the OLR. For example, the OLR implicitly refers to the applicatio= n 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 meani= ng in the context of the enclosing answer. If you moved an OLR from one ans= wer to another, it's meaning may change completely. >=20 > I think this approach is a mistake. I would greatly prefer that we explic= itly include such values in the OLR itself, for multiple reasons: >=20 > 1) It's more complex to interpret implicit, contextual values than explic= it values. The consumer cannot simply look at the OLR; it must look in vari= ous other AVPs to find all the information it needs. For example, I think a= common software design for overload control processing to be separated fro= m application processing. The consumer cannot simply hand the OLR to that m= odule 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 "con= text" avps that must be interpreted can grow large. This approach is error = prone, and will likely encourage brittle, hard-to-maintain code. Self-conta= ined OLRs would keep all the information related to overload in one place. = making for simpler implementations. >=20 > 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 r= eporting node realizes that it is overloade, it has to wait for the right a= nswer that contains the right context before it can send the OLR. This is p= articularly troublesome for agents, since they will typically have to inser= t OLRs into answers created by other nodes.=20 >=20 > If the reporting node screws this up, the meaning of the OLR may change s= ignificantly. So again, implicit meaning gives us error prone implementatio= ns. Self-contained OLRs are simpler to create and send. >=20 > 3) Implicit values don't work at all for certain problems. For=20 > example, if an agent needs to originate an OLR, it typically needs to=20 > insert that OLR into an existing Diameter answer created by a server.=20 > It can't create its own answer without affecting the application=20 > state. If the responding node assumes the OLR comes from or refers to=20 > the node identified by the Origin-Host AVP in the enclosing answer,=20 > things break. (For examples of when an agent needs to send OLRs that=20 > are distinct from those sent by a server, see Steve's agent overload=20 > draft, or my dh/dr example.) >=20 > OTOH, explicit values will work for all cases where we need to associate = some arbitrary value with an OLR. >=20 > 4) Implicit values seriously constrain the future evolution of Diameter O= C standards. For example, lets say we find a good reason to allow OLRs to b= e sent out of band, or be sent in a dedicated Diameter application. If over= load 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 transpo= rted, this won't work. We would have to create a new or significantly modif= ied OLR format if we found a need to transport OLRs in different ways. Self= -contained OLRs would allow much greater flexibility. >=20 > So, in summary, I think that self-contained OLRs would lead to simpler im= plementations, less brittle deployments, and more flexibility for future ev= olution of standards. >=20 > Thanks! >=20 > 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 confiden= tielles 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. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation 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 dele= te 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. From jouni.nospam@gmail.com Mon Dec 9 04:00:27 2013 Return-Path: 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 D2E871ADDD1 for ; Mon, 9 Dec 2013 04:00:27 -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 2uAH9MAic3bc for ; Mon, 9 Dec 2013 04:00:26 -0800 (PST) Received: from mail-bk0-x231.google.com (mail-bk0-x231.google.com [IPv6:2a00:1450:4008:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id AC7FC1ADF57 for ; Mon, 9 Dec 2013 04:00:24 -0800 (PST) Received: by mail-bk0-f49.google.com with SMTP id my13so1319634bkb.36 for ; Mon, 09 Dec 2013 04:00:19 -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 :content-transfer-encoding:message-id:references:to; bh=PuacnUZnU2MWxGe5n2GZBAV5ECkG5mfQxkpeo31+FYA=; b=F8CoUe823o/oYgXg/uMxE0mJv85sHnH6cnizZv8eiGNES+p4Vou2HBBD079PIJSLQT oQiVlKJf/FAX0KhUwd0ct0YKlIHhl4wd26dtVfBis6BJNpmwtPm1R53xm4woL1yXIIKy Vn5HjBYnBsw9ClTmORtSz7EkQzxe6tTapKXVPddEmu1p0MK6550dsUBAzYprzN8+x29y iJF/xZbnfKH9Zb+SejNGxASv7EMMNQjQ2HJQiPllDXxYH2EluRlK8dFUycPdgcy9CJoM DbmIEaM3U6Ok9WpSinzydEO9HxgO+n6OY6ybMIbLhrwLKr6kS9NtfjuJdsZhcroPjPSN JGRw== X-Received: by 10.204.102.201 with SMTP id h9mr663744bko.123.1386590419348; Mon, 09 Dec 2013 04:00:19 -0800 (PST) Received: from ?IPv6:2001:1bc8:101:f101:3c66:e081:e506:53b3? ([2001:1bc8:101:f101:3c66:e081:e506:53b3]) by mx.google.com with ESMTPSA id it12sm8446962bkb.12.2013.12.09.04.00.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Dec 2013 04:00:18 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681519DCBC@DEMUMBX014.nsn-intra.net> Date: Mon, 9 Dec 2013 14:00:17 +0200 Content-Transfer-Encoding: 7bit Message-Id: <453156F8-9090-46D4-BF8E-A877F40EE3AC@gmail.com> References: <5BCBA1FC2B7F0B4C9D935572D90006681519DCBC@DEMUMBX014.nsn-intra.net> To: "dime@ietf.org list" X-Mailer: Apple Mail (2.1510) Subject: [Dime] Conclusion for the Report Type X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 12:00:28 -0000 Folks, We need a conclusion here so that I can actually write something into the -01. How about the following (I try to reflect as many points given here as possible): 1) The basic principle for the Report Type use is that only one OLR per report type is allowed unless the report type and the OLR reflecting the new report type define exact semantics how to differentiate between multiple OLRs with the same report type. In 3GPP context, for example, a report type with an AVP that identifies an APN could be such a differentiator.. and that would need a new report type where an implementation exactly knows to look for this additional AVP without guesswork or fuzzy heuristics. 2) A new report type or a set of new report types require a new feature to be allocated/defined so that both endpoints know how to handle the new report type that was defined after the publication of the baseline specification. The handling of the new report types must be defined (along with the new AVPs it might need to be included into the OC-OLR AVP). 3) With 2) in place I do not care whether the OC-Report-Type is enumerated or unsigned (flag vector?). I still favour Enumerated myself as it forces the protocol designer to come up with a cleaner design ;) 4) For the baseline we only define host and realm report types. We do not allow multiple OLRs with these report types i.e. single instances of OLRs with host and/or realm are allowed. - Jouni From jouni.nospam@gmail.com Mon Dec 9 04:06:54 2013 Return-Path: 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 55F041ADF51 for ; Mon, 9 Dec 2013 04:06:54 -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 Nx0vLGeLJNQB for ; Mon, 9 Dec 2013 04:06:52 -0800 (PST) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 6EEB61ADDD1 for ; Mon, 9 Dec 2013 04:06:52 -0800 (PST) Received: by mail-la0-f43.google.com with SMTP id n7so1514666lam.30 for ; Mon, 09 Dec 2013 04:06:47 -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 :content-transfer-encoding:message-id:references:to; bh=XUJBgM/s0TY6Yqs9fvdm1o7+KaHlW1iVbZA8dAOIzbY=; b=W6TxQatJNRajptKZRmywgTJSL68fssyZZ+VnQm+rCpi+sKSd/PajAEHeomPybSsLxs pD1FwCev25FoVIJDRKCbUe1xu/b9beZIYMgi6FZ0+iq9v2fOS5gjTfPZPlejpVAdHtM9 5e+jgdp9k+i1Jz/OmujrhmZ4pcyHuJcFmMOgDwndwBIwDR2qLLhJrGUGmRUR+0zWEGEN QgsFrgakaRgC6cMY9MmD+q6hs1iN5gC2QEEYX9KjCL3l8HIudbqChee89wWOSqU+oAub qteL8Ex7EQbMQLeftSJhRzUyxxMuW5JqIYap4MvFO5cZti2K5rvWV+6omEOioMINepWJ l9Qg== X-Received: by 10.152.87.142 with SMTP id ay14mr4931696lab.7.1386590806952; Mon, 09 Dec 2013 04:06:46 -0800 (PST) Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id r10sm14075524lag.7.2013.12.09.04.06.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Dec 2013 04:06:46 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681519DA3E@DEMUMBX014.nsn-intra.net> Date: Mon, 9 Dec 2013 14:06:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2488E8AF-2899-4264-8BD0-7E382D9A95B0@gmail.com> References: <5BCBA1FC2B7F0B4C9D935572D90006681519DA3E@DEMUMBX014.nsn-intra.net> To: "dime@ietf.org list" X-Mailer: Apple Mail (2.1510) Subject: [Dime] Conclusion for OC-Feature-Vector - was Re: OVLI: comments to 4.1 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 12:06:54 -0000 Folks, Unless someone strongly disagrees, I'll submit the below changes into = -01. That is just renaming AVPs but as Ulrich says, the current definitions are = misleading. - Jouni ps: I already made global change into my -01 copy so you need a very = strong case for me to revert the changes back ;-) On Dec 5, 2013, at 3:23 PM, "Wiehe, Ulrich (NSN - DE/Munich)" = wrote: > Dear all, >=20 > here are comments to clause 4.1: >=20 > 1. The OC-Feature-Vector AVP is no longer a vector; the name of the = AVP may be misleading. Proposal is to rename it to = "OC-Supported-Features AVP" >=20 > 2. The OC-Feature AVP is a vector of features. Proposal is to rename = it to "OC-Feature-Vector AVP" >=20 From jouni.nospam@gmail.com Mon Dec 9 04:12:39 2013 Return-Path: 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 979721ADF51 for ; Mon, 9 Dec 2013 04:12:39 -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 ug98jfJjBsfw for ; Mon, 9 Dec 2013 04:12:37 -0800 (PST) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id DCE261AD947 for ; Mon, 9 Dec 2013 04:12:36 -0800 (PST) Received: by mail-la0-f52.google.com with SMTP id y1so1483758lam.39 for ; Mon, 09 Dec 2013 04:12:31 -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=XyxhMSZK6zg3980TyVhaqj+wOJvNRU5vZL8sjyemzyQ=; b=RCoc1c9Wk34IoB3UXKmlAbiwtd7APE7iPZ14CRHB25NfFZXgvn0NMiPp7rolSyrNhr UOJyHaFDBZ1tLJx+92uY9nYKS+OuK03LHdBvQF6l3Bi6pivnA3IjtFWDirz2JdPyJi/3 u37ISO9n63Q6QGdyXDGWOay5MFdl/n4Iay/k4tmR3BxkU4gyvLm4xw98aV7CqO4Tj+3v IWlSh5seBTkog2Va0AjCfsyx/mGvfktGFSNgn+4hALAfCb++4jZr8G9QAtYpBT8woV9b RICp3CTRSBHJMldyLMiQ8gNZzIInirMd0YSIKnV+COjSXXYPk2lN2kfKWVGHF318MNYh LFEg== X-Received: by 10.152.7.67 with SMTP id h3mr5114253laa.29.1386591151357; Mon, 09 Dec 2013 04:12:31 -0800 (PST) Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id a8sm14109092lae.5.2013.12.09.04.12.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Dec 2013 04:12:30 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681519DCE5@DEMUMBX014.nsn-intra.net> Date: Mon, 9 Dec 2013 14:12:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <09616DA2-D1ED-40EE-8E89-755DFCD81092@gmail.com> References: <5BCBA1FC2B7F0B4C9D935572D90006681519DA3E@DEMUMBX014.nsn-intra.net> <6CDCFC84-3048-40B9-91A4-1451FCC65F60@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519DCE5@DEMUMBX014.nsn-intra.net> To: "Wiehe, Ulrich (NSN - DE/Munich)" X-Mailer: Apple Mail (2.1510) Cc: "dime@ietf.org" Subject: Re: [Dime] OVLI: comments to 4.1 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 12:12:39 -0000 Ulrich, On Dec 6, 2013, at 3:03 PM, "Wiehe, Ulrich (NSN - DE/Munich)" = wrote: > Hi Jouni, >=20 > thank you for your response. >=20 > With regard to 3)=20 > I still fail to see the usecase for Sequence-Number or TimeStamp = within OC-Feature-Vector. Please clarify. Since we also allow extending the OC-Feature-Vector beyond recognition,=20= it has good chances become a rather complex grouped AVP. In that context the Sequence-Number allows an easy and quick way to check if the feature vector contains something that an implementation needs to act upon. > With regard to 4) > This was not obvious to me. (The obvious typo is the missing "of" = between "one" and "the"). Ack. Fixed the missing 'of'. - Jouni >=20 > Best regards > Ulrich >=20 >=20 > -----Original Message----- > From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20 > Sent: Friday, December 06, 2013 11:17 AM > To: Wiehe, Ulrich (NSN - DE/Munich) > Cc: dime@ietf.org > Subject: Re: [Dime] OVLI: comments to 4.1 >=20 >=20 > On Dec 5, 2013, at 3:23 PM, "Wiehe, Ulrich (NSN - DE/Munich)" = wrote: >=20 >> Dear all, >>=20 >> here are comments to clause 4.1: >>=20 >> 1. The OC-Feature-Vector AVP is no longer a vector; the name of the = AVP may be misleading. Proposal is to rename it to = "OC-Supported-Features AVP" >=20 > OK with me. >=20 >> 2. The OC-Feature AVP is a vector of features. Proposal is to rename = it to "OC-Feature-Vector AVP" >=20 > OK with me. >=20 >> 3. The OC-Sequence-Number within OC-Feature-Vector only makes sense = if the receiving reporting endpoint can determine the identity of the = reacting endpoint (which is not necessarily the origin host (client), >=20 > My original proposal was to have seqnr as a timestamp. Some folks = argued > it is no good and suggested seqnr. I still think time makes more sense = than > seqnr. >=20 >> it may be an agent and it may not always be the same agent), and if = the reporting endpoint is required to store the OC-Feature-Vector / = reacting-endpoint-identity pair (which I think both is not required). = The reporting endpoint can base its processing logic on the actually = received OC-Feature-Vector value, no matter whether it is brand-new or = old but stil valid. Proposal is to delete OC-Sequence-Number AVP from = OC-Feature-Vector. >=20 > Do not agree removing it. >=20 >> 4. The text >>=20 >> The reporting node that sends the answer also includes the OC- >> Feature-Vector AVP that describe the capabilities it supports. The >> set of capabilities advertised by the reporting node depends on = local >> policies. At least one the announced capabilities MUST match >> mutually. If there is no single matching capability the reacting >> node MUST act as if it does not implement DOIC and cease inserting >> any DOIC related AVPs into any Diameter messages with this specific >> reacting node. >>=20 >> is not clear. Would the reporting node include the OC-Feature-Vector = AVP in the answer only if there is at least one matching capability?=20 >=20 > Because then they have found a way to exchange something that both = ends > know how to handle it. >=20 >> Mandating the reacting node to cease for all time inserting = OC-Feature-Vector AVPs if it did not get back=20 >=20 > There is an obvious typo. It should say: >=20 > policies. At least one the announced capabilities MUST match > mutually. If there is no single matching capability the reporting > node MUST act as if it does not implement DOIC and cease inserting > any DOIC related AVPs into any Diameter messages with this specific > reacting node. >=20 > - JOuni >=20 >=20 >> at least one match is also not ok. The request might have been a = realm-type request (i.e. without Destination Host) and the reacting node = cannot control whether subsequent requests will take the same path to = the same reporting node. >> Even if the request contains a destination host the reacting node = cannot know wether the reacting node's capabilities have been modified = by the time a subsequent request is sent.=20 >> Proposal is to keep only the first sentence and delete the rest. >>=20 >> Ulrich >>=20 >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >=20 From jouni.nospam@gmail.com Mon Dec 9 04:17:44 2013 Return-Path: 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 221401ADBD5 for ; Mon, 9 Dec 2013 04:17:44 -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 b6bhA22zcyk2 for ; Mon, 9 Dec 2013 04:17:42 -0800 (PST) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 2855C1AE253 for ; Mon, 9 Dec 2013 04:17:41 -0800 (PST) Received: by mail-la0-f50.google.com with SMTP id el20so1508134lab.9 for ; Mon, 09 Dec 2013 04:17:36 -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=G1JQDgt8of8/ldUKguSJsd8Cdl7ul0MSlX7l7Ngqf0o=; b=cWWn/MRR5qMBaMtTKWlTNZa/UjwPJDnUYC01eAcgSxn/Zkzvug1mMKBBOryfYaK4p1 O/mniyRGkrfrnrxo+bnAUvAD01DzQIr5pgkcTzsSSJ21lV7Who6b00toUBAKLjeAdp/q irHgieWLtViEM8nUc7LCr859OyHABV0DYQKtNFfesK9OfyVVlcRwkST6wDaKZRLhkbAN JCeYfdsdw/WE1RTy9Yv45cgZ1miZQmMUYjIN2+n6DucfCRV5oKaT52g2xKH7jUPZ/Yba chXjp3uonQbh+Nxci8BdlBT881WVVamqsJVfgSyPUABzj3Q8SwyzqoiTbLUaUgDauSlO 5Atg== X-Received: by 10.152.10.10 with SMTP id e10mr2177514lab.56.1386591456682; Mon, 09 Dec 2013 04:17:36 -0800 (PST) Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id m5sm14134416laj.4.2013.12.09.04.17.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Dec 2013 04:17:35 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: Date: Mon, 9 Dec 2013 14:17:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6B5ED268-1936-44DB-93AD-68341378DCF7@gmail.com> References: <5BCBA1FC2B7F0B4C9D935572D90006681519DAA6@DEMUMBX014.nsn-intra.net> <01D3D8A5-2584-4D81-A010-982C8BF77614@gmail.com> To: Ben Campbell X-Mailer: Apple Mail (2.1510) Cc: "dime@ietf.org" Subject: Re: [Dime] OVLI: comments to 4.2 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 12:17:44 -0000 On Dec 6, 2013, at 11:31 PM, Ben Campbell wrote: >=20 > On Dec 6, 2013, at 4:19 AM, Jouni Korhonen = wrote: >=20 >>>=20 >>> 2. Supporting OLR_DEFAULT_ALGO means different things depending on = the endpoint=92s role (reacting/reporting). >>> Proposal is to expand the text to read: >>>=20 >>>=20 >>> When this flag is set by the overload control reacting endpoint = it means >>> that the default traffic abatement (loss) algorithm is supported = by the >>> reacting endpoint, i.e. the reacting endpont is able and willing = to execute >>> the default traffic abatement algorithm if so requested by the = reporting >>> endpoint. >>> When this flag is set by the overload control reporting endpoint = it means >>> that the reporting endpoint when overloaded is able and willing = to demand >>> executing the default traffic abatement algorithm from the = reacting endpoint. >>=20 >> OK with me. >>=20 >=20 > On reflection, if that's all it means why does the reporting node need = to send it at all? It can just choose to send OLRs for the algorithm the = reacting node has advertised. Or is the reporting node declaring that = this is the algorithm it will use? mmmmmyes..=20 - Jouni >=20 >> - Jouni >=20 From ulrich.wiehe@nsn.com Mon Dec 9 04:24:48 2013 Return-Path: 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 057401AE268 for ; Mon, 9 Dec 2013 04:24:48 -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 wOSSABPsHALp for ; Mon, 9 Dec 2013 04:24:44 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 2171D1ADF67 for ; Mon, 9 Dec 2013 04:24:43 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rB9COZND005888 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 9 Dec 2013 13:24:35 +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 rB9COYcq011495 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Dec 2013 13:24:34 +0100 Received: from DEMUHTC010.nsn-intra.net (10.159.42.41) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 9 Dec 2013 13:24:34 +0100 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.152]) by DEMUHTC010.nsn-intra.net ([10.159.42.41]) with mapi id 14.03.0123.003; Mon, 9 Dec 2013 13:24:34 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: "ext Nirav Salot (nsalot)" , ext Jouni Thread-Topic: [Dime] OVLI: comments to 4.6 Thread-Index: Ac7yfC5RbFsL+gV9TT6AJTwE2Xmtw///9WMA///VCNCAAY5MAP/8pa7Q Date: Mon, 9 Dec 2013 12:24:34 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519E00D@DEMUMBX014.nsn-intra.net> References: <5BCBA1FC2B7F0B4C9D935572D90006681519DCBC@DEMUMBX014.nsn-intra.net> <6950EE6B-689E-47A1-88AA-1A67C47BC82E@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519DD4D@DEMUMBX014.nsn-intra.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.112] Content-Type: text/plain; charset="us-ascii" 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: 8668 X-purgate-ID: 151667::1386591875-000030AF-0892D4CE/0-0/0-0 Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 12:24:48 -0000 Hi Nirav, can you please point out what actually is confusing. I would have thougth t= hat my proposal is more clear and precise as it exactly identifies when a g= iven request matches the OLR (i.e. must undergo the throttling). With regard to complexity there is no difference between checking the two a= llowed enumeration values 1 and 2 (current version) or the two allowed Unsi= gned64 values (0x0000000000000007) and (0x0000000000000019) (my proposal). The main benefit I see with my proposal is the extensibility e.g. One new value of ORIGIN_HOST_MATCH (0x0000000000000020) for Overload Miti= gation Differentiation per client rather than Two new values of "host report with origin-host match" and realm-report wit= h origin-host match". Best regards Ulrich -----Original Message----- From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com]=20 Sent: Saturday, December 07, 2013 10:44 AM To: Wiehe, Ulrich (NSN - DE/Munich); ext Jouni Cc: dime@ietf.org Subject: RE: [Dime] OVLI: comments to 4.6 Hi Ulrich, Instead of re-packing, I see your proposal as confusing or adding more impl= ementation complexity to the exiting simple proposal of having just two Rep= ort-Type. e.g. with your proposal, now the nodes have to validate if the combination = of Report-Type flag is correct/allowed or not and perform the error handlin= g if there is any discrepancy.=20 Besides, I do not see the need for some obvious Report-Type e.g. "APPLICATI= ON_ID_MATCH" since it is always present and/or implicit. Same is the case with "DESTINATION_HOST_PRESENT" and "DESTINATION_HOST_MATC= H". What is the use case for destination-host present but not match? In oth= er words, the reacting node should use this type of report towards which no= de/realm? I guess this time you need to convince me (at least) as why you think so ma= ny different Report-Types are needed and what is the issue with existing de= finition of Report-Type. Regards, Nirav. -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN -= DE/Munich) Sent: Friday, December 06, 2013 7:48 PM To: ext Jouni Cc: dime@ietf.org Subject: Re: [Dime] OVLI: comments to 4.6 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. Best regards Ulrich -----Original Message----- From: ext Jouni [mailto:jouni.nospam@gmail.com]=20 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, > =20 > here are comments to clause 4.6: > =20 > 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 pr= oblems. =20 I do not see how changing the type to unsigned would help with the extensib= ility 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 semantic= s to something like what we have on OC-Feature AVP. How the receiver of the repo= rt 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 receiv= er has no other choice than drop the OLR, since it cannot be sure how to handle th= e 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 ma= ps to a report type (that has been defined after the publication of this=20 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 le= t the reacting node know to which (future) request commands the overload tr= eatment should apply: >=20 > 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=20 > c) The request command's Destination-Host matches the Origin-Host of the = OC-Report-Type AVP's encapsulating answer command >=20 > For a realm report-type the overload treatment should apply to all reques= t commands for which > a) and > d) The request command's Destination-Host is absent and=20 > e) The request command's Destination Realm matches the Origin-Realm of th= e OC-Report-Type AVP's encapsulating answer command. >=20 > The proposal now is to assign individual bits of the Unsinged64 type to a= ), b), c), d), and e): >=20 > Proposed text: > 4.6 OC-Report-Type AVP >=20 > The OC-Report-Type AVP (AVP code TBD5) is type of Unsigned64 and contai= ns a 64 bit flags field of a request > command's characteristics. >=20 > The following characteristics are defined in this document: >=20 > APPLICATION_ID_MATCH (0x0000000000000001) >=20 > 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 Appli= cation-Id of the OC-Report-Type AVP's > encapsulating answer command. >=20 > DESTINATION_HOST_PRESENT (0x0000000000000002) >=20 > 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. >=20 > DESTINATION_HOST_MATCH (0x0000000000000004) >=20 > 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. >=20 > DESTINATION_HOST_ABSENT (0x0000000000000008) >=20 > 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. >=20 > DESTINATION_REALM_MATCH (0x0000000000000010) >=20 > 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. >=20 > Combinations other than=20 > 1) APPLICATION_ID_MATCH and DESTINATION_HOST_PRESENT and DESTINATION_HO= ST_MATCH > and > 2) APPLICATION_ID_MATCH and DESTINATION_HOST_ABSENT and DESTINATION_REA= LM_MATCH > require a mutually agreed extension. >=20 >=20 >=20 >=20 > One extension required by 3GPP applications is the Overload Mitigation Di= fferentiation per client (see 3GPP TR 29.809 clause 6.4.7. To address this,= a new value would be needed e.g. >=20 > ORIGIN_HOST_MATCH (0x0000000000000020) >=20 > 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 Dest= ination-Host of the OC-Report-Type AVP's > encapsulating answer command. >=20 > With this extension the following additional combinations would be allowe= d: > 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 >=20 > Another potential extension is Diameter Agent Overload. To address this, = a new value would be needed e.g. >=20 > NEXT_HOP_MATCH (0x0000000000000040) >=20 > 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. >=20 >=20 > Best regards > Ulrich >=20 >=20 > _______________________________________________ > 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 From nsalot@cisco.com Mon Dec 9 04:43:40 2013 Return-Path: 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 B09291AE2AB for ; Mon, 9 Dec 2013 04:43:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.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 Xlzea2jWpPQ8 for ; Mon, 9 Dec 2013 04:43:38 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 86A761AE2A2 for ; Mon, 9 Dec 2013 04:43:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4663; q=dns/txt; s=iport; t=1386593014; x=1387802614; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=El5gPTbXhay4JcH+M9/epd1qhrHd/F4RbmeKCiMELKE=; b=FrbG9FFFhqjnVd1zmxy7ZaEV30gJLPnPioSsNK9YHM8SS2uWHH1L/mvq ufVH9ejoA79ar8aVq6easDz7pGFRUUKsM8xkiiq5Dy9m4I9k0qf4X5wVo 2yW+S0pUxYrG2hjoC73pV21en4QFeyvcUd/LxgLAN9JGNRqz5+vtYvBO4 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFACi6pVKtJV2b/2dsb2JhbABZgwc4U7kUgS4WdIIlAQEBAwEBAQE3NAsFBwQCAQgRBAEBCxQJBycLFAkIAgQBDQUIh3QGDcElEwSOXzEHBoMagRMDqieDKYIq X-IronPort-AV: E=Sophos;i="4.93,857,1378857600"; d="scan'208";a="290284441" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 09 Dec 2013 12:43:33 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rB9ChXB5029108 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Dec 2013 12:43:33 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.250]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0123.003; Mon, 9 Dec 2013 06:43:33 -0600 From: "Nirav Salot (nsalot)" To: "Wiehe, Ulrich (NSN - DE/Munich)" , Ben Campbell Thread-Topic: [Dime] OVLI: comments to 4.3 Thread-Index: Ac7xzgT7drC0NV4iSVSEGFHx9aP+WQA0gLQAAAa3TAAAER7hgAAJZ7uQAHabNIAACQPf4A== Date: Mon, 9 Dec 2013 12:43:33 +0000 Message-ID: References: <5BCBA1FC2B7F0B4C9D935572D90006681519DB1B@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681519DD2A@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681519DF8A@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681519DF8A@DEMUMBX014.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.38.70] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dime@ietf.org" Subject: Re: [Dime] OVLI: comments to 4.3 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 12:43:40 -0000 Ulrich, > it is also an important part that the reacting node calculates the expiry= time of an OLR based on the included timestamp and duration and not based = on the reception time and the included duration. I do not agree that this is important. I do not see any issue if the reacting node starts the timer equal to Valid= ity-Period on reception of the message containing a fresh OC-OLR. I agree that this means each reacting node will run this timer for differen= t duration since each of them will start the timer of the same value but st= arting from the time when they received OC-OLR. But this is not an issue si= nce Validity-Period is anyway a guestimate and it would provide a natural r= amp up effect (to avoid message storm at the reporting node) if each of the= reacting node stops the throttling at different time. > It is much simpler for reporting nodes to include a pre-calculated OLR in= to the answer rather than to adjust the validity-duration in the OLR in de= pendency of the time when the OLR is included into the answer. I agree. The reporting node should not be required to adjust Validity-Perio= d while sending OC-OLR to different reacting nodes. I do not see any need t= o do so based on my explanation above. Regards, Nirav. -----Original Message----- From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 Sent: Monday, December 09, 2013 4:25 PM To: Nirav Salot (nsalot); Ben Campbell Cc: dime@ietf.org Subject: RE: [Dime] OVLI: comments to 4.3 Nirav, it is also an important part that the reacting node calculates the expiry t= ime of an OLR based on the included timestamp and duration and not based on= the reception time and the included duration. It is much simpler for repor= ting nodes to include a pre-calculated OLR into the answer rather than to = adjust the validity-duration in the OLR in dependency of the time when the = OLR is included into the answer. The reporting node may want the OLR to be = valid starting from creation time (t0) for the validity-duration (d), i.e. = until t0+d independent from the point in time (t0, t0+1,...,t0+d-1) when th= e OLR is sent. Ulrich =20 -----Original Message----- From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com]=20 Sent: Saturday, December 07, 2013 9:27 AM To: Ben Campbell; Wiehe, Ulrich (NSN - DE/Munich) Cc: dime@ietf.org Subject: RE: [Dime] OVLI: comments to 4.3 In my view, from the reacting point of view, Timestamp and Sequence-Number = are both the same since it is just a number defining the uniqueness/version= -Id of the OC-OLR. e.g. we can define Sequence-Number and the reporting node can use Timestamp= to populate the same.=20 The most important part is that the reacting node is not supposed to use th= is parameter for anything but finding out the newness/version-ID of the rep= ort. Beyond that, from the reporting node's point of view, I am fine to use Sequ= ence-Number or Timestamp. Regards, Nirav. -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell Sent: Saturday, December 07, 2013 3:20 AM To: Wiehe, Ulrich (NSN - DE/Munich) Cc: dime@ietf.org Subject: Re: [Dime] OVLI: comments to 4.3 On Dec 6, 2013, at 7:39 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >>=20 >> 2. TimeStamp has been replaced with Sequence-Number. This has the negati= ve impact that reacting nodes must calculate the expiration time base on OL= R-reception time. OLR reception time and OLR creation time may be signific= antly different. >> I don't see any reason in favour of Sequence-Number. Proposal is to repl= ace Sequence-Number with TimeStamp. >=20 > I agree but you need to convince the others as well who favoured sequence= number. I don't think it was so much that we didn't want it to be a timestamp as we= didn't want to mandate the implementation. We need to make sure the number= changes between different versions. A time stamp is one way to do that. A = sequence number (or version number) is another. As I mentioned in a separate thread, we at list need to describe the expect= ed properties. For example, the scope-of-uniqueness, whether we expect the = number to always increase or just be different, etc. It's not clear to me t= hat any association with wall clock time is one of those needed properties,= even though a time stamp might be a perfectly reasonable way to achieve th= e other needed properties. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From ulrich.wiehe@nsn.com Mon Dec 9 04:47:17 2013 Return-Path: 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 BA39A1AE28D for ; Mon, 9 Dec 2013 04:47:17 -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 5Es18llySnA4 for ; Mon, 9 Dec 2013 04:47:15 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id E274C1ADF70 for ; Mon, 9 Dec 2013 04:47:14 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rB9Cl8qD025492 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 9 Dec 2013 13:47:08 +0100 Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rB9Cl8Rj023453 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Dec 2013 13:47:08 +0100 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.123.3; Mon, 9 Dec 2013 13:47:08 +0100 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.152]) by DEMUHTC013.nsn-intra.net ([10.159.42.44]) with mapi id 14.03.0123.003; Mon, 9 Dec 2013 13:47:08 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: ext Jouni Korhonen Thread-Topic: [Dime] OVLI: comments to 4.1 Thread-Index: Ac7xvTHHIECkLcDwSDuVAh2ACeOasAAprlMAAAaV6CAAlFJBAAADLijg Date: Mon, 9 Dec 2013 12:47:07 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519E02B@DEMUMBX014.nsn-intra.net> References: <5BCBA1FC2B7F0B4C9D935572D90006681519DA3E@DEMUMBX014.nsn-intra.net> <6CDCFC84-3048-40B9-91A4-1451FCC65F60@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519DCE5@DEMUMBX014.nsn-intra.net> <09616DA2-D1ED-40EE-8E89-755DFCD81092@gmail.com> In-Reply-To: <09616DA2-D1ED-40EE-8E89-755DFCD81092@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.112] Content-Type: text/plain; charset="us-ascii" 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: 4804 X-purgate-ID: 151667::1386593229-000030AF-58251DCA/0-0/0-0 Cc: "dime@ietf.org" Subject: Re: [Dime] OVLI: comments to 4.1 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 12:47:17 -0000 Isn't it so that the Feature-Vector (if present) always contains something = that an implementation needs to act upon? Ulrich -----Original Message----- From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20 Sent: Monday, December 09, 2013 1:12 PM To: Wiehe, Ulrich (NSN - DE/Munich) Cc: dime@ietf.org Subject: Re: [Dime] OVLI: comments to 4.1 Ulrich, On Dec 6, 2013, at 3:03 PM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: > Hi Jouni, >=20 > thank you for your response. >=20 > With regard to 3)=20 > I still fail to see the usecase for Sequence-Number or TimeStamp within O= C-Feature-Vector. Please clarify. Since we also allow extending the OC-Feature-Vector beyond recognition,=20 it has good chances become a rather complex grouped AVP. In that context the Sequence-Number allows an easy and quick way to check if the feature vector contains something that an implementation needs to act upon. > With regard to 4) > This was not obvious to me. (The obvious typo is the missing "of" between= "one" and "the"). Ack. Fixed the missing 'of'. - Jouni >=20 > Best regards > Ulrich >=20 >=20 > -----Original Message----- > From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20 > Sent: Friday, December 06, 2013 11:17 AM > To: Wiehe, Ulrich (NSN - DE/Munich) > Cc: dime@ietf.org > Subject: Re: [Dime] OVLI: comments to 4.1 >=20 >=20 > On Dec 5, 2013, at 3:23 PM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: >=20 >> Dear all, >>=20 >> here are comments to clause 4.1: >>=20 >> 1. The OC-Feature-Vector AVP is no longer a vector; the name of the AVP = may be misleading. Proposal is to rename it to "OC-Supported-Features AVP" >=20 > OK with me. >=20 >> 2. The OC-Feature AVP is a vector of features. Proposal is to rename it = to "OC-Feature-Vector AVP" >=20 > OK with me. >=20 >> 3. The OC-Sequence-Number within OC-Feature-Vector only makes sense if t= he receiving reporting endpoint can determine the identity of the reacting = endpoint (which is not necessarily the origin host (client), >=20 > My original proposal was to have seqnr as a timestamp. Some folks argued > it is no good and suggested seqnr. I still think time makes more sense th= an > seqnr. >=20 >> it may be an agent and it may not always be the same agent), and if the = reporting endpoint is required to store the OC-Feature-Vector / reacting-en= dpoint-identity pair (which I think both is not required). The reporting en= dpoint can base its processing logic on the actually received OC-Feature-Ve= ctor value, no matter whether it is brand-new or old but stil valid. Propos= al is to delete OC-Sequence-Number AVP from OC-Feature-Vector. >=20 > Do not agree removing it. >=20 >> 4. The text >>=20 >> The reporting node that sends the answer also includes the OC- >> Feature-Vector AVP that describe the capabilities it supports. The >> set of capabilities advertised by the reporting node depends on local >> policies. At least one the announced capabilities MUST match >> mutually. If there is no single matching capability the reacting >> node MUST act as if it does not implement DOIC and cease inserting >> any DOIC related AVPs into any Diameter messages with this specific >> reacting node. >>=20 >> is not clear. Would the reporting node include the OC-Feature-Vector AV= P in the answer only if there is at least one matching capability?=20 >=20 > Because then they have found a way to exchange something that both ends > know how to handle it. >=20 >> Mandating the reacting node to cease for all time inserting OC-Feature-V= ector AVPs if it did not get back=20 >=20 > There is an obvious typo. It should say: >=20 > policies. At least one the announced capabilities MUST match > mutually. If there is no single matching capability the reporting > node MUST act as if it does not implement DOIC and cease inserting > any DOIC related AVPs into any Diameter messages with this specific > reacting node. >=20 > - JOuni >=20 >=20 >> at least one match is also not ok. The request might have been a realm-t= ype request (i.e. without Destination Host) and the reacting node cannot co= ntrol whether subsequent requests will take the same path to the same repor= ting node. >> Even if the request contains a destination host the reacting node cannot= know wether the reacting node's capabilities have been modified by the tim= e a subsequent request is sent.=20 >> Proposal is to keep only the first sentence and delete the rest. >>=20 >> Ulrich >>=20 >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >=20 From jouni.nospam@gmail.com Mon Dec 9 04:55:33 2013 Return-Path: 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 5C8421AE2B7 for ; Mon, 9 Dec 2013 04:55:33 -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 OhyH-4ZR4BXO for ; Mon, 9 Dec 2013 04:55:31 -0800 (PST) Received: from mail-bk0-x22f.google.com (mail-bk0-x22f.google.com [IPv6:2a00:1450:4008:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 204FD1ADF32 for ; Mon, 9 Dec 2013 04:55:30 -0800 (PST) Received: by mail-bk0-f47.google.com with SMTP id mx12so1361917bkb.34 for ; Mon, 09 Dec 2013 04:55:25 -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=QIwec+ZNmsviEbWUuks4eLkuGiC0fVgWqIj1RBOK+g8=; b=M8AVm8QQ14h+SatIiZ38CbE6nxYnGXN9sWzdUGGBV9ZVtYYRtO/pvJEU2EusyJwF2k 0NGjL7ksfv2GZVS0avP02fzrCqT79O2EyBuWB8g0VLf69HZK0wgC1lvVVx+SmHd07/8H DFg6JKWQfGfqMdtQLKRMnCikb8GYnNoX1OTiOtZO0WfpNJZFwFIte6qUqhdZUhc2ff2H ayqGMoUKYf9QQ2EaaryUO8tdgz8JvX1gaS9XXBDoaeQ0vtzptE9l+QvHUX4YyAFznF0K zgNiXhq4w6qRz2FK3871xaM7AS9wtgbOv7CqQ3FJen63jpLLcy2UvPhuIw+QwfaGhcEj Zeaw== X-Received: by 10.204.106.139 with SMTP id x11mr5922307bko.7.1386593725705; Mon, 09 Dec 2013 04:55:25 -0800 (PST) Received: from ?IPv6:2001:1bc8:101:f101:3c66:e081:e506:53b3? ([2001:1bc8:101:f101:3c66:e081:e506:53b3]) by mx.google.com with ESMTPSA id o5sm8581094bkz.4.2013.12.09.04.55.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Dec 2013 04:55:23 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681519E02B@DEMUMBX014.nsn-intra.net> Date: Mon, 9 Dec 2013 14:55:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1A402C59-E390-4C95-8E30-97F1F9D3EF0F@gmail.com> References: <5BCBA1FC2B7F0B4C9D935572D90006681519DA3E@DEMUMBX014.nsn-intra.net> <6CDCFC84-3048-40B9-91A4-1451FCC65F60@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519DCE5@DEMUMBX014.nsn-intra.net> <09616DA2-D1ED-40EE-8E89-755DFCD81092@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E02B@DEMUMBX014.nsn-intra.net> To: "Wiehe, Ulrich (NSN - DE/Munich)" X-Mailer: Apple Mail (2.1510) Cc: "dime@ietf.org" Subject: Re: [Dime] OVLI: comments to 4.1 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 12:55:33 -0000 In the same vein as folks wanted send OLRs with the new or old = information, the feature vector should behave in a same way IMHO. That implies there = are situations when a reception of the feature vector does not change = anything in an endpoint current behavior. - Jouni On Dec 9, 2013, at 2:47 PM, "Wiehe, Ulrich (NSN - DE/Munich)" = wrote: > Isn't it so that the Feature-Vector (if present) always contains = something that an implementation needs to act upon? >=20 > Ulrich >=20 > -----Original Message----- > From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20 > Sent: Monday, December 09, 2013 1:12 PM > To: Wiehe, Ulrich (NSN - DE/Munich) > Cc: dime@ietf.org > Subject: Re: [Dime] OVLI: comments to 4.1 >=20 > Ulrich, >=20 > On Dec 6, 2013, at 3:03 PM, "Wiehe, Ulrich (NSN - DE/Munich)" = wrote: >=20 >> Hi Jouni, >>=20 >> thank you for your response. >>=20 >> With regard to 3)=20 >> I still fail to see the usecase for Sequence-Number or TimeStamp = within OC-Feature-Vector. Please clarify. >=20 > Since we also allow extending the OC-Feature-Vector beyond = recognition,=20 > it has good chances become a rather complex grouped AVP. In that = context > the Sequence-Number allows an easy and quick way to check if the = feature > vector contains something that an implementation needs to act upon. >=20 >> With regard to 4) >> This was not obvious to me. (The obvious typo is the missing "of" = between "one" and "the"). >=20 > Ack. Fixed the missing 'of'. >=20 > - Jouni >=20 >>=20 >> Best regards >> Ulrich >>=20 >>=20 >> -----Original Message----- >> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20 >> Sent: Friday, December 06, 2013 11:17 AM >> To: Wiehe, Ulrich (NSN - DE/Munich) >> Cc: dime@ietf.org >> Subject: Re: [Dime] OVLI: comments to 4.1 >>=20 >>=20 >> On Dec 5, 2013, at 3:23 PM, "Wiehe, Ulrich (NSN - DE/Munich)" = wrote: >>=20 >>> Dear all, >>>=20 >>> here are comments to clause 4.1: >>>=20 >>> 1. The OC-Feature-Vector AVP is no longer a vector; the name of the = AVP may be misleading. Proposal is to rename it to = "OC-Supported-Features AVP" >>=20 >> OK with me. >>=20 >>> 2. The OC-Feature AVP is a vector of features. Proposal is to rename = it to "OC-Feature-Vector AVP" >>=20 >> OK with me. >>=20 >>> 3. The OC-Sequence-Number within OC-Feature-Vector only makes sense = if the receiving reporting endpoint can determine the identity of the = reacting endpoint (which is not necessarily the origin host (client), >>=20 >> My original proposal was to have seqnr as a timestamp. Some folks = argued >> it is no good and suggested seqnr. I still think time makes more = sense than >> seqnr. >>=20 >>> it may be an agent and it may not always be the same agent), and if = the reporting endpoint is required to store the OC-Feature-Vector / = reacting-endpoint-identity pair (which I think both is not required). = The reporting endpoint can base its processing logic on the actually = received OC-Feature-Vector value, no matter whether it is brand-new or = old but stil valid. Proposal is to delete OC-Sequence-Number AVP from = OC-Feature-Vector. >>=20 >> Do not agree removing it. >>=20 >>> 4. The text >>>=20 >>> The reporting node that sends the answer also includes the OC- >>> Feature-Vector AVP that describe the capabilities it supports. The >>> set of capabilities advertised by the reporting node depends on = local >>> policies. At least one the announced capabilities MUST match >>> mutually. If there is no single matching capability the reacting >>> node MUST act as if it does not implement DOIC and cease inserting >>> any DOIC related AVPs into any Diameter messages with this specific >>> reacting node. >>>=20 >>> is not clear. Would the reporting node include the = OC-Feature-Vector AVP in the answer only if there is at least one = matching capability?=20 >>=20 >> Because then they have found a way to exchange something that both = ends >> know how to handle it. >>=20 >>> Mandating the reacting node to cease for all time inserting = OC-Feature-Vector AVPs if it did not get back=20 >>=20 >> There is an obvious typo. It should say: >>=20 >> policies. At least one the announced capabilities MUST match >> mutually. If there is no single matching capability the reporting >> node MUST act as if it does not implement DOIC and cease inserting >> any DOIC related AVPs into any Diameter messages with this specific >> reacting node. >>=20 >> - JOuni >>=20 >>=20 >>> at least one match is also not ok. The request might have been a = realm-type request (i.e. without Destination Host) and the reacting node = cannot control whether subsequent requests will take the same path to = the same reporting node. >>> Even if the request contains a destination host the reacting node = cannot know wether the reacting node's capabilities have been modified = by the time a subsequent request is sent.=20 >>> Proposal is to keep only the first sentence and delete the rest. >>>=20 >>> Ulrich >>>=20 >>>=20 >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>=20 >=20 From nsalot@cisco.com Mon Dec 9 04:56:20 2013 Return-Path: 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 B794E1ADF32 for ; Mon, 9 Dec 2013 04:56:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.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 9MaPS5XZpx5D for ; Mon, 9 Dec 2013 04:56:18 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 380421AE2B7 for ; Mon, 9 Dec 2013 04:56:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9497; q=dns/txt; s=iport; t=1386593773; x=1387803373; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=7GcFh2yPh5kPAx9RGJB3qaGWOg687F0azCd8cFGySzQ=; b=dKoeGPUu7L3TaZ0P9jpchT9Zy7Od3ry38mHk9+aNaUDJ/o4PI4LPmWag GPKIG9ncydzlxEFJUZNnwjfEs3qK2xo9iRtkhRoQa8I02Xn2jM9wXI/Pu Fb5Uc2VRx5Qdk+0HVWJFIP6HDkLOgfQtbczPg2SQK17nAOmMim29X/fOM w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAHK9pVKtJV2d/2dsb2JhbABZgwc4U7kUgS4WdIIlAQEBAwEBAQE3NAsFBwQCAQgRBAEBCxQJByEGCxQJCAEBBAENBQiHaAMJBg26NA2GZxMEjH2BYjEHBoMagRMDlDGBeI5FhTmDKYFqJBw X-IronPort-AV: E=Sophos;i="4.93,857,1378857600"; d="scan'208";a="290304743" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 09 Dec 2013 12:56:13 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id rB9CuDKn012395 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Dec 2013 12:56:13 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.250]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Mon, 9 Dec 2013 06:56:13 -0600 From: "Nirav Salot (nsalot)" To: "Wiehe, Ulrich (NSN - DE/Munich)" , ext Jouni Thread-Topic: [Dime] OVLI: comments to 4.6 Thread-Index: Ac7yfC5RbFsL+gV9TT6AJTwE2XmtwwANV4kAAAOr9wAAG9aeQAB3FIIAAAup3DA= Date: Mon, 9 Dec 2013 12:56:12 +0000 Message-ID: References: <5BCBA1FC2B7F0B4C9D935572D90006681519DCBC@DEMUMBX014.nsn-intra.net> <6950EE6B-689E-47A1-88AA-1A67C47BC82E@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519DD4D@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681519E00D@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681519E00D@DEMUMBX014.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.38.70] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 12:56:20 -0000 Ulrich, Defining a bit "APPLICATION_ID_MATCH" and not having a use case when this b= it is set to "0" (at least in the context of the current draft) is confusin= g to me. Same is the case with some other bits you have proposed. In summary, I do not see any issue with the current ReportType.=20 For the extensibility, we have to deal with it anyway when we have correspo= nding use case in 3GPP or in IETF. In my view, defining the ReportType with= some assumption of its extensibility is confusing since those use cases ar= e not discussed here yet. Regards, Nirav. -----Original Message----- From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 Sent: Monday, December 09, 2013 5:55 PM To: Nirav Salot (nsalot); ext Jouni Cc: dime@ietf.org Subject: RE: [Dime] OVLI: comments to 4.6 Hi Nirav, can you please point out what actually is confusing. I would have thougth t= hat my proposal is more clear and precise as it exactly identifies when a g= iven request matches the OLR (i.e. must undergo the throttling). With regard to complexity there is no difference between checking the two a= llowed enumeration values 1 and 2 (current version) or the two allowed Unsi= gned64 values (0x0000000000000007) and (0x0000000000000019) (my proposal). The main benefit I see with my proposal is the extensibility e.g. One new value of ORIGIN_HOST_MATCH (0x0000000000000020) for Overload Miti= gation Differentiation per client rather than Two new values of "host report with origin-host match" and realm-report wit= h origin-host match". Best regards Ulrich -----Original Message----- From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com]=20 Sent: Saturday, December 07, 2013 10:44 AM To: Wiehe, Ulrich (NSN - DE/Munich); ext Jouni Cc: dime@ietf.org Subject: RE: [Dime] OVLI: comments to 4.6 Hi Ulrich, Instead of re-packing, I see your proposal as confusing or adding more impl= ementation complexity to the exiting simple proposal of having just two Rep= ort-Type. e.g. with your proposal, now the nodes have to validate if the combination = of Report-Type flag is correct/allowed or not and perform the error handlin= g if there is any discrepancy.=20 Besides, I do not see the need for some obvious Report-Type e.g. "APPLICATI= ON_ID_MATCH" since it is always present and/or implicit. Same is the case with "DESTINATION_HOST_PRESENT" and "DESTINATION_HOST_MATC= H". What is the use case for destination-host present but not match? In oth= er words, the reacting node should use this type of report towards which no= de/realm? I guess this time you need to convince me (at least) as why you think so ma= ny different Report-Types are needed and what is the issue with existing de= finition of Report-Type. Regards, Nirav. -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN -= DE/Munich) Sent: Friday, December 06, 2013 7:48 PM To: ext Jouni Cc: dime@ietf.org Subject: Re: [Dime] OVLI: comments to 4.6 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. Best regards Ulrich -----Original Message----- From: ext Jouni [mailto:jouni.nospam@gmail.com]=20 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, > =20 > here are comments to clause 4.6: > =20 > 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 pr= oblems. =20 I do not see how changing the type to unsigned would help with the extensib= ility 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 semantic= s to something like what we have on OC-Feature AVP. How the receiver of the repo= rt 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 receiv= er has no other choice than drop the OLR, since it cannot be sure how to handle th= e 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 ma= ps to a report type (that has been defined after the publication of this=20 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 le= t the reacting node know to which (future) request commands the overload tr= eatment should apply: >=20 > 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=20 > c) The request command's Destination-Host matches the Origin-Host of the = OC-Report-Type AVP's encapsulating answer command >=20 > For a realm report-type the overload treatment should apply to all reques= t commands for which > a) and > d) The request command's Destination-Host is absent and=20 > e) The request command's Destination Realm matches the Origin-Realm of th= e OC-Report-Type AVP's encapsulating answer command. >=20 > The proposal now is to assign individual bits of the Unsinged64 type to a= ), b), c), d), and e): >=20 > Proposed text: > 4.6 OC-Report-Type AVP >=20 > The OC-Report-Type AVP (AVP code TBD5) is type of Unsigned64 and contai= ns a 64 bit flags field of a request > command's characteristics. >=20 > The following characteristics are defined in this document: >=20 > APPLICATION_ID_MATCH (0x0000000000000001) >=20 > 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 Appli= cation-Id of the OC-Report-Type AVP's > encapsulating answer command. >=20 > DESTINATION_HOST_PRESENT (0x0000000000000002) >=20 > 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. >=20 > DESTINATION_HOST_MATCH (0x0000000000000004) >=20 > 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. >=20 > DESTINATION_HOST_ABSENT (0x0000000000000008) >=20 > 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. >=20 > DESTINATION_REALM_MATCH (0x0000000000000010) >=20 > 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. >=20 > Combinations other than=20 > 1) APPLICATION_ID_MATCH and DESTINATION_HOST_PRESENT and DESTINATION_HO= ST_MATCH > and > 2) APPLICATION_ID_MATCH and DESTINATION_HOST_ABSENT and DESTINATION_REA= LM_MATCH > require a mutually agreed extension. >=20 >=20 >=20 >=20 > One extension required by 3GPP applications is the Overload Mitigation Di= fferentiation per client (see 3GPP TR 29.809 clause 6.4.7. To address this,= a new value would be needed e.g. >=20 > ORIGIN_HOST_MATCH (0x0000000000000020) >=20 > 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 Dest= ination-Host of the OC-Report-Type AVP's > encapsulating answer command. >=20 > With this extension the following additional combinations would be allowe= d: > 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 >=20 > Another potential extension is Diameter Agent Overload. To address this, = a new value would be needed e.g. >=20 > NEXT_HOP_MATCH (0x0000000000000040) >=20 > 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. >=20 >=20 > Best regards > Ulrich >=20 >=20 > _______________________________________________ > 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 From ulrich.wiehe@nsn.com Mon Dec 9 05:13:16 2013 Return-Path: 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 5CA391ADF32 for ; Mon, 9 Dec 2013 05:13:16 -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 YusJj5-129Hg for ; Mon, 9 Dec 2013 05:13:13 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 5A65A1ADF66 for ; Mon, 9 Dec 2013 05:13:13 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rB9DD7vb020111 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 9 Dec 2013 14:13:07 +0100 Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rB9DD7Sq009611 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Dec 2013 14:13:07 +0100 Received: from DEMUHTC007.nsn-intra.net (10.159.42.38) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 9 Dec 2013 14:13:06 +0100 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.152]) by DEMUHTC007.nsn-intra.net ([10.159.42.38]) with mapi id 14.03.0123.003; Mon, 9 Dec 2013 14:13:07 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: ext Jouni Korhonen Thread-Topic: [Dime] OVLI: comments to 4.1 Thread-Index: Ac7xvTHHIECkLcDwSDuVAh2ACeOasAAprlMAAAaV6CAAlFJBAAADLijg///yiAD//+yxwA== Date: Mon, 9 Dec 2013 13:13:06 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519E05C@DEMUMBX014.nsn-intra.net> References: <5BCBA1FC2B7F0B4C9D935572D90006681519DA3E@DEMUMBX014.nsn-intra.net> <6CDCFC84-3048-40B9-91A4-1451FCC65F60@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519DCE5@DEMUMBX014.nsn-intra.net> <09616DA2-D1ED-40EE-8E89-755DFCD81092@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E02B@DEMUMBX014.nsn-intra.net> <1A402C59-E390-4C95-8E30-97F1F9D3EF0F@gmail.com> In-Reply-To: <1A402C59-E390-4C95-8E30-97F1F9D3EF0F@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.112] Content-Type: text/plain; charset="us-ascii" 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: 5845 X-purgate-ID: 151667::1386594787-000030AF-A9A372AE/0-0/0-0 Cc: "dime@ietf.org" Subject: Re: [Dime] OVLI: comments to 4.1 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 13:13:16 -0000 There is a fundamental difference: OLRs need to be stored, Feature-Vectors not. When receiving an OLR you may want to know whether its worth the effort to = replace an already stored OLR with the received OLR. When receiving a Feature-Vector you just act on it. Ulrich=20 -----Original Message----- From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20 Sent: Monday, December 09, 2013 1:55 PM To: Wiehe, Ulrich (NSN - DE/Munich) Cc: dime@ietf.org Subject: Re: [Dime] OVLI: comments to 4.1 In the same vein as folks wanted send OLRs with the new or old information, the feature vector should behave in a same way IMHO. That implies there are situations when a reception of the feature vector does not change anything in an endpoint current behavior. - Jouni On Dec 9, 2013, at 2:47 PM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: > Isn't it so that the Feature-Vector (if present) always contains somethin= g that an implementation needs to act upon? >=20 > Ulrich >=20 > -----Original Message----- > From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20 > Sent: Monday, December 09, 2013 1:12 PM > To: Wiehe, Ulrich (NSN - DE/Munich) > Cc: dime@ietf.org > Subject: Re: [Dime] OVLI: comments to 4.1 >=20 > Ulrich, >=20 > On Dec 6, 2013, at 3:03 PM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: >=20 >> Hi Jouni, >>=20 >> thank you for your response. >>=20 >> With regard to 3)=20 >> I still fail to see the usecase for Sequence-Number or TimeStamp within = OC-Feature-Vector. Please clarify. >=20 > Since we also allow extending the OC-Feature-Vector beyond recognition,=20 > it has good chances become a rather complex grouped AVP. In that context > the Sequence-Number allows an easy and quick way to check if the feature > vector contains something that an implementation needs to act upon. >=20 >> With regard to 4) >> This was not obvious to me. (The obvious typo is the missing "of" betwee= n "one" and "the"). >=20 > Ack. Fixed the missing 'of'. >=20 > - Jouni >=20 >>=20 >> Best regards >> Ulrich >>=20 >>=20 >> -----Original Message----- >> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20 >> Sent: Friday, December 06, 2013 11:17 AM >> To: Wiehe, Ulrich (NSN - DE/Munich) >> Cc: dime@ietf.org >> Subject: Re: [Dime] OVLI: comments to 4.1 >>=20 >>=20 >> On Dec 5, 2013, at 3:23 PM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: >>=20 >>> Dear all, >>>=20 >>> here are comments to clause 4.1: >>>=20 >>> 1. The OC-Feature-Vector AVP is no longer a vector; the name of the AVP= may be misleading. Proposal is to rename it to "OC-Supported-Features AVP" >>=20 >> OK with me. >>=20 >>> 2. The OC-Feature AVP is a vector of features. Proposal is to rename it= to "OC-Feature-Vector AVP" >>=20 >> OK with me. >>=20 >>> 3. The OC-Sequence-Number within OC-Feature-Vector only makes sense if = the receiving reporting endpoint can determine the identity of the reacting= endpoint (which is not necessarily the origin host (client), >>=20 >> My original proposal was to have seqnr as a timestamp. Some folks argued >> it is no good and suggested seqnr. I still think time makes more sense t= han >> seqnr. >>=20 >>> it may be an agent and it may not always be the same agent), and if the= reporting endpoint is required to store the OC-Feature-Vector / reacting-e= ndpoint-identity pair (which I think both is not required). The reporting e= ndpoint can base its processing logic on the actually received OC-Feature-V= ector value, no matter whether it is brand-new or old but stil valid. Propo= sal is to delete OC-Sequence-Number AVP from OC-Feature-Vector. >>=20 >> Do not agree removing it. >>=20 >>> 4. The text >>>=20 >>> The reporting node that sends the answer also includes the OC- >>> Feature-Vector AVP that describe the capabilities it supports. The >>> set of capabilities advertised by the reporting node depends on local >>> policies. At least one the announced capabilities MUST match >>> mutually. If there is no single matching capability the reacting >>> node MUST act as if it does not implement DOIC and cease inserting >>> any DOIC related AVPs into any Diameter messages with this specific >>> reacting node. >>>=20 >>> is not clear. Would the reporting node include the OC-Feature-Vector A= VP in the answer only if there is at least one matching capability?=20 >>=20 >> Because then they have found a way to exchange something that both ends >> know how to handle it. >>=20 >>> Mandating the reacting node to cease for all time inserting OC-Feature-= Vector AVPs if it did not get back=20 >>=20 >> There is an obvious typo. It should say: >>=20 >> policies. At least one the announced capabilities MUST match >> mutually. If there is no single matching capability the reporting >> node MUST act as if it does not implement DOIC and cease inserting >> any DOIC related AVPs into any Diameter messages with this specific >> reacting node. >>=20 >> - JOuni >>=20 >>=20 >>> at least one match is also not ok. The request might have been a realm-= type request (i.e. without Destination Host) and the reacting node cannot c= ontrol whether subsequent requests will take the same path to the same repo= rting node. >>> Even if the request contains a destination host the reacting node canno= t know wether the reacting node's capabilities have been modified by the ti= me a subsequent request is sent.=20 >>> Proposal is to keep only the first sentence and delete the rest. >>>=20 >>> Ulrich >>>=20 >>>=20 >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>=20 >=20 From jouni.nospam@gmail.com Mon Dec 9 05:24:45 2013 Return-Path: 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 DAA2F1AE2C5 for ; Mon, 9 Dec 2013 05:24:45 -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 brYlX1PPDrew for ; Mon, 9 Dec 2013 05:24:43 -0800 (PST) Received: from mail-bk0-x22b.google.com (mail-bk0-x22b.google.com [IPv6:2a00:1450:4008:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 12B0F1ADF75 for ; Mon, 9 Dec 2013 05:24:42 -0800 (PST) Received: by mail-bk0-f43.google.com with SMTP id mz12so1368580bkb.30 for ; Mon, 09 Dec 2013 05:24:37 -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=FpaPgF2/lWVIcXgeTuudC1SgFdhloEdpupUVCuUodlY=; b=NfUKWFxDCMWMFzOk6r/za4GJKb3vOphU0zR/5LaRyqR5JjHvGPSFtoTKi+I6IWAjXY 8ZtE94j7kiMDILUuEToP3HJFVTWKXyV5jjF2eNFOgkAKPOKzuLij+XTHcQssG1TQ4y4f fCHWzb9LpIKhybqWkWR9fXplbt11Do+vANSdXrcO5+k2z7ATjplUYTxlsBO3Xmo6FCMy pv8wAzHA2g1ddps5Jy8S7dwIqKq7ht1bPr83jmmqpVyEaKfaoJB2cV5D96oY/nBKMAkH vgtQDL1wPU0DeBGZdgvTM6oPmRZ56jletYvNHh0MFaZByTh262nDPpN6Yli4Nq7kj12v gugg== X-Received: by 10.205.35.204 with SMTP id sx12mr2258511bkb.49.1386595477735; Mon, 09 Dec 2013 05:24:37 -0800 (PST) Received: from ?IPv6:2001:1bc8:101:f101:3c66:e081:e506:53b3? ([2001:1bc8:101:f101:3c66:e081:e506:53b3]) by mx.google.com with ESMTPSA id lr9sm8646293bkb.2.2013.12.09.05.24.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Dec 2013 05:24:33 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681519E05C@DEMUMBX014.nsn-intra.net> Date: Mon, 9 Dec 2013 15:24:32 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <790F1603-64D5-40E2-BC59-FD4C104EEF1B@gmail.com> References: <5BCBA1FC2B7F0B4C9D935572D90006681519DA3E@DEMUMBX014.nsn-intra.net> <6CDCFC84-3048-40B9-91A4-1451FCC65F60@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519DCE5@DEMUMBX014.nsn-intra.net> <09616DA2-D1ED-40EE-8E89-755DFCD81092@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E02B@DEMUMBX014.nsn-intra.net> <1A402C59-E390-4C95-8E30-97F1F9D3EF0F@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E05C@DEMUMBX014.nsn-intra.net> To: "Wiehe, Ulrich (NSN - DE/Munich)" X-Mailer: Apple Mail (2.1510) Cc: "dime@ietf.org" Subject: Re: [Dime] OVLI: comments to 4.1 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 13:24:46 -0000 On Dec 9, 2013, at 3:13 PM, "Wiehe, Ulrich (NSN - DE/Munich)" = wrote: > There is a fundamental difference: > OLRs need to be stored, Feature-Vectors not. How come feature vector does not need to be stored? I do not get that? I would set my implementation to a specific state or mode based on the feature vector. When that changes I'd like to know that. And then keep functioning based on that. - Jouni > When receiving an OLR you may want to know whether its worth the = effort to replace an already stored OLR with the received OLR. > When receiving a Feature-Vector you just act on it. >=20 > Ulrich=20 >=20 > -----Original Message----- > From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20 > Sent: Monday, December 09, 2013 1:55 PM > To: Wiehe, Ulrich (NSN - DE/Munich) > Cc: dime@ietf.org > Subject: Re: [Dime] OVLI: comments to 4.1 >=20 >=20 > In the same vein as folks wanted send OLRs with the new or old = information, > the feature vector should behave in a same way IMHO. That implies = there are > situations when a reception of the feature vector does not change = anything > in an endpoint current behavior. >=20 > - Jouni >=20 > On Dec 9, 2013, at 2:47 PM, "Wiehe, Ulrich (NSN - DE/Munich)" = wrote: >=20 >> Isn't it so that the Feature-Vector (if present) always contains = something that an implementation needs to act upon? >>=20 >> Ulrich >>=20 >> -----Original Message----- >> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20 >> Sent: Monday, December 09, 2013 1:12 PM >> To: Wiehe, Ulrich (NSN - DE/Munich) >> Cc: dime@ietf.org >> Subject: Re: [Dime] OVLI: comments to 4.1 >>=20 >> Ulrich, >>=20 >> On Dec 6, 2013, at 3:03 PM, "Wiehe, Ulrich (NSN - DE/Munich)" = wrote: >>=20 >>> Hi Jouni, >>>=20 >>> thank you for your response. >>>=20 >>> With regard to 3)=20 >>> I still fail to see the usecase for Sequence-Number or TimeStamp = within OC-Feature-Vector. Please clarify. >>=20 >> Since we also allow extending the OC-Feature-Vector beyond = recognition,=20 >> it has good chances become a rather complex grouped AVP. In that = context >> the Sequence-Number allows an easy and quick way to check if the = feature >> vector contains something that an implementation needs to act upon. >>=20 >>> With regard to 4) >>> This was not obvious to me. (The obvious typo is the missing "of" = between "one" and "the"). >>=20 >> Ack. Fixed the missing 'of'. >>=20 >> - Jouni >>=20 >>>=20 >>> Best regards >>> Ulrich >>>=20 >>>=20 >>> -----Original Message----- >>> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20 >>> Sent: Friday, December 06, 2013 11:17 AM >>> To: Wiehe, Ulrich (NSN - DE/Munich) >>> Cc: dime@ietf.org >>> Subject: Re: [Dime] OVLI: comments to 4.1 >>>=20 >>>=20 >>> On Dec 5, 2013, at 3:23 PM, "Wiehe, Ulrich (NSN - DE/Munich)" = wrote: >>>=20 >>>> Dear all, >>>>=20 >>>> here are comments to clause 4.1: >>>>=20 >>>> 1. The OC-Feature-Vector AVP is no longer a vector; the name of the = AVP may be misleading. Proposal is to rename it to = "OC-Supported-Features AVP" >>>=20 >>> OK with me. >>>=20 >>>> 2. The OC-Feature AVP is a vector of features. Proposal is to = rename it to "OC-Feature-Vector AVP" >>>=20 >>> OK with me. >>>=20 >>>> 3. The OC-Sequence-Number within OC-Feature-Vector only makes sense = if the receiving reporting endpoint can determine the identity of the = reacting endpoint (which is not necessarily the origin host (client), >>>=20 >>> My original proposal was to have seqnr as a timestamp. Some folks = argued >>> it is no good and suggested seqnr. I still think time makes more = sense than >>> seqnr. >>>=20 >>>> it may be an agent and it may not always be the same agent), and if = the reporting endpoint is required to store the OC-Feature-Vector / = reacting-endpoint-identity pair (which I think both is not required). = The reporting endpoint can base its processing logic on the actually = received OC-Feature-Vector value, no matter whether it is brand-new or = old but stil valid. Proposal is to delete OC-Sequence-Number AVP from = OC-Feature-Vector. >>>=20 >>> Do not agree removing it. >>>=20 >>>> 4. The text >>>>=20 >>>> The reporting node that sends the answer also includes the OC- >>>> Feature-Vector AVP that describe the capabilities it supports. The >>>> set of capabilities advertised by the reporting node depends on = local >>>> policies. At least one the announced capabilities MUST match >>>> mutually. If there is no single matching capability the reacting >>>> node MUST act as if it does not implement DOIC and cease inserting >>>> any DOIC related AVPs into any Diameter messages with this specific >>>> reacting node. >>>>=20 >>>> is not clear. Would the reporting node include the = OC-Feature-Vector AVP in the answer only if there is at least one = matching capability?=20 >>>=20 >>> Because then they have found a way to exchange something that both = ends >>> know how to handle it. >>>=20 >>>> Mandating the reacting node to cease for all time inserting = OC-Feature-Vector AVPs if it did not get back=20 >>>=20 >>> There is an obvious typo. It should say: >>>=20 >>> policies. At least one the announced capabilities MUST match >>> mutually. If there is no single matching capability the reporting >>> node MUST act as if it does not implement DOIC and cease inserting >>> any DOIC related AVPs into any Diameter messages with this specific >>> reacting node. >>>=20 >>> - JOuni >>>=20 >>>=20 >>>> at least one match is also not ok. The request might have been a = realm-type request (i.e. without Destination Host) and the reacting node = cannot control whether subsequent requests will take the same path to = the same reporting node. >>>> Even if the request contains a destination host the reacting node = cannot know wether the reacting node's capabilities have been modified = by the time a subsequent request is sent.=20 >>>> Proposal is to keep only the first sentence and delete the rest. >>>>=20 >>>> Ulrich >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >>>=20 >>=20 >=20 From ulrich.wiehe@nsn.com Mon Dec 9 05:38:41 2013 Return-Path: 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 3E6741ADF75 for ; Mon, 9 Dec 2013 05:38:41 -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 29jQCwCkGWjs for ; Mon, 9 Dec 2013 05:38:38 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 85FC81ADF7B for ; Mon, 9 Dec 2013 05:38:37 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rB9DcSxL007804 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 9 Dec 2013 14:38:28 +0100 Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rB9DcSGt021187 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Dec 2013 14:38:28 +0100 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.152]) by DEMUHTC002.nsn-intra.net ([10.159.42.33]) with mapi id 14.03.0123.003; Mon, 9 Dec 2013 14:38:27 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: "ext Nirav Salot (nsalot)" , ext Jouni Thread-Topic: [Dime] OVLI: comments to 4.6 Thread-Index: Ac7yfC5RbFsL+gV9TT6AJTwE2Xmtw///9WMA///VCNCAAY5MAP/8pa7QgAa0jQD//+gXwA== Date: Mon, 9 Dec 2013 13:38:27 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519E086@DEMUMBX014.nsn-intra.net> References: <5BCBA1FC2B7F0B4C9D935572D90006681519DCBC@DEMUMBX014.nsn-intra.net> <6950EE6B-689E-47A1-88AA-1A67C47BC82E@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519DD4D@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681519E00D@DEMUMBX014.nsn-intra.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.112] Content-Type: text/plain; charset="us-ascii" 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: 10318 X-purgate-ID: 151667::1386596308-00002466-3BABD335/0-0/0-0 Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 13:38:41 -0000 Hi Nirav, in the end its a matter of taste, and I definitly prefer the Unsigned64 app= roach. Please note: The Enumerated approach also has a value (0 Reserved) without = use case. And there is confusing text e.g. "...should apply to requests tha= t the reacting node knows will reach the overloaded node."=20 How would the reacting node know that a request will actually reach the ove= rloaded node? And even if it knows this, wouldn't the overload treatment ap= ply only to those requests that match the application-id from the answer? Best regards Ulrich -----Original Message----- From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com]=20 Sent: Monday, December 09, 2013 1:56 PM To: Wiehe, Ulrich (NSN - DE/Munich); ext Jouni Cc: dime@ietf.org Subject: RE: [Dime] OVLI: comments to 4.6 Ulrich, Defining a bit "APPLICATION_ID_MATCH" and not having a use case when this b= it is set to "0" (at least in the context of the current draft) is confusin= g to me. Same is the case with some other bits you have proposed. In summary, I do not see any issue with the current ReportType.=20 For the extensibility, we have to deal with it anyway when we have correspo= nding use case in 3GPP or in IETF. In my view, defining the ReportType with= some assumption of its extensibility is confusing since those use cases ar= e not discussed here yet. Regards, Nirav. -----Original Message----- From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 Sent: Monday, December 09, 2013 5:55 PM To: Nirav Salot (nsalot); ext Jouni Cc: dime@ietf.org Subject: RE: [Dime] OVLI: comments to 4.6 Hi Nirav, can you please point out what actually is confusing. I would have thougth t= hat my proposal is more clear and precise as it exactly identifies when a g= iven request matches the OLR (i.e. must undergo the throttling). With regard to complexity there is no difference between checking the two a= llowed enumeration values 1 and 2 (current version) or the two allowed Unsi= gned64 values (0x0000000000000007) and (0x0000000000000019) (my proposal). The main benefit I see with my proposal is the extensibility e.g. One new value of ORIGIN_HOST_MATCH (0x0000000000000020) for Overload Miti= gation Differentiation per client rather than Two new values of "host report with origin-host match" and realm-report wit= h origin-host match". Best regards Ulrich -----Original Message----- From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com]=20 Sent: Saturday, December 07, 2013 10:44 AM To: Wiehe, Ulrich (NSN - DE/Munich); ext Jouni Cc: dime@ietf.org Subject: RE: [Dime] OVLI: comments to 4.6 Hi Ulrich, Instead of re-packing, I see your proposal as confusing or adding more impl= ementation complexity to the exiting simple proposal of having just two Rep= ort-Type. e.g. with your proposal, now the nodes have to validate if the combination = of Report-Type flag is correct/allowed or not and perform the error handlin= g if there is any discrepancy.=20 Besides, I do not see the need for some obvious Report-Type e.g. "APPLICATI= ON_ID_MATCH" since it is always present and/or implicit. Same is the case with "DESTINATION_HOST_PRESENT" and "DESTINATION_HOST_MATC= H". What is the use case for destination-host present but not match? In oth= er words, the reacting node should use this type of report towards which no= de/realm? I guess this time you need to convince me (at least) as why you think so ma= ny different Report-Types are needed and what is the issue with existing de= finition of Report-Type. Regards, Nirav. -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN -= DE/Munich) Sent: Friday, December 06, 2013 7:48 PM To: ext Jouni Cc: dime@ietf.org Subject: Re: [Dime] OVLI: comments to 4.6 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. Best regards Ulrich -----Original Message----- From: ext Jouni [mailto:jouni.nospam@gmail.com]=20 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, > =20 > here are comments to clause 4.6: > =20 > 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 pr= oblems. =20 I do not see how changing the type to unsigned would help with the extensib= ility 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 semantic= s to something like what we have on OC-Feature AVP. How the receiver of the repo= rt 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 receiv= er has no other choice than drop the OLR, since it cannot be sure how to handle th= e 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 ma= ps to a report type (that has been defined after the publication of this=20 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 le= t the reacting node know to which (future) request commands the overload tr= eatment should apply: >=20 > 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=20 > c) The request command's Destination-Host matches the Origin-Host of the = OC-Report-Type AVP's encapsulating answer command >=20 > For a realm report-type the overload treatment should apply to all reques= t commands for which > a) and > d) The request command's Destination-Host is absent and=20 > e) The request command's Destination Realm matches the Origin-Realm of th= e OC-Report-Type AVP's encapsulating answer command. >=20 > The proposal now is to assign individual bits of the Unsinged64 type to a= ), b), c), d), and e): >=20 > Proposed text: > 4.6 OC-Report-Type AVP >=20 > The OC-Report-Type AVP (AVP code TBD5) is type of Unsigned64 and contai= ns a 64 bit flags field of a request > command's characteristics. >=20 > The following characteristics are defined in this document: >=20 > APPLICATION_ID_MATCH (0x0000000000000001) >=20 > 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 Appli= cation-Id of the OC-Report-Type AVP's > encapsulating answer command. >=20 > DESTINATION_HOST_PRESENT (0x0000000000000002) >=20 > 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. >=20 > DESTINATION_HOST_MATCH (0x0000000000000004) >=20 > 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. >=20 > DESTINATION_HOST_ABSENT (0x0000000000000008) >=20 > 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. >=20 > DESTINATION_REALM_MATCH (0x0000000000000010) >=20 > 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. >=20 > Combinations other than=20 > 1) APPLICATION_ID_MATCH and DESTINATION_HOST_PRESENT and DESTINATION_HO= ST_MATCH > and > 2) APPLICATION_ID_MATCH and DESTINATION_HOST_ABSENT and DESTINATION_REA= LM_MATCH > require a mutually agreed extension. >=20 >=20 >=20 >=20 > One extension required by 3GPP applications is the Overload Mitigation Di= fferentiation per client (see 3GPP TR 29.809 clause 6.4.7. To address this,= a new value would be needed e.g. >=20 > ORIGIN_HOST_MATCH (0x0000000000000020) >=20 > 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 Dest= ination-Host of the OC-Report-Type AVP's > encapsulating answer command. >=20 > With this extension the following additional combinations would be allowe= d: > 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 >=20 > Another potential extension is Diameter Agent Overload. To address this, = a new value would be needed e.g. >=20 > NEXT_HOP_MATCH (0x0000000000000040) >=20 > 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. >=20 >=20 > Best regards > Ulrich >=20 >=20 > _______________________________________________ > 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 From srdonovan@usdonovans.com Mon Dec 9 05:42:15 2013 Return-Path: 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 136041AE294 for ; Mon, 9 Dec 2013 05:42:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.58 X-Spam-Level: * X-Spam-Status: No, score=1.58 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no 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 dxYztUsZAYkf for ; Mon, 9 Dec 2013 05:42:14 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 11FDC1ADF84 for ; Mon, 9 Dec 2013 05:42:14 -0800 (PST) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:54113 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1Vq168-00083A-Qt for dime@ietf.org; Mon, 09 Dec 2013 05:42:09 -0800 Message-ID: <52A5C8B0.2080002@usdonovans.com> Date: Mon, 09 Dec 2013 07:42:08 -0600 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "dime@ietf.org" Content-Type: multipart/alternative; boundary="------------010805090607030908060607" X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com Subject: [Dime] DOIC: Sections 5.3.1 and 5.3.2 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 13:42:15 -0000 This is a multi-part message in MIME format. --------------010805090607030908060607 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The wording in section 5.3.1 and 5.3.2 need to be aligned with the reacting and reporting node concepts. The wording "Request/Response Message Initiator" is misleading in this context. The "initiator" of the message will be either a client or a server. The logic being discussed in 5.3.1 deals with the reacting node and the logic in 5.3.2 deals with the reporting node. Given that an agent can be reacting and/or reporting node but does not initiate the messages, I suggest changing the titles to the sections to: 5.3.1 Reacting Node Endpoint Considerations and 5.3.2 Reporting Node Endpoint Considerations The text in the sections should also be updated to align with the reacting node and reporting node concepts. Regards, Steve --------------010805090607030908060607 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The wording in section 5.3.1 and 5.3.2 need to be aligned with the reacting and reporting node concepts.  The wording "Request/Response Message Initiator" is misleading in this context.  The "initiator" of the message will be either a client or a server.  The logic being discussed in 5.3.1 deals with the reacting node and the logic in 5.3.2 deals with the reporting node.  Given that an agent can be reacting and/or reporting node but does not initiate the messages, I suggest changing the titles to the sections to:

5.3.1 Reacting Node Endpoint Considerations

and

5.3.2 Reporting Node Endpoint Considerations

The text in the sections should also be updated to align with the reacting node and reporting node concepts.

Regards,

Steve
 --------------010805090607030908060607-- From ulrich.wiehe@nsn.com Mon Dec 9 06:43:44 2013 Return-Path: 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 5D5D71AE2EE for ; Mon, 9 Dec 2013 06:43:44 -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 qX_AvtHVB04G for ; Mon, 9 Dec 2013 06:43:41 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 49F6E1AE2E2 for ; Mon, 9 Dec 2013 06:43:41 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rB9EhZQx028662 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 9 Dec 2013 15:43:35 +0100 Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rB9EhYMq019134 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Dec 2013 15:43:34 +0100 Received: from DEMUHTC005.nsn-intra.net (10.159.42.36) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 9 Dec 2013 15:43:33 +0100 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.152]) by DEMUHTC005.nsn-intra.net ([10.159.42.36]) with mapi id 14.03.0123.003; Mon, 9 Dec 2013 15:43:33 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: ext Jouni Korhonen Thread-Topic: [Dime] OVLI: comments to 4.1 Thread-Index: Ac7xvTHHIECkLcDwSDuVAh2ACeOasAAprlMAAAaV6CAAlFJBAAADLijg///yiAD//+yxwIAAG3gA///jPWA= Date: Mon, 9 Dec 2013 14:43:33 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519E0D9@DEMUMBX014.nsn-intra.net> References: <5BCBA1FC2B7F0B4C9D935572D90006681519DA3E@DEMUMBX014.nsn-intra.net> <6CDCFC84-3048-40B9-91A4-1451FCC65F60@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519DCE5@DEMUMBX014.nsn-intra.net> <09616DA2-D1ED-40EE-8E89-755DFCD81092@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E02B@DEMUMBX014.nsn-intra.net> <1A402C59-E390-4C95-8E30-97F1F9D3EF0F@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E05C@DEMUMBX014.nsn-intra.net> <790F1603-64D5-40E2-BC59-FD4C104EEF1B@gmail.com> In-Reply-To: <790F1603-64D5-40E2-BC59-FD4C104EEF1B@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.112] Content-Type: text/plain; charset="us-ascii" 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: 6937 X-purgate-ID: 151667::1386600215-000030AF-208BAF6B/0-0/0-0 Cc: "dime@ietf.org" Subject: Re: [Dime] OVLI: comments to 4.1 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 14:43:44 -0000 But maintaining a specific state per reacting node is very resource consumi= ng for the (overloaded) reporting node. It is simpler and more efficient to= base any processing logic on actual information received in the request ra= ther than on information stored from previous communication. Ulrich -----Original Message----- From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20 Sent: Monday, December 09, 2013 2:25 PM To: Wiehe, Ulrich (NSN - DE/Munich) Cc: dime@ietf.org Subject: Re: [Dime] OVLI: comments to 4.1 On Dec 9, 2013, at 3:13 PM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: > There is a fundamental difference: > OLRs need to be stored, Feature-Vectors not. How come feature vector does not need to be stored? I do not get that? I would set my implementation to a specific state or mode based on the feature vector. When that changes I'd like to know that. And then keep functioning based on that. - Jouni > When receiving an OLR you may want to know whether its worth the effort t= o replace an already stored OLR with the received OLR. > When receiving a Feature-Vector you just act on it. >=20 > Ulrich=20 >=20 > -----Original Message----- > From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20 > Sent: Monday, December 09, 2013 1:55 PM > To: Wiehe, Ulrich (NSN - DE/Munich) > Cc: dime@ietf.org > Subject: Re: [Dime] OVLI: comments to 4.1 >=20 >=20 > In the same vein as folks wanted send OLRs with the new or old informatio= n, > the feature vector should behave in a same way IMHO. That implies there a= re > situations when a reception of the feature vector does not change anythin= g > in an endpoint current behavior. >=20 > - Jouni >=20 > On Dec 9, 2013, at 2:47 PM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: >=20 >> Isn't it so that the Feature-Vector (if present) always contains somethi= ng that an implementation needs to act upon? >>=20 >> Ulrich >>=20 >> -----Original Message----- >> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20 >> Sent: Monday, December 09, 2013 1:12 PM >> To: Wiehe, Ulrich (NSN - DE/Munich) >> Cc: dime@ietf.org >> Subject: Re: [Dime] OVLI: comments to 4.1 >>=20 >> Ulrich, >>=20 >> On Dec 6, 2013, at 3:03 PM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: >>=20 >>> Hi Jouni, >>>=20 >>> thank you for your response. >>>=20 >>> With regard to 3)=20 >>> I still fail to see the usecase for Sequence-Number or TimeStamp within= OC-Feature-Vector. Please clarify. >>=20 >> Since we also allow extending the OC-Feature-Vector beyond recognition,= =20 >> it has good chances become a rather complex grouped AVP. In that context >> the Sequence-Number allows an easy and quick way to check if the feature >> vector contains something that an implementation needs to act upon. >>=20 >>> With regard to 4) >>> This was not obvious to me. (The obvious typo is the missing "of" betwe= en "one" and "the"). >>=20 >> Ack. Fixed the missing 'of'. >>=20 >> - Jouni >>=20 >>>=20 >>> Best regards >>> Ulrich >>>=20 >>>=20 >>> -----Original Message----- >>> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20 >>> Sent: Friday, December 06, 2013 11:17 AM >>> To: Wiehe, Ulrich (NSN - DE/Munich) >>> Cc: dime@ietf.org >>> Subject: Re: [Dime] OVLI: comments to 4.1 >>>=20 >>>=20 >>> On Dec 5, 2013, at 3:23 PM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: >>>=20 >>>> Dear all, >>>>=20 >>>> here are comments to clause 4.1: >>>>=20 >>>> 1. The OC-Feature-Vector AVP is no longer a vector; the name of the AV= P may be misleading. Proposal is to rename it to "OC-Supported-Features AVP= " >>>=20 >>> OK with me. >>>=20 >>>> 2. The OC-Feature AVP is a vector of features. Proposal is to rename i= t to "OC-Feature-Vector AVP" >>>=20 >>> OK with me. >>>=20 >>>> 3. The OC-Sequence-Number within OC-Feature-Vector only makes sense if= the receiving reporting endpoint can determine the identity of the reactin= g endpoint (which is not necessarily the origin host (client), >>>=20 >>> My original proposal was to have seqnr as a timestamp. Some folks argue= d >>> it is no good and suggested seqnr. I still think time makes more sense = than >>> seqnr. >>>=20 >>>> it may be an agent and it may not always be the same agent), and if th= e reporting endpoint is required to store the OC-Feature-Vector / reacting-= endpoint-identity pair (which I think both is not required). The reporting = endpoint can base its processing logic on the actually received OC-Feature-= Vector value, no matter whether it is brand-new or old but stil valid. Prop= osal is to delete OC-Sequence-Number AVP from OC-Feature-Vector. >>>=20 >>> Do not agree removing it. >>>=20 >>>> 4. The text >>>>=20 >>>> The reporting node that sends the answer also includes the OC- >>>> Feature-Vector AVP that describe the capabilities it supports. The >>>> set of capabilities advertised by the reporting node depends on local >>>> policies. At least one the announced capabilities MUST match >>>> mutually. If there is no single matching capability the reacting >>>> node MUST act as if it does not implement DOIC and cease inserting >>>> any DOIC related AVPs into any Diameter messages with this specific >>>> reacting node. >>>>=20 >>>> is not clear. Would the reporting node include the OC-Feature-Vector = AVP in the answer only if there is at least one matching capability?=20 >>>=20 >>> Because then they have found a way to exchange something that both ends >>> know how to handle it. >>>=20 >>>> Mandating the reacting node to cease for all time inserting OC-Feature= -Vector AVPs if it did not get back=20 >>>=20 >>> There is an obvious typo. It should say: >>>=20 >>> policies. At least one the announced capabilities MUST match >>> mutually. If there is no single matching capability the reporting >>> node MUST act as if it does not implement DOIC and cease inserting >>> any DOIC related AVPs into any Diameter messages with this specific >>> reacting node. >>>=20 >>> - JOuni >>>=20 >>>=20 >>>> at least one match is also not ok. The request might have been a realm= -type request (i.e. without Destination Host) and the reacting node cannot = control whether subsequent requests will take the same path to the same rep= orting node. >>>> Even if the request contains a destination host the reacting node cann= ot know wether the reacting node's capabilities have been modified by the t= ime a subsequent request is sent.=20 >>>> Proposal is to keep only the first sentence and delete the rest. >>>>=20 >>>> Ulrich >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >>>=20 >>=20 >=20 From srdonovan@usdonovans.com Mon Dec 9 07:56:20 2013 Return-Path: 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 157821AE307 for ; Mon, 9 Dec 2013 07:56:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.139 X-Spam-Level: X-Spam-Status: No, score=-0.139 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no 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 Lp55kmh0Q0X2 for ; Mon, 9 Dec 2013 07:56:17 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 565621AE287 for ; Mon, 9 Dec 2013 07:56:17 -0800 (PST) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:55075 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1Vq3Bk-0005qW-Ek for dime@ietf.org; Mon, 09 Dec 2013 07:56:12 -0800 Message-ID: <52A5E813.60801@usdonovans.com> Date: Mon, 09 Dec 2013 09:56:03 -0600 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: dime@ietf.org References: <5BCBA1FC2B7F0B4C9D935572D90006681519DA3E@DEMUMBX014.nsn-intra.net> <6CDCFC84-3048-40B9-91A4-1451FCC65F60@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519DCE5@DEMUMBX014.nsn-intra.net> <09616DA2-D1ED-40EE-8E89-755DFCD81092@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E02B@DEMUMBX014.nsn-intra.net> <1A402C59-E390-4C95-8E30-97F1F9D3EF0F@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E05C@DEMUMBX014.nsn-intra.net> <790F1603-64D5-40E2-BC59-FD4C104EEF1B@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E0D9@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681519E0D9@DEMUMBX014.nsn-intra.net> Content-Type: multipart/alternative; boundary="------------080703010304000801030501" X-OutGoing-Spam-Status: No, score=-1.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com Subject: Re: [Dime] OVLI: comments to 4.1 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 15:56:20 -0000 This is a multi-part message in MIME format. --------------080703010304000801030501 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Ulrich, Looking at the impacts of removing the sequence number from the feature vector AVP. This would require the following logic for each request received at the reporting node: Parse the full set of OC-Feature-Vector AVPs Calculate the set of overlapping capabilities Generate the reporting nodes OC-Feature-Vector AVPs If the reporting node is in overload then generate and append the OC-OLR AVPs. Keeping the version number requires the reporting node to do the following: Parse the feature vector sequence number If the sequence number is changed from the last version number received then Parse the remaining OC-Feature-Vector AVPs Calculate the set of overlapping capabilities Generate the reporting nodes capability AVPs Save the version number and results of capabilities exchange If the reporting node is in overload then generate and append the OC-OLR AVPs. Removing the sequence number forces the reporting node to do extra work for all requests, including requests received when overloaded. Given that the sequence number will almost never change, this seems like a bad idea. We should be reducing the work of overloaded nodes, not increasing it. Regards, Steve On 12/9/13 8:43 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: > But maintaining a specific state per reacting node is very resource consuming for the (overloaded) reporting node. It is simpler and more efficient to base any processing logic on actual information received in the request rather than on information stored from previous communication. > > Ulrich > > -----Original Message----- > From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] > Sent: Monday, December 09, 2013 2:25 PM > To: Wiehe, Ulrich (NSN - DE/Munich) > Cc: dime@ietf.org > Subject: Re: [Dime] OVLI: comments to 4.1 > > > On Dec 9, 2013, at 3:13 PM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: > >> There is a fundamental difference: >> OLRs need to be stored, Feature-Vectors not. > How come feature vector does not need to be stored? I do not > get that? I would set my implementation to a specific state > or mode based on the feature vector. When that changes I'd > like to know that. And then keep functioning based on that. > > - Jouni > >> When receiving an OLR you may want to know whether its worth the effort to replace an already stored OLR with the received OLR. >> When receiving a Feature-Vector you just act on it. >> >> Ulrich >> >> -----Original Message----- >> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] >> Sent: Monday, December 09, 2013 1:55 PM >> To: Wiehe, Ulrich (NSN - DE/Munich) >> Cc: dime@ietf.org >> Subject: Re: [Dime] OVLI: comments to 4.1 >> >> >> In the same vein as folks wanted send OLRs with the new or old information, >> the feature vector should behave in a same way IMHO. That implies there are >> situations when a reception of the feature vector does not change anything >> in an endpoint current behavior. >> >> - Jouni >> >> On Dec 9, 2013, at 2:47 PM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: >> >>> Isn't it so that the Feature-Vector (if present) always contains something that an implementation needs to act upon? >>> >>> Ulrich >>> >>> -----Original Message----- >>> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] >>> Sent: Monday, December 09, 2013 1:12 PM >>> To: Wiehe, Ulrich (NSN - DE/Munich) >>> Cc: dime@ietf.org >>> Subject: Re: [Dime] OVLI: comments to 4.1 >>> >>> Ulrich, >>> >>> On Dec 6, 2013, at 3:03 PM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: >>> >>>> Hi Jouni, >>>> >>>> thank you for your response. >>>> >>>> With regard to 3) >>>> I still fail to see the usecase for Sequence-Number or TimeStamp within OC-Feature-Vector. Please clarify. >>> Since we also allow extending the OC-Feature-Vector beyond recognition, >>> it has good chances become a rather complex grouped AVP. In that context >>> the Sequence-Number allows an easy and quick way to check if the feature >>> vector contains something that an implementation needs to act upon. >>> >>>> With regard to 4) >>>> This was not obvious to me. (The obvious typo is the missing "of" between "one" and "the"). >>> Ack. Fixed the missing 'of'. >>> >>> - Jouni >>> >>>> Best regards >>>> Ulrich >>>> >>>> >>>> -----Original Message----- >>>> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] >>>> Sent: Friday, December 06, 2013 11:17 AM >>>> To: Wiehe, Ulrich (NSN - DE/Munich) >>>> Cc: dime@ietf.org >>>> Subject: Re: [Dime] OVLI: comments to 4.1 >>>> >>>> >>>> On Dec 5, 2013, at 3:23 PM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: >>>> >>>>> Dear all, >>>>> >>>>> here are comments to clause 4.1: >>>>> >>>>> 1. The OC-Feature-Vector AVP is no longer a vector; the name of the AVP may be misleading. Proposal is to rename it to "OC-Supported-Features AVP" >>>> OK with me. >>>> >>>>> 2. The OC-Feature AVP is a vector of features. Proposal is to rename it to "OC-Feature-Vector AVP" >>>> OK with me. >>>> >>>>> 3. The OC-Sequence-Number within OC-Feature-Vector only makes sense if the receiving reporting endpoint can determine the identity of the reacting endpoint (which is not necessarily the origin host (client), >>>> My original proposal was to have seqnr as a timestamp. Some folks argued >>>> it is no good and suggested seqnr. I still think time makes more sense than >>>> seqnr. >>>> >>>>> it may be an agent and it may not always be the same agent), and if the reporting endpoint is required to store the OC-Feature-Vector / reacting-endpoint-identity pair (which I think both is not required). The reporting endpoint can base its processing logic on the actually received OC-Feature-Vector value, no matter whether it is brand-new or old but stil valid. Proposal is to delete OC-Sequence-Number AVP from OC-Feature-Vector. >>>> Do not agree removing it. >>>> >>>>> 4. The text >>>>> >>>>> The reporting node that sends the answer also includes the OC- >>>>> Feature-Vector AVP that describe the capabilities it supports. The >>>>> set of capabilities advertised by the reporting node depends on local >>>>> policies. At least one the announced capabilities MUST match >>>>> mutually. If there is no single matching capability the reacting >>>>> node MUST act as if it does not implement DOIC and cease inserting >>>>> any DOIC related AVPs into any Diameter messages with this specific >>>>> reacting node. >>>>> >>>>> is not clear. Would the reporting node include the OC-Feature-Vector AVP in the answer only if there is at least one matching capability? >>>> Because then they have found a way to exchange something that both ends >>>> know how to handle it. >>>> >>>>> Mandating the reacting node to cease for all time inserting OC-Feature-Vector AVPs if it did not get back >>>> There is an obvious typo. It should say: >>>> >>>> policies. At least one the announced capabilities MUST match >>>> mutually. If there is no single matching capability the reporting >>>> node MUST act as if it does not implement DOIC and cease inserting >>>> any DOIC related AVPs into any Diameter messages with this specific >>>> reacting node. >>>> >>>> - JOuni >>>> >>>> >>>>> at least one match is also not ok. The request might have been a realm-type request (i.e. without Destination Host) and the reacting node cannot control whether subsequent requests will take the same path to the same reporting node. >>>>> Even if the request contains a destination host the reacting node cannot know wether the reacting node's capabilities have been modified by the time a subsequent request is sent. >>>>> Proposal is to keep only the first sentence and delete the rest. >>>>> >>>>> Ulrich >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 > --------------080703010304000801030501 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Ulrich,

Looking at the impacts of removing the sequence number from the feature vector AVP.  This would require the following logic for each request received at the reporting node:

Parse the full set of OC-Feature-Vector AVPs
Calculate the set of overlapping capabilities
Generate the reporting nodes OC-Feature-Vector AVPs
If the reporting node is in overload then generate and append the OC-OLR AVPs.

Keeping the version number requires the reporting node to do the following:

Parse the feature vector sequence number
If the sequence number is changed from the last version number received then
  Parse the remaining OC-Feature-Vector AVPs
  Calculate the set of overlapping capabilities
  Generate the reporting nodes capability AVPs
  Save the version number and results of capabilities exchange
If the reporting node is in overload then generate and append the OC-OLR AVPs.

Removing the sequence number forces the reporting node to do extra work for all requests, including requests received when overloaded.  Given that the sequence number will almost never change, this seems like a bad idea.  We should be reducing the work of overloaded nodes, not increasing it.

Regards,

Steve
On 12/9/13 8:43 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
But maintaining a specific state per reacting node is very resource consuming for the (overloaded) reporting node. It is simpler and more efficient to base any processing logic on actual information received in the request rather than on information stored from previous communication.

Ulrich

-----Original Message-----
From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] 
Sent: Monday, December 09, 2013 2:25 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: dime@ietf.org
Subject: Re: [Dime] OVLI: comments to 4.1


On Dec 9, 2013, at 3:13 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> wrote:


There is a fundamental difference:
OLRs need to be stored, Feature-Vectors not.

How come feature vector does not need to be stored? I do not
get that? I would set my implementation to a specific state
or mode based on the feature vector. When that changes I'd
like to know that. And then keep functioning based on that.

- Jouni


When receiving an OLR you may want to know whether its worth the effort to replace an already stored OLR with the received OLR.
When receiving a Feature-Vector you just act on it.

Ulrich 

-----Original Message-----
From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] 
Sent: Monday, December 09, 2013 1:55 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: dime@ietf.org
Subject: Re: [Dime] OVLI: comments to 4.1


In the same vein as folks wanted send OLRs with the new or old information,
the feature vector should behave in a same way IMHO. That implies there are
situations when a reception of the feature vector does not change anything
in an endpoint current behavior.

- Jouni

On Dec 9, 2013, at 2:47 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> wrote:


Isn't it so that the Feature-Vector (if present) always contains something that an implementation needs to act upon?

Ulrich

-----Original Message-----
From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] 
Sent: Monday, December 09, 2013 1:12 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: dime@ietf.org
Subject: Re: [Dime] OVLI: comments to 4.1

Ulrich,

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


Hi Jouni,

thank you for your response.

With regard to 3) 
I still fail to see the usecase for Sequence-Number or TimeStamp within OC-Feature-Vector. Please clarify.

Since we also allow extending the OC-Feature-Vector beyond recognition, 
it has good chances become a rather complex grouped AVP. In that context
the Sequence-Number allows an easy and quick way to check if the feature
vector contains something that an implementation needs to act upon.


With regard to 4)
This was not obvious to me. (The obvious typo is the missing "of" between "one" and "the").

Ack. Fixed the missing 'of'.

- Jouni


Best regards
Ulrich


-----Original Message-----
From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] 
Sent: Friday, December 06, 2013 11:17 AM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: dime@ietf.org
Subject: Re: [Dime] OVLI: comments to 4.1


On Dec 5, 2013, at 3:23 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> wrote:


Dear all,

here are comments to clause 4.1:

1. The OC-Feature-Vector AVP is no longer a vector; the name of the AVP may be misleading. Proposal is to rename it to "OC-Supported-Features AVP"

OK with me.


2. The OC-Feature AVP is a vector of features. Proposal is to rename it to "OC-Feature-Vector AVP"

OK with me.


3. The OC-Sequence-Number within OC-Feature-Vector only makes sense if the receiving reporting endpoint can determine the identity of the reacting endpoint (which is not necessarily the origin host (client),

My original proposal was to have seqnr as a timestamp. Some folks argued
it is no good and suggested seqnr. I still think time makes more sense than
seqnr.


it may be an agent and it may not always be the same agent), and if the reporting endpoint is required to store the OC-Feature-Vector / reacting-endpoint-identity pair (which I think both is not required). The reporting endpoint can base its processing logic on the actually received OC-Feature-Vector value, no matter whether it is brand-new or old but stil valid. Proposal is to delete OC-Sequence-Number AVP from OC-Feature-Vector.

Do not agree removing it.


4. The text

The reporting node that sends the answer also includes the OC-
Feature-Vector AVP that describe the capabilities it supports.  The
set of capabilities advertised by the reporting node depends on local
policies.  At least one the announced capabilities MUST match
mutually.  If there is no single matching capability the reacting
node MUST act as if it does not implement DOIC and cease inserting
any DOIC related AVPs into any Diameter messages with this specific
reacting node.

is not clear.  Would the reporting node include the OC-Feature-Vector AVP in the answer only if there is at least one matching capability? 

Because then they have found a way to exchange something that both ends
know how to handle it.


Mandating the reacting node to cease for all time inserting OC-Feature-Vector AVPs if it did not get back 

There is an obvious typo. It should say:

policies.  At least one the announced capabilities MUST match
mutually.  If there is no single matching capability the reporting
node MUST act as if it does not implement DOIC and cease inserting
any DOIC related AVPs into any Diameter messages with this specific
reacting node.

- JOuni



at least one match is also not ok. The request might have been a realm-type request (i.e. without Destination Host) and the reacting node cannot control whether subsequent requests will take the same path to the same reporting node.
Even if the request contains a destination host the reacting node cannot know wether the reacting node's capabilities have been modified by the time a subsequent request is sent. 
Proposal is to keep only the first sentence and delete the rest.

Ulrich


_______________________________________________
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



    

    

  


--------------080703010304000801030501--

From srdonovan@usdonovans.com  Mon Dec  9 08:00:14 2013
Return-Path: 
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 BF4A41AE347 for ; Mon,  9 Dec 2013 08:00:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.779
X-Spam-Level: 
X-Spam-Status: No, score=0.779 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no
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 kWFIo9OHFXqX for ; Mon,  9 Dec 2013 08:00:13 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id E9EBD1AE357 for ; Mon,  9 Dec 2013 08:00:09 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:55087 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1Vq3Fa-0001cV-88 for dime@ietf.org; Mon, 09 Dec 2013 08:00:03 -0800
Message-ID: <52A5E902.20605@usdonovans.com>
Date: Mon, 09 Dec 2013 10:00:02 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: dime@ietf.org
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DB1B@DEMUMBX014.nsn-intra.net> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------070802010606000707000700"
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 09 Dec 2013 16:00:15 -0000

This is a multi-part message in MIME format.
--------------070802010606000707000700
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Jouni,

I propose that we keep the name OC-Sequence-Number but that we use the
Time type for OC-Sequence-Number.  It is misleading and potentially
confusing to call it OC-Time-Stamp. 

We might consider expanding on the format of the AVP to make it
something like Session-ID, where it is a concatenation of the
Diameter-ID of the generating node and a timestamp.  This might help the
reacting node keep track of which sequence number it has received.

Steve

On 12/9/13 5:37 AM, Jouni Korhonen wrote:
> Folks
>
> Could we conclude on the sequence number vs. time stamp vs. something else?
> We got more important places to spend our energy than this ;)
>
> My proposal is the following (based on the original pre-00 design):
>
> o We change the OC-Sequence-Number to OC-Time-Stamp in all occurrences
>   in the -01.
> o We use RFC6733 Time type for the OC-Time-Stamp. RFC6733 gives us
>   already exact definition how to handle the AVP.
> o Define that the OC-Time-Stamp is the time of the creation of the 
>   "original" AVP within whose context the time stamp is present.
> o The OC-Time-Stamp AVP uniqueness is still considered to be in scope
>   of the communicating endpoints.
> o The time stamp can be used to quickly determine if the content of
>   the encapsulating AVP context has changed (among other properties).
>   This would be useful specifically in the future when the encapsulating
>   grouped AVPs  grow in size and functionality.
>
>
> - Jouni
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>


--------------070802010606000707000700
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Jouni,

      

      I propose that we keep the name OC-Sequence-Number but that we use
      the Time type for OC-Sequence-Number.  It is misleading and
      potentially confusing to call it OC-Time-Stamp.  

      

      We might consider expanding on the format of the AVP to make it
      something like Session-ID, where it is a concatenation of the
      Diameter-ID of the generating node and a timestamp.  This might
      help the reacting node keep track of which sequence number it has
      received.

      

      Steve

      

    
    
On 12/9/13 5:37 AM, Jouni Korhonen
      wrote:

    

    

      
Folks

Could we conclude on the sequence number vs. time stamp vs. something else?
We got more important places to spend our energy than this ;)

My proposal is the following (based on the original pre-00 design):

o We change the OC-Sequence-Number to OC-Time-Stamp in all occurrences
  in the -01.
o We use RFC6733 Time type for the OC-Time-Stamp. RFC6733 gives us
  already exact definition how to handle the AVP.
o Define that the OC-Time-Stamp is the time of the creation of the 
  "original" AVP within whose context the time stamp is present.
o The OC-Time-Stamp AVP uniqueness is still considered to be in scope
  of the communicating endpoints.
o The time stamp can be used to quickly determine if the content of
  the encapsulating AVP context has changed (among other properties).
  This would be useful specifically in the future when the encapsulating
  grouped AVPs  grow in size and functionality.


- Jouni

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



    

    

  


--------------070802010606000707000700--

From ben@nostrum.com  Mon Dec  9 11:26:39 2013
Return-Path: 
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 62A2D1AE07C for ; Mon,  9 Dec 2013 11:26:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Level: 
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no
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 Ue6hsbH3LUSZ for ; Mon,  9 Dec 2013 11:26:37 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6A9DA1AE07D for ; Mon,  9 Dec 2013 11:26:36 -0800 (PST)
Received: from [10.119.73.38] (174.34.177.203.rdns.ubiquity.io [174.34.177.203] (may be forged)) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rB9JPuH0024379 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 9 Dec 2013 13:25:57 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Ben Campbell 
In-Reply-To: <26C84DFD55BC3040A45BF70926E55F2587C1D016@SZXEMA512-MBX.china.huawei.com>
Date: Mon, 9 Dec 2013 13:25:50 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <345A59EB-A13B-4E0A-A616-94D0A82A4D99@nostrum.com>
References: , <2901_1385634414_52971A6E_2901_2686_1_6B7134B31289DC4FAF731D844122B36E307743@PEXCVZYM13.corporate.adroot.infra.ftgroup>  <26C84DFD55BC3040A45BF70926E55F2587C1D016@SZXEMA512-MBX.china.huawei.com>
To: "Shishufeng (Susan)" 
X-Mailer: Apple Mail (2.1822)
Received-SPF: pass (shaman.nostrum.com: 174.34.177.203 is authenticated by a trusted mechanism)
Cc: "dime@ietf.org" 
Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same type) within a response message
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 09 Dec 2013 19:26:39 -0000

Susan, am I correct in reading that to mean that while it may only make =
sense to have one host report or one realm report, this may not be true =
for all future report types, and that it should be up to the definition =
of each report type to allow or disallow multiple instances? If so, I =
agree.

Any report type that allows multiple instances will need to describe how =
to handle (or avoid) potential conflicts.

On Dec 9, 2013, at 4:12 AM, Shishufeng (Susan) =
 wrote:

> Hi Nirav,
> =20
> For now, I couldn=92t see the need to have more than one instance of =
the overload report with the same report-type, i.e. host or realm. But =
to allow extensibility if needed in the future, whether some texts can =
be written in the IETF e.g. Multiple OC-OLR AVPs exist with different =
report types, if it is not the case, it is the application where =
multiple OC-OLR AVPs are allowed with the same report type to specify =
the details how to differentiate the information contained in these =
OC-OLR AVPs. Thus we can move on without having to addressing the issue =
now in the base solution.
> =20
> Best Regards,
> Susan
> =20
> From: Nirav Salot (nsalot) [mailto:nsalot@cisco.com]=20
> Sent: Thursday, November 28, 2013 8:00 PM
> To: lionel.morand@orange.com
> Cc: dime@ietf.org
> Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same =
type) within a response message
> =20
> Lionel,
>=20
> 3gpp may define an optional avp which can be included by the reporting =
node if it wishes to do so. E.g. APN can be additionally included by the =
reporting node to indicate APN specific overload within the given =
application.
> In that case, the reporting node may also want to indicate application =
level overload without including the APN (e.g. this overload report is =
applicable to all other APNs).
>=20
> And hence there is a possibility of including multiple instances of =
the overload report.
>=20
> I am not suggesting that 3gpp will define APN (or any other avp) =
within overload report. But later, if 3gpp need to define the same, then =
corresponding handling needs to be defined within IETF now.
>=20
> Regards,
> Nirav.
>=20
> On Nov 28, 2013 3:56 PM, "lionel.morand@orange.com" =
 wrote:
> Hi Nirav,
> =20
> Not sure to understand the proposal or question.
> The OLR is significant per application (piggybacking principle). So if =
the 3GPP decides to add specific AVPs in the OLR (that will be =
possible), what would be the need to add the OLR without the specific =
3GPP AVPs as the OLR will be anyway handle by 3GPP aware entities?
> =20
> Lionel
> =20
> De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot =
(nsalot)
> Envoy=E9 : jeudi 28 novembre 2013 10:33
> =C0 : dime@ietf.org
> Objet : [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same =
type) within a response message
> =20
> Hi,
> =20
> As I understand IETF will define the base overload control solution as =
part of DOIC. Then 3GPP would adopt the defined solution for each of its =
application.
> When that happens, 3GPP might want to add 3GPP specific AVP within =
OC-OLR AVP. Based on the current definition of the OC-OLR AVP this =
should be allowed since it contains "* [AVP]" in its definition.
> e.g. for a given application 3GPP decides to add information into =
OC-OLR which changes the scope of the OC-OLR from application level to =
the provided information level.
> Additionally, the reporting may want to advertise the OC-OLR at the =
application level scope =96 i.e. the OC-OLR without any 3GPP specific =
info.
> =20
> So if the above is allowed, we will have the possibility of the =
reporting node wanting to include two instances of OC-OLR with the =
Report-Type=3D"host".
> And then we need to define the handling of multiple instances of =
OC-OLR in the DOIC draft.
> =20
> So the questions are,
> -          Is 3GPP (or any other SDO) allowed to extend the definition =
of OC-OLR by adding information into it?
> -          If no, can we guarantee that application level scope of =
OC-OLR (which is what we have defined currently) is sufficient (and not =
restricting) to all the applications of 3GPP?
> =20
> Regards,
> Nirav.
> =20
> =
__________________________________________________________________________=
_______________________________________________
> =20
> 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.
> =20
> 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


From ben@nostrum.com  Mon Dec  9 14:19:17 2013
Return-Path: 
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 38A681AE5FE for ; Mon,  9 Dec 2013 14:19:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Level: 
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no
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 YNwH89PLuVrO for ; Mon,  9 Dec 2013 14:19:15 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8B8791AE5EA for ; Mon,  9 Dec 2013 14:19:15 -0800 (PST)
Received: from [10.119.72.250] (173.234.16.35.rdns.ubiquity.io [173.234.16.35] (may be forged)) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rB9MIv8P031477 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 9 Dec 2013 16:18:58 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Ben Campbell 
In-Reply-To: <453156F8-9090-46D4-BF8E-A877F40EE3AC@gmail.com>
Date: Mon, 9 Dec 2013 16:18:51 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DCBC@DEMUMBX014.nsn-intra.net> <453156F8-9090-46D4-BF8E-A877F40EE3AC@gmail.com>
To: Jouni Korhonen 
X-Mailer: Apple Mail (2.1822)
Received-SPF: pass (shaman.nostrum.com: 173.234.16.35 is authenticated by a trusted mechanism)
Cc: "dime@ietf.org list" 
Subject: Re: [Dime] Conclusion for the Report Type
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 09 Dec 2013 22:19:17 -0000

It's probably also worth adding some guidance on when it makes sense to =
define a new report type. For example, if I want to add a new AVP that =
can be safely ignored by a recipient that doesn't understand it, I =
probably don't need a new report type.

On Dec 9, 2013, at 6:00 AM, Jouni Korhonen  =
wrote:

> Folks,
>=20
> We need a conclusion here so that I can actually write something
> into the -01. How about the following (I try to reflect as many
> points given here as possible):
>=20
> 1) The basic principle for the Report Type use is that only one
>   OLR per report type is allowed unless the report type and the
>   OLR reflecting the new report type define exact semantics how
>   to differentiate between multiple OLRs with the same report
>   type. In 3GPP context, for example, a report type with an AVP
>   that identifies an APN could be such a differentiator.. and that
>   would need a new report type where an implementation exactly
>   knows to look for this additional AVP without guesswork or=20
>   fuzzy heuristics.
>=20
> 2) A new report type or a set of new report types require a new
>   feature to be allocated/defined so that both endpoints know how
>   to handle the new report type that was defined after the
>   publication of the baseline specification. The handling of the
>   new report types must be defined (along with the new AVPs it
>   might need to be included into the OC-OLR AVP).
>=20
> 3) With 2) in place I do not care whether the OC-Report-Type is
>   enumerated or unsigned (flag vector?). I still favour Enumerated
>   myself as it forces the protocol designer to come up with a=20
>   cleaner design ;)
>=20
> 4) For the baseline we only define host and realm report types.
>   We do not allow multiple OLRs with these report types i.e.
>   single instances of OLRs with host and/or realm are allowed.
>=20
> - Jouni
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From ben@nostrum.com  Mon Dec  9 14:25:00 2013
Return-Path: 
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 5EC591AE607 for ; Mon,  9 Dec 2013 14:25:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Level: 
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no
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 rbXheJYxbmXn for ; Mon,  9 Dec 2013 14:24:58 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5F2B91AE5FF for ; Mon,  9 Dec 2013 14:24:58 -0800 (PST)
Received: from [10.119.72.250] (173.234.16.35.rdns.ubiquity.io [173.234.16.35] (may be forged)) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rB9MOnRH031715 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 9 Dec 2013 16:24:50 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Ben Campbell 
In-Reply-To: 
Date: Mon, 9 Dec 2013 16:24:42 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <2495B298-0B49-406A-884C-0C354D87948E@nostrum.com>
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DB1B@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D90006681519DD2A@DEMUMBX014.nsn-intra.net>   <5BCBA1FC2B7F0B4C9D935572D90006681519DF8A@DEMUMBX014.nsn-intra.net> 
To: "Nirav Salot (nsalot)" 
X-Mailer: Apple Mail (2.1822)
Received-SPF: pass (shaman.nostrum.com: 173.234.16.35 is authenticated by a trusted mechanism)
Cc: "dime@ietf.org" 
Subject: Re: [Dime] OVLI: comments to 4.3
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 09 Dec 2013 22:25:00 -0000

On Dec 9, 2013, at 6:43 AM, Nirav Salot (nsalot)  =
wrote:

> Ulrich,
>=20
>> it is also an important part that the reacting node calculates the =
expiry time of an OLR based on the included timestamp and duration and =
not based on the reception time and the included duration.
> I do not agree that this is important.

> I do not see any issue if the reacting node starts the timer equal to =
Validity-Period on reception of the message containing a fresh OC-OLR.
> I agree that this means each reacting node will run this timer for =
different duration since each of them will start the timer of the same =
value but starting from the time when they received OC-OLR. But this is =
not an issue since Validity-Period is anyway a guestimate and it would =
provide a natural ramp up effect (to avoid message storm at the =
reporting node) if each of the reacting node stops the throttling at =
different time.
>=20

Nirav and I agree on something for a change :-) The validity period is =
from the time you first get the OLR. It's not based on a timestamp in =
the message. The in-transit times for an OLR are not going to be so =
long, and the need for precision not so high, to justify the need for a =
time reference in the OLR.


>> It is much simpler for reporting nodes to include a pre-calculated =
OLR into the answer rather than  to adjust the validity-duration in the =
OLR in dependency of the time when the OLR is included into the answer.
> I agree. The reporting node should not be required to adjust =
Validity-Period while sending OC-OLR to different reacting nodes. I do =
not see any need to do so based on my explanation above.
>=20

This would only be an issue if we expect an overloaded node to keep the =
same overload state for relatively long periods of time. The nature of =
overload is such that I do not expect that to be true.

However, one point we need to be clear on is that receipt of a new copy =
of the same OLR does not restart the timer.


From ben@nostrum.com  Mon Dec  9 14:34:51 2013
Return-Path: 
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 988571AE0B9 for ; Mon,  9 Dec 2013 14:34:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Level: 
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no
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 7oTZ1N8Ky_Lr for ; Mon,  9 Dec 2013 14:34:50 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2A7EA1ADF99 for ; Mon,  9 Dec 2013 14:34:50 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rB9MYhDg032155 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 9 Dec 2013 16:34:44 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Ben Campbell 
In-Reply-To: <52A5E902.20605@usdonovans.com>
Date: Mon, 9 Dec 2013 16:34:42 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <7475B713-1104-4791-96B1-CE97632A0D69@nostrum.com>
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DB1B@DEMUMBX014.nsn-intra.net>  <52A5E902.20605@usdonovans.com>
To: Steve Donovan 
X-Mailer: Apple Mail (2.1822)
Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism)
Cc: "dime@ietf.org list" 
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 09 Dec 2013 22:34:51 -0000

On Dec 9, 2013, at 10:00 AM, Steve Donovan  =
wrote:

> Jouni,
>=20
> I propose that we keep the name OC-Sequence-Number but that we use the =
Time type for OC-Sequence-Number.  It is misleading and potentially =
confusing to call it OC-Time-Stamp. =20
>=20

I could live with that, although I would rather just define the expected =
properties of the sequence number, and leave the implementation up to =
the implementor. I assume your reasoning for not calling it a timestamp =
is that you do not want people to try to use it as a time base =
reference. If so, then we don't require any connection to a clock. We =
just need it to be monotonically increasing.

> We might consider expanding on the format of the AVP to make it =
something like Session-ID, where it is a concatenation of the =
Diameter-ID of the generating node and a timestamp.  This might help the =
reacting node keep track of which sequence number it has received.
>=20

Do we need a uniqueness across multiple nodes property? If so, why?

> Steve
>=20
> On 12/9/13 5:37 AM, Jouni Korhonen wrote:
>> Folks
>>=20
>> Could we conclude on the sequence number vs. time stamp vs. something =
else?
>> We got more important places to spend our energy than this ;)
>>=20
>> My proposal is the following (based on the original pre-00 design):
>>=20
>> o We change the OC-Sequence-Number to OC-Time-Stamp in all =
occurrences
>>   in the -01.
>> o We use RFC6733 Time type for the OC-Time-Stamp. RFC6733 gives us
>>   already exact definition how to handle the AVP.
>> o Define that the OC-Time-Stamp is the time of the creation of the=20
>>   "original" AVP within whose context the time stamp is present.
>> o The OC-Time-Stamp AVP uniqueness is still considered to be in scope
>>   of the communicating endpoints.
>> o The time stamp can be used to quickly determine if the content of
>>   the encapsulating AVP context has changed (among other properties).
>>   This would be useful specifically in the future when the =
encapsulating
>>   grouped AVPs  grow in size and functionality.
>>=20
>>=20
>> - Jouni
>>=20
>> _______________________________________________
>> DiME mailing list
>>=20
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>>=20
>>=20
>>=20
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From ben@nostrum.com  Mon Dec  9 14:46:55 2013
Return-Path: 
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 9B4981AE087 for ; Mon,  9 Dec 2013 14:46:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Level: 
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no
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 s5ewWc3AWxAE for ; Mon,  9 Dec 2013 14:46:54 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id A3AFD1AE07F for ; Mon,  9 Dec 2013 14:46:54 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rB9MkmpA032679 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 9 Dec 2013 16:46:49 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Ben Campbell 
In-Reply-To: <52A5E813.60801@usdonovans.com>
Date: Mon, 9 Dec 2013 16:46:46 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <7AE3F729-B987-45B1-A9AF-2F0C9A36641E@nostrum.com>
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DA3E@DEMUMBX014.nsn-intra.net> <6CDCFC84-3048-40B9-91A4-1451FCC65F60@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519DCE5@DEMUMBX014.nsn-intra.net> <09616DA2-D1ED-40EE-8E89-755DFCD81092@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E02B@DEMUMBX014.nsn-intra.net> <1A402C59-E390-4C95-8E30-97F1F9D3EF0F@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E05C@DEMUMBX014.nsn-intra.net> <790F1603-64D5-40E2-BC59-FD4C104EEF1B@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E0D9@DEMUMBX014.nsn-intra.net> <52A5E813.60801@usdonovans.com>
To: Steve Donovan 
X-Mailer: Apple Mail (2.1822)
Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism)
Cc: "dime@ietf.org list" 
Subject: Re: [Dime] OVLI: comments to 4.1
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 09 Dec 2013 22:46:55 -0000

On Dec 9, 2013, at 9:56 AM, Steve Donovan  =
wrote:

> Ulrich,
>=20
> Looking at the impacts of removing the sequence number from the =
feature vector AVP.  This would require the following logic for each =
request received at the reporting node:
>=20
> Parse the full set of OC-Feature-Vector AVPs=20
> Calculate the set of overlapping capabilities
> Generate the reporting nodes OC-Feature-Vector AVPs
> If the reporting node is in overload then generate and append the =
OC-OLR AVPs.
>=20
> Keeping the version number requires the reporting node to do the =
following:
>=20
> Parse the feature vector sequence number
> If the sequence number is changed from the last version number =
received then=20
>   Parse the remaining OC-Feature-Vector AVPs
>   Calculate the set of overlapping capabilities
>   Generate the reporting nodes capability AVPs
>   Save the version number and results of capabilities exchange
> If the reporting node is in overload then generate and append the =
OC-OLR AVPs.
>=20
> Removing the sequence number forces the reporting node to do extra =
work for all requests, including requests received when overloaded.  =
Given that the sequence number will almost never change, this seems like =
a bad idea.  We should be reducing the work of overloaded nodes, not =
increasing it.

It's worth pointing out that, if someone believes the sequence number =
comparison is not worth the trouble, they can always ignore it and =
revert to Steve's first example.


From ben@nostrum.com  Mon Dec  9 15:53:25 2013
Return-Path: 
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 A6FB91ADF5A for ; Mon,  9 Dec 2013 15:53:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.035
X-Spam-Level: 
X-Spam-Status: No, score=-1.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001] autolearn=no
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 pyql6jCAZBay for ; Mon,  9 Dec 2013 15:53:24 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0A1411ADF71 for ; Mon,  9 Dec 2013 15:53:23 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rB9NrHpr035347 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 9 Dec 2013 17:53:18 -0600 (CST) (envelope-from ben@nostrum.com)
From: Ben Campbell 
Content-Type: multipart/alternative; boundary="Apple-Mail=_1137622B-7D57-4B61-9977-62FE24A184B9"
Message-Id: <8FD63E2D-5203-4DA4-A6DA-C4CA181C9CFB@nostrum.com>
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
Date: Mon, 9 Dec 2013 17:53:15 -0600
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>  <14594_1386204165_529FCC05_14594_12646_1_6B7134B31289DC4FAF731D844122B36E329907@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B920972CCAA@ESESSMB101.ericsson.se>  <52A077CC.3000004@usdonovans.com>  <52A088D0.2020406@usdonovans.com>  <52A091CE.2000104@usdonovans.com> <13081_1386256433_52A09831_13081_8197_1_6B7134B31289DC4FAF! 731D84412 2B36E32B6EB@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B9209739738@ESESSMB101.ericsson.se> 
To: "dime@ietf.org list" 
In-Reply-To: 
X-Mailer: Apple Mail (2.1822)
Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism)
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 09 Dec 2013 23:53:25 -0000

--Apple-Mail=_1137622B-7D57-4B61-9977-62FE24A184B9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

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:=20

The recipient cannot assume an OLR matches the context of the =
transaction in which it is received. =20
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  =
wrote:

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


--Apple-Mail=_1137622B-7D57-4B61-9977-62FE24A184B9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252


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> =
wrote:


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

- =
Jouni


=

--Apple-Mail=_1137622B-7D57-4B61-9977-62FE24A184B9--

From susan.shishufeng@huawei.com  Mon Dec  9 18:46:42 2013
Return-Path: 
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 37BF11AE107 for ; Mon,  9 Dec 2013 18:46:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level: 
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 5kEnzZPoGIqJ for ; Mon,  9 Dec 2013 18:46:39 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 909281ADED7 for ; Mon,  9 Dec 2013 18:46:38 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBE57682; Tue, 10 Dec 2013 02:46:32 +0000 (GMT)
Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 10 Dec 2013 02:46:25 +0000
Received: from SZXEMA401-HUB.china.huawei.com (10.82.72.33) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 10 Dec 2013 02:46:31 +0000
Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.155]) by SZXEMA401-HUB.china.huawei.com ([10.82.72.33]) with mapi id 14.03.0158.001; Tue, 10 Dec 2013 10:46:18 +0800
From: "Shishufeng (Susan)" 
To: Ben Campbell 
Thread-Topic: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same type) within a response message
Thread-Index: AQHO7DRyp0pKDS+VfEyygMMnybAXTZpLsyOAgAAXRwCAAP2CkA==
Date: Tue, 10 Dec 2013 02:46:16 +0000
Message-ID: <26C84DFD55BC3040A45BF70926E55F2587C1D6BB@SZXEMA512-MBX.china.huawei.com>
References: ,  <2901_1385634414_52971A6E_2901_2686_1_6B7134B31289DC4FAF731D844122B36E307743@PEXCVZYM13.corporate.adroot.infra.ftgroup>  <26C84DFD55BC3040A45BF70926E55F2587C1D016@SZXEMA512-MBX.china.huawei.com> <345A59EB-A13B-4E0A-A616-94D0A82A4D99@nostrum.com>
In-Reply-To: <345A59EB-A13B-4E0A-A616-94D0A82A4D99@nostrum.com>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.146.62.57]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "dime@ietf.org" 
Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same type) within a response message
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Dec 2013 02:46:42 -0000

Hi Ben,

Try to make it more clear.=20

So far, there are only two report types defined, i.e. host and realm. In th=
e future, if more overload reports are needed for the same report type, e.g=
. for the same host but for different APNs, it should be up to the Diameter=
 application where this is to be applied to define how to differentiate and=
 use the multiple OC-OLR instances. One possible way could be to extend the=
 report type with more types or values for such differentiation, as discuss=
ed previously, while there might be other ways e.g. with definition of new =
AVPs inside or outside OC-OLR AVP.

Best Regards,
Susan

-----Original Message-----
From: Ben Campbell [mailto:ben@nostrum.com]=20
Sent: Tuesday, December 10, 2013 3:26 AM
To: Shishufeng (Susan)
Cc: Nirav Salot (nsalot); lionel.morand@orange.com; dime@ietf.org
Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same type=
) within a response message

Susan, am I correct in reading that to mean that while it may only make sen=
se to have one host report or one realm report, this may not be true for al=
l future report types, and that it should be up to the definition of each r=
eport type to allow or disallow multiple instances? If so, I agree.

Any report type that allows multiple instances will need to describe how to=
 handle (or avoid) potential conflicts.

On Dec 9, 2013, at 4:12 AM, Shishufeng (Susan)  wrote:

> Hi Nirav,
> =20
> For now, I couldn't see the need to have more than one instance of the ov=
erload report with the same report-type, i.e. host or realm. But to allow e=
xtensibility if needed in the future, whether some texts can be written in =
the IETF e.g. Multiple OC-OLR AVPs exist with different report types, if it=
 is not the case, it is the application where multiple OC-OLR AVPs are allo=
wed with the same report type to specify the details how to differentiate t=
he information contained in these OC-OLR AVPs. Thus we can move on without =
having to addressing the issue now in the base solution.
> =20
> Best Regards,
> Susan
> =20
> From: Nirav Salot (nsalot) [mailto:nsalot@cisco.com]
> Sent: Thursday, November 28, 2013 8:00 PM
> To: lionel.morand@orange.com
> Cc: dime@ietf.org
> Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same=20
> type) within a response message
> =20
> Lionel,
>=20
> 3gpp may define an optional avp which can be included by the reporting no=
de if it wishes to do so. E.g. APN can be additionally included by the repo=
rting node to indicate APN specific overload within the given application.
> In that case, the reporting node may also want to indicate application le=
vel overload without including the APN (e.g. this overload report is applic=
able to all other APNs).
>=20
> And hence there is a possibility of including multiple instances of the o=
verload report.
>=20
> I am not suggesting that 3gpp will define APN (or any other avp) within o=
verload report. But later, if 3gpp need to define the same, then correspond=
ing handling needs to be defined within IETF now.
>=20
> Regards,
> Nirav.
>=20
> On Nov 28, 2013 3:56 PM, "lionel.morand@orange.com"  wrote:
> Hi Nirav,
> =20
> Not sure to understand the proposal or question.
> The OLR is significant per application (piggybacking principle). So if th=
e 3GPP decides to add specific AVPs in the OLR (that will be possible), wha=
t would be the need to add the OLR without the specific 3GPP AVPs as the OL=
R will be anyway handle by 3GPP aware entities?
> =20
> Lionel
> =20
> De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot=20
> (nsalot) Envoy=E9 : jeudi 28 novembre 2013 10:33 =C0 : dime@ietf.org Obje=
t=20
> : [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same type)=20
> within a response message
> =20
> Hi,
> =20
> As I understand IETF will define the base overload control solution as pa=
rt of DOIC. Then 3GPP would adopt the defined solution for each of its appl=
ication.
> When that happens, 3GPP might want to add 3GPP specific AVP within OC-OLR=
 AVP. Based on the current definition of the OC-OLR AVP this should be allo=
wed since it contains "* [AVP]" in its definition.
> e.g. for a given application 3GPP decides to add information into OC-OLR =
which changes the scope of the OC-OLR from application level to the provide=
d information level.
> Additionally, the reporting may want to advertise the OC-OLR at the appli=
cation level scope - i.e. the OC-OLR without any 3GPP specific info.
> =20
> So if the above is allowed, we will have the possibility of the reporting=
 node wanting to include two instances of OC-OLR with the Report-Type=3D"ho=
st".
> And then we need to define the handling of multiple instances of OC-OLR i=
n the DOIC draft.
> =20
> So the questions are,
> -          Is 3GPP (or any other SDO) allowed to extend the definition of=
 OC-OLR by adding information into it?
> -          If no, can we guarantee that application level scope of OC-OLR=
 (which is what we have defined currently) is sufficient (and not restricti=
ng) to all the applications of 3GPP?
> =20
> Regards,
> Nirav.
> =20
> ______________________________________________________________________
> ___________________________________________________
> =20
> Ce message et ses pieces jointes peuvent contenir des informations=20
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20
> exploites ou copies sans autorisation. Si vous avez recu ce message=20
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que =
les pieces jointes. Les messages electroniques etant susceptibles d'alterat=
ion, Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
> =20
> This message and its attachments may contain confidential or=20
> privileged information that may be protected by law; they should not be d=
istributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and de=
lete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have bee=
n modified, changed or falsified.
> Thank you.
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From susan.shishufeng@huawei.com  Mon Dec  9 19:02:05 2013
Return-Path: 
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 CD14A1AE11A for ; Mon,  9 Dec 2013 19:02:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level: 
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 fl5xBBw6uUxZ for ; Mon,  9 Dec 2013 19:02:03 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 531D31AE111 for ; Mon,  9 Dec 2013 19:02:02 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBE58923; Tue, 10 Dec 2013 03:01:54 +0000 (GMT)
Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 10 Dec 2013 03:01:47 +0000
Received: from SZXEMA403-HUB.china.huawei.com (10.82.72.35) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 10 Dec 2013 03:01:53 +0000
Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.155]) by SZXEMA403-HUB.china.huawei.com ([10.82.72.35]) with mapi id 14.03.0158.001; Tue, 10 Dec 2013 11:01:41 +0800
From: "Shishufeng (Susan)" 
To: "Wiehe, Ulrich (NSN - DE/Munich)" , "ext lionel.morand@orange.com" , ext Jouni Korhonen , Ben Campbell 
Thread-Topic: [Dime] DOIC: Self-Contained OLRs
Thread-Index: AQHO7CTaot3HeYq6iU+vru+Aq+dgEZpLuCfw//+RMQCAAYJlYA==
Date: Tue, 10 Dec 2013 03:01:40 +0000
Message-ID: <26C84DFD55BC3040A45BF70926E55F2587C1D705@SZXEMA512-MBX.china.huawei.com>
References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com>  <5BCBA1FC2B7F0B4C9D935572D90006681519BC90@DEMUMBX014.nsn-intra.net> <6390_1385631044_52970D44_6390_18593_1_6B7134B31289DC4FAF731D844122B36E30748E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BD19@DEMUMBX014.nsn-intra.net> <26C84DFD55BC3040A45BF70926E55F2587C1D028@SZXEMA512-MBX.china.huawei.com> <5BCBA1FC2B7F0B4C9D935572D90006681519DFC0@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681519DFC0@DEMUMBX014.nsn-intra.net>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.146.62.57]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "dime@ietf.org list" 
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Dec 2013 03:02:06 -0000

Hi Ulrich,

Thanks for your clarification. I understood the scenario, while from my poi=
nt of view, if the agent that selects the HSS is not configured to serve as=
 a load balancer for the HSS, the agent should not change any supported/neg=
otiated features between C and S, that would be the normal case. If the age=
nt serve as a load balancer for the HSS, the subsequent request from C towa=
rds the S would always go via the agent, in this case whatever the associat=
ions between C and A, between A and S are the same or not, it doesn't matte=
r. With an E2E solution as we agreed, I don't see the problem with it.

Best Regards,
Susan

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20
Sent: Monday, December 09, 2013 7:43 PM
To: Shishufeng (Susan); ext lionel.morand@orange.com; ext Jouni Korhonen; B=
en Campbell
Cc: dime@ietf.org list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Hi Susan,

let me come back to your S6a example.

The MME (C) sends a request without Destination-Host towards the HPLMN (rea=
lm). There must be an agent (A) in the HPLMN (realm) that selects the HSS (=
S).=20
We would have two distinct DOIC associations: one between C and A, another =
between A and S (see figure 5 in clause 5.1). The two DOIC associations may=
 have different supported/negotiated features. An OLR sent from S to A base=
d on supported/negotiated features valid for the DOIC association between A=
 and S is at least problematic (out-of context) when sent from A to C.

When the MME (C) sends a subsequent request with Destination-Host towards t=
he HSS (S), there is no agent that selects the HSS (as the HSS is already s=
elected). For this session there is only one DOIC association between C and=
 S (see figure 3 in clause 5.1) and OLRs sent from S to C are not problemat=
ic.

Best regards
Ulrich


-----Original Message-----
From: ext Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
Sent: Monday, December 09, 2013 11:30 AM
To: Wiehe, Ulrich (NSN - DE/Munich); ext lionel.morand@orange.com; ext Joun=
i Korhonen; Ben Campbell
Cc: dime@ietf.org list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Hi Ulrich,

I have different views. In any case, I think the host-type OLR should not b=
e ignored by the clients. On the contrary, the realm-type OLR can be though=
t as optimization, which may not even be needed at all for all cases, espec=
ially in 3GPP. Here is an example of S6a, in the case the first attach requ=
est comes from the UE to the MME, the MME can only derive the realm informa=
tion, and sends a request without Destination-Host towards the HPLMN. Since=
 the subscriber corresponding to the UE belongs to a specific HSS, and the =
HSS may provide its overload report to the MME, and the MME is able to know=
 how to react regarding the requests towards the HSS, which would be the no=
rmal case. Whether Realm report will be provided by the HSS or the agent se=
rving the HSS is kind of optimization which may help the MME to know how to=
 react on the requests towards the realm, not specific to the HSS.

Best Regards,
Susan

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
Sent: Thursday, November 28, 2013 6:30 PM
To: ext lionel.morand@orange.com; ext Jouni Korhonen; Ben Campbell
Cc: dime@ietf.org list
Subject: 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 act=
ual OLR created by the reporting end point and which OLR is an additional O=
LR created by another node.

We have two cases:
a) The request sent by the client (reacting end point) contains no Destinat=
ion Host. The agent (reporting node) (after forwarding the request to the s=
elected server and receiving the answer) returns a realm-type OLR as the ac=
tual 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 Destinat=
ion 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 stat=
us. It could be provided an agent inserting this info in answers received f=
rom a server behind but also from a server that would know this info by som=
e internal magic.
But in any case, if we assume that the client will received a successful an=
swer from the server for an initial request with only Dest-Realm AVP, it sh=
ould be possible to have both report types in the answer: one for the serve=
r itself, one for the realm for new request sent to the realm with only Des=
t-Realm AVP.

Lionel

-----Message d'origine-----
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN=
 - DE/Munich) Envoy=E9=A0: jeudi 28 novembre 2013 10:26 =C0=A0: ext Jouni K=
orhonen; Ben Campbell Cc=A0: dime@ietf.org list Objet=A0: Re: [Dime] DOIC: =
Self-Contained OLRs

Hi,

I don't see how the possibility to send more than one OLR in an answer is a=
ligned with the "endpoint principle". If the ReportType is "realm" this ind=
icates 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  wrote:

> Hi,
>=20
> I mentioned in another thread that I prefer putting an explicit=20
> ReportType AVP in an OLR, rather than

The more I spent time thinking/writing the actual procedures on the endpoin=
ts, the more it makes sense to me to keep the ReportType in the OC-OLR. Eve=
n if the baseline does not have agent overload etc, the ReportType fits wel=
l to the "endpoint principle" we have in the draft. It indeed gives more to=
ols to make a host vs. realm base decision on the reacting node and is plai=
n 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 Diam=
eter request that corresponds to the answer containing the OLR. My reasons =
for that go beyond just ReportType, so I'm starting a separate thread.
>=20
> As currently described, a consumer of an OLR must infer several things fr=
om other context. In most cases, that context is in the Diameter answer tha=
t carries the OLR. For example, the OLR implicitly refers to the applicatio=
n 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 meani=
ng in the context of the enclosing answer. If you moved an OLR from one ans=
wer to another, it's meaning may change completely.
>=20
> I think this approach is a mistake. I would greatly prefer that we explic=
itly include such values in the OLR itself, for multiple reasons:
>=20
> 1) It's more complex to interpret implicit, contextual values than explic=
it values. The consumer cannot simply look at the OLR; it must look in vari=
ous other AVPs to find all the information it needs. For example, I think a=
 common software design for overload control processing to be separated fro=
m application processing. The consumer cannot simply hand the OLR to that m=
odule 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 "con=
text" avps that must be interpreted can grow large. This approach is error =
prone, and will likely encourage brittle, hard-to-maintain code. Self-conta=
ined OLRs would keep all the information related to overload in one place. =
making for simpler implementations.
>=20
> 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 r=
eporting node realizes that it is overloade, it has to wait for the right a=
nswer that contains the right context before it can send the OLR. This is p=
articularly troublesome for agents, since they will typically have to inser=
t OLRs into answers created by other nodes.=20
>=20
> If the reporting node screws this up, the meaning of the OLR may change s=
ignificantly. So again, implicit meaning gives us error prone implementatio=
ns. Self-contained OLRs are simpler to create and send.
>=20
> 3) Implicit values don't work at all for certain problems. For=20
> example, if an agent needs to originate an OLR, it typically needs to=20
> insert that OLR into an existing Diameter answer created by a server.
> It can't create its own answer without affecting the application=20
> state. If the responding node assumes the OLR comes from or refers to=20
> the node identified by the Origin-Host AVP in the enclosing answer,=20
> things break. (For examples of when an agent needs to send OLRs that=20
> are distinct from those sent by a server, see Steve's agent overload=20
> draft, or my dh/dr example.)
>=20
> OTOH, explicit values will work for all cases where we need to associate =
some arbitrary value with an OLR.
>=20
> 4) Implicit values seriously constrain the future evolution of Diameter O=
C standards. For example, lets say we find a good reason to allow OLRs to b=
e sent out of band, or be sent in a dedicated Diameter application. If over=
load 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 transpo=
rted, this won't work. We would have to create a new or significantly modif=
ied OLR format if we found a need to transport OLRs in different ways. Self=
-contained OLRs would allow much greater flexibility.
>=20
> So, in summary, I think that self-contained OLRs would lead to simpler im=
plementations, less brittle deployments, and more flexibility for future ev=
olution of standards.
>=20
> Thanks!
>=20
> 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 confiden=
tielles 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. Le=
s messages electroniques etant susceptibles d'alteration, Orange decline to=
ute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation 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 dele=
te 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.



From ben@nostrum.com  Mon Dec  9 19:10:15 2013
Return-Path: 
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 B3E171AE128 for ; Mon,  9 Dec 2013 19:10:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Level: 
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no
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 1iX8-RnmPfUL for ; Mon,  9 Dec 2013 19:10:14 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 898511AE11B for ; Mon,  9 Dec 2013 19:10:14 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rBA3A0Zl042762 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 9 Dec 2013 21:10:02 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Ben Campbell 
In-Reply-To: <26C84DFD55BC3040A45BF70926E55F2587C1D6BB@SZXEMA512-MBX.china.huawei.com>
Date: Mon, 9 Dec 2013 21:09:59 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <641914EC-C7D2-4059-A0B2-E8AE672C3F82@nostrum.com>
References: , <2901_1385634414_52971A6E_2901_2686_1_6B7134B31289DC4FAF731D844122B36E307743@PEXCVZYM13.corporate.adroot.infra.ftgroup>  <26C84DFD55BC3040A45BF70926E55F2587C1D016@SZXEMA512-MBX.china.huawei.com> <345A59EB-A13B-4E0A-A616-94D0A82A4D99@nostrum.com> <26C84DFD55BC3040A45BF70926E55F2587C1D6BB@SZXEMA512-MBX.china.huawei.com>
To: "Shishufeng (Susan)" 
X-Mailer: Apple Mail (2.1822)
Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism)
Cc: "dime@ietf.org" 
Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same type) within a response message
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Dec 2013 03:10:15 -0000

On Dec 9, 2013, at 8:46 PM, Shishufeng (Susan) =
 wrote:

> Try to make it more clear.=20
>=20
> So far, there are only two report types defined, i.e. host and realm. =
In the future, if more overload reports are needed for the same report =
type, e.g. for the same host but for different APNs, it should be up to =
the Diameter application where this is to be applied to define how to =
differentiate and use the multiple OC-OLR instances. One possible way =
could be to extend the report type with more types or values for such =
differentiation, as discussed previously, while there might be other =
ways e.g. with definition of new AVPs inside or outside OC-OLR AVP.

Okay, then I partially agree. But I think the rules for whether (and =
how) you allow multiple instances of the same report type should be per =
report type, rather than per application. I have trouble thinking of a =
situation where the rules for a given report type would be different =
between one application and another. (But I would welcome an example to =
change my mind :-)  )

Thanks!

Ben.=

From susan.shishufeng@huawei.com  Mon Dec  9 19:21:44 2013
Return-Path: 
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 A2A001AE029 for ; Mon,  9 Dec 2013 19:21:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level: 
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 lW-GMltnx-wY for ; Mon,  9 Dec 2013 19:21:43 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 693AD1AE13D for ; Mon,  9 Dec 2013 19:21:42 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBF00334; Tue, 10 Dec 2013 03:21:36 +0000 (GMT)
Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 10 Dec 2013 03:21:28 +0000
Received: from SZXEMA408-HUB.china.huawei.com (10.82.72.40) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 10 Dec 2013 03:21:34 +0000
Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.155]) by SZXEMA408-HUB.china.huawei.com ([10.82.72.40]) with mapi id 14.03.0158.001; Tue, 10 Dec 2013 11:21:25 +0800
From: "Shishufeng (Susan)" 
To: Ben Campbell 
Thread-Topic: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same type) within a response message
Thread-Index: AQHO7DRyp0pKDS+VfEyygMMnybAXTZpLsyOAgAAXRwCAAP2CkP//hC2AgACHtaA=
Date: Tue, 10 Dec 2013 03:21:24 +0000
Message-ID: <26C84DFD55BC3040A45BF70926E55F2587C1D742@SZXEMA512-MBX.china.huawei.com>
References: ,  <2901_1385634414_52971A6E_2901_2686_1_6B7134B31289DC4FAF731D844122B36E307743@PEXCVZYM13.corporate.adroot.infra.ftgroup>  <26C84DFD55BC3040A45BF70926E55F2587C1D016@SZXEMA512-MBX.china.huawei.com> <345A59EB-A13B-4E0A-A616-94D0A82A4D99@nostrum.com> <26C84DFD55BC3040A45BF70926E55F2587C1D6BB@SZXEMA512-MBX.china.huawei.com> <641914EC-C7D2-4059-A0B2-E8AE672C3F82@nostrum.com>
In-Reply-To: <641914EC-C7D2-4059-A0B2-E8AE672C3F82@nostrum.com>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.146.62.57]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "dime@ietf.org" 
Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same type) within a response message
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Dec 2013 03:21:44 -0000

Hi Ben,

The APN example as Nirav raised may only be applicable to some 3GPP applica=
tions, e.g. S6a, Rx, Gx but not for others, e.g. Cx, Sh, Ro. Thus if some o=
f the applications need more granularity of the overload report for the sam=
e host or realm, it should be them to define the details. If we extend repo=
rt type for differentiation of such kinds of reports, it can be the applica=
tions to define the new report types, maybe with addition of new AVPs.

Best Regards,
Susan

-----Original Message-----
From: Ben Campbell [mailto:ben@nostrum.com]=20
Sent: Tuesday, December 10, 2013 11:10 AM
To: Shishufeng (Susan)
Cc: Nirav Salot (nsalot); lionel.morand@orange.com; dime@ietf.org
Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same type=
) within a response message


On Dec 9, 2013, at 8:46 PM, Shishufeng (Susan)  wrote:

> Try to make it more clear.=20
>=20
> So far, there are only two report types defined, i.e. host and realm. In =
the future, if more overload reports are needed for the same report type, e=
.g. for the same host but for different APNs, it should be up to the Diamet=
er application where this is to be applied to define how to differentiate a=
nd use the multiple OC-OLR instances. One possible way could be to extend t=
he report type with more types or values for such differentiation, as discu=
ssed previously, while there might be other ways e.g. with definition of ne=
w AVPs inside or outside OC-OLR AVP.

Okay, then I partially agree. But I think the rules for whether (and how) y=
ou allow multiple instances of the same report type should be per report ty=
pe, rather than per application. I have trouble thinking of a situation whe=
re the rules for a given report type would be different between one applica=
tion and another. (But I would welcome an example to change my mind :-)  )

Thanks!

Ben.

From susan.shishufeng@huawei.com  Mon Dec  9 19:58:33 2013
Return-Path: 
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 638F91AE168 for ; Mon,  9 Dec 2013 19:58:33 -0800 (PST)
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 jugsxwasRrXA for ; Mon,  9 Dec 2013 19:58:31 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5866E1AC82B for ; Mon,  9 Dec 2013 19:58:30 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBF02666; Tue, 10 Dec 2013 03:58:24 +0000 (GMT)
Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 10 Dec 2013 03:58:18 +0000
Received: from SZXEMA408-HUB.china.huawei.com (10.82.72.40) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 10 Dec 2013 03:58:23 +0000
Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.155]) by SZXEMA408-HUB.china.huawei.com ([10.82.72.40]) with mapi id 14.03.0158.001; Tue, 10 Dec 2013 11:58:17 +0800
From: "Shishufeng (Susan)" 
To: Ben Campbell , "dime@ietf.org list" 
Thread-Topic: [Dime] DOIC: Self-Contained OLRs
Thread-Index: AQHO9VIQot3HeYq6iU+vru+Aq+dgEZpMw4Uw
Date: Tue, 10 Dec 2013 03:58:17 +0000
Message-ID: <26C84DFD55BC3040A45BF70926E55F2587C1D786@SZXEMA512-MBX.china.huawei.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>  <14594_1386204165_529FCC05_14594_12646_1_6B7134B31289DC4FAF731D844122B36E329907@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B920972CCAA@ESESSMB101.ericsson.se>  <52A077CC.3000004@usdonovans.com>  <52A088D0.2020406@usdonovans.com>  <52A091CE.2000104@usdonovans.com> <13081_1386256433_52A09831_13081_8197_1_6B7134B31289DC4FAF! 731D84412 2B36E32B6EB@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B9209739738@ESESSMB101.ericsson.se>  <8FD63E2D-5203-4DA4-A6DA-C4CA181C9CFB@nostrum.com>
In-Reply-To: <8FD63E2D-5203-4DA4-A6DA-C4CA181C9CFB@nostrum.com>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.146.62.57]
Content-Type: multipart/alternative; boundary="_000_26C84DFD55BC3040A45BF70926E55F2587C1D786SZXEMA512MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Dec 2013 03:58:33 -0000

--_000_26C84DFD55BC3040A45BF70926E55F2587C1D786SZXEMA512MBXchi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Ben,

Each solution has its pros and cons. The key point here is to select a righ=
t 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 opti=
mization 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 overloa=
d.

-          The last three pros are mainly for the case of overload of agent=
, if I understood them correctly. Overload of agent is still a controversia=
l scenario, we may need more discussion in the future. But anyway, with def=
inition 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-co=
ntained OLR.

Best Regards,
Susan

From: Ben Campbell [mailto:ben@nostrum.com]
Sent: Tuesday, December 10, 2013 7:53 AM
To: 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 wh=
at we do for a later (or final) version.

So far, I've seen 4 people opposed to self-contained OLRs (Lionel, Nirav, M=
aria, 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 lo=
ok 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 firs=
t group explain what they think the pros of implicit OLRs might be beyond t=
hose 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 application=
s at once, instead of having to signal each one separately.
  *   Allows an easy solution to our "loss" algorithm corner case of not be=
ing able to signal the end of a 100% overload condition
  *   Makes it easier to solve the agent overload problem, without requirin=
g 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 transac=
tion 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 trans=
action context and the report type. [I don't understand why this is valuabl=
e, 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 supporte=
d 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 > wrote:



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

- Jouni


--_000_26C84DFD55BC3040A45BF70926E55F2587C1D786SZXEMA512MBXchi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi Ben,


 =
;


Each solut=
ion has its pros and cons. The key point here is to select a right one whic=
h could satisfy the requirements but with less resource consuming.



 =
;


Quick thin=
king on the pros you listed for self-contained OLR.


 =
;



-Th=
e 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.



-Th=
e 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 ov=
erload.



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


 =
;


Best Regar=
ds,


Susan=



 =
;






From: Ben Campbell [mailto:ben@nostrum.com]


Sent: Tuesday, December 10, 2013 7:53 AM

To: dime@ietf.org list

Subject: Re: [Dime] DOIC: Self-Contained OLRs






 




I am willing to call the discus=
sion concluded for the purposes of what goes in version 01 of the DOIC &nbs=
p;draft. But I'd like to poke a little more on what we do for a later (or f=
inal) version.






 






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






 






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






 






S=
elf-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 multi=
ple applications at once, instead of having to signal each one separately.<=
o:p>
  • 
Allows an easy solution to our "loss" algori=
thm corner case of not being able to signal the end of a 100% overload cond=
ition
  • 
Makes it easier to solve the agent overload problem, w=
ithout requiring inconsistent behavior.
  • 
Allows out-of-band transmission of OLRs without a new =
format
  • 
Makes it easier to do things like adding a dedicated a=
pplication for overload, without a new format. (Yes, I think there's still =
a use case for that, and I will detail it shortly.)
    • <=
/ul>





Cons: 





 






    

  • 
The recipient cannot assume an OLR matches the context=
 of the transaction in which it is received.  
    • <=
li class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto;mso-list:l3 level1 lfo2">
It's different than what's in the draft.




 








I=
mplicit OLRs:






 






Pros:






    

  • 
The recipient can infer the OLR scope from a combinati=
on 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 "al=
l-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% overloa=
d condition
  • 
cannot be used out-of-band.
  • 
cannot be used with dedicated applications.=





 








 






 




On Dec 9, 2013, at 5:09 AM, Jou=
ni Korhonen <jouni.nospam@gmai=
l.com> wrote:








=


OK. Lets call this thread concluded then. I keep the old OC-OLR  seman=
tics

regarding its information context then unmodified.



- Jouni


 






--_000_26C84DFD55BC3040A45BF70926E55F2587C1D786SZXEMA512MBXchi_--

From nsalot@cisco.com  Mon Dec  9 21:15:37 2013
Return-Path: 
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 6FDD31AE1C5 for ; Mon,  9 Dec 2013 21:15:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.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 V8OX9bwwbusc for ; Mon,  9 Dec 2013 21:15:35 -0800 (PST)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id A810B1AE1C4 for ; Mon,  9 Dec 2013 21:15:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2093; q=dns/txt; s=iport; t=1386652531; x=1387862131; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=C0/NjdnWZ6Pxx9a07V4SvwuVXPDtUfLL+Na1/2JXTOA=; b=CmjpoHNH+TYdCmKWtAq+sjC3tzn8ZAg6uf1vzJTpZG56/u7MlYizgmsL 1wQvkQ8OkR9rSUgSaWIlCNKa+CZ4VvPe5H2Su5It7cWK3pPfOwUOLr3tk 3Df5vtYjl+L/oDl6wHXM6FM7Biv0vNPvxOrjEkFrD6jhYpCqvvzQb4Pg/ o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhQFAJOiplKtJV2c/2dsb2JhbABZgwc4U7kWgSMWdIIlAQEBBAEBATc0FwQCAQgRBAEBCxQJBycLFAkIAgQBEgiHeg3AUBMEjlQ4BoMagRMDqieDKYIq
X-IronPort-AV: E=Sophos;i="4.93,863,1378857600"; d="scan'208";a="290447174"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 10 Dec 2013 05:15:30 +0000
Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id rBA5FUIX006951 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Dec 2013 05:15:30 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.250]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Mon, 9 Dec 2013 23:15:30 -0600
From: "Nirav Salot (nsalot)" 
To: Jouni Korhonen , "dime@ietf.org list" 
Thread-Topic: [Dime] Conclusion for the Report Type
Thread-Index: AQHO9NZBgN7qEWGWcUC1LbudqyUITZpM42pg
Date: Tue, 10 Dec 2013 05:15:29 +0000
Message-ID: 
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DCBC@DEMUMBX014.nsn-intra.net> <453156F8-9090-46D4-BF8E-A877F40EE3AC@gmail.com>
In-Reply-To: <453156F8-9090-46D4-BF8E-A877F40EE3AC@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.142.140.43]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [Dime] Conclusion for the Report Type
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Dec 2013 05:15:37 -0000

Jouni,

I am fine with the principles you have mentioned below for Report Type.
I also prefer to use enumerated type for this AVP if that does not risk the=
 extendibility of this AVP.

Regards,
Nirav.

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen
Sent: Monday, December 09, 2013 5:30 PM
To: dime@ietf.org list
Subject: [Dime] Conclusion for the Report Type

Folks,

We need a conclusion here so that I can actually write something into the -=
01. How about the following (I try to reflect as many points given here as =
possible):

1) The basic principle for the Report Type use is that only one
   OLR per report type is allowed unless the report type and the
   OLR reflecting the new report type define exact semantics how
   to differentiate between multiple OLRs with the same report
   type. In 3GPP context, for example, a report type with an AVP
   that identifies an APN could be such a differentiator.. and that
   would need a new report type where an implementation exactly
   knows to look for this additional AVP without guesswork or=20
   fuzzy heuristics.

2) A new report type or a set of new report types require a new
   feature to be allocated/defined so that both endpoints know how
   to handle the new report type that was defined after the
   publication of the baseline specification. The handling of the
   new report types must be defined (along with the new AVPs it
   might need to be included into the OC-OLR AVP).

3) With 2) in place I do not care whether the OC-Report-Type is
   enumerated or unsigned (flag vector?). I still favour Enumerated
   myself as it forces the protocol designer to come up with a=20
   cleaner design ;)

4) For the baseline we only define host and realm report types.
   We do not allow multiple OLRs with these report types i.e.
   single instances of OLRs with host and/or realm are allowed.

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

From jouni.nospam@gmail.com  Mon Dec  9 23:28:23 2013
Return-Path: 
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 04C401ADEA1 for ; Mon,  9 Dec 2013 23:28:23 -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 0PttJqpjeBgN for ; Mon,  9 Dec 2013 23:28:20 -0800 (PST)
Received: from mail-bk0-x229.google.com (mail-bk0-x229.google.com [IPv6:2a00:1450:4008:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 7E5251ADDAF for ; Mon,  9 Dec 2013 23:28:20 -0800 (PST)
Received: by mail-bk0-f41.google.com with SMTP id v15so1795450bkz.14 for ; Mon, 09 Dec 2013 23:28:14 -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 :content-transfer-encoding:message-id:references:to; bh=NFtZsOlX3CVGla/7kU10xhHRPBXbmBuVStf0Fu8BjzQ=; b=SOLWkPIPPfxhgONC45V4ozro45A8vDnqueBbdEjyiE5mEsdYgH6Mqu+nnsGQHMM367 kc4ibP9xqvPUAL9S1Sn2Nmk0NR1UBOOWTTL749nohbcKR7ifKs8Psjzn3noVQQWJJw5/ 2VP2JEeQrynCrja5n+PC3/PXperUg1KKsf9YFeE+YqFRhAaCoUweEyZNy3WzDIWJlGLB Yb9FJ53ckLzyJt+RnntMyXmRjHszMBcRn6VJIQkwMULHeSXr4+mpUJad/giTMQi4kD3l JZXDodJ5E1Q1aHTRTjdq4PaDS7cyyOF7/qvNLzSNUbA1zP6Mcz1W+wmICA0xrROZjzBD EXsA==
X-Received: by 10.204.231.207 with SMTP id jr15mr87516bkb.92.1386660494875; Mon, 09 Dec 2013 23:28:14 -0800 (PST)
Received: from ?IPv6:2001:6e8:480:60:20b9:7452:797c:e240? ([2001:6e8:480:60:20b9:7452:797c:e240]) by mx.google.com with ESMTPSA id sx5sm10722201bkb.0.2013.12.09.23.28.10 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Dec 2013 23:28:10 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jouni Korhonen 
In-Reply-To: <7475B713-1104-4791-96B1-CE97632A0D69@nostrum.com>
Date: Tue, 10 Dec 2013 09:28:09 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DB1B@DEMUMBX014.nsn-intra.net>  <52A5E902.20605@usdonovans.com> <7475B713-1104-4791-96B1-CE97632A0D69@nostrum.com>
To: Ben Campbell , "dime@ietf.org list" , Steve Donovan 
X-Mailer: Apple Mail (2.1510)
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Dec 2013 07:28:23 -0000

Fine.. lets define then the sequence number semantics. Basic
unsigned integer math. The text proposal is the following:

4.4.  OC-Sequence-Number AVP

   The OC-Sequence-Number AVP (AVP code TBD3) is type of Unsigned64.
   Its usage in the context of the overload control is described in
   Sections 4.1 and 4.3.

   =46rom the functionality point of view, the OC-Sequence-Number AVP
   MUST be used as a non-volatile increasing counter between two
   overload control endpoints.  The sequence number is only required
   to be unique between two overload control endpoints and does not
   need to be monotonically increasing.

   When comparing two sequence numbers, the new sequence number MUST
   be greater or equal than the old sequence number within a window
   that is half of the size of the maximum sequence number. This
   allows a simple handling of the sequence number overflow using
   unsigned integer arithmeticf:

     #define WINDOW 0x8000000000000000ULL
=20
     bool verify_seqnum( uint64_t newsn, uint64_t oldsn ) {
         if (newsn - oldsn <=3D WINDOW)
             // newsn >=3D oldsn
             return true;  =20
         } else
             // outside window or newsn < oldsn
             return false; =20
         }
     }



The above should even work is someone shovels NTP times into
sequence numbers with a blind typecasting.

- Jouni

On Dec 10, 2013, at 12:34 AM, Ben Campbell  wrote:

>=20
> On Dec 9, 2013, at 10:00 AM, Steve Donovan  =
wrote:
>=20
>> Jouni,
>>=20
>> I propose that we keep the name OC-Sequence-Number but that we use =
the Time type for OC-Sequence-Number.  It is misleading and potentially =
confusing to call it OC-Time-Stamp. =20
>>=20
>=20
> I could live with that, although I would rather just define the =
expected properties of the sequence number, and leave the implementation =
up to the implementor. I assume your reasoning for not calling it a =
timestamp is that you do not want people to try to use it as a time base =
reference. If so, then we don't require any connection to a clock. We =
just need it to be monotonically increasing.
>=20
>> We might consider expanding on the format of the AVP to make it =
something like Session-ID, where it is a concatenation of the =
Diameter-ID of the generating node and a timestamp.  This might help the =
reacting node keep track of which sequence number it has received.
>>=20
>=20
> Do we need a uniqueness across multiple nodes property? If so, why?
>=20
>> Steve
>>=20
>> On 12/9/13 5:37 AM, Jouni Korhonen wrote:
>>> Folks
>>>=20
>>> Could we conclude on the sequence number vs. time stamp vs. =
something else?
>>> We got more important places to spend our energy than this ;)
>>>=20
>>> My proposal is the following (based on the original pre-00 design):
>>>=20
>>> o We change the OC-Sequence-Number to OC-Time-Stamp in all =
occurrences
>>>  in the -01.
>>> o We use RFC6733 Time type for the OC-Time-Stamp. RFC6733 gives us
>>>  already exact definition how to handle the AVP.
>>> o Define that the OC-Time-Stamp is the time of the creation of the=20=

>>>  "original" AVP within whose context the time stamp is present.
>>> o The OC-Time-Stamp AVP uniqueness is still considered to be in =
scope
>>>  of the communicating endpoints.
>>> o The time stamp can be used to quickly determine if the content of
>>>  the encapsulating AVP context has changed (among other properties).
>>>  This would be useful specifically in the future when the =
encapsulating
>>>  grouped AVPs  grow in size and functionality.
>>>=20
>>>=20
>>> - Jouni
>>>=20
>>> _______________________________________________
>>> DiME mailing list
>>>=20
>>> DiME@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dime
>>>=20
>>>=20
>>>=20
>>=20
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From jouni.nospam@gmail.com  Mon Dec  9 23:29:10 2013
Return-Path: 
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 D75621ADEA1 for ; Mon,  9 Dec 2013 23:29:10 -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 l5qne_HuwAyB for ; Mon,  9 Dec 2013 23:29:09 -0800 (PST)
Received: from mail-bk0-x22f.google.com (mail-bk0-x22f.google.com [IPv6:2a00:1450:4008:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 030821ADDAF for ; Mon,  9 Dec 2013 23:29:08 -0800 (PST)
Received: by mail-bk0-f47.google.com with SMTP id mx12so1769624bkb.6 for ; Mon, 09 Dec 2013 23:29:03 -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=ZPxPylcjxqKD2P101/pdaSBP/S7PUdk3P8myLNoXN1A=; b=Ap+3tdgyPfIh8RT8lKfxeYkk2MIQaTtFBTGTgyRO/izsJUoQeR+sdU4RHwVsI7cK3v fP9mdR5Ml4RzuRF9JbTFm+A5rOwVMcdzpJZeMIfK79iMUI2t7DDwKqggTvwqFhbrvxR9 N3YyR+tQa415kJ5JoUtV97VoW9Cczp8UVKLoEXKv/Iu/uiAjZL5N6qcrgr7G/Xx1qTg5 FykUi4QJH79OLkAKeYcW1vSFgIqYwQVm4xi7C042fVOcCxEkUspMCwZZcmyLLDqsU+OT hzrI4NgGrXeu2HNZceIQOuplwgYZxKge+HCShUmE6XyXUUzYRXXPdn1I4yv6oHsY46Hu KwiA==
X-Received: by 10.205.42.74 with SMTP id tx10mr84762bkb.113.1386660543359; Mon, 09 Dec 2013 23:29:03 -0800 (PST)
Received: from ?IPv6:2001:6e8:480:60:20b9:7452:797c:e240? ([2001:6e8:480:60:20b9:7452:797c:e240]) by mx.google.com with ESMTPSA id sx5sm10722201bkb.0.2013.12.09.23.28.59 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Dec 2013 23:28:59 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jouni Korhonen 
In-Reply-To: 
Date: Tue, 10 Dec 2013 09:28:59 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DCBC@DEMUMBX014.nsn-intra.net> <453156F8-9090-46D4-BF8E-A877F40EE3AC@gmail.com> 
To: Ben Campbell 
X-Mailer: Apple Mail (2.1510)
Cc: "dime@ietf.org list" 
Subject: Re: [Dime] Conclusion for the Report Type
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Dec 2013 07:29:11 -0000

Good point.

- JOuni

On Dec 10, 2013, at 12:18 AM, Ben Campbell  wrote:

> It's probably also worth adding some guidance on when it makes sense =
to define a new report type. For example, if I want to add a new AVP =
that can be safely ignored by a recipient that doesn't understand it, I =
probably don't need a new report type.
>=20
> On Dec 9, 2013, at 6:00 AM, Jouni Korhonen  =
wrote:
>=20
>> Folks,
>>=20
>> We need a conclusion here so that I can actually write something
>> into the -01. How about the following (I try to reflect as many
>> points given here as possible):
>>=20
>> 1) The basic principle for the Report Type use is that only one
>>  OLR per report type is allowed unless the report type and the
>>  OLR reflecting the new report type define exact semantics how
>>  to differentiate between multiple OLRs with the same report
>>  type. In 3GPP context, for example, a report type with an AVP
>>  that identifies an APN could be such a differentiator.. and that
>>  would need a new report type where an implementation exactly
>>  knows to look for this additional AVP without guesswork or=20
>>  fuzzy heuristics.
>>=20
>> 2) A new report type or a set of new report types require a new
>>  feature to be allocated/defined so that both endpoints know how
>>  to handle the new report type that was defined after the
>>  publication of the baseline specification. The handling of the
>>  new report types must be defined (along with the new AVPs it
>>  might need to be included into the OC-OLR AVP).
>>=20
>> 3) With 2) in place I do not care whether the OC-Report-Type is
>>  enumerated or unsigned (flag vector?). I still favour Enumerated
>>  myself as it forces the protocol designer to come up with a=20
>>  cleaner design ;)
>>=20
>> 4) For the baseline we only define host and realm report types.
>>  We do not allow multiple OLRs with these report types i.e.
>>  single instances of OLRs with host and/or realm are allowed.
>>=20
>> - Jouni
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>=20


From jouni.nospam@gmail.com  Mon Dec  9 23:57:25 2013
Return-Path: 
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 A4BBB1AE13E for ; Mon,  9 Dec 2013 23:57:25 -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 iJeOog3Wn57Z for ; Mon,  9 Dec 2013 23:57:23 -0800 (PST)
Received: from mail-bk0-x236.google.com (mail-bk0-x236.google.com [IPv6:2a00:1450:4008:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 34E941ADEB4 for ; Mon,  9 Dec 2013 23:57:23 -0800 (PST)
Received: by mail-bk0-f54.google.com with SMTP id v16so1784180bkz.41 for ; Mon, 09 Dec 2013 23:57:17 -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=RKatohB895NgdKr8AP47wEtxgZrCjYvllBBEuqK3zf4=; b=cEI2WtNDwZLbpjVXghsGqBpkEtvi/HzOWufKLmnWj6IPlg8OBkjEbGnf1ZfTJma6oo sgjqDNOmufx7goz3fjuoghhH0jum7ZSNT9yk3ajQL/I1awkYzcrAGubhzEAwlbupq9M3 ZWwom1SjAL8Lprz6yMAX0iojh6Go72O9NSbaHFVnhpg+5bd1JO3Nw6vfhBT+EYoVXeqN V4TrXNPvNVkJHNcntHe83sMJM9p4TyDo7ZkRLVop+EDTfRvXfBzhJwYl4ybrerqixaAo /qoC90+coVsVsPIjXSa8qvaV1Lqc5ThcMCL4PVeMzVwVKXS3gGpOBa5Pp+0Xap6/ifXZ fSeg==
X-Received: by 10.205.9.131 with SMTP id ow3mr39849bkb.152.1386662237625; Mon, 09 Dec 2013 23:57:17 -0800 (PST)
Received: from ?IPv6:2001:6e8:480:60:20b9:7452:797c:e240? ([2001:6e8:480:60:20b9:7452:797c:e240]) by mx.google.com with ESMTPSA id j6sm10749740bki.17.2013.12.09.23.57.13 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Dec 2013 23:57:13 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jouni Korhonen 
In-Reply-To: 
Date: Tue, 10 Dec 2013 09:57:13 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <2B4A6453-CBF0-48BE-B917-96B279229D3C@gmail.com>
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DCBC@DEMUMBX014.nsn-intra.net> <453156F8-9090-46D4-BF8E-A877F40EE3AC@gmail.com> 
To: Nirav Salot (nsalot) 
X-Mailer: Apple Mail (2.1510)
Cc: "dime@ietf.org list" 
Subject: Re: [Dime] Conclusion for the Report Type
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Dec 2013 07:57:25 -0000

On Dec 10, 2013, at 7:15 AM, Nirav Salot (nsalot)  =
wrote:

> Jouni,
>=20
> I am fine with the principles you have mentioned below for Report =
Type.
> I also prefer to use enumerated type for this AVP if that does not =
risk the extendibility of this AVP.
>=20


Ok. Good.

- Jouni


> Regards,
> Nirav.
>=20
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen
> Sent: Monday, December 09, 2013 5:30 PM
> To: dime@ietf.org list
> Subject: [Dime] Conclusion for the Report Type
>=20
> Folks,
>=20
> We need a conclusion here so that I can actually write something into =
the -01. How about the following (I try to reflect as many points given =
here as possible):
>=20
> 1) The basic principle for the Report Type use is that only one
>   OLR per report type is allowed unless the report type and the
>   OLR reflecting the new report type define exact semantics how
>   to differentiate between multiple OLRs with the same report
>   type. In 3GPP context, for example, a report type with an AVP
>   that identifies an APN could be such a differentiator.. and that
>   would need a new report type where an implementation exactly
>   knows to look for this additional AVP without guesswork or=20
>   fuzzy heuristics.
>=20
> 2) A new report type or a set of new report types require a new
>   feature to be allocated/defined so that both endpoints know how
>   to handle the new report type that was defined after the
>   publication of the baseline specification. The handling of the
>   new report types must be defined (along with the new AVPs it
>   might need to be included into the OC-OLR AVP).
>=20
> 3) With 2) in place I do not care whether the OC-Report-Type is
>   enumerated or unsigned (flag vector?). I still favour Enumerated
>   myself as it forces the protocol designer to come up with a=20
>   cleaner design ;)
>=20
> 4) For the baseline we only define host and realm report types.
>   We do not allow multiple OLRs with these report types i.e.
>   single instances of OLRs with host and/or realm are allowed.
>=20
> - Jouni
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From jouni.nospam@gmail.com  Tue Dec 10 00:41:07 2013
Return-Path: 
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 B8BFB1AE0C4 for ; Tue, 10 Dec 2013 00:41:07 -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 5YSu0lgrr5XL for ; Tue, 10 Dec 2013 00:41:04 -0800 (PST)
Received: from mail-bk0-x232.google.com (mail-bk0-x232.google.com [IPv6:2a00:1450:4008:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 682381AE44E for ; Tue, 10 Dec 2013 00:41:04 -0800 (PST)
Received: by mail-bk0-f50.google.com with SMTP id e11so1810533bkh.9 for ; Tue, 10 Dec 2013 00:40:58 -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=IS5URP5OZR4s7ymdnMgaV9nYA5tfQkyQ4KID1vKQvvE=; b=kKvFyd/sZwTFuXNbHOdJCO74eTy+nvppqh4fOD0g5jyITYT5NPjw4NKx2MOduP/dg4 9rJgbDG6S8RmNF1isZGOU+HwllokvEwrtaHybJF48W1LhfpqvNtmlBQLF1jVwrbwFANA Dtbk/3mItOPEYxEEaCxPXUmqFVk1c8m0FvYgrkB0nRe5EtHw3h0PDZuXErkl07QQ/gXg kiV/AvrY6Dy808+iSztQh9cB63XDvoa/i71y47Z9SsM2Y+aayhOV5pb97Qt5rkheOXpa zteW3MVhB1f5qwDLGh+txOdTWvN9INIYohuor9WimJIuOP+UZe+iwIFB9dcn2ddQvczA 1LIg==
X-Received: by 10.204.99.200 with SMTP id v8mr68251bkn.157.1386664858288; Tue, 10 Dec 2013 00:40:58 -0800 (PST)
Received: from ?IPv6:2001:6e8:480:60:44d6:cc4b:4513:f475? ([2001:6e8:480:60:44d6:cc4b:4513:f475]) by mx.google.com with ESMTPSA id e3sm10851307bkk.13.2013.12.10.00.40.57 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Dec 2013 00:40:57 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jouni Korhonen 
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681519E0D9@DEMUMBX014.nsn-intra.net>
Date: Tue, 10 Dec 2013 10:40:56 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DA3E@DEMUMBX014.nsn-intra.net> <6CDCFC84-3048-40B9-91A4-1451FCC65F60@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519DCE5@DEMUMBX014.nsn-intra.net> <09616DA2-D1ED-40EE-8E89-755DFCD81092@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E02B@DEMUMBX014.nsn-intra.net> <1A402C59-E390-4C95-8E30-97F1F9D3EF0F@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E05C@DEMUMBX014.nsn-intra.net> <790F1603-64D5-40E2-BC59-FD4C104EEF1B@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E0D9@DEMUMBX014.nsn-intra.net>
To: "Wiehe, Ulrich (NSN - DE/Munich)" 
X-Mailer: Apple Mail (2.1510)
Cc: "dime@ietf.org" 
Subject: Re: [Dime] OVLI: comments to 4.1
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Dec 2013 08:41:07 -0000

On Dec 9, 2013, at 4:43 PM, "Wiehe, Ulrich (NSN - DE/Munich)" =
 wrote:

> But maintaining a specific state per reacting node is very resource =
consuming for the (overloaded) reporting node. It is simpler and more =
efficient to base any processing logic on actual information received in =
the request rather than on information stored from previous =
communication.

The "state" in a reporting node is merely the current configuration
and a counter for sequence number. Hard to me see that as resource
consuming function.

And the earlier comment of mine is done from reacting node point
of view, since it is more interested in the possible config changes
in the reporting node (e.g. S6a is stateless application, configuration
can change at any time).

- Jouni


>=20
> Ulrich
>=20
> -----Original Message-----
> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
> Sent: Monday, December 09, 2013 2:25 PM
> To: Wiehe, Ulrich (NSN - DE/Munich)
> Cc: dime@ietf.org
> Subject: Re: [Dime] OVLI: comments to 4.1
>=20
>=20
> On Dec 9, 2013, at 3:13 PM, "Wiehe, Ulrich (NSN - DE/Munich)" =
 wrote:
>=20
>> There is a fundamental difference:
>> OLRs need to be stored, Feature-Vectors not.
>=20
> How come feature vector does not need to be stored? I do not
> get that? I would set my implementation to a specific state
> or mode based on the feature vector. When that changes I'd
> like to know that. And then keep functioning based on that.
>=20
> - Jouni
>=20
>> When receiving an OLR you may want to know whether its worth the =
effort to replace an already stored OLR with the received OLR.
>> When receiving a Feature-Vector you just act on it.
>>=20
>> Ulrich=20
>>=20
>> -----Original Message-----
>> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
>> Sent: Monday, December 09, 2013 1:55 PM
>> To: Wiehe, Ulrich (NSN - DE/Munich)
>> Cc: dime@ietf.org
>> Subject: Re: [Dime] OVLI: comments to 4.1
>>=20
>>=20
>> In the same vein as folks wanted send OLRs with the new or old =
information,
>> the feature vector should behave in a same way IMHO. That implies =
there are
>> situations when a reception of the feature vector does not change =
anything
>> in an endpoint current behavior.
>>=20
>> - Jouni
>>=20
>> On Dec 9, 2013, at 2:47 PM, "Wiehe, Ulrich (NSN - DE/Munich)" =
 wrote:
>>=20
>>> Isn't it so that the Feature-Vector (if present) always contains =
something that an implementation needs to act upon?
>>>=20
>>> Ulrich
>>>=20
>>> -----Original Message-----
>>> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
>>> Sent: Monday, December 09, 2013 1:12 PM
>>> To: Wiehe, Ulrich (NSN - DE/Munich)
>>> Cc: dime@ietf.org
>>> Subject: Re: [Dime] OVLI: comments to 4.1
>>>=20
>>> Ulrich,
>>>=20
>>> On Dec 6, 2013, at 3:03 PM, "Wiehe, Ulrich (NSN - DE/Munich)" =
 wrote:
>>>=20
>>>> Hi Jouni,
>>>>=20
>>>> thank you for your response.
>>>>=20
>>>> With regard to 3)=20
>>>> I still fail to see the usecase for Sequence-Number or TimeStamp =
within OC-Feature-Vector. Please clarify.
>>>=20
>>> Since we also allow extending the OC-Feature-Vector beyond =
recognition,=20
>>> it has good chances become a rather complex grouped AVP. In that =
context
>>> the Sequence-Number allows an easy and quick way to check if the =
feature
>>> vector contains something that an implementation needs to act upon.
>>>=20
>>>> With regard to 4)
>>>> This was not obvious to me. (The obvious typo is the missing "of" =
between "one" and "the").
>>>=20
>>> Ack. Fixed the missing 'of'.
>>>=20
>>> - Jouni
>>>=20
>>>>=20
>>>> Best regards
>>>> Ulrich
>>>>=20
>>>>=20
>>>> -----Original Message-----
>>>> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
>>>> Sent: Friday, December 06, 2013 11:17 AM
>>>> To: Wiehe, Ulrich (NSN - DE/Munich)
>>>> Cc: dime@ietf.org
>>>> Subject: Re: [Dime] OVLI: comments to 4.1
>>>>=20
>>>>=20
>>>> On Dec 5, 2013, at 3:23 PM, "Wiehe, Ulrich (NSN - DE/Munich)" =
 wrote:
>>>>=20
>>>>> Dear all,
>>>>>=20
>>>>> here are comments to clause 4.1:
>>>>>=20
>>>>> 1. The OC-Feature-Vector AVP is no longer a vector; the name of =
the AVP may be misleading. Proposal is to rename it to =
"OC-Supported-Features AVP"
>>>>=20
>>>> OK with me.
>>>>=20
>>>>> 2. The OC-Feature AVP is a vector of features. Proposal is to =
rename it to "OC-Feature-Vector AVP"
>>>>=20
>>>> OK with me.
>>>>=20
>>>>> 3. The OC-Sequence-Number within OC-Feature-Vector only makes =
sense if the receiving reporting endpoint can determine the identity of =
the reacting endpoint (which is not necessarily the origin host =
(client),
>>>>=20
>>>> My original proposal was to have seqnr as a timestamp. Some folks =
argued
>>>> it is no good and suggested seqnr. I still think time makes more =
sense than
>>>> seqnr.
>>>>=20
>>>>> it may be an agent and it may not always be the same agent), and =
if the reporting endpoint is required to store the OC-Feature-Vector / =
reacting-endpoint-identity pair (which I think both is not required). =
The reporting endpoint can base its processing logic on the actually =
received OC-Feature-Vector value, no matter whether it is brand-new or =
old but stil valid. Proposal is to delete OC-Sequence-Number AVP from =
OC-Feature-Vector.
>>>>=20
>>>> Do not agree removing it.
>>>>=20
>>>>> 4. The text
>>>>>=20
>>>>> The reporting node that sends the answer also includes the OC-
>>>>> Feature-Vector AVP that describe the capabilities it supports.  =
The
>>>>> set of capabilities advertised by the reporting node depends on =
local
>>>>> policies.  At least one the announced capabilities MUST match
>>>>> mutually.  If there is no single matching capability the reacting
>>>>> node MUST act as if it does not implement DOIC and cease inserting
>>>>> any DOIC related AVPs into any Diameter messages with this =
specific
>>>>> reacting node.
>>>>>=20
>>>>> is not clear.  Would the reporting node include the =
OC-Feature-Vector AVP in the answer only if there is at least one =
matching capability?=20
>>>>=20
>>>> Because then they have found a way to exchange something that both =
ends
>>>> know how to handle it.
>>>>=20
>>>>> Mandating the reacting node to cease for all time inserting =
OC-Feature-Vector AVPs if it did not get back=20
>>>>=20
>>>> There is an obvious typo. It should say:
>>>>=20
>>>> policies.  At least one the announced capabilities MUST match
>>>> mutually.  If there is no single matching capability the reporting
>>>> node MUST act as if it does not implement DOIC and cease inserting
>>>> any DOIC related AVPs into any Diameter messages with this specific
>>>> reacting node.
>>>>=20
>>>> - JOuni
>>>>=20
>>>>=20
>>>>> at least one match is also not ok. The request might have been a =
realm-type request (i.e. without Destination Host) and the reacting node =
cannot control whether subsequent requests will take the same path to =
the same reporting node.
>>>>> Even if the request contains a destination host the reacting node =
cannot know wether the reacting node's capabilities have been modified =
by the time a subsequent request is sent.=20
>>>>> Proposal is to keep only the first sentence and delete the rest.
>>>>>=20
>>>>> Ulrich
>>>>>=20
>>>>>=20
>>>>> _______________________________________________
>>>>> DiME mailing list
>>>>> DiME@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>=20
>>>=20
>>=20
>=20


From ulrich.wiehe@nsn.com  Tue Dec 10 01:28:41 2013
Return-Path: 
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 7485F1AD8DB for ; Tue, 10 Dec 2013 01:28:41 -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 c2EqKne-B3Uq for ; Tue, 10 Dec 2013 01:28:39 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id BC6021A1F7B for ; Tue, 10 Dec 2013 01:28:38 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rBA9SU8W024834 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 10 Dec 2013 10:28:30 +0100
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 rBA9SSpR032445 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Dec 2013 10:28:29 +0100
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.123.3; Tue, 10 Dec 2013 10:28:28 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.152]) by DEMUHTC013.nsn-intra.net ([10.159.42.44]) with mapi id 14.03.0123.003; Tue, 10 Dec 2013 10:28:28 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Ben Campbell , Steve Donovan 
Thread-Topic: [Dime] OVLI: comments to 4.1
Thread-Index: Ac7xvTHHIECkLcDwSDuVAh2ACeOasAAprlMAAAaV6CAAlFJBAAADLijg///yiAD//+yxwIAAG3gA///jPWCAAEcYgIAAcsEA//8+xjA=
Date: Tue, 10 Dec 2013 09:28:27 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519E29A@DEMUMBX014.nsn-intra.net>
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DA3E@DEMUMBX014.nsn-intra.net> <6CDCFC84-3048-40B9-91A4-1451FCC65F60@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519DCE5@DEMUMBX014.nsn-intra.net> <09616DA2-D1ED-40EE-8E89-755DFCD81092@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E02B@DEMUMBX014.nsn-intra.net> <1A402C59-E390-4C95-8E30-97F1F9D3EF0F@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E05C@DEMUMBX014.nsn-intra.net> <790F1603-64D5-40E2-BC59-FD4C104EEF1B@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E0D9@DEMUMBX014.nsn-intra.net> <52A5E813.60801@usdonovans.com> <7AE3F729-B987-45B1-A9AF-2F0C9A36641E@nostrum.com>
In-Reply-To: <7AE3F729-B987-45B1-A9AF-2F0C9A36641E@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.112]
Content-Type: text/plain; charset="us-ascii"
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: 2171
X-purgate-ID: 151667::1386667710-000030AF-37CCB45E/0-0/0-0
Cc: "dime@ietf.org list" 
Subject: Re: [Dime] OVLI: comments to 4.1
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Dec 2013 09:28:41 -0000

Steve, Ben,

thank you for the clarification.
Its definitly worth pointing out what the intended (optional) use for the s=
equence number is.

Do you have any clarification for the use of Sequence-Number in OC-Feature-=
Vectors in answer messages?=20

Ulrich

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Ben Campbell
Sent: Monday, December 09, 2013 11:47 PM
To: Steve Donovan
Cc: dime@ietf.org list
Subject: Re: [Dime] OVLI: comments to 4.1


On Dec 9, 2013, at 9:56 AM, Steve Donovan  wrote:

> Ulrich,
>=20
> Looking at the impacts of removing the sequence number from the feature v=
ector AVP.  This would require the following logic for each request receive=
d at the reporting node:
>=20
> Parse the full set of OC-Feature-Vector AVPs=20
> Calculate the set of overlapping capabilities
> Generate the reporting nodes OC-Feature-Vector AVPs
> If the reporting node is in overload then generate and append the OC-OLR =
AVPs.
>=20
> Keeping the version number requires the reporting node to do the followin=
g:
>=20
> Parse the feature vector sequence number
> If the sequence number is changed from the last version number received t=
hen=20
>   Parse the remaining OC-Feature-Vector AVPs
>   Calculate the set of overlapping capabilities
>   Generate the reporting nodes capability AVPs
>   Save the version number and results of capabilities exchange
> If the reporting node is in overload then generate and append the OC-OLR =
AVPs.
>=20
> Removing the sequence number forces the reporting node to do extra work f=
or all requests, including requests received when overloaded.  Given that t=
he sequence number will almost never change, this seems like a bad idea.  W=
e should be reducing the work of overloaded nodes, not increasing it.

It's worth pointing out that, if someone believes the sequence number compa=
rison is not worth the trouble, they can always ignore it and revert to Ste=
ve's first example.

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

From jouni.nospam@gmail.com  Tue Dec 10 02:08:18 2013
Return-Path: 
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 87CB21AD6D1 for ; Tue, 10 Dec 2013 02:08: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 opqzCKf2lCPV for ; Tue, 10 Dec 2013 02:08:17 -0800 (PST)
Received: from mail-bk0-x231.google.com (mail-bk0-x231.google.com [IPv6:2a00:1450:4008:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 1CEAC1ACCD9 for ; Tue, 10 Dec 2013 02:08:15 -0800 (PST)
Received: by mail-bk0-f49.google.com with SMTP id my13so1826260bkb.36 for ; Tue, 10 Dec 2013 02:08:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=eFLmy1Yvqh5gxfb7JoVXt/MTqzIPJ48j38T9aLMncAE=; b=xshwwH+myVQ1kohgIFgJGgH7gm+pnmzYxVG0fBqA755XF3qs7liiR9Qr6tcruPqpSA ClYVzU33BGBI31z5PWHVhK9BDePI/FUOIQN7T60gbQGNDT4aYHjDO8BbzUTfKCcErdzx AIBUfkUBs5+6qbCtfcYqhzuoHEV/cTm58GFoY0FVtp4iNTGT2tC3notgMdBRLFbYPuli ORYQfECz3GvLRYlrLPo1SgCNgCFEzQty68v+Afn13qBxrhrNip++IslAeIBQPwF0hKwa li1g8KRjADlsE0CJADUo9D4Vgq30p24G0rTXMMZcRjWVT5ZWTc9IjlLKHg+JVepSXHVK dFlw==
X-Received: by 10.205.106.202 with SMTP id dv10mr236057bkc.109.1386670090266;  Tue, 10 Dec 2013 02:08:10 -0800 (PST)
Received: from ?IPv6:2001:6e8:480:60:44d6:cc4b:4513:f475? ([2001:6e8:480:60:44d6:cc4b:4513:f475]) by mx.google.com with ESMTPSA id no2sm11055400bkb.15.2013.12.10.02.08.09 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Dec 2013 02:08:09 -0800 (PST)
From: Jouni Korhonen 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <5B77F6A6-FEED-49D6-8F60-9CBFE0962757@gmail.com>
Date: Tue, 10 Dec 2013 12:08:09 +0200
To: "dime@ietf.org list" 
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
X-Mailer: Apple Mail (2.1510)
Subject: [Dime] DOIC updates uploaded
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Dec 2013 10:08:18 -0000

Changes pushed to repository.

    Renames OC-Feature-Vector to OC-Supported-Features.
    Renamed OC-Features to OC-Feature-Vector.
    
    Described the OC-Sequence-Number semantics when the
    value overflows.. and added a small pseudo code to
    illustrate the algorithm.
    
    Clarified the use of OC-Report-Type, when a new value
    is needed and what it implies..
    
    Clarified that a new report type implies an allocation
    of a new feature.
    
    Clarified how to extend the OC-OLR and when a new
    report type is needed in that context.

    Changes to Section 5.5.2. Reacting Node Considerations
    o Updated AVPs names to current ones.
    o Added a note that new report types are possible and
      may imply new ways of treating the report.


- Jouni

From maria.cruz.bartolome@ericsson.com  Tue Dec 10 02:12:36 2013
Return-Path: 
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 843AE1A1F3D for ; Tue, 10 Dec 2013 02:12:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.24
X-Spam-Level: 
X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no
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 FuZCenm91E99 for ; Tue, 10 Dec 2013 02:12:28 -0800 (PST)
Received: from sesbmg21.mgmt.ericsson.se (sesbmg21.ericsson.net [193.180.251.49]) by ietfa.amsl.com (Postfix) with ESMTP id 8795E1AD83F for ; Tue, 10 Dec 2013 02:12:18 -0800 (PST)
X-AuditID: c1b4fb31-b7fa78e0000005dd-a3-52a6e8fcbd96
Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg21.mgmt.ericsson.se (Symantec Mail Security) with SMTP id D8.C0.01501.CF8E6A25; Tue, 10 Dec 2013 11:12:12 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.197]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.02.0347.000; Tue, 10 Dec 2013 11:12:12 +0100
From: Maria Cruz Bartolome 
To: Ben Campbell , "Nirav Salot (nsalot)" 
Thread-Topic: [Dime] OVLI: comments to 4.3
Thread-Index: AQHO9S2KtBqqNIzFn0S5w15MWFQ2wZpNMmkA
Date: Tue, 10 Dec 2013 10:12:12 +0000
Message-ID: <087A34937E64E74E848732CFF8354B9209739F8C@ESESSMB101.ericsson.se>
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DB1B@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D90006681519DD2A@DEMUMBX014.nsn-intra.net>   <5BCBA1FC2B7F0B4C9D935572D90006681519DF8A@DEMUMBX014.nsn-intra.net>  <2495B298-0B49-406A-884C-0C354D87948E@nostrum.com>
In-Reply-To: <2495B298-0B49-406A-884C-0C354D87948E@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.20]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBLMWRmVeSWpSXmKPExsUyM+Jvre6fF8uCDG5f1LCY33ma3WJu7wo2 i2erUhyYPab83sjqsWTJTyaPWTufsAQwR3HZpKTmZJalFunbJXBlrDvwgbWgRaLiXWsnYwPj NOEuRk4OCQETibvNH1khbDGJC/fWs3UxcnEICZxglHi69zaUs4RRYuLEb2wgVWwCdhKXTr9g ArFFBHwl9u19xAJiMwsoS8ze8YAdxBYW0JTY8eYsC0SNlsShP/uZuxg5gGwjif93akDCLAKq Es9Ozwcbwws05sOeU6wQu/4xS1xYuAxsF6eAvcSf5U/BZjICXff91BomiF3iEreeQDRLCAhI LNlznhnCFpV4+fgf1DeKElenL4eq15FYsPsTG4StLbFs4WtmiMWCEidnPmGZwCg2C8nYWUha ZiFpmYWkZQEjyypGyeLU4qTcdCNDvdz03BK91KLM5OLi/Dy94tRNjMDYOrjlt+EOxonX7A8x SnOwKInzMkzvDBISSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAyJzMxDrp3Lebk9c87OLxz7G8 5zKzcvb1W+7CR99on45Lm3AkQOHNxbRDZ50Tgq9XKaZv4Zq/s1FvXcMetyvRNyX2tG1P/ixr PGUu875ZJ5tWcfb+MhL7HOH33O1OQvdinj1beL7zKU83Sb5fMUWLU9rZ47jfx8WrJY/96i/c umTBUzahG8/vvFViKc5INNRiLipOBABNG6KdewIAAA==
Cc: "dime@ietf.org" 
Subject: Re: [Dime] OVLI: comments to 4.3
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Dec 2013 10:12:36 -0000

Dear all,

See my comments below.
Best regards
MCruz



-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell
Sent: lunes, 09 de diciembre de 2013 23:25
To: Nirav Salot (nsalot)
Cc: dime@ietf.org
Subject: Re: [Dime] OVLI: comments to 4.3


On Dec 9, 2013, at 6:43 AM, Nirav Salot (nsalot)  wrote:

> Ulrich,
>=20
>> it is also an important part that the reacting node calculates the expir=
y time of an OLR based on the included timestamp and duration and not based=
 on the reception time and the included duration.
> I do not agree that this is important.

> I do not see any issue if the reacting node starts the timer equal to Val=
idity-Period on reception of the message containing a fresh OC-OLR.
> I agree that this means each reacting node will run this timer for differ=
ent duration since each of them will start the timer of the same value but =
starting from the time when they received OC-OLR. But this is not an issue =
since Validity-Period is anyway a guestimate and it would provide a natural=
 ramp up effect (to avoid message storm at the reporting node) if each of t=
he reacting node stops the throttling at different time.
>=20

[Ben] Nirav and I agree on something for a change :-) The validity period i=
s from the time you first get the OLR. It's not based on a timestamp in the=
 message. The in-transit times for an OLR are not going to be so long, and =
the need for precision not so high, to justify the need for a time referenc=
e in the OLR.

[MCruz] I agree with Ben and Nirav, I think it is enough to start the valid=
ity period when the OLR is received by reacting node.


>> It is much simpler for reporting nodes to include a pre-calculated OLR i=
nto the answer rather than  to adjust the validity-duration in the OLR in d=
ependency of the time when the OLR is included into the answer.
> I agree. The reporting node should not be required to adjust Validity-Per=
iod while sending OC-OLR to different reacting nodes. I do not see any need=
 to do so based on my explanation above.
>=20

[Ben] This would only be an issue if we expect an overloaded node to keep t=
he same overload state for relatively long periods of time. The nature of o=
verload is such that I do not expect that to be true.
However, one point we need to be clear on is that receipt of a new copy of =
the same OLR does not restart the timer.

[MCruz] My understanding is that validity-period should be adjusted by repo=
rting node depending on their expectations on traffic reduction by one clie=
nt. Therefore, it should be updated towards _each_ client, based on reporti=
ng node expectations on _each_ client traffic reduction. I understand it do=
es not mean (necessarily) that validity period has to be updated each time =
a message is sent, but it will depend on each overload situation and per cl=
ient.

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

From ulrich.wiehe@nsn.com  Tue Dec 10 02:15:52 2013
Return-Path: 
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 B78EA1A1F3D for ; Tue, 10 Dec 2013 02:15:52 -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 UB0RFkmiqaEt for ; Tue, 10 Dec 2013 02:15:46 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 28E911AD9AC for ; Tue, 10 Dec 2013 02:15:39 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rBAAFTre016490 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 10 Dec 2013 11:15:29 +0100
Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rBAAFSQn012275 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Dec 2013 11:15:28 +0100
Received: from DEMUHTC011.nsn-intra.net (10.159.42.42) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 10 Dec 2013 11:15:28 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.152]) by DEMUHTC011.nsn-intra.net ([10.159.42.42]) with mapi id 14.03.0123.003; Tue, 10 Dec 2013 11:15:28 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: "ext Shishufeng (Susan)" , "ext lionel.morand@orange.com" , ext Jouni Korhonen , Ben Campbell 
Thread-Topic: [Dime] DOIC: Self-Contained OLRs
Thread-Index: AQHO67/t2PaAGa/GgUyaCwjRxXVUh5o5m/0AgAC8o/D///ghgIAAFu+wgBFDRACAABmHcIAA+40AgACAkLA=
Date: Tue, 10 Dec 2013 10:15:27 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519E2DE@DEMUMBX014.nsn-intra.net>
References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com>  <5BCBA1FC2B7F0B4C9D935572D90006681519BC90@DEMUMBX014.nsn-intra.net> <6390_1385631044_52970D44_6390_18593_1_6B7134B31289DC4FAF731D844122B36E30748E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BD19@DEMUMBX014.nsn-intra.net> <26C84DFD55BC3040A45BF70926E55F2587C1D028@SZXEMA512-MBX.china.huawei.com> <5BCBA1FC2B7F0B4C9D935572D90006681519DFC0@DEMUMBX014.nsn-intra.net> <26C84DFD55BC3040A45BF70926E55F2587C1D705@SZXEMA512-MBX.china.huawei.com>
In-Reply-To: <26C84DFD55BC3040A45BF70926E55F2587C1D705@SZXEMA512-MBX.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.112]
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: 13942
X-purgate-ID: 151667::1386670529-000030AF-937547E8/0-0/0-0
Cc: "dime@ietf.org list" 
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Dec 2013 10:15:53 -0000

Hi Susan,

if the agent does not take the role of a DOIC endpont then the feature nego=
tiation/adverisement is between client and server and one host type OLR is =
sent from server to client. For the agent this is all transparent and there=
 is no need for the agent to support any DOIC feature.
However, if the agent takes the role of an DOIC endpoint then the feature n=
egotiation/advertisement is between client and agent and a separate feature=
 negotiation/advertisement is between agent and server. An OLR sent from se=
rver to agent is in-context with the supported features of server and agent=
 but possibly not in-context with supported features of client and agent an=
d therefore must not be (blindly) sent to the client. And in fact there is =
also no need to do that. For subsequent requests that contain the desinatio=
n host of the server, the agent will not take the role of a DOIC endpoint.

Best regards
Ulrich

-----Original Message-----
From: ext Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]=20
Sent: Tuesday, December 10, 2013 4:02 AM
To: Wiehe, Ulrich (NSN - DE/Munich); ext lionel.morand@orange.com; ext Joun=
i Korhonen; Ben Campbell
Cc: dime@ietf.org list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Hi Ulrich,

Thanks for your clarification. I understood the scenario, while from my poi=
nt of view, if the agent that selects the HSS is not configured to serve as=
 a load balancer for the HSS, the agent should not change any supported/neg=
otiated features between C and S, that would be the normal case. If the age=
nt serve as a load balancer for the HSS, the subsequent request from C towa=
rds the S would always go via the agent, in this case whatever the associat=
ions between C and A, between A and S are the same or not, it doesn't matte=
r. With an E2E solution as we agreed, I don't see the problem with it.

Best Regards,
Susan

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20
Sent: Monday, December 09, 2013 7:43 PM
To: Shishufeng (Susan); ext lionel.morand@orange.com; ext Jouni Korhonen; B=
en Campbell
Cc: dime@ietf.org list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Hi Susan,

let me come back to your S6a example.

The MME (C) sends a request without Destination-Host towards the HPLMN (rea=
lm). There must be an agent (A) in the HPLMN (realm) that selects the HSS (=
S).=20
We would have two distinct DOIC associations: one between C and A, another =
between A and S (see figure 5 in clause 5.1). The two DOIC associations may=
 have different supported/negotiated features. An OLR sent from S to A base=
d on supported/negotiated features valid for the DOIC association between A=
 and S is at least problematic (out-of context) when sent from A to C.

When the MME (C) sends a subsequent request with Destination-Host towards t=
he HSS (S), there is no agent that selects the HSS (as the HSS is already s=
elected). For this session there is only one DOIC association between C and=
 S (see figure 3 in clause 5.1) and OLRs sent from S to C are not problemat=
ic.

Best regards
Ulrich


-----Original Message-----
From: ext Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
Sent: Monday, December 09, 2013 11:30 AM
To: Wiehe, Ulrich (NSN - DE/Munich); ext lionel.morand@orange.com; ext Joun=
i Korhonen; Ben Campbell
Cc: dime@ietf.org list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Hi Ulrich,

I have different views. In any case, I think the host-type OLR should not b=
e ignored by the clients. On the contrary, the realm-type OLR can be though=
t as optimization, which may not even be needed at all for all cases, espec=
ially in 3GPP. Here is an example of S6a, in the case the first attach requ=
est comes from the UE to the MME, the MME can only derive the realm informa=
tion, and sends a request without Destination-Host towards the HPLMN. Since=
 the subscriber corresponding to the UE belongs to a specific HSS, and the =
HSS may provide its overload report to the MME, and the MME is able to know=
 how to react regarding the requests towards the HSS, which would be the no=
rmal case. Whether Realm report will be provided by the HSS or the agent se=
rving the HSS is kind of optimization which may help the MME to know how to=
 react on the requests towards the realm, not specific to the HSS.

Best Regards,
Susan

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
Sent: Thursday, November 28, 2013 6:30 PM
To: ext lionel.morand@orange.com; ext Jouni Korhonen; Ben Campbell
Cc: dime@ietf.org list
Subject: 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 act=
ual OLR created by the reporting end point and which OLR is an additional O=
LR created by another node.

We have two cases:
a) The request sent by the client (reacting end point) contains no Destinat=
ion Host. The agent (reporting node) (after forwarding the request to the s=
elected server and receiving the answer) returns a realm-type OLR as the ac=
tual 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 Destinat=
ion 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 stat=
us. It could be provided an agent inserting this info in answers received f=
rom a server behind but also from a server that would know this info by som=
e internal magic.
But in any case, if we assume that the client will received a successful an=
swer from the server for an initial request with only Dest-Realm AVP, it sh=
ould be possible to have both report types in the answer: one for the serve=
r itself, one for the realm for new request sent to the realm with only Des=
t-Realm AVP.

Lionel

-----Message d'origine-----
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN=
 - DE/Munich) Envoy=E9=A0: jeudi 28 novembre 2013 10:26 =C0=A0: ext Jouni K=
orhonen; Ben Campbell Cc=A0: dime@ietf.org list Objet=A0: Re: [Dime] DOIC: =
Self-Contained OLRs

Hi,

I don't see how the possibility to send more than one OLR in an answer is a=
ligned with the "endpoint principle". If the ReportType is "realm" this ind=
icates 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  wrote:

> Hi,
>=20
> I mentioned in another thread that I prefer putting an explicit=20
> ReportType AVP in an OLR, rather than

The more I spent time thinking/writing the actual procedures on the endpoin=
ts, the more it makes sense to me to keep the ReportType in the OC-OLR. Eve=
n if the baseline does not have agent overload etc, the ReportType fits wel=
l to the "endpoint principle" we have in the draft. It indeed gives more to=
ols to make a host vs. realm base decision on the reacting node and is plai=
n 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 Diam=
eter request that corresponds to the answer containing the OLR. My reasons =
for that go beyond just ReportType, so I'm starting a separate thread.
>=20
> As currently described, a consumer of an OLR must infer several things fr=
om other context. In most cases, that context is in the Diameter answer tha=
t carries the OLR. For example, the OLR implicitly refers to the applicatio=
n 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 meani=
ng in the context of the enclosing answer. If you moved an OLR from one ans=
wer to another, it's meaning may change completely.
>=20
> I think this approach is a mistake. I would greatly prefer that we explic=
itly include such values in the OLR itself, for multiple reasons:
>=20
> 1) It's more complex to interpret implicit, contextual values than explic=
it values. The consumer cannot simply look at the OLR; it must look in vari=
ous other AVPs to find all the information it needs. For example, I think a=
 common software design for overload control processing to be separated fro=
m application processing. The consumer cannot simply hand the OLR to that m=
odule 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 "con=
text" avps that must be interpreted can grow large. This approach is error =
prone, and will likely encourage brittle, hard-to-maintain code. Self-conta=
ined OLRs would keep all the information related to overload in one place. =
making for simpler implementations.
>=20
> 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 r=
eporting node realizes that it is overloade, it has to wait for the right a=
nswer that contains the right context before it can send the OLR. This is p=
articularly troublesome for agents, since they will typically have to inser=
t OLRs into answers created by other nodes.=20
>=20
> If the reporting node screws this up, the meaning of the OLR may change s=
ignificantly. So again, implicit meaning gives us error prone implementatio=
ns. Self-contained OLRs are simpler to create and send.
>=20
> 3) Implicit values don't work at all for certain problems. For=20
> example, if an agent needs to originate an OLR, it typically needs to=20
> insert that OLR into an existing Diameter answer created by a server.
> It can't create its own answer without affecting the application=20
> state. If the responding node assumes the OLR comes from or refers to=20
> the node identified by the Origin-Host AVP in the enclosing answer,=20
> things break. (For examples of when an agent needs to send OLRs that=20
> are distinct from those sent by a server, see Steve's agent overload=20
> draft, or my dh/dr example.)
>=20
> OTOH, explicit values will work for all cases where we need to associate =
some arbitrary value with an OLR.
>=20
> 4) Implicit values seriously constrain the future evolution of Diameter O=
C standards. For example, lets say we find a good reason to allow OLRs to b=
e sent out of band, or be sent in a dedicated Diameter application. If over=
load 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 transpo=
rted, this won't work. We would have to create a new or significantly modif=
ied OLR format if we found a need to transport OLRs in different ways. Self=
-contained OLRs would allow much greater flexibility.
>=20
> So, in summary, I think that self-contained OLRs would lead to simpler im=
plementations, less brittle deployments, and more flexibility for future ev=
olution of standards.
>=20
> Thanks!
>=20
> 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 confiden=
tielles 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. Le=
s messages electroniques etant susceptibles d'alteration, Orange decline to=
ute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation 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 dele=
te 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.



From jouni.nospam@gmail.com  Tue Dec 10 02:18:17 2013
Return-Path: 
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 54C7E1AD944 for ; Tue, 10 Dec 2013 02:18:17 -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 KmU5OLPC2lDx for ; Tue, 10 Dec 2013 02:18:14 -0800 (PST)
Received: from mail-bk0-x22f.google.com (mail-bk0-x22f.google.com [IPv6:2a00:1450:4008:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 070EE1A1F3D for ; Tue, 10 Dec 2013 02:18:13 -0800 (PST)
Received: by mail-bk0-f47.google.com with SMTP id mx12so1839466bkb.20 for ; Tue, 10 Dec 2013 02:18:08 -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=wembXsPY8PvalwTDF3QDkgm2qfPh8T1O9r8y+E7LPFA=; b=tcZ6SQCOUggLolMC6V1FXzQp17fwTAOUGHl38WOEtydE9a6037afDsOTBavQoW1Eat FXCcNzIpI5XIb8+iLh2TdB4EjJWSKN3sc9VVZxb4kVbB7yS8U90QhCMsbX7ANlfFpUGS igZ3oFDNLph+4dXMNMjWQkxTMVdLF3KyVE4io2LIsHTvRuYT0i62QNoA8GjJnQxhleXh sjq/ldmRb92Oql3Uoslr2cQKi6/ijT3Eq88nnZTmVCrWXMAhb/KdAEy7d/XU5NJWUN5+ eMwDl3ONwnGp/0AUPVL6m8sVH6vEE+N9e/GA2B6FeLqECaXrGdt+4VNyS0ccm6Bvr2cq mxbQ==
X-Received: by 10.205.64.209 with SMTP id xj17mr257946bkb.76.1386670688369; Tue, 10 Dec 2013 02:18:08 -0800 (PST)
Received: from ?IPv6:2001:6e8:480:60:44d6:cc4b:4513:f475? ([2001:6e8:480:60:44d6:cc4b:4513:f475]) by mx.google.com with ESMTPSA id qg7sm11099950bkb.6.2013.12.10.02.18.07 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Dec 2013 02:18:07 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jouni Korhonen 
In-Reply-To: <087A34937E64E74E848732CFF8354B9209739F8C@ESESSMB101.ericsson.se>
Date: Tue, 10 Dec 2013 12:18:06 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <651FE189-F6B1-4807-938D-67C6B7841044@gmail.com>
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DB1B@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D90006681519DD2A@DEMUMBX014.nsn-intra.net>   <5BCBA1FC2B7F0B4C9D935572D90006681519DF8A@DEMUMBX014.nsn-intra.net>  <2495B298-0B49-406A-884C-0C354D87948E@nostrum.com> <087A34937E64E74E848732CFF8354B9209739F8C@ESESSMB101.ericsson.se>
To: Maria Cruz Bartolome 
X-Mailer: Apple Mail (2.1510)
Cc: Ben Campbell , "dime@ietf.org" 
Subject: Re: [Dime] OVLI: comments to 4.3
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Dec 2013 10:18:17 -0000

>=20
>=20
> [MCruz] My understanding is that validity-period should be adjusted by =
reporting node depending on their expectations on traffic reduction by =
one client. Therefore, it should be updated towards _each_ client, based =
on reporting node expectations on _each_ client traffic reduction. I =
understand it does not mean (necessarily) that validity period has to be =
updated each time a message is sent, but it will depend on each overload =
situation and per client.
>=20

This is my understanding as well (and how the text currently is =
written.. or=20
is meant to be read ;)

- Jouni


From ulrich.wiehe@nsn.com  Tue Dec 10 02:41:42 2013
Return-Path: 
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 D86531ADDD3 for ; Tue, 10 Dec 2013 02:41:42 -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 1fSUAnsRaUx2 for ; Tue, 10 Dec 2013 02:41:39 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 7D2D51ADBF7 for ; Tue, 10 Dec 2013 02:41:38 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rBAAfVSA022206 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 10 Dec 2013 11:41:31 +0100
Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rBAAfVow014135 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Dec 2013 11:41:31 +0100
Received: from DEMUHTC012.nsn-intra.net (10.159.42.43) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 10 Dec 2013 11:41:31 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.152]) by DEMUHTC012.nsn-intra.net ([10.159.42.43]) with mapi id 14.03.0123.003; Tue, 10 Dec 2013 11:41:30 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Jouni Korhonen 
Thread-Topic: [Dime] OVLI: comments to 4.1
Thread-Index: Ac7xvTHHIECkLcDwSDuVAh2ACeOasAAprlMAAAaV6CAAlFJBAAADLijg///yiAD//+yxwIAAG3gA///jPWCAAV/bAP//0rCw
Date: Tue, 10 Dec 2013 10:41:30 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519E331@DEMUMBX014.nsn-intra.net>
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DA3E@DEMUMBX014.nsn-intra.net> <6CDCFC84-3048-40B9-91A4-1451FCC65F60@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519DCE5@DEMUMBX014.nsn-intra.net> <09616DA2-D1ED-40EE-8E89-755DFCD81092@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E02B@DEMUMBX014.nsn-intra.net> <1A402C59-E390-4C95-8E30-97F1F9D3EF0F@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E05C@DEMUMBX014.nsn-intra.net> <790F1603-64D5-40E2-BC59-FD4C104EEF1B@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E0D9@DEMUMBX014.nsn-intra.net> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.112]
Content-Type: text/plain; charset="us-ascii"
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: 8436
X-purgate-ID: 151667::1386672091-00002466-17D91F38/0-0/0-0
Cc: "dime@ietf.org" 
Subject: Re: [Dime] OVLI: comments to 4.1
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Dec 2013 10:41:43 -0000

Hi Jouni,

my understanding from Steve's clarification was that the reporting node wou=
ld setup and maintain a database of "states", one per reacting node where a=
 state of a reacting node is identified by a sequence number and the databa=
se entry would contain the pre-calculated OLR.=20
Hard to see how this is done without consuming resources.

Furthermore,
Why would the reacting node be interested in config changes of the reportin=
g node?
Isn't it so that the reacting node is only interested in OLR changes?

Ulrich

-----Original Message-----
From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
Sent: Tuesday, December 10, 2013 9:41 AM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: dime@ietf.org
Subject: Re: [Dime] OVLI: comments to 4.1


On Dec 9, 2013, at 4:43 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:

> But maintaining a specific state per reacting node is very resource consu=
ming for the (overloaded) reporting node. It is simpler and more efficient =
to base any processing logic on actual information received in the request =
rather than on information stored from previous communication.

The "state" in a reporting node is merely the current configuration
and a counter for sequence number. Hard to me see that as resource
consuming function.

And the earlier comment of mine is done from reacting node point
of view, since it is more interested in the possible config changes
in the reporting node (e.g. S6a is stateless application, configuration
can change at any time).

- Jouni


>=20
> Ulrich
>=20
> -----Original Message-----
> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
> Sent: Monday, December 09, 2013 2:25 PM
> To: Wiehe, Ulrich (NSN - DE/Munich)
> Cc: dime@ietf.org
> Subject: Re: [Dime] OVLI: comments to 4.1
>=20
>=20
> On Dec 9, 2013, at 3:13 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:
>=20
>> There is a fundamental difference:
>> OLRs need to be stored, Feature-Vectors not.
>=20
> How come feature vector does not need to be stored? I do not
> get that? I would set my implementation to a specific state
> or mode based on the feature vector. When that changes I'd
> like to know that. And then keep functioning based on that.
>=20
> - Jouni
>=20
>> When receiving an OLR you may want to know whether its worth the effort =
to replace an already stored OLR with the received OLR.
>> When receiving a Feature-Vector you just act on it.
>>=20
>> Ulrich=20
>>=20
>> -----Original Message-----
>> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
>> Sent: Monday, December 09, 2013 1:55 PM
>> To: Wiehe, Ulrich (NSN - DE/Munich)
>> Cc: dime@ietf.org
>> Subject: Re: [Dime] OVLI: comments to 4.1
>>=20
>>=20
>> In the same vein as folks wanted send OLRs with the new or old informati=
on,
>> the feature vector should behave in a same way IMHO. That implies there =
are
>> situations when a reception of the feature vector does not change anythi=
ng
>> in an endpoint current behavior.
>>=20
>> - Jouni
>>=20
>> On Dec 9, 2013, at 2:47 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:
>>=20
>>> Isn't it so that the Feature-Vector (if present) always contains someth=
ing that an implementation needs to act upon?
>>>=20
>>> Ulrich
>>>=20
>>> -----Original Message-----
>>> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
>>> Sent: Monday, December 09, 2013 1:12 PM
>>> To: Wiehe, Ulrich (NSN - DE/Munich)
>>> Cc: dime@ietf.org
>>> Subject: Re: [Dime] OVLI: comments to 4.1
>>>=20
>>> Ulrich,
>>>=20
>>> On Dec 6, 2013, at 3:03 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:
>>>=20
>>>> Hi Jouni,
>>>>=20
>>>> thank you for your response.
>>>>=20
>>>> With regard to 3)=20
>>>> I still fail to see the usecase for Sequence-Number or TimeStamp withi=
n OC-Feature-Vector. Please clarify.
>>>=20
>>> Since we also allow extending the OC-Feature-Vector beyond recognition,=
=20
>>> it has good chances become a rather complex grouped AVP. In that contex=
t
>>> the Sequence-Number allows an easy and quick way to check if the featur=
e
>>> vector contains something that an implementation needs to act upon.
>>>=20
>>>> With regard to 4)
>>>> This was not obvious to me. (The obvious typo is the missing "of" betw=
een "one" and "the").
>>>=20
>>> Ack. Fixed the missing 'of'.
>>>=20
>>> - Jouni
>>>=20
>>>>=20
>>>> Best regards
>>>> Ulrich
>>>>=20
>>>>=20
>>>> -----Original Message-----
>>>> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
>>>> Sent: Friday, December 06, 2013 11:17 AM
>>>> To: Wiehe, Ulrich (NSN - DE/Munich)
>>>> Cc: dime@ietf.org
>>>> Subject: Re: [Dime] OVLI: comments to 4.1
>>>>=20
>>>>=20
>>>> On Dec 5, 2013, at 3:23 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:
>>>>=20
>>>>> Dear all,
>>>>>=20
>>>>> here are comments to clause 4.1:
>>>>>=20
>>>>> 1. The OC-Feature-Vector AVP is no longer a vector; the name of the A=
VP may be misleading. Proposal is to rename it to "OC-Supported-Features AV=
P"
>>>>=20
>>>> OK with me.
>>>>=20
>>>>> 2. The OC-Feature AVP is a vector of features. Proposal is to rename =
it to "OC-Feature-Vector AVP"
>>>>=20
>>>> OK with me.
>>>>=20
>>>>> 3. The OC-Sequence-Number within OC-Feature-Vector only makes sense i=
f the receiving reporting endpoint can determine the identity of the reacti=
ng endpoint (which is not necessarily the origin host (client),
>>>>=20
>>>> My original proposal was to have seqnr as a timestamp. Some folks argu=
ed
>>>> it is no good and suggested seqnr. I still think time makes more sense=
 than
>>>> seqnr.
>>>>=20
>>>>> it may be an agent and it may not always be the same agent), and if t=
he reporting endpoint is required to store the OC-Feature-Vector / reacting=
-endpoint-identity pair (which I think both is not required). The reporting=
 endpoint can base its processing logic on the actually received OC-Feature=
-Vector value, no matter whether it is brand-new or old but stil valid. Pro=
posal is to delete OC-Sequence-Number AVP from OC-Feature-Vector.
>>>>=20
>>>> Do not agree removing it.
>>>>=20
>>>>> 4. The text
>>>>>=20
>>>>> The reporting node that sends the answer also includes the OC-
>>>>> Feature-Vector AVP that describe the capabilities it supports.  The
>>>>> set of capabilities advertised by the reporting node depends on local
>>>>> policies.  At least one the announced capabilities MUST match
>>>>> mutually.  If there is no single matching capability the reacting
>>>>> node MUST act as if it does not implement DOIC and cease inserting
>>>>> any DOIC related AVPs into any Diameter messages with this specific
>>>>> reacting node.
>>>>>=20
>>>>> is not clear.  Would the reporting node include the OC-Feature-Vector=
 AVP in the answer only if there is at least one matching capability?=20
>>>>=20
>>>> Because then they have found a way to exchange something that both end=
s
>>>> know how to handle it.
>>>>=20
>>>>> Mandating the reacting node to cease for all time inserting OC-Featur=
e-Vector AVPs if it did not get back=20
>>>>=20
>>>> There is an obvious typo. It should say:
>>>>=20
>>>> policies.  At least one the announced capabilities MUST match
>>>> mutually.  If there is no single matching capability the reporting
>>>> node MUST act as if it does not implement DOIC and cease inserting
>>>> any DOIC related AVPs into any Diameter messages with this specific
>>>> reacting node.
>>>>=20
>>>> - JOuni
>>>>=20
>>>>=20
>>>>> at least one match is also not ok. The request might have been a real=
m-type request (i.e. without Destination Host) and the reacting node cannot=
 control whether subsequent requests will take the same path to the same re=
porting node.
>>>>> Even if the request contains a destination host the reacting node can=
not know wether the reacting node's capabilities have been modified by the =
time a subsequent request is sent.=20
>>>>> Proposal is to keep only the first sentence and delete the rest.
>>>>>=20
>>>>> Ulrich
>>>>>=20
>>>>>=20
>>>>> _______________________________________________
>>>>> DiME mailing list
>>>>> DiME@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>=20
>>>=20
>>=20
>=20


From jouni.nospam@gmail.com  Tue Dec 10 03:32:09 2013
Return-Path: 
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 6D0EE1ADFAC for ; Tue, 10 Dec 2013 03:32:09 -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 kccHc6nZUdyp for ; Tue, 10 Dec 2013 03:32:07 -0800 (PST)
Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 984511ADF6D for ; Tue, 10 Dec 2013 03:32:06 -0800 (PST)
Received: by mail-la0-f45.google.com with SMTP id eh20so2585395lab.4 for ; Tue, 10 Dec 2013 03:32:00 -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=bMYUxkw9OAPj/8W0qwfF1aSr6hUeuZOFsh1Wk6Ztq9A=; b=my/O/S1jf3GU3T+7HCRoOsMqF2YMDXV8ggehtd7NxG3Zc1xErFg3iezXQYwuChSec3 t+7Upmt08/nT/8KnOA585LTeXOqqDO6lGnTJbR0akPQVTDKUC3b8IWXxChOQuaJOwS5+ ZcEOwnLwmcEaomtJndXN8PJgnoZ0dltOzYOWBc0mAX+REDQeoE/YeVBKubCoAknDNZ// 1mh5TV+V7HN8NMT5Juzkfbz/znVXdPHYx8UdZw1oh6krAGwfQ6jfVA6i6zkyJJhsqA6Z IcgIhIfO/92+dRE6YzP3DUcyn+xEKJlsqrf5qOP0HseknO+KLHwH8HKCGIBJ36efgx0L McPg==
X-Received: by 10.152.115.230 with SMTP id jr6mr4958824lab.45.1386675120288; Tue, 10 Dec 2013 03:32:00 -0800 (PST)
Received: from [192.168.250.75] ([194.100.71.98]) by mx.google.com with ESMTPSA id di11sm21179761lac.0.2013.12.10.03.31.58 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Dec 2013 03:31:59 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jouni Korhonen 
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681519E331@DEMUMBX014.nsn-intra.net>
Date: Tue, 10 Dec 2013 13:31:58 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DA3E@DEMUMBX014.nsn-intra.net> <6CDCFC84-3048-40B9-91A4-1451FCC65F60@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519DCE5@DEMUMBX014.nsn-intra.net> <09616DA2-D1ED-40EE-8E89-755DFCD81092@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E02B@DEMUMBX014.nsn-intra.net> <1A402C59-E390-4C95-8E30-97F1F9D3EF0F@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E05C@DEMUMBX014.nsn-intra.net> <790F1603-64D5-40E2-BC59-FD4C104EEF1B@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E0D9@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D90006681519E331@DEMUMBX014.nsn-intra.net>
To: "Wiehe, Ulrich (NSN - DE/Munich)" 
X-Mailer: Apple Mail (2.1510)
Cc: "dime@ietf.org" 
Subject: Re: [Dime] OVLI: comments to 4.1
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Dec 2013 11:32:09 -0000

On Dec 10, 2013, at 12:41 PM, "Wiehe, Ulrich (NSN - DE/Munich)" =
 wrote:

> Hi Jouni,
>=20
> my understanding from Steve's clarification was that the reporting =
node would setup and maintain a database of "states", one per reacting =
node where a state of a reacting node is identified by a sequence number =
and the database entry would contain the pre-calculated OLR.=20
> Hard to see how this is done without consuming resources.

It is mostly static information. Still I do not see how
you would get away without any state.

> Furthermore,
> Why would the reacting node be interested in config changes of the =
reporting node?
> Isn't it so that the reacting node is only interested in OLR changes?

Sigh.. say the traffic abatement algorithm changes or new features
get added. Those have more impact than just OLR change.

- Jouni

>=20
> Ulrich
>=20
> -----Original Message-----
> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
> Sent: Tuesday, December 10, 2013 9:41 AM
> To: Wiehe, Ulrich (NSN - DE/Munich)
> Cc: dime@ietf.org
> Subject: Re: [Dime] OVLI: comments to 4.1
>=20
>=20
> On Dec 9, 2013, at 4:43 PM, "Wiehe, Ulrich (NSN - DE/Munich)" =
 wrote:
>=20
>> But maintaining a specific state per reacting node is very resource =
consuming for the (overloaded) reporting node. It is simpler and more =
efficient to base any processing logic on actual information received in =
the request rather than on information stored from previous =
communication.
>=20
> The "state" in a reporting node is merely the current configuration
> and a counter for sequence number. Hard to me see that as resource
> consuming function.
>=20
> And the earlier comment of mine is done from reacting node point
> of view, since it is more interested in the possible config changes
> in the reporting node (e.g. S6a is stateless application, =
configuration
> can change at any time).
>=20
> - Jouni
>=20
>=20
>>=20
>> Ulrich
>>=20
>> -----Original Message-----
>> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
>> Sent: Monday, December 09, 2013 2:25 PM
>> To: Wiehe, Ulrich (NSN - DE/Munich)
>> Cc: dime@ietf.org
>> Subject: Re: [Dime] OVLI: comments to 4.1
>>=20
>>=20
>> On Dec 9, 2013, at 3:13 PM, "Wiehe, Ulrich (NSN - DE/Munich)" =
 wrote:
>>=20
>>> There is a fundamental difference:
>>> OLRs need to be stored, Feature-Vectors not.
>>=20
>> How come feature vector does not need to be stored? I do not
>> get that? I would set my implementation to a specific state
>> or mode based on the feature vector. When that changes I'd
>> like to know that. And then keep functioning based on that.
>>=20
>> - Jouni
>>=20
>>> When receiving an OLR you may want to know whether its worth the =
effort to replace an already stored OLR with the received OLR.
>>> When receiving a Feature-Vector you just act on it.
>>>=20
>>> Ulrich=20
>>>=20
>>> -----Original Message-----
>>> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
>>> Sent: Monday, December 09, 2013 1:55 PM
>>> To: Wiehe, Ulrich (NSN - DE/Munich)
>>> Cc: dime@ietf.org
>>> Subject: Re: [Dime] OVLI: comments to 4.1
>>>=20
>>>=20
>>> In the same vein as folks wanted send OLRs with the new or old =
information,
>>> the feature vector should behave in a same way IMHO. That implies =
there are
>>> situations when a reception of the feature vector does not change =
anything
>>> in an endpoint current behavior.
>>>=20
>>> - Jouni
>>>=20
>>> On Dec 9, 2013, at 2:47 PM, "Wiehe, Ulrich (NSN - DE/Munich)" =
 wrote:
>>>=20
>>>> Isn't it so that the Feature-Vector (if present) always contains =
something that an implementation needs to act upon?
>>>>=20
>>>> Ulrich
>>>>=20
>>>> -----Original Message-----
>>>> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
>>>> Sent: Monday, December 09, 2013 1:12 PM
>>>> To: Wiehe, Ulrich (NSN - DE/Munich)
>>>> Cc: dime@ietf.org
>>>> Subject: Re: [Dime] OVLI: comments to 4.1
>>>>=20
>>>> Ulrich,
>>>>=20
>>>> On Dec 6, 2013, at 3:03 PM, "Wiehe, Ulrich (NSN - DE/Munich)" =
 wrote:
>>>>=20
>>>>> Hi Jouni,
>>>>>=20
>>>>> thank you for your response.
>>>>>=20
>>>>> With regard to 3)=20
>>>>> I still fail to see the usecase for Sequence-Number or TimeStamp =
within OC-Feature-Vector. Please clarify.
>>>>=20
>>>> Since we also allow extending the OC-Feature-Vector beyond =
recognition,=20
>>>> it has good chances become a rather complex grouped AVP. In that =
context
>>>> the Sequence-Number allows an easy and quick way to check if the =
feature
>>>> vector contains something that an implementation needs to act upon.
>>>>=20
>>>>> With regard to 4)
>>>>> This was not obvious to me. (The obvious typo is the missing "of" =
between "one" and "the").
>>>>=20
>>>> Ack. Fixed the missing 'of'.
>>>>=20
>>>> - Jouni
>>>>=20
>>>>>=20
>>>>> Best regards
>>>>> Ulrich
>>>>>=20
>>>>>=20
>>>>> -----Original Message-----
>>>>> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
>>>>> Sent: Friday, December 06, 2013 11:17 AM
>>>>> To: Wiehe, Ulrich (NSN - DE/Munich)
>>>>> Cc: dime@ietf.org
>>>>> Subject: Re: [Dime] OVLI: comments to 4.1
>>>>>=20
>>>>>=20
>>>>> On Dec 5, 2013, at 3:23 PM, "Wiehe, Ulrich (NSN - DE/Munich)" =
 wrote:
>>>>>=20
>>>>>> Dear all,
>>>>>>=20
>>>>>> here are comments to clause 4.1:
>>>>>>=20
>>>>>> 1. The OC-Feature-Vector AVP is no longer a vector; the name of =
the AVP may be misleading. Proposal is to rename it to =
"OC-Supported-Features AVP"
>>>>>=20
>>>>> OK with me.
>>>>>=20
>>>>>> 2. The OC-Feature AVP is a vector of features. Proposal is to =
rename it to "OC-Feature-Vector AVP"
>>>>>=20
>>>>> OK with me.
>>>>>=20
>>>>>> 3. The OC-Sequence-Number within OC-Feature-Vector only makes =
sense if the receiving reporting endpoint can determine the identity of =
the reacting endpoint (which is not necessarily the origin host =
(client),
>>>>>=20
>>>>> My original proposal was to have seqnr as a timestamp. Some folks =
argued
>>>>> it is no good and suggested seqnr. I still think time makes more =
sense than
>>>>> seqnr.
>>>>>=20
>>>>>> it may be an agent and it may not always be the same agent), and =
if the reporting endpoint is required to store the OC-Feature-Vector / =
reacting-endpoint-identity pair (which I think both is not required). =
The reporting endpoint can base its processing logic on the actually =
received OC-Feature-Vector value, no matter whether it is brand-new or =
old but stil valid. Proposal is to delete OC-Sequence-Number AVP from =
OC-Feature-Vector.
>>>>>=20
>>>>> Do not agree removing it.
>>>>>=20
>>>>>> 4. The text
>>>>>>=20
>>>>>> The reporting node that sends the answer also includes the OC-
>>>>>> Feature-Vector AVP that describe the capabilities it supports.  =
The
>>>>>> set of capabilities advertised by the reporting node depends on =
local
>>>>>> policies.  At least one the announced capabilities MUST match
>>>>>> mutually.  If there is no single matching capability the reacting
>>>>>> node MUST act as if it does not implement DOIC and cease =
inserting
>>>>>> any DOIC related AVPs into any Diameter messages with this =
specific
>>>>>> reacting node.
>>>>>>=20
>>>>>> is not clear.  Would the reporting node include the =
OC-Feature-Vector AVP in the answer only if there is at least one =
matching capability?=20
>>>>>=20
>>>>> Because then they have found a way to exchange something that both =
ends
>>>>> know how to handle it.
>>>>>=20
>>>>>> Mandating the reacting node to cease for all time inserting =
OC-Feature-Vector AVPs if it did not get back=20
>>>>>=20
>>>>> There is an obvious typo. It should say:
>>>>>=20
>>>>> policies.  At least one the announced capabilities MUST match
>>>>> mutually.  If there is no single matching capability the reporting
>>>>> node MUST act as if it does not implement DOIC and cease inserting
>>>>> any DOIC related AVPs into any Diameter messages with this =
specific
>>>>> reacting node.
>>>>>=20
>>>>> - JOuni
>>>>>=20
>>>>>=20
>>>>>> at least one match is also not ok. The request might have been a =
realm-type request (i.e. without Destination Host) and the reacting node =
cannot control whether subsequent requests will take the same path to =
the same reporting node.
>>>>>> Even if the request contains a destination host the reacting node =
cannot know wether the reacting node's capabilities have been modified =
by the time a subsequent request is sent.=20
>>>>>> Proposal is to keep only the first sentence and delete the rest.
>>>>>>=20
>>>>>> Ulrich
>>>>>>=20
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> DiME mailing list
>>>>>> DiME@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>>=20
>>>>=20
>>>=20
>>=20
>=20


From ulrich.wiehe@nsn.com  Tue Dec 10 04:18:47 2013
Return-Path: 
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 0AD251ADF5E for ; Tue, 10 Dec 2013 04:18:47 -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 MG0ThIVhJM2y for ; Tue, 10 Dec 2013 04:18:44 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 594231ADEB7 for ; Tue, 10 Dec 2013 04:18:42 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rBACIZ6n024118 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 10 Dec 2013 13:18:36 +0100
Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rBACIZhu001539 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Dec 2013 13:18:35 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.152]) by DEMUHTC004.nsn-intra.net ([10.159.42.35]) with mapi id 14.03.0123.003; Tue, 10 Dec 2013 13:18:35 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Jouni Korhonen 
Thread-Topic: [Dime] OVLI: comments to 4.1
Thread-Index: Ac7xvTHHIECkLcDwSDuVAh2ACeOasAAprlMAAAaV6CAAlFJBAAADLijg///yiAD//+yxwIAAG3gA///jPWCAAV/bAP//0rCwAAujOgD//+gx4A==
Date: Tue, 10 Dec 2013 12:18:35 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519E3C4@DEMUMBX014.nsn-intra.net>
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DA3E@DEMUMBX014.nsn-intra.net> <6CDCFC84-3048-40B9-91A4-1451FCC65F60@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519DCE5@DEMUMBX014.nsn-intra.net> <09616DA2-D1ED-40EE-8E89-755DFCD81092@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E02B@DEMUMBX014.nsn-intra.net> <1A402C59-E390-4C95-8E30-97F1F9D3EF0F@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E05C@DEMUMBX014.nsn-intra.net> <790F1603-64D5-40E2-BC59-FD4C104EEF1B@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E0D9@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D90006681519E331@DEMUMBX014.nsn-intra.net> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.112]
Content-Type: text/plain; charset="us-ascii"
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: 9703
X-purgate-ID: 151667::1386677916-000030AF-C1C68D73/0-0/0-0
Cc: "dime@ietf.org" 
Subject: Re: [Dime] OVLI: comments to 4.1
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Dec 2013 12:18:47 -0000

-----Original Message-----
From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
Sent: Tuesday, December 10, 2013 12:32 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: dime@ietf.org
Subject: Re: [Dime] OVLI: comments to 4.1


On Dec 10, 2013, at 12:41 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:

> Hi Jouni,
>=20
> my understanding from Steve's clarification was that the reporting node w=
ould setup and maintain a database of "states", one per reacting node where=
 a state of a reacting node is identified by a sequence number and the data=
base entry would contain the pre-calculated OLR.=20
> Hard to see how this is done without consuming resources.

It is mostly static information. Still I do not see how
you would get away without any state.
[Wiehe, Ulrich (NSN - DE/Munich)] There is no need for the reporting node t=
o store and maintain information per reacting node because the reacting nod=
e actually tells within the request message all information the reporting n=
ode needs to know. The reporting node simply fetches the pre-calculated OLR=
 that matches the supported features of the reacting node as indicated in t=
he request and appends it to the answer.

> Furthermore,
> Why would the reacting node be interested in config changes of the report=
ing node?
> Isn't it so that the reacting node is only interested in OLR changes?

Sigh.. say the traffic abatement algorithm changes or new features
get added. Those have more impact than just OLR change.

- Jouni

>=20
> Ulrich
>=20
> -----Original Message-----
> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
> Sent: Tuesday, December 10, 2013 9:41 AM
> To: Wiehe, Ulrich (NSN - DE/Munich)
> Cc: dime@ietf.org
> Subject: Re: [Dime] OVLI: comments to 4.1
>=20
>=20
> On Dec 9, 2013, at 4:43 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:
>=20
>> But maintaining a specific state per reacting node is very resource cons=
uming for the (overloaded) reporting node. It is simpler and more efficient=
 to base any processing logic on actual information received in the request=
 rather than on information stored from previous communication.
>=20
> The "state" in a reporting node is merely the current configuration
> and a counter for sequence number. Hard to me see that as resource
> consuming function.
>=20
> And the earlier comment of mine is done from reacting node point
> of view, since it is more interested in the possible config changes
> in the reporting node (e.g. S6a is stateless application, configuration
> can change at any time).
>=20
> - Jouni
>=20
>=20
>>=20
>> Ulrich
>>=20
>> -----Original Message-----
>> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
>> Sent: Monday, December 09, 2013 2:25 PM
>> To: Wiehe, Ulrich (NSN - DE/Munich)
>> Cc: dime@ietf.org
>> Subject: Re: [Dime] OVLI: comments to 4.1
>>=20
>>=20
>> On Dec 9, 2013, at 3:13 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:
>>=20
>>> There is a fundamental difference:
>>> OLRs need to be stored, Feature-Vectors not.
>>=20
>> How come feature vector does not need to be stored? I do not
>> get that? I would set my implementation to a specific state
>> or mode based on the feature vector. When that changes I'd
>> like to know that. And then keep functioning based on that.
>>=20
>> - Jouni
>>=20
>>> When receiving an OLR you may want to know whether its worth the effort=
 to replace an already stored OLR with the received OLR.
>>> When receiving a Feature-Vector you just act on it.
>>>=20
>>> Ulrich=20
>>>=20
>>> -----Original Message-----
>>> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
>>> Sent: Monday, December 09, 2013 1:55 PM
>>> To: Wiehe, Ulrich (NSN - DE/Munich)
>>> Cc: dime@ietf.org
>>> Subject: Re: [Dime] OVLI: comments to 4.1
>>>=20
>>>=20
>>> In the same vein as folks wanted send OLRs with the new or old informat=
ion,
>>> the feature vector should behave in a same way IMHO. That implies there=
 are
>>> situations when a reception of the feature vector does not change anyth=
ing
>>> in an endpoint current behavior.
>>>=20
>>> - Jouni
>>>=20
>>> On Dec 9, 2013, at 2:47 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:
>>>=20
>>>> Isn't it so that the Feature-Vector (if present) always contains somet=
hing that an implementation needs to act upon?
>>>>=20
>>>> Ulrich
>>>>=20
>>>> -----Original Message-----
>>>> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
>>>> Sent: Monday, December 09, 2013 1:12 PM
>>>> To: Wiehe, Ulrich (NSN - DE/Munich)
>>>> Cc: dime@ietf.org
>>>> Subject: Re: [Dime] OVLI: comments to 4.1
>>>>=20
>>>> Ulrich,
>>>>=20
>>>> On Dec 6, 2013, at 3:03 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:
>>>>=20
>>>>> Hi Jouni,
>>>>>=20
>>>>> thank you for your response.
>>>>>=20
>>>>> With regard to 3)=20
>>>>> I still fail to see the usecase for Sequence-Number or TimeStamp with=
in OC-Feature-Vector. Please clarify.
>>>>=20
>>>> Since we also allow extending the OC-Feature-Vector beyond recognition=
,=20
>>>> it has good chances become a rather complex grouped AVP. In that conte=
xt
>>>> the Sequence-Number allows an easy and quick way to check if the featu=
re
>>>> vector contains something that an implementation needs to act upon.
>>>>=20
>>>>> With regard to 4)
>>>>> This was not obvious to me. (The obvious typo is the missing "of" bet=
ween "one" and "the").
>>>>=20
>>>> Ack. Fixed the missing 'of'.
>>>>=20
>>>> - Jouni
>>>>=20
>>>>>=20
>>>>> Best regards
>>>>> Ulrich
>>>>>=20
>>>>>=20
>>>>> -----Original Message-----
>>>>> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
>>>>> Sent: Friday, December 06, 2013 11:17 AM
>>>>> To: Wiehe, Ulrich (NSN - DE/Munich)
>>>>> Cc: dime@ietf.org
>>>>> Subject: Re: [Dime] OVLI: comments to 4.1
>>>>>=20
>>>>>=20
>>>>> On Dec 5, 2013, at 3:23 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:
>>>>>=20
>>>>>> Dear all,
>>>>>>=20
>>>>>> here are comments to clause 4.1:
>>>>>>=20
>>>>>> 1. The OC-Feature-Vector AVP is no longer a vector; the name of the =
AVP may be misleading. Proposal is to rename it to "OC-Supported-Features A=
VP"
>>>>>=20
>>>>> OK with me.
>>>>>=20
>>>>>> 2. The OC-Feature AVP is a vector of features. Proposal is to rename=
 it to "OC-Feature-Vector AVP"
>>>>>=20
>>>>> OK with me.
>>>>>=20
>>>>>> 3. The OC-Sequence-Number within OC-Feature-Vector only makes sense =
if the receiving reporting endpoint can determine the identity of the react=
ing endpoint (which is not necessarily the origin host (client),
>>>>>=20
>>>>> My original proposal was to have seqnr as a timestamp. Some folks arg=
ued
>>>>> it is no good and suggested seqnr. I still think time makes more sens=
e than
>>>>> seqnr.
>>>>>=20
>>>>>> it may be an agent and it may not always be the same agent), and if =
the reporting endpoint is required to store the OC-Feature-Vector / reactin=
g-endpoint-identity pair (which I think both is not required). The reportin=
g endpoint can base its processing logic on the actually received OC-Featur=
e-Vector value, no matter whether it is brand-new or old but stil valid. Pr=
oposal is to delete OC-Sequence-Number AVP from OC-Feature-Vector.
>>>>>=20
>>>>> Do not agree removing it.
>>>>>=20
>>>>>> 4. The text
>>>>>>=20
>>>>>> The reporting node that sends the answer also includes the OC-
>>>>>> Feature-Vector AVP that describe the capabilities it supports.  The
>>>>>> set of capabilities advertised by the reporting node depends on loca=
l
>>>>>> policies.  At least one the announced capabilities MUST match
>>>>>> mutually.  If there is no single matching capability the reacting
>>>>>> node MUST act as if it does not implement DOIC and cease inserting
>>>>>> any DOIC related AVPs into any Diameter messages with this specific
>>>>>> reacting node.
>>>>>>=20
>>>>>> is not clear.  Would the reporting node include the OC-Feature-Vecto=
r AVP in the answer only if there is at least one matching capability?=20
>>>>>=20
>>>>> Because then they have found a way to exchange something that both en=
ds
>>>>> know how to handle it.
>>>>>=20
>>>>>> Mandating the reacting node to cease for all time inserting OC-Featu=
re-Vector AVPs if it did not get back=20
>>>>>=20
>>>>> There is an obvious typo. It should say:
>>>>>=20
>>>>> policies.  At least one the announced capabilities MUST match
>>>>> mutually.  If there is no single matching capability the reporting
>>>>> node MUST act as if it does not implement DOIC and cease inserting
>>>>> any DOIC related AVPs into any Diameter messages with this specific
>>>>> reacting node.
>>>>>=20
>>>>> - JOuni
>>>>>=20
>>>>>=20
>>>>>> at least one match is also not ok. The request might have been a rea=
lm-type request (i.e. without Destination Host) and the reacting node canno=
t control whether subsequent requests will take the same path to the same r=
eporting node.
>>>>>> Even if the request contains a destination host the reacting node ca=
nnot know wether the reacting node's capabilities have been modified by the=
 time a subsequent request is sent.=20
>>>>>> Proposal is to keep only the first sentence and delete the rest.
>>>>>>=20
>>>>>> Ulrich
>>>>>>=20
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> DiME mailing list
>>>>>> DiME@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>>=20
>>>>=20
>>>=20
>>=20
>=20


From ulrich.wiehe@nsn.com  Tue Dec 10 05:01:00 2013
Return-Path: 
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 0B03E1AE0A1 for ; Tue, 10 Dec 2013 05:01:00 -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 GISX4uqlSgmi for ; Tue, 10 Dec 2013 05:00:58 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id E71591AE09F for ; Tue, 10 Dec 2013 05:00:57 -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 rBAD0oN8025435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 10 Dec 2013 14:00:50 +0100
Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rBAD0oSe028983 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Dec 2013 14:00:50 +0100
Received: from DEMUHTC007.nsn-intra.net (10.159.42.38) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 10 Dec 2013 14:00:49 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.152]) by DEMUHTC007.nsn-intra.net ([10.159.42.38]) with mapi id 14.03.0123.003; Tue, 10 Dec 2013 14:00:49 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Jouni Korhonen , Maria Cruz Bartolome 
Thread-Topic: [Dime] OVLI: comments to 4.3
Thread-Index: Ac7xzgT7drC0NV4iSVSEGFHx9aP+WQAl1Z0AAAfOC0AAEAghgAAWP9KAAGrqkFAAGQgrFAAWmq8AAAA0wAAAB1UlkA==
Date: Tue, 10 Dec 2013 13:00:49 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519E41A@DEMUMBX014.nsn-intra.net>
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DB1B@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D90006681519DD2A@DEMUMBX014.nsn-intra.net>   <5BCBA1FC2B7F0B4C9D935572D90006681519DF8A@DEMUMBX014.nsn-intra.net>  <2495B298-0B49-406A-884C-0C354D87948E@nostrum.com> <087A34937E64E74E848732CFF8354B9209739F8C@ESESSMB101.ericsson.se> <651FE189-F6B1-4807-938D-67C6B7841044@gmail.com>
In-Reply-To: <651FE189-F6B1-4807-938D-67C6B7841044@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.112]
Content-Type: text/plain; charset="us-ascii"
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: 1393
X-purgate-ID: 151667::1386680450-00001A6F-7F67E5EB/0-0/0-0
Cc: Ben Campbell , "dime@ietf.org" 
Subject: Re: [Dime] OVLI: comments to 4.3
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Dec 2013 13:01:00 -0000

MCruz, Jouni,

> and per client


my understanding was that the differentiation _per_client_ was a requiremen=
t from 3GPP that is not covered by the DIOC base version and that requires =
an extension.

Note that the main problem is to cover cases where a single DOIC-supporting=
 client performs overload mitigation on behalf of two different non-support=
ing clients.

Ulrich



-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Jouni Korhonen
Sent: Tuesday, December 10, 2013 11:18 AM
To: Maria Cruz Bartolome
Cc: Ben Campbell; dime@ietf.org
Subject: Re: [Dime] OVLI: comments to 4.3

>=20
>=20
> [MCruz] My understanding is that validity-period should be adjusted by re=
porting node depending on their expectations on traffic reduction by one cl=
ient. Therefore, it should be updated towards _each_ client, based on repor=
ting node expectations on _each_ client traffic reduction. I understand it =
does not mean (necessarily) that validity period has to be updated each tim=
e a message is sent, but it will depend on each overload situation and per =
client.
>=20

This is my understanding as well (and how the text currently is written.. o=
r=20
is meant to be read ;)

- Jouni

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

From srdonovan@usdonovans.com  Tue Dec 10 05:25:18 2013
Return-Path: 
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 1243C1AE091 for ; Tue, 10 Dec 2013 05:25:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.12
X-Spam-Level: 
X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no
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 pqz9WLSgHZOc for ; Tue, 10 Dec 2013 05:25:16 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id B76D21AE062 for ; Tue, 10 Dec 2013 05:25:16 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:58507 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1VqNJE-0004Sr-11; Tue, 10 Dec 2013 05:25:09 -0800
Message-ID: <52A71632.7040806@usdonovans.com>
Date: Tue, 10 Dec 2013 07:25:06 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: Ben Campbell 
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DB1B@DEMUMBX014.nsn-intra.net>  <52A5E902.20605@usdonovans.com> <7475B713-1104-4791-96B1-CE97632A0D69@nostrum.com>
In-Reply-To: <7475B713-1104-4791-96B1-CE97632A0D69@nostrum.com>
Content-Type: multipart/alternative; boundary="------------090305030900080607050906"
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com
Cc: "dime@ietf.org list" 
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Dec 2013 13:25:18 -0000

This is a multi-part message in MIME format.
--------------090305030900080607050906
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

inline

On 12/9/13 4:34 PM, Ben Campbell wrote:
> On Dec 9, 2013, at 10:00 AM, Steve Donovan  wrote:
>
>> Jouni,
>>
>> I propose that we keep the name OC-Sequence-Number but that we use the Time type for OC-Sequence-Number.  It is misleading and potentially confusing to call it OC-Time-Stamp.  
>>
> I could live with that, although I would rather just define the expected properties of the sequence number, and leave the implementation up to the implementor. I assume your reasoning for not calling it a timestamp is that you do not want people to try to use it as a time base reference. If so, then we don't require any connection to a clock. We just need it to be monotonically increasing.
>
>> We might consider expanding on the format of the AVP to make it something like Session-ID, where it is a concatenation of the Diameter-ID of the generating node and a timestamp.  This might help the reacting node keep track of which sequence number it has received.
>>
> Do we need a uniqueness across multiple nodes property? If so, why?
Strictly speaking, no.  The thought was to make it similar to session-id
and potentially make it easier for the reacting node to keep
differentiate sequence numbers from different reporting nodes.
>
>> Steve
>>
>> On 12/9/13 5:37 AM, Jouni Korhonen wrote:
>>> Folks
>>>
>>> Could we conclude on the sequence number vs. time stamp vs. something else?
>>> We got more important places to spend our energy than this ;)
>>>
>>> My proposal is the following (based on the original pre-00 design):
>>>
>>> o We change the OC-Sequence-Number to OC-Time-Stamp in all occurrences
>>>   in the -01.
>>> o We use RFC6733 Time type for the OC-Time-Stamp. RFC6733 gives us
>>>   already exact definition how to handle the AVP.
>>> o Define that the OC-Time-Stamp is the time of the creation of the 
>>>   "original" AVP within whose context the time stamp is present.
>>> o The OC-Time-Stamp AVP uniqueness is still considered to be in scope
>>>   of the communicating endpoints.
>>> o The time stamp can be used to quickly determine if the content of
>>>   the encapsulating AVP context has changed (among other properties).
>>>   This would be useful specifically in the future when the encapsulating
>>>   grouped AVPs  grow in size and functionality.
>>>
>>>
>>> - Jouni
>>>
>>> _______________________________________________
>>> 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
>


--------------090305030900080607050906
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    inline

      

    
    
On 12/9/13 4:34 PM, Ben Campbell wrote:

    

    

      
On Dec 9, 2013, at 10:00 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:



      

        
Jouni,

I propose that we keep the name OC-Sequence-Number but that we use the Time type for OC-Sequence-Number.  It is misleading and potentially confusing to call it OC-Time-Stamp.  



      

      
I could live with that, although I would rather just define the expected properties of the sequence number, and leave the implementation up to the implementor. I assume your reasoning for not calling it a timestamp is that you do not want people to try to use it as a time base reference. If so, then we don't require any connection to a clock. We just need it to be monotonically increasing.



      

        
We might consider expanding on the format of the AVP to make it something like Session-ID, where it is a concatenation of the Diameter-ID of the generating node and a timestamp.  This might help the reacting node keep track of which sequence number it has received.



      

      
Do we need a uniqueness across multiple nodes property? If so, why?

    

    Strictly speaking, no.  The thought was to make it similar to
    session-id and potentially make it easier for the reacting node to
    keep differentiate sequence numbers from different reporting nodes.

    

      



      

        
Steve

On 12/9/13 5:37 AM, Jouni Korhonen wrote:


        

          
Folks

Could we conclude on the sequence number vs. time stamp vs. something else?
We got more important places to spend our energy than this ;)

My proposal is the following (based on the original pre-00 design):

o We change the OC-Sequence-Number to OC-Time-Stamp in all occurrences
  in the -01.
o We use RFC6733 Time type for the OC-Time-Stamp. RFC6733 gives us
  already exact definition how to handle the AVP.
o Define that the OC-Time-Stamp is the time of the creation of the 
  "original" AVP within whose context the time stamp is present.
o The OC-Time-Stamp AVP uniqueness is still considered to be in scope
  of the communicating endpoints.
o The time stamp can be used to quickly determine if the content of
  the encapsulating AVP context has changed (among other properties).
  This would be useful specifically in the future when the encapsulating
  grouped AVPs  grow in size and functionality.


- Jouni

_______________________________________________
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


      

      



    

    

  


--------------090305030900080607050906--

From ulrich.wiehe@nsn.com  Tue Dec 10 06:31:57 2013
Return-Path: 
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 362661ADF7D for ; Tue, 10 Dec 2013 06:31:57 -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 2fTB5C0jiGKx for ; Tue, 10 Dec 2013 06:31:54 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id C83B51A1F65 for ; Tue, 10 Dec 2013 06:31:53 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rBAEVk78024283 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 10 Dec 2013 15:31:46 +0100
Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rBAEViLU030989 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Dec 2013 15:31:45 +0100
Received: from DEMUHTC010.nsn-intra.net (10.159.42.41) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 10 Dec 2013 15:31:44 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.152]) by DEMUHTC010.nsn-intra.net ([10.159.42.41]) with mapi id 14.03.0123.003; Tue, 10 Dec 2013 15:31:44 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Jouni Korhonen , Ben Campbell , "dime@ietf.org list" , Steve Donovan 
Thread-Topic: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments	to 4.3
Thread-Index: AQHO9S7f8z1v638NLUKtrE/MnydsbJpM956AgAB0hdA=
Date: Tue, 10 Dec 2013 14:31:43 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519E476@DEMUMBX014.nsn-intra.net>
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DB1B@DEMUMBX014.nsn-intra.net>  <52A5E902.20605@usdonovans.com> <7475B713-1104-4791-96B1-CE97632A0D69@nostrum.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.112]
Content-Type: text/plain; charset="us-ascii"
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: 5374
X-purgate-ID: 151667::1386685906-00000661-304AF6EA/0-0/0-0
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments	to 4.3
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Dec 2013 14:31:57 -0000

Jouni,

1. I find the texts
a) "The sequence number ... does not need to be monotonically increasing"
and=20
b) "...the new sequence number MUST be greater or equal than the old sequen=
ce number..."
contradicting.
Can you please clarify.

2. The expected behaviour when receiving an out-of-sequence sequence number=
 within OC-OLR is described in 4.3:
   "The receiver SHOULD discard an OC-OLR AVP with a sequence number that i=
s less than previously received one."
I don't find this very robust. Once a higher sequence number (received erro=
neously by mistake) is accepted you cannot (easily) recover.

3. The expected behaviour when receiving an out-of-sequence sequence number=
 within the OC-Supported-Features AVP is not described. What is the intenti=
on here?

Ulrich

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Jouni Korhonen
Sent: Tuesday, December 10, 2013 8:28 AM
To: Ben Campbell; dime@ietf.org list; Steve Donovan
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comment=
s to 4.3


Fine.. lets define then the sequence number semantics. Basic
unsigned integer math. The text proposal is the following:

4.4.  OC-Sequence-Number AVP

   The OC-Sequence-Number AVP (AVP code TBD3) is type of Unsigned64.
   Its usage in the context of the overload control is described in
   Sections 4.1 and 4.3.

   From the functionality point of view, the OC-Sequence-Number AVP
   MUST be used as a non-volatile increasing counter between two
   overload control endpoints.  The sequence number is only required
   to be unique between two overload control endpoints and does not
   need to be monotonically increasing.

   When comparing two sequence numbers, the new sequence number MUST
   be greater or equal than the old sequence number within a window
   that is half of the size of the maximum sequence number. This
   allows a simple handling of the sequence number overflow using
   unsigned integer arithmeticf:

     #define WINDOW 0x8000000000000000ULL
=20
     bool verify_seqnum( uint64_t newsn, uint64_t oldsn ) {
         if (newsn - oldsn <=3D WINDOW)
             // newsn >=3D oldsn
             return true;  =20
         } else
             // outside window or newsn < oldsn
             return false; =20
         }
     }



The above should even work is someone shovels NTP times into
sequence numbers with a blind typecasting.

- Jouni

On Dec 10, 2013, at 12:34 AM, Ben Campbell  wrote:

>=20
> On Dec 9, 2013, at 10:00 AM, Steve Donovan  wro=
te:
>=20
>> Jouni,
>>=20
>> I propose that we keep the name OC-Sequence-Number but that we use the T=
ime type for OC-Sequence-Number.  It is misleading and potentially confusin=
g to call it OC-Time-Stamp. =20
>>=20
>=20
> I could live with that, although I would rather just define the expected =
properties of the sequence number, and leave the implementation up to the i=
mplementor. I assume your reasoning for not calling it a timestamp is that =
you do not want people to try to use it as a time base reference. If so, th=
en we don't require any connection to a clock. We just need it to be monoto=
nically increasing.
>=20
>> We might consider expanding on the format of the AVP to make it somethin=
g like Session-ID, where it is a concatenation of the Diameter-ID of the ge=
nerating node and a timestamp.  This might help the reacting node keep trac=
k of which sequence number it has received.
>>=20
>=20
> Do we need a uniqueness across multiple nodes property? If so, why?
>=20
>> Steve
>>=20
>> On 12/9/13 5:37 AM, Jouni Korhonen wrote:
>>> Folks
>>>=20
>>> Could we conclude on the sequence number vs. time stamp vs. something e=
lse?
>>> We got more important places to spend our energy than this ;)
>>>=20
>>> My proposal is the following (based on the original pre-00 design):
>>>=20
>>> o We change the OC-Sequence-Number to OC-Time-Stamp in all occurrences
>>>  in the -01.
>>> o We use RFC6733 Time type for the OC-Time-Stamp. RFC6733 gives us
>>>  already exact definition how to handle the AVP.
>>> o Define that the OC-Time-Stamp is the time of the creation of the=20
>>>  "original" AVP within whose context the time stamp is present.
>>> o The OC-Time-Stamp AVP uniqueness is still considered to be in scope
>>>  of the communicating endpoints.
>>> o The time stamp can be used to quickly determine if the content of
>>>  the encapsulating AVP context has changed (among other properties).
>>>  This would be useful specifically in the future when the encapsulating
>>>  grouped AVPs  grow in size and functionality.
>>>=20
>>>=20
>>> - Jouni
>>>=20
>>> _______________________________________________
>>> DiME mailing list
>>>=20
>>> DiME@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dime
>>>=20
>>>=20
>>>=20
>>=20
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>=20
> _______________________________________________
> 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

From ulrich.wiehe@nsn.com  Tue Dec 10 06:43:58 2013
Return-Path: 
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 6BA4C1ADF7D for ; Tue, 10 Dec 2013 06:43:58 -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 69yDnSnNbx8f for ; Tue, 10 Dec 2013 06:43:56 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 64D951ADBD1 for ; Tue, 10 Dec 2013 06:43:55 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rBAEhnAo016894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 10 Dec 2013 15:43:49 +0100
Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rBAEhn9Z025800 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Dec 2013 15:43:49 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.152]) by DEMUHTC002.nsn-intra.net ([10.159.42.33]) with mapi id 14.03.0123.003; Tue, 10 Dec 2013 15:43:49 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Steve Donovan , Ben Campbell 
Thread-Topic: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3
Thread-Index: AQHO9atFkoRa3B+doUWxxFMNrNdzoppNfy7w
Date: Tue, 10 Dec 2013 14:43:48 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519E48F@DEMUMBX014.nsn-intra.net>
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DB1B@DEMUMBX014.nsn-intra.net>  <52A5E902.20605@usdonovans.com> <7475B713-1104-4791-96B1-CE97632A0D69@nostrum.com> <52A71632.7040806@usdonovans.com>
In-Reply-To: <52A71632.7040806@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.112]
Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D90006681519E48FDEMUMBX014nsnin_"
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: 12786
X-purgate-ID: 151667::1386686629-00000661-CF7B9648/0-0/0-0
Cc: "dime@ietf.org list" 
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Dec 2013 14:43:58 -0000

--_000_5BCBA1FC2B7F0B4C9D935572D90006681519E48FDEMUMBX014nsnin_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Steve,

how does this work in scenarios where a non supporting client C sends some =
requests via the DOIC supporting agent A1 to the server S and other request=
s via a different DOIC supporting agent A2 to the same server S?

Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Tuesday, December 10, 2013 2:25 PM
To: Ben Campbell
Cc: dime@ietf.org list
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comment=
s to 4.3

inline
On 12/9/13 4:34 PM, Ben Campbell wrote:



On Dec 9, 2013, at 10:00 AM, Steve Donovan  wrote:



Jouni,



I propose that we keep the name OC-Sequence-Number but that we use the Time=
 type for OC-Sequence-Number.  It is misleading and potentially confusing t=
o call it OC-Time-Stamp.





I could live with that, although I would rather just define the expected pr=
operties of the sequence number, and leave the implementation up to the imp=
lementor. I assume your reasoning for not calling it a timestamp is that yo=
u do not want people to try to use it as a time base reference. If so, then=
 we don't require any connection to a clock. We just need it to be monotoni=
cally increasing.



We might consider expanding on the format of the AVP to make it something l=
ike Session-ID, where it is a concatenation of the Diameter-ID of the gener=
ating node and a timestamp.  This might help the reacting node keep track o=
f which sequence number it has received.





Do we need a uniqueness across multiple nodes property? If so, why?
Strictly speaking, no.  The thought was to make it similar to session-id an=
d potentially make it easier for the reacting node to keep differentiate se=
quence numbers from different reporting nodes.






Steve



On 12/9/13 5:37 AM, Jouni Korhonen wrote:

Folks



Could we conclude on the sequence number vs. time stamp vs. something else?

We got more important places to spend our energy than this ;)



My proposal is the following (based on the original pre-00 design):



o We change the OC-Sequence-Number to OC-Time-Stamp in all occurrences

  in the -01.

o We use RFC6733 Time type for the OC-Time-Stamp. RFC6733 gives us

  already exact definition how to handle the AVP.

o Define that the OC-Time-Stamp is the time of the creation of the

  "original" AVP within whose context the time stamp is present.

o The OC-Time-Stamp AVP uniqueness is still considered to be in scope

  of the communicating endpoints.

o The time stamp can be used to quickly determine if the content of

  the encapsulating AVP context has changed (among other properties).

  This would be useful specifically in the future when the encapsulating

  grouped AVPs  grow in size and functionality.





- Jouni



_______________________________________________

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






--_000_5BCBA1FC2B7F0B4C9D935572D90006681519E48FDEMUMBX014nsnin_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Steve,


 =
;


how does t=
his work in scenarios where a non supporting client C sends some requests v=
ia the DOIC supporting agent A1 to the server S and other
 requests via a different DOIC supporting agent A2 to the same server S?


 =
;


Ulrich


 =
;






From:=
 DiME [mailto:dime-b=
ounces@ietf.org]
On Behalf Of ext Steve Donovan

Sent: Tuesday, December 10, 2013 2:25 PM

To: Ben Campbell

Cc: dime@ietf.org list

Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: =
comments to 4.3






 


inline




On 12/9/13 4:34 PM, Ben Campbell wrote:





 


On Dec 9, 2013, at 10:00 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:

 




Jouni,


 


I propose that we keep the name OC-Sequence-Number but that we use the=
 Time type for OC-Sequence-Number.  It is misleading and potentially c=
onfusing to call it OC-Time-Stamp.  


 




 


I could live with that, although I would rather just define the expect=
ed properties of the sequence number, and leave the implementation up to th=
e implementor. I assume your reasoning for not calling it a timestamp is th=
at you do not want people to try to use it as a time base reference. If so,=
 then we don't require any connection to a clock. We just need it to be mon=
otonically increasing.


 




We might consider expanding on the format of the AVP to make it someth=
ing like Session-ID, where it is a concatenation of the Diameter-ID of the =
generating node and a timestamp.  This might help the reacting node ke=
ep track of which sequence number it has received.


 




 


Do we need a uniqueness across multiple nodes property? If so, why?




Strictly speaking, no.  The thought was to make=
 it similar to session-id and potentially make it easier for the reacting n=
ode to keep differentiate sequence numbers from different reporting nodes.<=
br>





 


 




Steve


 


On 12/9/13 5:37 AM, Jouni Korhonen wrote:




Folks


 


Could we conclude on the sequence number vs. time stamp vs. something =
else?


We got more important places to spend our energy than this ;)


 


My proposal is the following (based on the original pre-00 design):


 


o We change the OC-Sequence-Number to OC-Time-Stamp in all occurrences=



  in the -01.


o We use RFC6733 Time type for the OC-Time-Stamp. RFC6733 gives us


  already exact definition how to handle the AVP.

o Define that the OC-Time-Stamp is the time of the creation of the 


  "original" AVP within whose context the time sta=
mp is present.


o The OC-Time-Stamp AVP uniqueness is still considered to be in scope<=
o:p>


  of the communicating endpoints.


o The time stamp can be used to quickly determine if the content of


  the encapsulating AVP context has changed (among other properti=
es).


  This would be useful specifically in the future when the encaps=
ulating


  grouped AVPs  grow in size and functionality.

 


 


- Jouni


 


_______________________________________________


DiME mailing list


 


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 


 


 




 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime




 


 


 






--_000_5BCBA1FC2B7F0B4C9D935572D90006681519E48FDEMUMBX014nsnin_--

From ben@nostrum.com  Tue Dec 10 07:03:22 2013
Return-Path: 
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 1B30C1AE02F for ; Tue, 10 Dec 2013 07:03:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Level: 
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no
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 ESycieSzE6nn for ; Tue, 10 Dec 2013 07:03:20 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4A5261ADF90 for ; Tue, 10 Dec 2013 07:03:20 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rBAF37jn083655 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 10 Dec 2013 09:03:08 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Ben Campbell 
In-Reply-To: 
Date: Tue, 10 Dec 2013 09:03:07 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <46347965-5D5B-4EE9-A4DE-AB4C6D200973@nostrum.com>
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DB1B@DEMUMBX014.nsn-intra.net>  <52A5E902.20605@usdonovans.com> <7475B713-1104-4791-96B1-CE97632A0D69@nostrum.com> 
To: Jouni Korhonen 
X-Mailer: Apple Mail (2.1822)
Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism)
Cc: "dime@ietf.org list" 
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Dec 2013 15:03:22 -0000

I think that's close to correct. A couple of comments:

On Dec 10, 2013, at 1:28 AM, Jouni Korhonen  =
wrote:

>=20
> Fine.. lets define then the sequence number semantics. Basic
> unsigned integer math. The text proposal is the following:
>=20
> 4.4.  OC-Sequence-Number AVP
>=20
>   The OC-Sequence-Number AVP (AVP code TBD3) is type of Unsigned64.
>   Its usage in the context of the overload control is described in
>   Sections 4.1 and 4.3.
>=20
>   =46rom the functionality point of view, the OC-Sequence-Number AVP
>   MUST be used as a non-volatile increasing counter between two
>   overload control endpoints.  The sequence number is only required
>   to be unique between two overload control endpoints and does not
>   need to be monotonically increasing.

I think "increasing" and "monotonically increasing" mean the same thing. =
I believe the term we are looking for is "strictly increasing".

>=20
>   When comparing two sequence numbers, the new sequence number MUST
>   be greater or equal than the old sequence number within a window
>   that is half of the size of the maximum sequence number. This
>   allows a simple handling of the sequence number overflow using
>   unsigned integer arithmeticf:

The MUST probably belongs in the generation side, not the comparison =
side. For comparison, we can say something like "a new sequence number =
is greater than a previous one if the new sequence number..."

>=20
>     #define WINDOW 0x8000000000000000ULL
>=20
>     bool verify_seqnum( uint64_t newsn, uint64_t oldsn ) {
>         if (newsn - oldsn <=3D WINDOW)
>             // newsn >=3D oldsn
>             return true;  =20
>         } else
>             // outside window or newsn < oldsn
>             return false; =20
>         }
>     }
>=20
>=20
>=20
> The above should even work is someone shovels NTP times into
> sequence numbers with a blind typecasting.
>=20
> - Jouni
>=20
> On Dec 10, 2013, at 12:34 AM, Ben Campbell  wrote:
>=20
>>=20
>> On Dec 9, 2013, at 10:00 AM, Steve Donovan  =
wrote:
>>=20
>>> Jouni,
>>>=20
>>> I propose that we keep the name OC-Sequence-Number but that we use =
the Time type for OC-Sequence-Number.  It is misleading and potentially =
confusing to call it OC-Time-Stamp. =20
>>>=20
>>=20
>> I could live with that, although I would rather just define the =
expected properties of the sequence number, and leave the implementation =
up to the implementor. I assume your reasoning for not calling it a =
timestamp is that you do not want people to try to use it as a time base =
reference. If so, then we don't require any connection to a clock. We =
just need it to be monotonically increasing.
>>=20
>>> We might consider expanding on the format of the AVP to make it =
something like Session-ID, where it is a concatenation of the =
Diameter-ID of the generating node and a timestamp.  This might help the =
reacting node keep track of which sequence number it has received.
>>>=20
>>=20
>> Do we need a uniqueness across multiple nodes property? If so, why?
>>=20
>>> Steve
>>>=20
>>> On 12/9/13 5:37 AM, Jouni Korhonen wrote:
>>>> Folks
>>>>=20
>>>> Could we conclude on the sequence number vs. time stamp vs. =
something else?
>>>> We got more important places to spend our energy than this ;)
>>>>=20
>>>> My proposal is the following (based on the original pre-00 design):
>>>>=20
>>>> o We change the OC-Sequence-Number to OC-Time-Stamp in all =
occurrences
>>>> in the -01.
>>>> o We use RFC6733 Time type for the OC-Time-Stamp. RFC6733 gives us
>>>> already exact definition how to handle the AVP.
>>>> o Define that the OC-Time-Stamp is the time of the creation of the=20=

>>>> "original" AVP within whose context the time stamp is present.
>>>> o The OC-Time-Stamp AVP uniqueness is still considered to be in =
scope
>>>> of the communicating endpoints.
>>>> o The time stamp can be used to quickly determine if the content of
>>>> the encapsulating AVP context has changed (among other properties).
>>>> This would be useful specifically in the future when the =
encapsulating
>>>> grouped AVPs  grow in size and functionality.
>>>>=20
>>>>=20
>>>> - Jouni
>>>>=20
>>>> _______________________________________________
>>>> DiME mailing list
>>>>=20
>>>> DiME@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>=20
>>>>=20
>>>>=20
>>>=20
>>> _______________________________________________
>>> DiME mailing list
>>> DiME@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dime
>>=20
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>=20


From jouni.nospam@gmail.com  Tue Dec 10 13:31:27 2013
Return-Path: 
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 08A611AD73F for ; Tue, 10 Dec 2013 13:31:27 -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 adN14OsRfBpI for ; Tue, 10 Dec 2013 13:31:23 -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 C70111AE070 for ; Tue, 10 Dec 2013 13:31:22 -0800 (PST)
Received: by mail-la0-f47.google.com with SMTP id ep20so3150804lab.20 for ; Tue, 10 Dec 2013 13:31:16 -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=HxCayBRFz+9Spb0quAhldVJeiJ9qjDiHvStpbOF5mTE=; b=WkYsjj9joHG19xTOY7Ro6a/SfR4168S+mNFRPchaTTiMz6uuHNKHwA2K45m0XqZjbe kPVF0PwiIR+f2I7OHklV8ZktLpm8CiMpbh0M4N9QLXkyEXBUy++9WMJnq0PWR9x7Ag0F qpq9dJIZUHg0QNqCb5MjvRLgUzQzNYYiBJRKeuWZbDiWZiaTgqRumO+1jIZfelhc2jRi KaW8eHsQNO4pRlVwYBLOsUkzQNoE55yNqvHzStRMxKmILNEGRc7RtJx4RdJicTg8sbDq sW5H451xAX8ND0yvXT7F6wlnb1zBnOz1HvtC3PLdlRHIQ/4CPg4+IjcUA8tgAYV2ucep 2R+A==
X-Received: by 10.152.4.230 with SMTP id n6mr9359113lan.1.1386711076732; Tue, 10 Dec 2013 13:31:16 -0800 (PST)
Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id ld10sm24290813lab.8.2013.12.10.13.31.12 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Dec 2013 13:31:12 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jouni Korhonen 
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681519E476@DEMUMBX014.nsn-intra.net>
Date: Tue, 10 Dec 2013 23:31:13 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <1CD20507-B0FE-4367-804A-B831734CF060@gmail.com>
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DB1B@DEMUMBX014.nsn-intra.net>  <52A5E902.20605@usdonovans.com> <7475B713-1104-4791-96B1-CE97632A0D69@nostrum.com>  <5BCBA1FC2B7F0B4C9D935572D90006681519E476@DEMUMBX014.nsn-intra.net>
To: "Wiehe, Ulrich (NSN - DE/Munich)" 
X-Mailer: Apple Mail (2.1510)
Cc: Ben Campbell , "dime@ietf.org list" 
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Dec 2013 21:31:27 -0000

Ulrich,

On Dec 10, 2013, at 4:31 PM, "Wiehe, Ulrich (NSN - DE/Munich)" =
 wrote:

> Jouni,
>=20
> 1. I find the texts
> a) "The sequence number ... does not need to be monotonically =
increasing"
> and=20

Means the delta from old-seqno to new-seqno can be any non-negative =
integer
(within the given limits) not something fixed step/delta (like +1). As =
long as
"new-seqno >=3D old-seqno" holds we are fine.

> b) "...the new sequence number MUST be greater or equal than the old =
sequence number..."
> contradicting.
> Can you please clarify.

See above. (mind the overflow case)

> 2. The expected behaviour when receiving an out-of-sequence sequence =
number within OC-OLR is described in 4.3:
>   "The receiver SHOULD discard an OC-OLR AVP with a sequence number =
that is less than previously received one."
> I don't find this very robust. Once a higher sequence number (received =
erroneously by mistake) is accepted you cannot (easily) recover.

I find it more robust in a sense that I should not care about stale old =
information.
However, since we are piggybacking (by popular demand) we have little =
room for seqno
re-sync negotiation.

What is the mistake you refer here? A misbehaving implementation? In =
that case, it=20
deserves to get a manual intervention once figured out by admins =
checking alarms and
logs. If the mistake is due other things, like endpoints being out of =
sync, we currently
have no written down mechanism to survive that.

> 3. The expected behaviour when receiving an out-of-sequence sequence =
number within the OC-Supported-Features AVP is not described. What is =
the intention here?

No intention. Just a sloppy specification. You are right that something =
needs to be
done & clarified here. (again the semantics of Time would nice..)

I'll propose something. Others should too ;)

- Jouni

>=20
> Ulrich
>=20
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Jouni =
Korhonen
> Sent: Tuesday, December 10, 2013 8:28 AM
> To: Ben Campbell; dime@ietf.org list; Steve Donovan
> Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: =
comments to 4.3
>=20
>=20
> Fine.. lets define then the sequence number semantics. Basic
> unsigned integer math. The text proposal is the following:
>=20
> 4.4.  OC-Sequence-Number AVP
>=20
>   The OC-Sequence-Number AVP (AVP code TBD3) is type of Unsigned64.
>   Its usage in the context of the overload control is described in
>   Sections 4.1 and 4.3.
>=20
>   =46rom the functionality point of view, the OC-Sequence-Number AVP
>   MUST be used as a non-volatile increasing counter between two
>   overload control endpoints.  The sequence number is only required
>   to be unique between two overload control endpoints and does not
>   need to be monotonically increasing.
>=20
>   When comparing two sequence numbers, the new sequence number MUST
>   be greater or equal than the old sequence number within a window
>   that is half of the size of the maximum sequence number. This
>   allows a simple handling of the sequence number overflow using
>   unsigned integer arithmeticf:
>=20
>     #define WINDOW 0x8000000000000000ULL
>=20
>     bool verify_seqnum( uint64_t newsn, uint64_t oldsn ) {
>         if (newsn - oldsn <=3D WINDOW)
>             // newsn >=3D oldsn
>             return true;  =20
>         } else
>             // outside window or newsn < oldsn
>             return false; =20
>         }
>     }
>=20
>=20
>=20
> The above should even work is someone shovels NTP times into
> sequence numbers with a blind typecasting.
>=20
> - Jouni
>=20
> On Dec 10, 2013, at 12:34 AM, Ben Campbell  wrote:
>=20
>>=20
>> On Dec 9, 2013, at 10:00 AM, Steve Donovan  =
wrote:
>>=20
>>> Jouni,
>>>=20
>>> I propose that we keep the name OC-Sequence-Number but that we use =
the Time type for OC-Sequence-Number.  It is misleading and potentially =
confusing to call it OC-Time-Stamp. =20
>>>=20
>>=20
>> I could live with that, although I would rather just define the =
expected properties of the sequence number, and leave the implementation =
up to the implementor. I assume your reasoning for not calling it a =
timestamp is that you do not want people to try to use it as a time base =
reference. If so, then we don't require any connection to a clock. We =
just need it to be monotonically increasing.
>>=20
>>> We might consider expanding on the format of the AVP to make it =
something like Session-ID, where it is a concatenation of the =
Diameter-ID of the generating node and a timestamp.  This might help the =
reacting node keep track of which sequence number it has received.
>>>=20
>>=20
>> Do we need a uniqueness across multiple nodes property? If so, why?
>>=20
>>> Steve
>>>=20
>>> On 12/9/13 5:37 AM, Jouni Korhonen wrote:
>>>> Folks
>>>>=20
>>>> Could we conclude on the sequence number vs. time stamp vs. =
something else?
>>>> We got more important places to spend our energy than this ;)
>>>>=20
>>>> My proposal is the following (based on the original pre-00 design):
>>>>=20
>>>> o We change the OC-Sequence-Number to OC-Time-Stamp in all =
occurrences
>>>> in the -01.
>>>> o We use RFC6733 Time type for the OC-Time-Stamp. RFC6733 gives us
>>>> already exact definition how to handle the AVP.
>>>> o Define that the OC-Time-Stamp is the time of the creation of the=20=

>>>> "original" AVP within whose context the time stamp is present.
>>>> o The OC-Time-Stamp AVP uniqueness is still considered to be in =
scope
>>>> of the communicating endpoints.
>>>> o The time stamp can be used to quickly determine if the content of
>>>> the encapsulating AVP context has changed (among other properties).
>>>> This would be useful specifically in the future when the =
encapsulating
>>>> grouped AVPs  grow in size and functionality.
>>>>=20
>>>>=20
>>>> - Jouni
>>>>=20
>>>> _______________________________________________
>>>> DiME mailing list
>>>>=20
>>>> DiME@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>=20
>>>>=20
>>>>=20
>>>=20
>>> _______________________________________________
>>> DiME mailing list
>>> DiME@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dime
>>=20
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From ben@nostrum.com  Tue Dec 10 13:36:29 2013
Return-Path: 
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 A28071AE06B for ; Tue, 10 Dec 2013 13:36:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Level: 
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no
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 h5Xf_0W959J4 for ; Tue, 10 Dec 2013 13:36:28 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id AFF351ADFF6 for ; Tue, 10 Dec 2013 13:36:28 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rBALaHsQ001664 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 10 Dec 2013 15:36:18 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Ben Campbell 
In-Reply-To: <1CD20507-B0FE-4367-804A-B831734CF060@gmail.com>
Date: Tue, 10 Dec 2013 15:36:16 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DB1B@DEMUMBX014.nsn-intra.net>  <52A5E902.20605@usdonovans.com> <7475B713-1104-4791-96B1-CE97632A0D69@nostrum.com>  <5BCBA1FC2B7F0B4C9D935572D90006681519E476@DEMUMBX014.nsn-intra.net> <1CD20507-B0FE-4367-804A-B831734CF060@gmail.com>
To: Jouni Korhonen 
X-Mailer: Apple Mail (2.1822)
Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism)
Cc: "dime@ietf.org list" 
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Dec 2013 21:36:29 -0000

On Dec 10, 2013, at 3:31 PM, Jouni Korhonen  =
wrote:

>> Jouni,
>>=20
>> 1. I find the texts
>> a) "The sequence number ... does not need to be monotonically =
increasing"
>> and=20
>=20
> Means the delta from old-seqno to new-seqno can be any non-negative =
integer
> (within the given limits) not something fixed step/delta (like +1). As =
long as
> "new-seqno >=3D old-seqno" holds we are fine.

My understanding is that "new-seqno >=3D old-seqno" is the _definition_ =
of monotonically increasing.

But don't we want "new-seqno > old-seqno", that is, increase by a =
positive integer? (Assuming we are talking about a new OLR, not merely a =
copy of an old one.)


From jouni.nospam@gmail.com  Tue Dec 10 13:46:33 2013
Return-Path: 
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 23DB81AE0EC for ; Tue, 10 Dec 2013 13:46:33 -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 yTO6dusNHxTu for ; Tue, 10 Dec 2013 13:46:30 -0800 (PST)
Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA1D1AE04B for ; Tue, 10 Dec 2013 13:46:29 -0800 (PST)
Received: by mail-la0-f42.google.com with SMTP id ec20so3189617lab.29 for ; Tue, 10 Dec 2013 13:46:23 -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=uJZl4yFAJWfNhnifdD10Gv4kOaDYEI29wmG7DYrDUXI=; b=o10ZwXRm3XUtelZFTh0e58qEa6ALZQTIjMbBAjWU0lnDjk/2JTM0Panbr04vnFit1z XpK10dnSlUYp0pAdQr3E+7eZqSI+kOpVYq0c0sN6oAdGpueKJlHagQ/9klZOIGAeLe10 S6eQllX7mcMAR7nx2RLViYLpMg5amk+mWSpVDt6DFcaZIoJ8QGWVQTNY7nnk2R+m1VAA Gjb5GGc8L/88Hl5fbEK6/SntTKEOA7elJxWDE9fuomjRYHtvywUu4YFqNBvDcjNseBrS w5d8DWgwR2MzryzQGejYQrGSK+OoUIVap+Rgtiyxz85SRHXObZLEH9gMhYu09Smxkqur d5tQ==
X-Received: by 10.152.115.230 with SMTP id jr6mr6475803lab.45.1386711983628; Tue, 10 Dec 2013 13:46:23 -0800 (PST)
Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id ld10sm24361455lab.8.2013.12.10.13.46.19 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Dec 2013 13:46:19 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jouni Korhonen 
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681519E3C4@DEMUMBX014.nsn-intra.net>
Date: Tue, 10 Dec 2013 23:46:20 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <0CDBF4BB-4E38-41D6-A5E2-9218FFEFEA43@gmail.com>
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DA3E@DEMUMBX014.nsn-intra.net> <6CDCFC84-3048-40B9-91A4-1451FCC65F60@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519DCE5@DEMUMBX014.nsn-intra.net> <09616DA2-D1ED-40EE-8E89-755DFCD81092@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E02B@DEMUMBX014.nsn-intra.net> <1A402C59-E390-4C95-8E30-97F1F9D3EF0F@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E05C@DEMUMBX014.nsn-intra.net> <790F1603-64D5-40E2-BC59-FD4C104EEF1B@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E0D9@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D90006681519E331@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D90006681519E3C4@DEMUMBX014.nsn-intra.net>
To: "Wiehe, Ulrich (NSN - DE/Munich)" 
X-Mailer: Apple Mail (2.1510)
Cc: "dime@ietf.org" 
Subject: Re: [Dime] OVLI: comments to 4.1
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Dec 2013 21:46:33 -0000

Ulrich,

On Dec 10, 2013, at 2:18 PM, "Wiehe, Ulrich (NSN - DE/Munich)" =
 wrote:

>=20
>=20
> -----Original Message-----
> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
> Sent: Tuesday, December 10, 2013 12:32 PM
> To: Wiehe, Ulrich (NSN - DE/Munich)
> Cc: dime@ietf.org
> Subject: Re: [Dime] OVLI: comments to 4.1
>=20
>=20
> On Dec 10, 2013, at 12:41 PM, "Wiehe, Ulrich (NSN - DE/Munich)" =
 wrote:
>=20
>> Hi Jouni,
>>=20
>> my understanding from Steve's clarification was that the reporting =
node would setup and maintain a database of "states", one per reacting =
node where a state of a reacting node is identified by a sequence number =
and the database entry would contain the pre-calculated OLR.=20
>> Hard to see how this is done without consuming resources.
>=20
> It is mostly static information. Still I do not see how
> you would get away without any state.
> [Wiehe, Ulrich (NSN - DE/Munich)] There is no need for the reporting =
node to store and maintain information per reacting node because the =
reacting node actually tells within the request message all information =
the reporting node needs to know. The reporting node simply fetches the =
pre-calculated OLR that matches the supported features of the reacting =
node as indicated in the request and appends it to the answer.

This could be true for the default algorithm in this spec. However,
given the extension mechanism we have in place it is quite possible
that the assumption does not hold for new features.

Also, if I were to implement a server front end agent that would
definitely need state and still ought to comply the protocol spec.

- Jouni




>> Furthermore,
>> Why would the reacting node be interested in config changes of the =
reporting node?
>> Isn't it so that the reacting node is only interested in OLR changes?
>=20
> Sigh.. say the traffic abatement algorithm changes or new features
> get added. Those have more impact than just OLR change.
>=20
> - Jouni
>=20
>>=20
>> Ulrich
>>=20
>> -----Original Message-----
>> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
>> Sent: Tuesday, December 10, 2013 9:41 AM
>> To: Wiehe, Ulrich (NSN - DE/Munich)
>> Cc: dime@ietf.org
>> Subject: Re: [Dime] OVLI: comments to 4.1
>>=20
>>=20
>> On Dec 9, 2013, at 4:43 PM, "Wiehe, Ulrich (NSN - DE/Munich)" =
 wrote:
>>=20
>>> But maintaining a specific state per reacting node is very resource =
consuming for the (overloaded) reporting node. It is simpler and more =
efficient to base any processing logic on actual information received in =
the request rather than on information stored from previous =
communication.
>>=20
>> The "state" in a reporting node is merely the current configuration
>> and a counter for sequence number. Hard to me see that as resource
>> consuming function.
>>=20
>> And the earlier comment of mine is done from reacting node point
>> of view, since it is more interested in the possible config changes
>> in the reporting node (e.g. S6a is stateless application, =
configuration
>> can change at any time).
>>=20
>> - Jouni
>>=20
>>=20
>>>=20
>>> Ulrich
>>>=20
>>> -----Original Message-----
>>> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
>>> Sent: Monday, December 09, 2013 2:25 PM
>>> To: Wiehe, Ulrich (NSN - DE/Munich)
>>> Cc: dime@ietf.org
>>> Subject: Re: [Dime] OVLI: comments to 4.1
>>>=20
>>>=20
>>> On Dec 9, 2013, at 3:13 PM, "Wiehe, Ulrich (NSN - DE/Munich)" =
 wrote:
>>>=20
>>>> There is a fundamental difference:
>>>> OLRs need to be stored, Feature-Vectors not.
>>>=20
>>> How come feature vector does not need to be stored? I do not
>>> get that? I would set my implementation to a specific state
>>> or mode based on the feature vector. When that changes I'd
>>> like to know that. And then keep functioning based on that.
>>>=20
>>> - Jouni
>>>=20
>>>> When receiving an OLR you may want to know whether its worth the =
effort to replace an already stored OLR with the received OLR.
>>>> When receiving a Feature-Vector you just act on it.
>>>>=20
>>>> Ulrich=20
>>>>=20
>>>> -----Original Message-----
>>>> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
>>>> Sent: Monday, December 09, 2013 1:55 PM
>>>> To: Wiehe, Ulrich (NSN - DE/Munich)
>>>> Cc: dime@ietf.org
>>>> Subject: Re: [Dime] OVLI: comments to 4.1
>>>>=20
>>>>=20
>>>> In the same vein as folks wanted send OLRs with the new or old =
information,
>>>> the feature vector should behave in a same way IMHO. That implies =
there are
>>>> situations when a reception of the feature vector does not change =
anything
>>>> in an endpoint current behavior.
>>>>=20
>>>> - Jouni
>>>>=20
>>>> On Dec 9, 2013, at 2:47 PM, "Wiehe, Ulrich (NSN - DE/Munich)" =
 wrote:
>>>>=20
>>>>> Isn't it so that the Feature-Vector (if present) always contains =
something that an implementation needs to act upon?
>>>>>=20
>>>>> Ulrich
>>>>>=20
>>>>> -----Original Message-----
>>>>> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
>>>>> Sent: Monday, December 09, 2013 1:12 PM
>>>>> To: Wiehe, Ulrich (NSN - DE/Munich)
>>>>> Cc: dime@ietf.org
>>>>> Subject: Re: [Dime] OVLI: comments to 4.1
>>>>>=20
>>>>> Ulrich,
>>>>>=20
>>>>> On Dec 6, 2013, at 3:03 PM, "Wiehe, Ulrich (NSN - DE/Munich)" =
 wrote:
>>>>>=20
>>>>>> Hi Jouni,
>>>>>>=20
>>>>>> thank you for your response.
>>>>>>=20
>>>>>> With regard to 3)=20
>>>>>> I still fail to see the usecase for Sequence-Number or TimeStamp =
within OC-Feature-Vector. Please clarify.
>>>>>=20
>>>>> Since we also allow extending the OC-Feature-Vector beyond =
recognition,=20
>>>>> it has good chances become a rather complex grouped AVP. In that =
context
>>>>> the Sequence-Number allows an easy and quick way to check if the =
feature
>>>>> vector contains something that an implementation needs to act =
upon.
>>>>>=20
>>>>>> With regard to 4)
>>>>>> This was not obvious to me. (The obvious typo is the missing "of" =
between "one" and "the").
>>>>>=20
>>>>> Ack. Fixed the missing 'of'.
>>>>>=20
>>>>> - Jouni
>>>>>=20
>>>>>>=20
>>>>>> Best regards
>>>>>> Ulrich
>>>>>>=20
>>>>>>=20
>>>>>> -----Original Message-----
>>>>>> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
>>>>>> Sent: Friday, December 06, 2013 11:17 AM
>>>>>> To: Wiehe, Ulrich (NSN - DE/Munich)
>>>>>> Cc: dime@ietf.org
>>>>>> Subject: Re: [Dime] OVLI: comments to 4.1
>>>>>>=20
>>>>>>=20
>>>>>> On Dec 5, 2013, at 3:23 PM, "Wiehe, Ulrich (NSN - DE/Munich)" =
 wrote:
>>>>>>=20
>>>>>>> Dear all,
>>>>>>>=20
>>>>>>> here are comments to clause 4.1:
>>>>>>>=20
>>>>>>> 1. The OC-Feature-Vector AVP is no longer a vector; the name of =
the AVP may be misleading. Proposal is to rename it to =
"OC-Supported-Features AVP"
>>>>>>=20
>>>>>> OK with me.
>>>>>>=20
>>>>>>> 2. The OC-Feature AVP is a vector of features. Proposal is to =
rename it to "OC-Feature-Vector AVP"
>>>>>>=20
>>>>>> OK with me.
>>>>>>=20
>>>>>>> 3. The OC-Sequence-Number within OC-Feature-Vector only makes =
sense if the receiving reporting endpoint can determine the identity of =
the reacting endpoint (which is not necessarily the origin host =
(client),
>>>>>>=20
>>>>>> My original proposal was to have seqnr as a timestamp. Some folks =
argued
>>>>>> it is no good and suggested seqnr. I still think time makes more =
sense than
>>>>>> seqnr.
>>>>>>=20
>>>>>>> it may be an agent and it may not always be the same agent), and =
if the reporting endpoint is required to store the OC-Feature-Vector / =
reacting-endpoint-identity pair (which I think both is not required). =
The reporting endpoint can base its processing logic on the actually =
received OC-Feature-Vector value, no matter whether it is brand-new or =
old but stil valid. Proposal is to delete OC-Sequence-Number AVP from =
OC-Feature-Vector.
>>>>>>=20
>>>>>> Do not agree removing it.
>>>>>>=20
>>>>>>> 4. The text
>>>>>>>=20
>>>>>>> The reporting node that sends the answer also includes the OC-
>>>>>>> Feature-Vector AVP that describe the capabilities it supports.  =
The
>>>>>>> set of capabilities advertised by the reporting node depends on =
local
>>>>>>> policies.  At least one the announced capabilities MUST match
>>>>>>> mutually.  If there is no single matching capability the =
reacting
>>>>>>> node MUST act as if it does not implement DOIC and cease =
inserting
>>>>>>> any DOIC related AVPs into any Diameter messages with this =
specific
>>>>>>> reacting node.
>>>>>>>=20
>>>>>>> is not clear.  Would the reporting node include the =
OC-Feature-Vector AVP in the answer only if there is at least one =
matching capability?=20
>>>>>>=20
>>>>>> Because then they have found a way to exchange something that =
both ends
>>>>>> know how to handle it.
>>>>>>=20
>>>>>>> Mandating the reacting node to cease for all time inserting =
OC-Feature-Vector AVPs if it did not get back=20
>>>>>>=20
>>>>>> There is an obvious typo. It should say:
>>>>>>=20
>>>>>> policies.  At least one the announced capabilities MUST match
>>>>>> mutually.  If there is no single matching capability the =
reporting
>>>>>> node MUST act as if it does not implement DOIC and cease =
inserting
>>>>>> any DOIC related AVPs into any Diameter messages with this =
specific
>>>>>> reacting node.
>>>>>>=20
>>>>>> - JOuni
>>>>>>=20
>>>>>>=20
>>>>>>> at least one match is also not ok. The request might have been a =
realm-type request (i.e. without Destination Host) and the reacting node =
cannot control whether subsequent requests will take the same path to =
the same reporting node.
>>>>>>> Even if the request contains a destination host the reacting =
node cannot know wether the reacting node's capabilities have been =
modified by the time a subsequent request is sent.=20
>>>>>>> Proposal is to keep only the first sentence and delete the rest.
>>>>>>>=20
>>>>>>> Ulrich
>>>>>>>=20
>>>>>>>=20
>>>>>>> _______________________________________________
>>>>>>> DiME mailing list
>>>>>>> DiME@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>>>=20
>>>>>=20
>>>>=20
>>>=20
>>=20
>=20


From jouni.nospam@gmail.com  Tue Dec 10 13:48:21 2013
Return-Path: 
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 B91E11AE19A for ; Tue, 10 Dec 2013 13:48:21 -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 3jRhX-bJyazv for ; Tue, 10 Dec 2013 13:48:20 -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 DC0161AE04B for ; Tue, 10 Dec 2013 13:48:19 -0800 (PST)
Received: by mail-la0-f47.google.com with SMTP id ep20so3163657lab.20 for ; Tue, 10 Dec 2013 13:48:14 -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=F9w6MDUlpfpiEQ7yZQQVl9pwH2t9svMEMCofrEPMT7s=; b=WLbIiMuigFrhlg0lMHAfMudgBljuBNhWYYB93ZXX5mHgfXvCKwjaxnQNrF3O8lqJ2m yUayQubUVJJkSD35mTvsVGVcP2pX1brdRnTxMFQ3mKYXRskbrUtxNQbnZOpUlgucHaKF bcGl/HVqYNFtKdZirAP7z0JtNhGIWTBxYEqZg2K1wnp59B3zDfTnVFT296wExnP1LJM3 x4h0xmyB1l94sIpK2ABJwFDOkPwg9RrLja0Q5FH5r7SJ3/RaAYTpVR+u/DReb69PQm/v 9q0/2ULHJD9jsyvSjjfEHdE0Ei2XIZSV9ubVg/ftzW4WmeDRK6IjvaX+wL6HrkkXE6S5 CYXg==
X-Received: by 10.152.2.5 with SMTP id 5mr9435073laq.21.1386712093810; Tue, 10 Dec 2013 13:48:13 -0800 (PST)
Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id t9sm24380355lat.1.2013.12.10.13.48.10 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Dec 2013 13:48:10 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jouni Korhonen 
In-Reply-To: 
Date: Tue, 10 Dec 2013 23:48:11 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <42A8AA73-EA94-4D0B-B88B-407BFA597726@gmail.com>
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DB1B@DEMUMBX014.nsn-intra.net>  <52A5E902.20605@usdonovans.com> <7475B713-1104-4791-96B1-CE97632A0D69@nostrum.com>  <5BCBA1FC2B7F0B4C9D935572D90006681519E476@DEMUMBX014.nsn-intra.net> <1CD20507-B0FE-4367-804A-B831734CF060@gmail.com> 
To: Ben Campbell 
X-Mailer: Apple Mail (2.1510)
Cc: "dime@ietf.org list" 
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Dec 2013 21:48:21 -0000

Ben,

On Dec 10, 2013, at 11:36 PM, Ben Campbell  wrote:

>=20
> On Dec 10, 2013, at 3:31 PM, Jouni Korhonen  =
wrote:
>=20
>>> Jouni,
>>>=20
>>> 1. I find the texts
>>> a) "The sequence number ... does not need to be monotonically =
increasing"
>>> and=20
>>=20
>> Means the delta from old-seqno to new-seqno can be any non-negative =
integer
>> (within the given limits) not something fixed step/delta (like +1). =
As long as
>> "new-seqno >=3D old-seqno" holds we are fine.
>=20
> My understanding is that "new-seqno >=3D old-seqno" is the =
_definition_ of monotonically increasing.
>=20
> But don't we want "new-seqno > old-seqno", that is, increase by a =
positive integer? (Assuming we are talking about a new OLR, not merely a =
copy of an old one.)
>=20

Zero delta is there since, as far as I understood, replaying an
old (i.e. current) OLR or supported feature was desired functionality.

- jouni=

From ben@nostrum.com  Tue Dec 10 13:56:25 2013
Return-Path: 
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 840151AE04B for ; Tue, 10 Dec 2013 13:56:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Level: 
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no
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 uYygAsr-2XS4 for ; Tue, 10 Dec 2013 13:56:24 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6EF7D1AE08B for ; Tue, 10 Dec 2013 13:56:24 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rBALuC2H002492 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 10 Dec 2013 15:56:13 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Ben Campbell 
In-Reply-To: <42A8AA73-EA94-4D0B-B88B-407BFA597726@gmail.com>
Date: Tue, 10 Dec 2013 15:56:12 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <4A1B8A7A-D03E-4DCD-B0AC-4FE160C32E0E@nostrum.com>
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DB1B@DEMUMBX014.nsn-intra.net>  <52A5E902.20605@usdonovans.com> <7475B713-1104-4791-96B1-CE97632A0D69@nostrum.com>  <5BCBA1FC2B7F0B4C9D935572D90006681519E476@DEMUMBX014.nsn-intra.net> <1CD20507-B0FE-4367-804A-B831734CF060@gmail.com>  <42A8AA73-EA94-4D0B-B88B-407BFA597726@gmail.com>
To: Jouni Korhonen 
X-Mailer: Apple Mail (2.1822)
Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism)
Cc: "dime@ietf.org list" 
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Dec 2013 21:56:25 -0000

On Dec 10, 2013, at 3:48 PM, Jouni Korhonen  =
wrote:

> Ben,
>=20
> On Dec 10, 2013, at 11:36 PM, Ben Campbell  wrote:
>=20
>>=20
>> On Dec 10, 2013, at 3:31 PM, Jouni Korhonen  =
wrote:
>>=20
>>>> Jouni,
>>>>=20
>>>> 1. I find the texts
>>>> a) "The sequence number ... does not need to be monotonically =
increasing"
>>>> and=20
>>>=20
>>> Means the delta from old-seqno to new-seqno can be any non-negative =
integer
>>> (within the given limits) not something fixed step/delta (like +1). =
As long as
>>> "new-seqno >=3D old-seqno" holds we are fine.
>>=20
>> My understanding is that "new-seqno >=3D old-seqno" is the =
_definition_ of monotonically increasing.
>>=20
>> But don't we want "new-seqno > old-seqno", that is, increase by a =
positive integer? (Assuming we are talking about a new OLR, not merely a =
copy of an old one.)
>>=20
>=20
> Zero delta is there since, as far as I understood, replaying an
> old (i.e. current) OLR or supported feature was desired functionality.

But that's not a new sequence number, is it? For that, the property is =
"old-seqno =3D=3D old-seqno" :-)  The important thing is to ensure that, =
if the OLR is changed in any way, the new sequence number is incremented =
by a positive integer.



From jouni.nospam@gmail.com  Tue Dec 10 14:07:46 2013
Return-Path: 
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 742961AE220 for ; Tue, 10 Dec 2013 14:07:46 -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 Uek0va1TJm03 for ; Tue, 10 Dec 2013 14:07:45 -0800 (PST)
Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id B17C41AE1BB for ; Tue, 10 Dec 2013 14:07:44 -0800 (PST)
Received: by mail-la0-f50.google.com with SMTP id el20so3138126lab.23 for ; Tue, 10 Dec 2013 14:07:38 -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=NRgK/RcSWEWAWD+5n3+2FV+mXF1i0DyKKRAdLCs6Cbo=; b=fp1E6qvjoeqkzqaAiF1lT8t+8emf4RGNPPFkM684zi91SMcFV8DlcF0yV8X55fsR4D CDv3ySX622zmRKD3PrtKhJ8XhpYjmCqsXjPlSFb9F5s1rCBMVKLODjYeKm8ibwBHRd4M cNXhgWpCo6lESS5iiGxO+f3R7g8pWJEYgb95geWklZQRShVtbJTOzyUdb3x98GiSjIAu CNyCkVsFhlhWOG+5j7PLvw/XTl2rQSJZSBApLg+FnYtY4eYEjzYRVAlcgiGQnkQaHgcN WIySrLw0jWWdQDsqBifFR4z3igT8BSokMtl4o6KMOAyLWS6oKh5GCxlswWe5yER1l4Tc RvVA==
X-Received: by 10.152.180.66 with SMTP id dm2mr42962lac.88.1386713258718; Tue, 10 Dec 2013 14:07:38 -0800 (PST)
Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id a8sm24457561lae.5.2013.12.10.14.07.33 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Dec 2013 14:07:35 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jouni Korhonen 
In-Reply-To: <4A1B8A7A-D03E-4DCD-B0AC-4FE160C32E0E@nostrum.com>
Date: Wed, 11 Dec 2013 00:07:33 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <571BCA01-65A3-4344-82D7-457EB465C5DF@gmail.com>
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DB1B@DEMUMBX014.nsn-intra.net>  <52A5E902.20605@usdonovans.com> <7475B713-1104-4791-96B1-CE97632A0D69@nostrum.com>  <5BCBA1FC2B7F0B4C9D935572D90006681519E476@DEMUMBX014.nsn-intra.net> <1CD20507-B0FE-4367-804A-B831734CF060@gmail.com>  <42A8AA73-EA94-4D0B-B88B-407BFA597726@gmail.com> <4A1B8A7A-D03E-4DCD-B0AC-4FE160C32E0E@nostrum.com>
To: Ben Campbell 
X-Mailer: Apple Mail (2.1510)
Cc: "dime@ietf.org list" 
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Dec 2013 22:07:46 -0000

On Dec 10, 2013, at 11:56 PM, Ben Campbell  wrote:

>=20
> On Dec 10, 2013, at 3:48 PM, Jouni Korhonen  =
wrote:
>=20
>> Ben,
>>=20
>> On Dec 10, 2013, at 11:36 PM, Ben Campbell  wrote:
>>=20
>>>=20
>>> On Dec 10, 2013, at 3:31 PM, Jouni Korhonen  =
wrote:
>>>=20
>>>>> Jouni,
>>>>>=20
>>>>> 1. I find the texts
>>>>> a) "The sequence number ... does not need to be monotonically =
increasing"
>>>>> and=20
>>>>=20
>>>> Means the delta from old-seqno to new-seqno can be any non-negative =
integer
>>>> (within the given limits) not something fixed step/delta (like +1). =
As long as
>>>> "new-seqno >=3D old-seqno" holds we are fine.
>>>=20
>>> My understanding is that "new-seqno >=3D old-seqno" is the =
_definition_ of monotonically increasing.
>>>=20
>>> But don't we want "new-seqno > old-seqno", that is, increase by a =
positive integer? (Assuming we are talking about a new OLR, not merely a =
copy of an old one.)
>>>=20
>>=20
>> Zero delta is there since, as far as I understood, replaying an
>> old (i.e. current) OLR or supported feature was desired =
functionality.
>=20
> But that's not a new sequence number, is it? For that, the property is =
"old-seqno =3D=3D old-seqno" :-)  The important thing is to ensure that, =
if the OLR is changed in any way, the new sequence number is incremented =
by a positive integer.

Righty right.

- Jouni=

From susan.shishufeng@huawei.com  Tue Dec 10 22:24:37 2013
Return-Path: 
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 452591AE3A6 for ; Tue, 10 Dec 2013 22:24:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level: 
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 RFXPPnH2f9NL for ; Tue, 10 Dec 2013 22:24:34 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA461AE39E for ; Tue, 10 Dec 2013 22:24:33 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYW15320; Wed, 11 Dec 2013 06:24:25 +0000 (GMT)
Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 11 Dec 2013 06:24:10 +0000
Received: from SZXEMA403-HUB.china.huawei.com (10.82.72.35) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 11 Dec 2013 06:24:20 +0000
Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.155]) by SZXEMA403-HUB.china.huawei.com ([10.82.72.35]) with mapi id 14.03.0158.001; Wed, 11 Dec 2013 14:24:09 +0800
From: "Shishufeng (Susan)" 
To: "Wiehe, Ulrich (NSN - DE/Munich)" , "ext lionel.morand@orange.com" , ext Jouni Korhonen , Ben Campbell 
Thread-Topic: [Dime] DOIC: Self-Contained OLRs
Thread-Index: AQHO7CTaot3HeYq6iU+vru+Aq+dgEZpLuCfw//+RMQCAAYJlYP//91uAgAHUm3A=
Date: Wed, 11 Dec 2013 06:24:08 +0000
Message-ID: <26C84DFD55BC3040A45BF70926E55F2587C1DC24@SZXEMA512-MBX.china.huawei.com>
References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com>  <5BCBA1FC2B7F0B4C9D935572D90006681519BC90@DEMUMBX014.nsn-intra.net> <6390_1385631044_52970D44_6390_18593_1_6B7134B31289DC4FAF731D844122B36E30748E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BD19@DEMUMBX014.nsn-intra.net> <26C84DFD55BC3040A45BF70926E55F2587C1D028@SZXEMA512-MBX.china.huawei.com> <5BCBA1FC2B7F0B4C9D935572D90006681519DFC0@DEMUMBX014.nsn-intra.net> <26C84DFD55BC3040A45BF70926E55F2587C1D705@SZXEMA512-MBX.china.huawei.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E2DE@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681519E2DE@DEMUMBX014.nsn-intra.net>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.146.62.57]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "dime@ietf.org list" 
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Dec 2013 06:24:37 -0000

Hi Ulrich,

I'm not sure if you are taking the overload of agent into account for which=
 we decided to not consider for the time being. If not, I couldn't understa=
nd why an agent which does not serve for a server farm needs to be a DOIC e=
ndpoint between the client and server if both of them support overload cont=
rol. My understanding is that if there is the need for an agent to take a r=
ole of a DOIC endpoint between a specific server and client, it would alway=
s do that, otherwise, it just transfer the overload information of the serv=
er to the client.

Best Regards,
Susan

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20
Sent: Tuesday, December 10, 2013 6:15 PM
To: Shishufeng (Susan); ext lionel.morand@orange.com; ext Jouni Korhonen; B=
en Campbell
Cc: dime@ietf.org list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Hi Susan,

if the agent does not take the role of a DOIC endpont then the feature nego=
tiation/adverisement is between client and server and one host type OLR is =
sent from server to client. For the agent this is all transparent and there=
 is no need for the agent to support any DOIC feature.
However, if the agent takes the role of an DOIC endpoint then the feature n=
egotiation/advertisement is between client and agent and a separate feature=
 negotiation/advertisement is between agent and server. An OLR sent from se=
rver to agent is in-context with the supported features of server and agent=
 but possibly not in-context with supported features of client and agent an=
d therefore must not be (blindly) sent to the client. And in fact there is =
also no need to do that. For subsequent requests that contain the desinatio=
n host of the server, the agent will not take the role of a DOIC endpoint.

Best regards
Ulrich

-----Original Message-----
From: ext Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
Sent: Tuesday, December 10, 2013 4:02 AM
To: Wiehe, Ulrich (NSN - DE/Munich); ext lionel.morand@orange.com; ext Joun=
i Korhonen; Ben Campbell
Cc: dime@ietf.org list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Hi Ulrich,

Thanks for your clarification. I understood the scenario, while from my poi=
nt of view, if the agent that selects the HSS is not configured to serve as=
 a load balancer for the HSS, the agent should not change any supported/neg=
otiated features between C and S, that would be the normal case. If the age=
nt serve as a load balancer for the HSS, the subsequent request from C towa=
rds the S would always go via the agent, in this case whatever the associat=
ions between C and A, between A and S are the same or not, it doesn't matte=
r. With an E2E solution as we agreed, I don't see the problem with it.

Best Regards,
Susan

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
Sent: Monday, December 09, 2013 7:43 PM
To: Shishufeng (Susan); ext lionel.morand@orange.com; ext Jouni Korhonen; B=
en Campbell
Cc: dime@ietf.org list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Hi Susan,

let me come back to your S6a example.

The MME (C) sends a request without Destination-Host towards the HPLMN (rea=
lm). There must be an agent (A) in the HPLMN (realm) that selects the HSS (=
S).=20
We would have two distinct DOIC associations: one between C and A, another =
between A and S (see figure 5 in clause 5.1). The two DOIC associations may=
 have different supported/negotiated features. An OLR sent from S to A base=
d on supported/negotiated features valid for the DOIC association between A=
 and S is at least problematic (out-of context) when sent from A to C.

When the MME (C) sends a subsequent request with Destination-Host towards t=
he HSS (S), there is no agent that selects the HSS (as the HSS is already s=
elected). For this session there is only one DOIC association between C and=
 S (see figure 3 in clause 5.1) and OLRs sent from S to C are not problemat=
ic.

Best regards
Ulrich


-----Original Message-----
From: ext Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
Sent: Monday, December 09, 2013 11:30 AM
To: Wiehe, Ulrich (NSN - DE/Munich); ext lionel.morand@orange.com; ext Joun=
i Korhonen; Ben Campbell
Cc: dime@ietf.org list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Hi Ulrich,

I have different views. In any case, I think the host-type OLR should not b=
e ignored by the clients. On the contrary, the realm-type OLR can be though=
t as optimization, which may not even be needed at all for all cases, espec=
ially in 3GPP. Here is an example of S6a, in the case the first attach requ=
est comes from the UE to the MME, the MME can only derive the realm informa=
tion, and sends a request without Destination-Host towards the HPLMN. Since=
 the subscriber corresponding to the UE belongs to a specific HSS, and the =
HSS may provide its overload report to the MME, and the MME is able to know=
 how to react regarding the requests towards the HSS, which would be the no=
rmal case. Whether Realm report will be provided by the HSS or the agent se=
rving the HSS is kind of optimization which may help the MME to know how to=
 react on the requests towards the realm, not specific to the HSS.

Best Regards,
Susan

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
Sent: Thursday, November 28, 2013 6:30 PM
To: ext lionel.morand@orange.com; ext Jouni Korhonen; Ben Campbell
Cc: dime@ietf.org list
Subject: 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 act=
ual OLR created by the reporting end point and which OLR is an additional O=
LR created by another node.

We have two cases:
a) The request sent by the client (reacting end point) contains no Destinat=
ion Host. The agent (reporting node) (after forwarding the request to the s=
elected server and receiving the answer) returns a realm-type OLR as the ac=
tual 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 Destinat=
ion 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 stat=
us. It could be provided an agent inserting this info in answers received f=
rom a server behind but also from a server that would know this info by som=
e internal magic.
But in any case, if we assume that the client will received a successful an=
swer from the server for an initial request with only Dest-Realm AVP, it sh=
ould be possible to have both report types in the answer: one for the serve=
r itself, one for the realm for new request sent to the realm with only Des=
t-Realm AVP.

Lionel

-----Message d'origine-----
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN=
 - DE/Munich) Envoy=E9=A0: jeudi 28 novembre 2013 10:26 =C0=A0: ext Jouni K=
orhonen; Ben Campbell Cc=A0: dime@ietf.org list Objet=A0: Re: [Dime] DOIC: =
Self-Contained OLRs

Hi,

I don't see how the possibility to send more than one OLR in an answer is a=
ligned with the "endpoint principle". If the ReportType is "realm" this ind=
icates 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  wrote:

> Hi,
>=20
> I mentioned in another thread that I prefer putting an explicit=20
> ReportType AVP in an OLR, rather than

The more I spent time thinking/writing the actual procedures on the endpoin=
ts, the more it makes sense to me to keep the ReportType in the OC-OLR. Eve=
n if the baseline does not have agent overload etc, the ReportType fits wel=
l to the "endpoint principle" we have in the draft. It indeed gives more to=
ols to make a host vs. realm base decision on the reacting node and is plai=
n 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 Diam=
eter request that corresponds to the answer containing the OLR. My reasons =
for that go beyond just ReportType, so I'm starting a separate thread.
>=20
> As currently described, a consumer of an OLR must infer several things fr=
om other context. In most cases, that context is in the Diameter answer tha=
t carries the OLR. For example, the OLR implicitly refers to the applicatio=
n 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 meani=
ng in the context of the enclosing answer. If you moved an OLR from one ans=
wer to another, it's meaning may change completely.
>=20
> I think this approach is a mistake. I would greatly prefer that we explic=
itly include such values in the OLR itself, for multiple reasons:
>=20
> 1) It's more complex to interpret implicit, contextual values than explic=
it values. The consumer cannot simply look at the OLR; it must look in vari=
ous other AVPs to find all the information it needs. For example, I think a=
 common software design for overload control processing to be separated fro=
m application processing. The consumer cannot simply hand the OLR to that m=
odule 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 "con=
text" avps that must be interpreted can grow large. This approach is error =
prone, and will likely encourage brittle, hard-to-maintain code. Self-conta=
ined OLRs would keep all the information related to overload in one place. =
making for simpler implementations.
>=20
> 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 r=
eporting node realizes that it is overloade, it has to wait for the right a=
nswer that contains the right context before it can send the OLR. This is p=
articularly troublesome for agents, since they will typically have to inser=
t OLRs into answers created by other nodes.=20
>=20
> If the reporting node screws this up, the meaning of the OLR may change s=
ignificantly. So again, implicit meaning gives us error prone implementatio=
ns. Self-contained OLRs are simpler to create and send.
>=20
> 3) Implicit values don't work at all for certain problems. For=20
> example, if an agent needs to originate an OLR, it typically needs to=20
> insert that OLR into an existing Diameter answer created by a server.
> It can't create its own answer without affecting the application=20
> state. If the responding node assumes the OLR comes from or refers to=20
> the node identified by the Origin-Host AVP in the enclosing answer,=20
> things break. (For examples of when an agent needs to send OLRs that=20
> are distinct from those sent by a server, see Steve's agent overload=20
> draft, or my dh/dr example.)
>=20
> OTOH, explicit values will work for all cases where we need to associate =
some arbitrary value with an OLR.
>=20
> 4) Implicit values seriously constrain the future evolution of Diameter O=
C standards. For example, lets say we find a good reason to allow OLRs to b=
e sent out of band, or be sent in a dedicated Diameter application. If over=
load 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 transpo=
rted, this won't work. We would have to create a new or significantly modif=
ied OLR format if we found a need to transport OLRs in different ways. Self=
-contained OLRs would allow much greater flexibility.
>=20
> So, in summary, I think that self-contained OLRs would lead to simpler im=
plementations, less brittle deployments, and more flexibility for future ev=
olution of standards.
>=20
> Thanks!
>=20
> 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 confiden=
tielles 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. Le=
s messages electroniques etant susceptibles d'alteration, Orange decline to=
ute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation 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 dele=
te 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.



From ulrich.wiehe@nsn.com  Tue Dec 10 23:21:15 2013
Return-Path: 
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 8A4381AE3D2 for ; Tue, 10 Dec 2013 23:21:15 -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 jJaF_nrkYr0e for ; Tue, 10 Dec 2013 23:21:12 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF811AD8E3 for ; Tue, 10 Dec 2013 23:21:11 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rBB7L4Eu017260 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 11 Dec 2013 08:21:04 +0100
Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rBB7L3Pr001737 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Dec 2013 08:21:03 +0100
Received: from DEMUHTC011.nsn-intra.net (10.159.42.42) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 11 Dec 2013 08:21:02 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.152]) by DEMUHTC011.nsn-intra.net ([10.159.42.42]) with mapi id 14.03.0123.003; Wed, 11 Dec 2013 08:21:02 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Jouni Korhonen 
Thread-Topic: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3
Thread-Index: AQHO9e8qVWG779dz9k2pnHnmYU487ZpOiY/w
Date: Wed, 11 Dec 2013 07:21:02 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519E6DC@DEMUMBX014.nsn-intra.net>
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DB1B@DEMUMBX014.nsn-intra.net>  <52A5E902.20605@usdonovans.com> <7475B713-1104-4791-96B1-CE97632A0D69@nostrum.com>  <5BCBA1FC2B7F0B4C9D935572D90006681519E476@DEMUMBX014.nsn-intra.net> <1CD20507-B0FE-4367-804A-B831734CF060@gmail.com>
In-Reply-To: <1CD20507-B0FE-4367-804A-B831734CF060@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.112]
Content-Type: text/plain; charset="us-ascii"
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: 7650
X-purgate-ID: 151667::1386746465-00001A6F-DAB09F2E/0-0/0-0
Cc: Ben Campbell , "dime@ietf.org list" 
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Dec 2013 07:21:16 -0000

Jouni,

ad 1. "monotonically" does not express your intention. What we are looking =
for may be "stepwise with fixed step".

Ad 2. Is not necessarily a mistake that could result in out-of-sequence seq=
uence numbers. When a client C sends a realm-type requests towards any serv=
er in the realm, an agent A1 that selects the server would send back the re=
alm-type OLR with sequence number s1. The next realm-type request sent by C=
 (that survived the throttling) may take a path that does not include A1 bu=
t A2. A2 then selects the server and sends back a sequence number s2. Nothi=
ng ensures that s1 and s2 are in sequence.

Ulrich
 =20

-----Original Message-----
From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
Sent: Tuesday, December 10, 2013 10:31 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: Ben Campbell; dime@ietf.org list; Steve Donovan
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comment=
s to 4.3

Ulrich,

On Dec 10, 2013, at 4:31 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:

> Jouni,
>=20
> 1. I find the texts
> a) "The sequence number ... does not need to be monotonically increasing"
> and=20

Means the delta from old-seqno to new-seqno can be any non-negative integer
(within the given limits) not something fixed step/delta (like +1). As long=
 as
"new-seqno >=3D old-seqno" holds we are fine.

> b) "...the new sequence number MUST be greater or equal than the old sequ=
ence number..."
> contradicting.
> Can you please clarify.

See above. (mind the overflow case)

> 2. The expected behaviour when receiving an out-of-sequence sequence numb=
er within OC-OLR is described in 4.3:
>   "The receiver SHOULD discard an OC-OLR AVP with a sequence number that =
is less than previously received one."
> I don't find this very robust. Once a higher sequence number (received er=
roneously by mistake) is accepted you cannot (easily) recover.

I find it more robust in a sense that I should not care about stale old inf=
ormation.
However, since we are piggybacking (by popular demand) we have little room =
for seqno
re-sync negotiation.

What is the mistake you refer here? A misbehaving implementation? In that c=
ase, it=20
deserves to get a manual intervention once figured out by admins checking a=
larms and
logs. If the mistake is due other things, like endpoints being out of sync,=
 we currently
have no written down mechanism to survive that.

> 3. The expected behaviour when receiving an out-of-sequence sequence numb=
er within the OC-Supported-Features AVP is not described. What is the inten=
tion here?

No intention. Just a sloppy specification. You are right that something nee=
ds to be
done & clarified here. (again the semantics of Time would nice..)

I'll propose something. Others should too ;)

- Jouni

>=20
> Ulrich
>=20
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Jouni Korhonen
> Sent: Tuesday, December 10, 2013 8:28 AM
> To: Ben Campbell; dime@ietf.org list; Steve Donovan
> Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comme=
nts to 4.3
>=20
>=20
> Fine.. lets define then the sequence number semantics. Basic
> unsigned integer math. The text proposal is the following:
>=20
> 4.4.  OC-Sequence-Number AVP
>=20
>   The OC-Sequence-Number AVP (AVP code TBD3) is type of Unsigned64.
>   Its usage in the context of the overload control is described in
>   Sections 4.1 and 4.3.
>=20
>   From the functionality point of view, the OC-Sequence-Number AVP
>   MUST be used as a non-volatile increasing counter between two
>   overload control endpoints.  The sequence number is only required
>   to be unique between two overload control endpoints and does not
>   need to be monotonically increasing.
>=20
>   When comparing two sequence numbers, the new sequence number MUST
>   be greater or equal than the old sequence number within a window
>   that is half of the size of the maximum sequence number. This
>   allows a simple handling of the sequence number overflow using
>   unsigned integer arithmeticf:
>=20
>     #define WINDOW 0x8000000000000000ULL
>=20
>     bool verify_seqnum( uint64_t newsn, uint64_t oldsn ) {
>         if (newsn - oldsn <=3D WINDOW)
>             // newsn >=3D oldsn
>             return true;  =20
>         } else
>             // outside window or newsn < oldsn
>             return false; =20
>         }
>     }
>=20
>=20
>=20
> The above should even work is someone shovels NTP times into
> sequence numbers with a blind typecasting.
>=20
> - Jouni
>=20
> On Dec 10, 2013, at 12:34 AM, Ben Campbell  wrote:
>=20
>>=20
>> On Dec 9, 2013, at 10:00 AM, Steve Donovan  wr=
ote:
>>=20
>>> Jouni,
>>>=20
>>> I propose that we keep the name OC-Sequence-Number but that we use the =
Time type for OC-Sequence-Number.  It is misleading and potentially confusi=
ng to call it OC-Time-Stamp. =20
>>>=20
>>=20
>> I could live with that, although I would rather just define the expected=
 properties of the sequence number, and leave the implementation up to the =
implementor. I assume your reasoning for not calling it a timestamp is that=
 you do not want people to try to use it as a time base reference. If so, t=
hen we don't require any connection to a clock. We just need it to be monot=
onically increasing.
>>=20
>>> We might consider expanding on the format of the AVP to make it somethi=
ng like Session-ID, where it is a concatenation of the Diameter-ID of the g=
enerating node and a timestamp.  This might help the reacting node keep tra=
ck of which sequence number it has received.
>>>=20
>>=20
>> Do we need a uniqueness across multiple nodes property? If so, why?
>>=20
>>> Steve
>>>=20
>>> On 12/9/13 5:37 AM, Jouni Korhonen wrote:
>>>> Folks
>>>>=20
>>>> Could we conclude on the sequence number vs. time stamp vs. something =
else?
>>>> We got more important places to spend our energy than this ;)
>>>>=20
>>>> My proposal is the following (based on the original pre-00 design):
>>>>=20
>>>> o We change the OC-Sequence-Number to OC-Time-Stamp in all occurrences
>>>> in the -01.
>>>> o We use RFC6733 Time type for the OC-Time-Stamp. RFC6733 gives us
>>>> already exact definition how to handle the AVP.
>>>> o Define that the OC-Time-Stamp is the time of the creation of the=20
>>>> "original" AVP within whose context the time stamp is present.
>>>> o The OC-Time-Stamp AVP uniqueness is still considered to be in scope
>>>> of the communicating endpoints.
>>>> o The time stamp can be used to quickly determine if the content of
>>>> the encapsulating AVP context has changed (among other properties).
>>>> This would be useful specifically in the future when the encapsulating
>>>> grouped AVPs  grow in size and functionality.
>>>>=20
>>>>=20
>>>> - Jouni
>>>>=20
>>>> _______________________________________________
>>>> DiME mailing list
>>>>=20
>>>> DiME@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>=20
>>>>=20
>>>>=20
>>>=20
>>> _______________________________________________
>>> DiME mailing list
>>> DiME@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dime
>>=20
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From ulrich.wiehe@nsn.com  Tue Dec 10 23:34:58 2013
Return-Path: 
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 27EF91AE3DA for ; Tue, 10 Dec 2013 23:34:58 -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 SR9oC0V1ck3w for ; Tue, 10 Dec 2013 23:34:55 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id C13C41AE38D for ; Tue, 10 Dec 2013 23:34:54 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rBB7YjuX026054 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 11 Dec 2013 08:34:45 +0100
Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rBB7YjD3000716 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Dec 2013 08:34:45 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.152]) by DEMUHTC001.nsn-intra.net ([10.159.42.32]) with mapi id 14.03.0123.003; Wed, 11 Dec 2013 08:34:44 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Jouni Korhonen 
Thread-Topic: [Dime] OVLI: comments to 4.1
Thread-Index: Ac7xvTHHIECkLcDwSDuVAh2ACeOasAAprlMAAAaV6CAAlFJBAAADLijg///yiAD//+yxwIAAG3gA///jPWCAAV/bAP//0rCwAAujOgD//+gx4P//PIoA//3FKSA=
Date: Wed, 11 Dec 2013 07:34:44 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519E6EF@DEMUMBX014.nsn-intra.net>
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DA3E@DEMUMBX014.nsn-intra.net> <6CDCFC84-3048-40B9-91A4-1451FCC65F60@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519DCE5@DEMUMBX014.nsn-intra.net> <09616DA2-D1ED-40EE-8E89-755DFCD81092@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E02B@DEMUMBX014.nsn-intra.net> <1A402C59-E390-4C95-8E30-97F1F9D3EF0F@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E05C@DEMUMBX014.nsn-intra.net> <790F1603-64D5-40E2-BC59-FD4C104EEF1B@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E0D9@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D90006681519E331@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D90006681519E3C4@DEMUMBX014.nsn-intra.net> <0CDBF4BB-4E38-41D6-A5E2-9218FFEFEA43@gmail.com>
In-Reply-To: <0CDBF4BB-4E38-41D6-A5E2-9218FFEFEA43@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.112]
Content-Type: text/plain; charset="us-ascii"
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: 10843
X-purgate-ID: 151667::1386747285-00000661-892F1AE9/0-0/0-0
Cc: "dime@ietf.org" 
Subject: Re: [Dime] OVLI: comments to 4.1
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Dec 2013 07:34:58 -0000

Jouni,

I do not agree.

My statement was general: reporting node may be server or SFA; supported fe=
atures may be defined features (default algo) or future extensions.

Ulrich

-----Original Message-----
From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
Sent: Tuesday, December 10, 2013 10:46 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: dime@ietf.org
Subject: Re: [Dime] OVLI: comments to 4.1

Ulrich,

On Dec 10, 2013, at 2:18 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:

>=20
>=20
> -----Original Message-----
> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
> Sent: Tuesday, December 10, 2013 12:32 PM
> To: Wiehe, Ulrich (NSN - DE/Munich)
> Cc: dime@ietf.org
> Subject: Re: [Dime] OVLI: comments to 4.1
>=20
>=20
> On Dec 10, 2013, at 12:41 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:
>=20
>> Hi Jouni,
>>=20
>> my understanding from Steve's clarification was that the reporting node =
would setup and maintain a database of "states", one per reacting node wher=
e a state of a reacting node is identified by a sequence number and the dat=
abase entry would contain the pre-calculated OLR.=20
>> Hard to see how this is done without consuming resources.
>=20
> It is mostly static information. Still I do not see how
> you would get away without any state.
> [Wiehe, Ulrich (NSN - DE/Munich)] There is no need for the reporting node=
 to store and maintain information per reacting node because the reacting n=
ode actually tells within the request message all information the reporting=
 node needs to know. The reporting node simply fetches the pre-calculated O=
LR that matches the supported features of the reacting node as indicated in=
 the request and appends it to the answer.

This could be true for the default algorithm in this spec. However,
given the extension mechanism we have in place it is quite possible
that the assumption does not hold for new features.

Also, if I were to implement a server front end agent that would
definitely need state and still ought to comply the protocol spec.

- Jouni




>> Furthermore,
>> Why would the reacting node be interested in config changes of the repor=
ting node?
>> Isn't it so that the reacting node is only interested in OLR changes?
>=20
> Sigh.. say the traffic abatement algorithm changes or new features
> get added. Those have more impact than just OLR change.
>=20
> - Jouni
>=20
>>=20
>> Ulrich
>>=20
>> -----Original Message-----
>> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
>> Sent: Tuesday, December 10, 2013 9:41 AM
>> To: Wiehe, Ulrich (NSN - DE/Munich)
>> Cc: dime@ietf.org
>> Subject: Re: [Dime] OVLI: comments to 4.1
>>=20
>>=20
>> On Dec 9, 2013, at 4:43 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:
>>=20
>>> But maintaining a specific state per reacting node is very resource con=
suming for the (overloaded) reporting node. It is simpler and more efficien=
t to base any processing logic on actual information received in the reques=
t rather than on information stored from previous communication.
>>=20
>> The "state" in a reporting node is merely the current configuration
>> and a counter for sequence number. Hard to me see that as resource
>> consuming function.
>>=20
>> And the earlier comment of mine is done from reacting node point
>> of view, since it is more interested in the possible config changes
>> in the reporting node (e.g. S6a is stateless application, configuration
>> can change at any time).
>>=20
>> - Jouni
>>=20
>>=20
>>>=20
>>> Ulrich
>>>=20
>>> -----Original Message-----
>>> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
>>> Sent: Monday, December 09, 2013 2:25 PM
>>> To: Wiehe, Ulrich (NSN - DE/Munich)
>>> Cc: dime@ietf.org
>>> Subject: Re: [Dime] OVLI: comments to 4.1
>>>=20
>>>=20
>>> On Dec 9, 2013, at 3:13 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:
>>>=20
>>>> There is a fundamental difference:
>>>> OLRs need to be stored, Feature-Vectors not.
>>>=20
>>> How come feature vector does not need to be stored? I do not
>>> get that? I would set my implementation to a specific state
>>> or mode based on the feature vector. When that changes I'd
>>> like to know that. And then keep functioning based on that.
>>>=20
>>> - Jouni
>>>=20
>>>> When receiving an OLR you may want to know whether its worth the effor=
t to replace an already stored OLR with the received OLR.
>>>> When receiving a Feature-Vector you just act on it.
>>>>=20
>>>> Ulrich=20
>>>>=20
>>>> -----Original Message-----
>>>> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
>>>> Sent: Monday, December 09, 2013 1:55 PM
>>>> To: Wiehe, Ulrich (NSN - DE/Munich)
>>>> Cc: dime@ietf.org
>>>> Subject: Re: [Dime] OVLI: comments to 4.1
>>>>=20
>>>>=20
>>>> In the same vein as folks wanted send OLRs with the new or old informa=
tion,
>>>> the feature vector should behave in a same way IMHO. That implies ther=
e are
>>>> situations when a reception of the feature vector does not change anyt=
hing
>>>> in an endpoint current behavior.
>>>>=20
>>>> - Jouni
>>>>=20
>>>> On Dec 9, 2013, at 2:47 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:
>>>>=20
>>>>> Isn't it so that the Feature-Vector (if present) always contains some=
thing that an implementation needs to act upon?
>>>>>=20
>>>>> Ulrich
>>>>>=20
>>>>> -----Original Message-----
>>>>> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
>>>>> Sent: Monday, December 09, 2013 1:12 PM
>>>>> To: Wiehe, Ulrich (NSN - DE/Munich)
>>>>> Cc: dime@ietf.org
>>>>> Subject: Re: [Dime] OVLI: comments to 4.1
>>>>>=20
>>>>> Ulrich,
>>>>>=20
>>>>> On Dec 6, 2013, at 3:03 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:
>>>>>=20
>>>>>> Hi Jouni,
>>>>>>=20
>>>>>> thank you for your response.
>>>>>>=20
>>>>>> With regard to 3)=20
>>>>>> I still fail to see the usecase for Sequence-Number or TimeStamp wit=
hin OC-Feature-Vector. Please clarify.
>>>>>=20
>>>>> Since we also allow extending the OC-Feature-Vector beyond recognitio=
n,=20
>>>>> it has good chances become a rather complex grouped AVP. In that cont=
ext
>>>>> the Sequence-Number allows an easy and quick way to check if the feat=
ure
>>>>> vector contains something that an implementation needs to act upon.
>>>>>=20
>>>>>> With regard to 4)
>>>>>> This was not obvious to me. (The obvious typo is the missing "of" be=
tween "one" and "the").
>>>>>=20
>>>>> Ack. Fixed the missing 'of'.
>>>>>=20
>>>>> - Jouni
>>>>>=20
>>>>>>=20
>>>>>> Best regards
>>>>>> Ulrich
>>>>>>=20
>>>>>>=20
>>>>>> -----Original Message-----
>>>>>> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
>>>>>> Sent: Friday, December 06, 2013 11:17 AM
>>>>>> To: Wiehe, Ulrich (NSN - DE/Munich)
>>>>>> Cc: dime@ietf.org
>>>>>> Subject: Re: [Dime] OVLI: comments to 4.1
>>>>>>=20
>>>>>>=20
>>>>>> On Dec 5, 2013, at 3:23 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:
>>>>>>=20
>>>>>>> Dear all,
>>>>>>>=20
>>>>>>> here are comments to clause 4.1:
>>>>>>>=20
>>>>>>> 1. The OC-Feature-Vector AVP is no longer a vector; the name of the=
 AVP may be misleading. Proposal is to rename it to "OC-Supported-Features =
AVP"
>>>>>>=20
>>>>>> OK with me.
>>>>>>=20
>>>>>>> 2. The OC-Feature AVP is a vector of features. Proposal is to renam=
e it to "OC-Feature-Vector AVP"
>>>>>>=20
>>>>>> OK with me.
>>>>>>=20
>>>>>>> 3. The OC-Sequence-Number within OC-Feature-Vector only makes sense=
 if the receiving reporting endpoint can determine the identity of the reac=
ting endpoint (which is not necessarily the origin host (client),
>>>>>>=20
>>>>>> My original proposal was to have seqnr as a timestamp. Some folks ar=
gued
>>>>>> it is no good and suggested seqnr. I still think time makes more sen=
se than
>>>>>> seqnr.
>>>>>>=20
>>>>>>> it may be an agent and it may not always be the same agent), and if=
 the reporting endpoint is required to store the OC-Feature-Vector / reacti=
ng-endpoint-identity pair (which I think both is not required). The reporti=
ng endpoint can base its processing logic on the actually received OC-Featu=
re-Vector value, no matter whether it is brand-new or old but stil valid. P=
roposal is to delete OC-Sequence-Number AVP from OC-Feature-Vector.
>>>>>>=20
>>>>>> Do not agree removing it.
>>>>>>=20
>>>>>>> 4. The text
>>>>>>>=20
>>>>>>> The reporting node that sends the answer also includes the OC-
>>>>>>> Feature-Vector AVP that describe the capabilities it supports.  The
>>>>>>> set of capabilities advertised by the reporting node depends on loc=
al
>>>>>>> policies.  At least one the announced capabilities MUST match
>>>>>>> mutually.  If there is no single matching capability the reacting
>>>>>>> node MUST act as if it does not implement DOIC and cease inserting
>>>>>>> any DOIC related AVPs into any Diameter messages with this specific
>>>>>>> reacting node.
>>>>>>>=20
>>>>>>> is not clear.  Would the reporting node include the OC-Feature-Vect=
or AVP in the answer only if there is at least one matching capability?=20
>>>>>>=20
>>>>>> Because then they have found a way to exchange something that both e=
nds
>>>>>> know how to handle it.
>>>>>>=20
>>>>>>> Mandating the reacting node to cease for all time inserting OC-Feat=
ure-Vector AVPs if it did not get back=20
>>>>>>=20
>>>>>> There is an obvious typo. It should say:
>>>>>>=20
>>>>>> policies.  At least one the announced capabilities MUST match
>>>>>> mutually.  If there is no single matching capability the reporting
>>>>>> node MUST act as if it does not implement DOIC and cease inserting
>>>>>> any DOIC related AVPs into any Diameter messages with this specific
>>>>>> reacting node.
>>>>>>=20
>>>>>> - JOuni
>>>>>>=20
>>>>>>=20
>>>>>>> at least one match is also not ok. The request might have been a re=
alm-type request (i.e. without Destination Host) and the reacting node cann=
ot control whether subsequent requests will take the same path to the same =
reporting node.
>>>>>>> Even if the request contains a destination host the reacting node c=
annot know wether the reacting node's capabilities have been modified by th=
e time a subsequent request is sent.=20
>>>>>>> Proposal is to keep only the first sentence and delete the rest.
>>>>>>>=20
>>>>>>> Ulrich
>>>>>>>=20
>>>>>>>=20
>>>>>>> _______________________________________________
>>>>>>> DiME mailing list
>>>>>>> DiME@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>>>=20
>>>>>=20
>>>>=20
>>>=20
>>=20
>=20


From jouni.nospam@gmail.com  Tue Dec 10 23:37:53 2013
Return-Path: 
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 854A71AE3D2 for ; Tue, 10 Dec 2013 23:37:53 -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 W6etj4RNwjjq for ; Tue, 10 Dec 2013 23:37:51 -0800 (PST)
Received: from mail-bk0-x22f.google.com (mail-bk0-x22f.google.com [IPv6:2a00:1450:4008:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id C66E41AE391 for ; Tue, 10 Dec 2013 23:37:50 -0800 (PST)
Received: by mail-bk0-f47.google.com with SMTP id mx12so153157bkb.20 for ; Tue, 10 Dec 2013 23:37:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=FDx5QByzErTxS+OH5QpIiTN3cZ0a4eOQ9X3Zvml25K4=; b=drWquhCuqb19JAnmEA1JeL3zmYsO3SOuuVJLcx6KmkFN6Wg9VQ/TjzNMOKGQGAhLay 3cieWMS9Hb5IJxrUPca+vM5LKrKqrIiQa+MEiBVZf4PNJTwrKormY8DNgjIl/sKRPFRA G+639hHfIcgJylp45bFC/Gp5IfOMQBONahXL4yi5OwGoWZUyavgF8GIR1ImJg0oV/Al+ dO5MAmOJYDKZSmxyoZtOyGMVUFRbEIaNFLDVCjcj9uM8YNuULqBa3d3CO3I88gcscuzL llXfycEqv2FxiD6nFt5c5laAUy8T2rFqEdEg/RR9GsmkB4xiVIqtv9+xVymb6FHi3ES2 zCFg==
X-Received: by 10.204.122.1 with SMTP id j1mr151645bkr.57.1386747464716; Tue, 10 Dec 2013 23:37:44 -0800 (PST)
Received: from ?IPv6:2001:1bc8:101:f101:4d7f:9ccd:6cf6:1b7? ([2001:1bc8:101:f101:4d7f:9ccd:6cf6:1b7]) by mx.google.com with ESMTPSA id no2sm13812805bkb.15.2013.12.10.23.37.40 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Dec 2013 23:37:40 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=us-ascii
From: Jouni 
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681519E6DC@DEMUMBX014.nsn-intra.net>
Date: Wed, 11 Dec 2013 09:37:39 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DB1B@DEMUMBX014.nsn-intra.net>  <52A5E902.20605@usdonovans.com> <7475B713-1104-4791-96B1-CE97632A0D69@nostrum.com>  <5BCBA1FC2B7F0B4C9D935572D90006681519E476@DEMUMBX014.nsn-intra.net> <1CD20507-B0FE-4367-804A-B831734CF060@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E6DC@DEMUMBX014.nsn-intra.net>
To: "Wiehe, Ulrich (NSN - DE/Munich)" 
X-Mailer: Apple Mail (2.1283)
Cc: Ben Campbell , "dime@ietf.org list" 
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Dec 2013 07:37:53 -0000

Ulrich,

On Dec 11, 2013, at 9:21 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:

> Jouni,
>=20
> ad 1. "monotonically" does not express your intention. What we are =
looking for may be "stepwise with fixed step".
>=20
> Ad 2. Is not necessarily a mistake that could result in =
out-of-sequence sequence numbers. When a client C sends a realm-type =
requests towards any server in the realm, an agent A1 that selects the =
server would send back the realm-type OLR with sequence number s1. The =
next realm-type request sent by C (that survived the throttling) may =
take a path that does not include A1 but A2. A2 then selects the server =
and sends back a sequence number s2. Nothing ensures that s1 and s2 are =
in sequence.

Would the server in both cases (via A1 and A2) be the same?

- Jouni


>=20
> Ulrich
>=20
>=20
> -----Original Message-----
> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
> Sent: Tuesday, December 10, 2013 10:31 PM
> To: Wiehe, Ulrich (NSN - DE/Munich)
> Cc: Ben Campbell; dime@ietf.org list; Steve Donovan
> Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: =
comments to 4.3
>=20
> Ulrich,
>=20
> On Dec 10, 2013, at 4:31 PM, "Wiehe, Ulrich (NSN - DE/Munich)" =
 wrote:
>=20
>> Jouni,
>>=20
>> 1. I find the texts
>> a) "The sequence number ... does not need to be monotonically =
increasing"
>> and=20
>=20
> Means the delta from old-seqno to new-seqno can be any non-negative =
integer
> (within the given limits) not something fixed step/delta (like +1). As =
long as
> "new-seqno >=3D old-seqno" holds we are fine.
>=20
>> b) "...the new sequence number MUST be greater or equal than the old =
sequence number..."
>> contradicting.
>> Can you please clarify.
>=20
> See above. (mind the overflow case)
>=20
>> 2. The expected behaviour when receiving an out-of-sequence sequence =
number within OC-OLR is described in 4.3:
>>  "The receiver SHOULD discard an OC-OLR AVP with a sequence number =
that is less than previously received one."
>> I don't find this very robust. Once a higher sequence number =
(received erroneously by mistake) is accepted you cannot (easily) =
recover.
>=20
> I find it more robust in a sense that I should not care about stale =
old information.
> However, since we are piggybacking (by popular demand) we have little =
room for seqno
> re-sync negotiation.
>=20
> What is the mistake you refer here? A misbehaving implementation? In =
that case, it=20
> deserves to get a manual intervention once figured out by admins =
checking alarms and
> logs. If the mistake is due other things, like endpoints being out of =
sync, we currently
> have no written down mechanism to survive that.
>=20
>> 3. The expected behaviour when receiving an out-of-sequence sequence =
number within the OC-Supported-Features AVP is not described. What is =
the intention here?
>=20
> No intention. Just a sloppy specification. You are right that =
something needs to be
> done & clarified here. (again the semantics of Time would nice..)
>=20
> I'll propose something. Others should too ;)
>=20
> - Jouni
>=20
>>=20
>> Ulrich
>>=20
>> -----Original Message-----
>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Jouni =
Korhonen
>> Sent: Tuesday, December 10, 2013 8:28 AM
>> To: Ben Campbell; dime@ietf.org list; Steve Donovan
>> Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: =
comments to 4.3
>>=20
>>=20
>> Fine.. lets define then the sequence number semantics. Basic
>> unsigned integer math. The text proposal is the following:
>>=20
>> 4.4.  OC-Sequence-Number AVP
>>=20
>>  The OC-Sequence-Number AVP (AVP code TBD3) is type of Unsigned64.
>>  Its usage in the context of the overload control is described in
>>  Sections 4.1 and 4.3.
>>=20
>>  =46rom the functionality point of view, the OC-Sequence-Number AVP
>>  MUST be used as a non-volatile increasing counter between two
>>  overload control endpoints.  The sequence number is only required
>>  to be unique between two overload control endpoints and does not
>>  need to be monotonically increasing.
>>=20
>>  When comparing two sequence numbers, the new sequence number MUST
>>  be greater or equal than the old sequence number within a window
>>  that is half of the size of the maximum sequence number. This
>>  allows a simple handling of the sequence number overflow using
>>  unsigned integer arithmeticf:
>>=20
>>    #define WINDOW 0x8000000000000000ULL
>>=20
>>    bool verify_seqnum( uint64_t newsn, uint64_t oldsn ) {
>>        if (newsn - oldsn <=3D WINDOW)
>>            // newsn >=3D oldsn
>>            return true;  =20
>>        } else
>>            // outside window or newsn < oldsn
>>            return false; =20
>>        }
>>    }
>>=20
>>=20
>>=20
>> The above should even work is someone shovels NTP times into
>> sequence numbers with a blind typecasting.
>>=20
>> - Jouni
>>=20
>> On Dec 10, 2013, at 12:34 AM, Ben Campbell  wrote:
>>=20
>>>=20
>>> On Dec 9, 2013, at 10:00 AM, Steve Donovan =
 wrote:
>>>=20
>>>> Jouni,
>>>>=20
>>>> I propose that we keep the name OC-Sequence-Number but that we use =
the Time type for OC-Sequence-Number.  It is misleading and potentially =
confusing to call it OC-Time-Stamp. =20
>>>>=20
>>>=20
>>> I could live with that, although I would rather just define the =
expected properties of the sequence number, and leave the implementation =
up to the implementor. I assume your reasoning for not calling it a =
timestamp is that you do not want people to try to use it as a time base =
reference. If so, then we don't require any connection to a clock. We =
just need it to be monotonically increasing.
>>>=20
>>>> We might consider expanding on the format of the AVP to make it =
something like Session-ID, where it is a concatenation of the =
Diameter-ID of the generating node and a timestamp.  This might help the =
reacting node keep track of which sequence number it has received.
>>>>=20
>>>=20
>>> Do we need a uniqueness across multiple nodes property? If so, why?
>>>=20
>>>> Steve
>>>>=20
>>>> On 12/9/13 5:37 AM, Jouni Korhonen wrote:
>>>>> Folks
>>>>>=20
>>>>> Could we conclude on the sequence number vs. time stamp vs. =
something else?
>>>>> We got more important places to spend our energy than this ;)
>>>>>=20
>>>>> My proposal is the following (based on the original pre-00 =
design):
>>>>>=20
>>>>> o We change the OC-Sequence-Number to OC-Time-Stamp in all =
occurrences
>>>>> in the -01.
>>>>> o We use RFC6733 Time type for the OC-Time-Stamp. RFC6733 gives us
>>>>> already exact definition how to handle the AVP.
>>>>> o Define that the OC-Time-Stamp is the time of the creation of the=20=

>>>>> "original" AVP within whose context the time stamp is present.
>>>>> o The OC-Time-Stamp AVP uniqueness is still considered to be in =
scope
>>>>> of the communicating endpoints.
>>>>> o The time stamp can be used to quickly determine if the content =
of
>>>>> the encapsulating AVP context has changed (among other =
properties).
>>>>> This would be useful specifically in the future when the =
encapsulating
>>>>> grouped AVPs  grow in size and functionality.
>>>>>=20
>>>>>=20
>>>>> - Jouni
>>>>>=20
>>>>> _______________________________________________
>>>>> DiME mailing list
>>>>>=20
>>>>> DiME@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>>=20
>>>>>=20
>>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> DiME mailing list
>>>> DiME@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dime
>>>=20
>>> _______________________________________________
>>> DiME mailing list
>>> DiME@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dime
>>=20
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>=20


From ulrich.wiehe@nsn.com  Tue Dec 10 23:43:30 2013
Return-Path: 
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 DBDD41AE3A1 for ; Tue, 10 Dec 2013 23:43:30 -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 h7H7va43ls4c for ; Tue, 10 Dec 2013 23:43:28 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 1AB9E1ADF65 for ; Tue, 10 Dec 2013 23:43:27 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rBB7hJI2003902 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 11 Dec 2013 08:43:19 +0100
Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rBB7hID9022666 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Dec 2013 08:43:19 +0100
Received: from DEMUHTC011.nsn-intra.net (10.159.42.42) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 11 Dec 2013 08:43:18 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.152]) by DEMUHTC011.nsn-intra.net ([10.159.42.42]) with mapi id 14.03.0123.003; Wed, 11 Dec 2013 08:43:17 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Jouni 
Thread-Topic: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3
Thread-Index: AQHO9e8qVWG779dz9k2pnHnmYU487ZpOiY/wgAABi4CAABHrIA==
Date: Wed, 11 Dec 2013 07:43:17 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519E712@DEMUMBX014.nsn-intra.net>
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DB1B@DEMUMBX014.nsn-intra.net>  <52A5E902.20605@usdonovans.com> <7475B713-1104-4791-96B1-CE97632A0D69@nostrum.com>  <5BCBA1FC2B7F0B4C9D935572D90006681519E476@DEMUMBX014.nsn-intra.net> <1CD20507-B0FE-4367-804A-B831734CF060@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E6DC@DEMUMBX014.nsn-intra.net> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.112]
Content-Type: text/plain; charset="us-ascii"
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: 8476
X-purgate-ID: 151667::1386747799-00001A6F-7CF9F6E3/0-0/0-0
Cc: Ben Campbell , "dime@ietf.org list" 
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Dec 2013 07:43:31 -0000

That's not predictable. It may be the same server in some cases, and differ=
ent servers in other cases.

-----Original Message-----
From: ext Jouni [mailto:jouni.nospam@gmail.com]=20
Sent: Wednesday, December 11, 2013 8:38 AM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: Ben Campbell; dime@ietf.org list; Steve Donovan
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comment=
s to 4.3


Ulrich,

On Dec 11, 2013, at 9:21 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:

> Jouni,
>=20
> ad 1. "monotonically" does not express your intention. What we are lookin=
g for may be "stepwise with fixed step".
>=20
> Ad 2. Is not necessarily a mistake that could result in out-of-sequence s=
equence numbers. When a client C sends a realm-type requests towards any se=
rver in the realm, an agent A1 that selects the server would send back the =
realm-type OLR with sequence number s1. The next realm-type request sent by=
 C (that survived the throttling) may take a path that does not include A1 =
but A2. A2 then selects the server and sends back a sequence number s2. Not=
hing ensures that s1 and s2 are in sequence.

Would the server in both cases (via A1 and A2) be the same?

- Jouni


>=20
> Ulrich
>=20
>=20
> -----Original Message-----
> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
> Sent: Tuesday, December 10, 2013 10:31 PM
> To: Wiehe, Ulrich (NSN - DE/Munich)
> Cc: Ben Campbell; dime@ietf.org list; Steve Donovan
> Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comme=
nts to 4.3
>=20
> Ulrich,
>=20
> On Dec 10, 2013, at 4:31 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:
>=20
>> Jouni,
>>=20
>> 1. I find the texts
>> a) "The sequence number ... does not need to be monotonically increasing=
"
>> and=20
>=20
> Means the delta from old-seqno to new-seqno can be any non-negative integ=
er
> (within the given limits) not something fixed step/delta (like +1). As lo=
ng as
> "new-seqno >=3D old-seqno" holds we are fine.
>=20
>> b) "...the new sequence number MUST be greater or equal than the old seq=
uence number..."
>> contradicting.
>> Can you please clarify.
>=20
> See above. (mind the overflow case)
>=20
>> 2. The expected behaviour when receiving an out-of-sequence sequence num=
ber within OC-OLR is described in 4.3:
>>  "The receiver SHOULD discard an OC-OLR AVP with a sequence number that =
is less than previously received one."
>> I don't find this very robust. Once a higher sequence number (received e=
rroneously by mistake) is accepted you cannot (easily) recover.
>=20
> I find it more robust in a sense that I should not care about stale old i=
nformation.
> However, since we are piggybacking (by popular demand) we have little roo=
m for seqno
> re-sync negotiation.
>=20
> What is the mistake you refer here? A misbehaving implementation? In that=
 case, it=20
> deserves to get a manual intervention once figured out by admins checking=
 alarms and
> logs. If the mistake is due other things, like endpoints being out of syn=
c, we currently
> have no written down mechanism to survive that.
>=20
>> 3. The expected behaviour when receiving an out-of-sequence sequence num=
ber within the OC-Supported-Features AVP is not described. What is the inte=
ntion here?
>=20
> No intention. Just a sloppy specification. You are right that something n=
eeds to be
> done & clarified here. (again the semantics of Time would nice..)
>=20
> I'll propose something. Others should too ;)
>=20
> - Jouni
>=20
>>=20
>> Ulrich
>>=20
>> -----Original Message-----
>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Jouni Korhone=
n
>> Sent: Tuesday, December 10, 2013 8:28 AM
>> To: Ben Campbell; dime@ietf.org list; Steve Donovan
>> Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comm=
ents to 4.3
>>=20
>>=20
>> Fine.. lets define then the sequence number semantics. Basic
>> unsigned integer math. The text proposal is the following:
>>=20
>> 4.4.  OC-Sequence-Number AVP
>>=20
>>  The OC-Sequence-Number AVP (AVP code TBD3) is type of Unsigned64.
>>  Its usage in the context of the overload control is described in
>>  Sections 4.1 and 4.3.
>>=20
>>  From the functionality point of view, the OC-Sequence-Number AVP
>>  MUST be used as a non-volatile increasing counter between two
>>  overload control endpoints.  The sequence number is only required
>>  to be unique between two overload control endpoints and does not
>>  need to be monotonically increasing.
>>=20
>>  When comparing two sequence numbers, the new sequence number MUST
>>  be greater or equal than the old sequence number within a window
>>  that is half of the size of the maximum sequence number. This
>>  allows a simple handling of the sequence number overflow using
>>  unsigned integer arithmeticf:
>>=20
>>    #define WINDOW 0x8000000000000000ULL
>>=20
>>    bool verify_seqnum( uint64_t newsn, uint64_t oldsn ) {
>>        if (newsn - oldsn <=3D WINDOW)
>>            // newsn >=3D oldsn
>>            return true;  =20
>>        } else
>>            // outside window or newsn < oldsn
>>            return false; =20
>>        }
>>    }
>>=20
>>=20
>>=20
>> The above should even work is someone shovels NTP times into
>> sequence numbers with a blind typecasting.
>>=20
>> - Jouni
>>=20
>> On Dec 10, 2013, at 12:34 AM, Ben Campbell  wrote:
>>=20
>>>=20
>>> On Dec 9, 2013, at 10:00 AM, Steve Donovan  w=
rote:
>>>=20
>>>> Jouni,
>>>>=20
>>>> I propose that we keep the name OC-Sequence-Number but that we use the=
 Time type for OC-Sequence-Number.  It is misleading and potentially confus=
ing to call it OC-Time-Stamp. =20
>>>>=20
>>>=20
>>> I could live with that, although I would rather just define the expecte=
d properties of the sequence number, and leave the implementation up to the=
 implementor. I assume your reasoning for not calling it a timestamp is tha=
t you do not want people to try to use it as a time base reference. If so, =
then we don't require any connection to a clock. We just need it to be mono=
tonically increasing.
>>>=20
>>>> We might consider expanding on the format of the AVP to make it someth=
ing like Session-ID, where it is a concatenation of the Diameter-ID of the =
generating node and a timestamp.  This might help the reacting node keep tr=
ack of which sequence number it has received.
>>>>=20
>>>=20
>>> Do we need a uniqueness across multiple nodes property? If so, why?
>>>=20
>>>> Steve
>>>>=20
>>>> On 12/9/13 5:37 AM, Jouni Korhonen wrote:
>>>>> Folks
>>>>>=20
>>>>> Could we conclude on the sequence number vs. time stamp vs. something=
 else?
>>>>> We got more important places to spend our energy than this ;)
>>>>>=20
>>>>> My proposal is the following (based on the original pre-00 design):
>>>>>=20
>>>>> o We change the OC-Sequence-Number to OC-Time-Stamp in all occurrence=
s
>>>>> in the -01.
>>>>> o We use RFC6733 Time type for the OC-Time-Stamp. RFC6733 gives us
>>>>> already exact definition how to handle the AVP.
>>>>> o Define that the OC-Time-Stamp is the time of the creation of the=20
>>>>> "original" AVP within whose context the time stamp is present.
>>>>> o The OC-Time-Stamp AVP uniqueness is still considered to be in scope
>>>>> of the communicating endpoints.
>>>>> o The time stamp can be used to quickly determine if the content of
>>>>> the encapsulating AVP context has changed (among other properties).
>>>>> This would be useful specifically in the future when the encapsulatin=
g
>>>>> grouped AVPs  grow in size and functionality.
>>>>>=20
>>>>>=20
>>>>> - Jouni
>>>>>=20
>>>>> _______________________________________________
>>>>> DiME mailing list
>>>>>=20
>>>>> DiME@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>>=20
>>>>>=20
>>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> DiME mailing list
>>>> DiME@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dime
>>>=20
>>> _______________________________________________
>>> DiME mailing list
>>> DiME@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dime
>>=20
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>=20


From jouni.nospam@gmail.com  Wed Dec 11 00:16:10 2013
Return-Path: 
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 D65A81AE3BC for ; Wed, 11 Dec 2013 00:16:10 -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 Rbq4B5MsGs_K for ; Wed, 11 Dec 2013 00:16:08 -0800 (PST)
Received: from mail-bk0-x230.google.com (mail-bk0-x230.google.com [IPv6:2a00:1450:4008:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id C4B641ADF44 for ; Wed, 11 Dec 2013 00:16:07 -0800 (PST)
Received: by mail-bk0-f48.google.com with SMTP id r7so168060bkg.21 for ; Wed, 11 Dec 2013 00:16:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=JkjAsLhAWKAFB+TZYcWq03s1POWuTFuFI/iL9meuT7U=; b=vjYY8r2uTk9ntl70F1O/bASpaxEY94BRAzTkAbsbIhRBg0hBFPy3YwqIdJr1XGA/dq PPa5VYooeVCjPNP2quiOgCFGZdvgXR8ia6WfUi0hsx11rYgR5/TWo2+3vGFquy83+nfK QyyTI+cjYZvt43XGez+7IbZVaqgCErDcNCUosWH5r8a4Mvdtce1kvkVUoKGNFIcjJ3I9 /UqzYF2zK4opT8YCtern9Z0Ml67x6a5PdDM1lzQUmnzosJFOnL49if+rB8Mlcj4eBtBb fd1oUyLz82ipPDYBza6PPeIPDHwciq60fj+KdKU/R2YA/Tg046VUOK3JP/leKAbDmwIg A7yw==
X-Received: by 10.204.56.201 with SMTP id z9mr13430bkg.77.1386749761673; Wed, 11 Dec 2013 00:16:01 -0800 (PST)
Received: from ?IPv6:2001:1bc8:101:f101:4d7f:9ccd:6cf6:1b7? ([2001:1bc8:101:f101:4d7f:9ccd:6cf6:1b7]) by mx.google.com with ESMTPSA id it12sm13921744bkb.12.2013.12.11.00.15.56 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Dec 2013 00:15:57 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=us-ascii
From: Jouni 
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681519E712@DEMUMBX014.nsn-intra.net>
Date: Wed, 11 Dec 2013 10:15:55 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <4A151D70-0291-4238-85B1-03BB54B361E6@gmail.com>
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DB1B@DEMUMBX014.nsn-intra.net>  <52A5E902.20605@usdonovans.com> <7475B713-1104-4791-96B1-CE97632A0D69@nostrum.com>  <5BCBA1FC2B7F0B4C9D935572D90006681519E476@DEMUMBX014.nsn-intra.net> <1CD20507-B0FE-4367-804A-B831734CF060@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E6DC@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D90006681519E712@DEMUMBX014.nsn-intra.net>
To: "Wiehe, Ulrich (NSN - DE/Munich)" 
X-Mailer: Apple Mail (2.1283)
Cc: Ben Campbell , "dime@ietf.org list" 
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Dec 2013 08:16:11 -0000

Ulrich,

I might be slow but.. Section 4.4 says

   control endpoints.  The sequence number is only required to be unique
   between two overload control endpoints and does not need to be

Unique between two endpoints..

Section 5.1 talks about endpoints:

   of an arbitrary Diameter network.  The overload control information
   is exchanged over on a "DOIC association" between two communication
   endpoints.  The endpoints, namely the "reacting node" and the
   "reporting node" do not need to be adjacent Diameter peer nodes, nor

So if your agents inject realm reports, they need to be endpoints to the
client. Similar to Figure 5. Therefore the sequence number spaces =
between
C-A1 and C-A2 are separate.

Now it is not clear to me, whether in your reasoning the C would see
the server identity (as the endpoint) when there is an active "DEP
agent" on the path. That would not clearly work and not be align with
the endpoint assumption.

Note that at some point of time we had (at least on a discussion level
in f2f meeting) report originator identity in the OLR. That would make
endpoint identification trivial. Now a "DEP agent" needs to act as a=20
"server" for its clients in order to appear as an endpoint.

- Jouni

ps: still think the use of Time is simpler..


On Dec 11, 2013, at 9:43 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:

> That's not predictable. It may be the same server in some cases, and =
different servers in other cases.
>=20
> -----Original Message-----
> From: ext Jouni [mailto:jouni.nospam@gmail.com]=20
> Sent: Wednesday, December 11, 2013 8:38 AM
> To: Wiehe, Ulrich (NSN - DE/Munich)
> Cc: Ben Campbell; dime@ietf.org list; Steve Donovan
> Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: =
comments to 4.3
>=20
>=20
> Ulrich,
>=20
> On Dec 11, 2013, at 9:21 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>=20
>> Jouni,
>>=20
>> ad 1. "monotonically" does not express your intention. What we are =
looking for may be "stepwise with fixed step".
>>=20
>> Ad 2. Is not necessarily a mistake that could result in =
out-of-sequence sequence numbers. When a client C sends a realm-type =
requests towards any server in the realm, an agent A1 that selects the =
server would send back the realm-type OLR with sequence number s1. The =
next realm-type request sent by C (that survived the throttling) may =
take a path that does not include A1 but A2. A2 then selects the server =
and sends back a sequence number s2. Nothing ensures that s1 and s2 are =
in sequence.
>=20
> Would the server in both cases (via A1 and A2) be the same?
>=20
> - Jouni
>=20
>=20
>>=20
>> Ulrich
>>=20
>>=20
>> -----Original Message-----
>> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
>> Sent: Tuesday, December 10, 2013 10:31 PM
>> To: Wiehe, Ulrich (NSN - DE/Munich)
>> Cc: Ben Campbell; dime@ietf.org list; Steve Donovan
>> Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: =
comments to 4.3
>>=20
>> Ulrich,
>>=20
>> On Dec 10, 2013, at 4:31 PM, "Wiehe, Ulrich (NSN - DE/Munich)" =
 wrote:
>>=20
>>> Jouni,
>>>=20
>>> 1. I find the texts
>>> a) "The sequence number ... does not need to be monotonically =
increasing"
>>> and=20
>>=20
>> Means the delta from old-seqno to new-seqno can be any non-negative =
integer
>> (within the given limits) not something fixed step/delta (like +1). =
As long as
>> "new-seqno >=3D old-seqno" holds we are fine.
>>=20
>>> b) "...the new sequence number MUST be greater or equal than the old =
sequence number..."
>>> contradicting.
>>> Can you please clarify.
>>=20
>> See above. (mind the overflow case)
>>=20
>>> 2. The expected behaviour when receiving an out-of-sequence sequence =
number within OC-OLR is described in 4.3:
>>> "The receiver SHOULD discard an OC-OLR AVP with a sequence number =
that is less than previously received one."
>>> I don't find this very robust. Once a higher sequence number =
(received erroneously by mistake) is accepted you cannot (easily) =
recover.
>>=20
>> I find it more robust in a sense that I should not care about stale =
old information.
>> However, since we are piggybacking (by popular demand) we have little =
room for seqno
>> re-sync negotiation.
>>=20
>> What is the mistake you refer here? A misbehaving implementation? In =
that case, it=20
>> deserves to get a manual intervention once figured out by admins =
checking alarms and
>> logs. If the mistake is due other things, like endpoints being out of =
sync, we currently
>> have no written down mechanism to survive that.
>>=20
>>> 3. The expected behaviour when receiving an out-of-sequence sequence =
number within the OC-Supported-Features AVP is not described. What is =
the intention here?
>>=20
>> No intention. Just a sloppy specification. You are right that =
something needs to be
>> done & clarified here. (again the semantics of Time would nice..)
>>=20
>> I'll propose something. Others should too ;)
>>=20
>> - Jouni
>>=20
>>>=20
>>> Ulrich
>>>=20
>>> -----Original Message-----
>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Jouni =
Korhonen
>>> Sent: Tuesday, December 10, 2013 8:28 AM
>>> To: Ben Campbell; dime@ietf.org list; Steve Donovan
>>> Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: =
comments to 4.3
>>>=20
>>>=20
>>> Fine.. lets define then the sequence number semantics. Basic
>>> unsigned integer math. The text proposal is the following:
>>>=20
>>> 4.4.  OC-Sequence-Number AVP
>>>=20
>>> The OC-Sequence-Number AVP (AVP code TBD3) is type of Unsigned64.
>>> Its usage in the context of the overload control is described in
>>> Sections 4.1 and 4.3.
>>>=20
>>> =46rom the functionality point of view, the OC-Sequence-Number AVP
>>> MUST be used as a non-volatile increasing counter between two
>>> overload control endpoints.  The sequence number is only required
>>> to be unique between two overload control endpoints and does not
>>> need to be monotonically increasing.
>>>=20
>>> When comparing two sequence numbers, the new sequence number MUST
>>> be greater or equal than the old sequence number within a window
>>> that is half of the size of the maximum sequence number. This
>>> allows a simple handling of the sequence number overflow using
>>> unsigned integer arithmeticf:
>>>=20
>>>   #define WINDOW 0x8000000000000000ULL
>>>=20
>>>   bool verify_seqnum( uint64_t newsn, uint64_t oldsn ) {
>>>       if (newsn - oldsn <=3D WINDOW)
>>>           // newsn >=3D oldsn
>>>           return true;  =20
>>>       } else
>>>           // outside window or newsn < oldsn
>>>           return false; =20
>>>       }
>>>   }
>>>=20
>>>=20
>>>=20
>>> The above should even work is someone shovels NTP times into
>>> sequence numbers with a blind typecasting.
>>>=20
>>> - Jouni
>>>=20
>>> On Dec 10, 2013, at 12:34 AM, Ben Campbell  wrote:
>>>=20
>>>>=20
>>>> On Dec 9, 2013, at 10:00 AM, Steve Donovan =
 wrote:
>>>>=20
>>>>> Jouni,
>>>>>=20
>>>>> I propose that we keep the name OC-Sequence-Number but that we use =
the Time type for OC-Sequence-Number.  It is misleading and potentially =
confusing to call it OC-Time-Stamp. =20
>>>>>=20
>>>>=20
>>>> I could live with that, although I would rather just define the =
expected properties of the sequence number, and leave the implementation =
up to the implementor. I assume your reasoning for not calling it a =
timestamp is that you do not want people to try to use it as a time base =
reference. If so, then we don't require any connection to a clock. We =
just need it to be monotonically increasing.
>>>>=20
>>>>> We might consider expanding on the format of the AVP to make it =
something like Session-ID, where it is a concatenation of the =
Diameter-ID of the generating node and a timestamp.  This might help the =
reacting node keep track of which sequence number it has received.
>>>>>=20
>>>>=20
>>>> Do we need a uniqueness across multiple nodes property? If so, why?
>>>>=20
>>>>> Steve
>>>>>=20
>>>>> On 12/9/13 5:37 AM, Jouni Korhonen wrote:
>>>>>> Folks
>>>>>>=20
>>>>>> Could we conclude on the sequence number vs. time stamp vs. =
something else?
>>>>>> We got more important places to spend our energy than this ;)
>>>>>>=20
>>>>>> My proposal is the following (based on the original pre-00 =
design):
>>>>>>=20
>>>>>> o We change the OC-Sequence-Number to OC-Time-Stamp in all =
occurrences
>>>>>> in the -01.
>>>>>> o We use RFC6733 Time type for the OC-Time-Stamp. RFC6733 gives =
us
>>>>>> already exact definition how to handle the AVP.
>>>>>> o Define that the OC-Time-Stamp is the time of the creation of =
the=20
>>>>>> "original" AVP within whose context the time stamp is present.
>>>>>> o The OC-Time-Stamp AVP uniqueness is still considered to be in =
scope
>>>>>> of the communicating endpoints.
>>>>>> o The time stamp can be used to quickly determine if the content =
of
>>>>>> the encapsulating AVP context has changed (among other =
properties).
>>>>>> This would be useful specifically in the future when the =
encapsulating
>>>>>> grouped AVPs  grow in size and functionality.
>>>>>>=20
>>>>>>=20
>>>>>> - Jouni
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> DiME mailing list
>>>>>>=20
>>>>>> DiME@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>=20
>>>>> _______________________________________________
>>>>> DiME mailing list
>>>>> DiME@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>=20
>>>> _______________________________________________
>>>> DiME mailing list
>>>> DiME@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dime
>>>=20
>>> _______________________________________________
>>> DiME mailing list
>>> DiME@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dime
>>=20
>=20


From jean-jacques.trottin@alcatel-lucent.com  Wed Dec 11 00:27:55 2013
Return-Path: 
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 ; 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 ; 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 ; 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 ; 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 ; 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)" 
To: "dime@ietf.org list" 
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: 
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>  <14594_1386204165_529FCC05_14594_12646_1_6B7134B31289DC4FAF731D844122B36E329907@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B920972CCAA@ESESSMB101.ericsson.se>  <52A077CC.3000004@usdonovans.com>  <52A088D0.2020406@usdonovans.com>  <52A091CE.2000104@usdonovans.com> <13081_1386256433_52A09831_13081_8197_1_6B7134B31289DC4FAF! 731D84412 2B36E32B6EB@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B9209739738@ESESSMB101.ericsson.se>  <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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Dec 2013 08:27:55 -0000

--_000_E194C2E18676714DACA9C3A2516265D201CB4AA4FR712WXCHMBA12z_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

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 multip=
ly the number of AVPs in the OLRs (AVPs identifying Application, destinatio=
n 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 sel=
f 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 rec=
reate  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 si=
mple way to proceed, which drove to the current draft content. This decisio=
n is a strong argument that still prevails  for the current baseline descri=
bed in the current draft.

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

As also said, when news requirements will appear (eg session group or APN e=
xamples)  the baseline is extensible to support these new requirements .  I=
 prefer this way of progressive extensions , rather than to create a self c=
ontained 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=E9 : mardi 10 d=E9cembre 2013 04:58
=C0 : 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 righ=
t 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 opti=
mization 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 overloa=
d.

-          The last three pros are mainly for the case of overload of agent=
, if I understood them correctly. Overload of agent is still a controversia=
l scenario, we may need more discussion in the future. But anyway, with def=
inition 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-co=
ntained OLR.

Best Regards,
Susan

From: Ben Campbell [mailto:ben@nostrum.com]
Sent: Tuesday, December 10, 2013 7:53 AM
To: 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 wh=
at we do for a later (or final) version.

So far, I've seen 4 people opposed to self-contained OLRs (Lionel, Nirav, M=
aria, 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 lo=
ok 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 firs=
t group explain what they think the pros of implicit OLRs might be beyond t=
hose 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 application=
s at once, instead of having to signal each one separately.
  *   Allows an easy solution to our "loss" algorithm corner case of not be=
ing able to signal the end of a 100% overload condition
  *   Makes it easier to solve the agent overload problem, without requirin=
g 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 transac=
tion 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 trans=
action context and the report type. [I don't understand why this is valuabl=
e, 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 supporte=
d 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 > wrote:


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

- Jouni


--_000_E194C2E18676714DACA9C3A2516265D201CB4AA4FR712WXCHMBA12z_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hi Ben and all



 <=
/p>

I remind my mail of 05/12=
, where the self contained OLRs approach is quite similar to the self conta=
ined 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 i=
n draft Roach).  


This also result in a pig=
gybacking  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 ho=
p, the self contained  OLRs are opened to be reprocessed in order to r=
ecreate  new self contained OLR(s)  to various destinations.



I remind that, now 6 mont=
hs 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 con=
tent. This decision is a strong argument that still prevails  for the =
current baseline described in the current draft.


 


This is why I remain in f=
avor of the baseline  described in the current  draft, as as I ha=
ve always and regularly  expressed for  a while.


 <=
/p>

As also said, when news r=
equirements will appear (eg session group or APN examples)  the baseli=
ne is extensible to support these new requirements .  I prefer
 this way of progressive extensions , rather than to create a self containe=
d OLR  with an  immediate and not needed complexity   &=
nbsp;


 <=
/p>

Best regards


 <=
/p>

JJacques


 <=
/p>

 <=
/p>





De : DiME [mailto:dime-bounces@ietf.org]
De la part de Shishufeng (Susan)

Envoy=E9 : mardi 10 d=E9cembre 2013 04:58

=C0 : Ben Campbell; dime@ietf.org list

Objet : Re: [Dime] DOIC: Self-Contained OLRs<=
/p>





 


Hi Ben,=



 <=
/p>

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



 <=
/p>

Quick thinking on the pro=
s you listed for self-contained OLR.


 <=
/p>


-  &n=
bsp;      
The first two pro=
s can be seen as optimization, on which we are still arguing if these optim=
ization are worth doing or not, since such optimization
 brings extra cost.



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



-  &n=
bsp;      
The last three pr=
os are mainly for the case of overload of agent, if I understood them corre=
ctly. 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.


 <=
/p>

Best Regards,<=
/span>


Susan

 <=
/p>





From: Ben Camp=
bell [mailto:ben@nostrum.com]


Sent: Tuesday, December 10, 2013 7:53 AM

To: dime@ietf.org list

Subject: Re: [Dime] DOIC: Self-Contained OLRs






 




I am willing to call the discussion concluded for th=
e 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 conse=
nsus. 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 explai=
n 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 no=
t already weighed into this.






 






Self-Contained O=
LRS:






 






Pros:






    

  • 
Allows an easy, generic solution to Maria's "all-application" sco=
ped overload use case.
  • 
Allows an overloaded node to signal overload for multiple applications at o=
nce, instead of having to signal each one separately.
  • 
Allows an easy solution to our "loss" algorithm corner case of no=
t being able to signal the end of a 100% overload condition
    • =

  • 
Makes it easier to solve the agent overload problem, without requiring inco=
nsistent behavior.
  • 
Allows out-of-band transmission of OLRs without a new format
  • 
Makes it easier to do things like adding a dedicated application for overlo=
ad, 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 i=
n 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" s=
cope.
  • 
An overloaded node needs to send a separate report for every supported appl=
ication.
  • 
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.
  •  
    







 






 




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








OK. Lets call this thread concluded then. I keep the old OC-OLR  seman=
tics

regarding its information context then unmodified.



- Jouni


 




Hello all,=



 =
;


I’m =
trying to follow up all these discussions.


 =
;


Firs=
tly quick answer to Steve’s following question, “Strongly No=
221; to have self-contained OC-OLR. Apart from that I agree with the argume=
nts from Nirav and Lionel, it is not needed anyway at this
 stage. Extension is allowed and can be defined if needed in the future. I =
don’t even see the need to have the report-type for 3GPP applications=
 usage if considering the realm in 3GPP is with PLMN granularity, but IR=
17;m not going to kick off again the discussion
 on it. I could live with it as an optional AVP and the OC-OLR applies to t=
he Origin-Host of the Answer when the report type is absent, exactly as wha=
t Lionel suggested.


 


I=
217;ll come up with other threads.


 =
;


Best Regar=
ds,


Susan=



 =
;






From:=
 Nirav Salot (nsalot=
) [mailto:nsalot@cisco.com]


Sent: Thursday, December 05, 2013 10:00 PM

To: Steve Donovan; dime@ietf.org

Subject: Re: [Dime] DOIC: Self-Contained OLRs






 


Steve,


 =
;


> If we are to pose a question at this point I would s=
uggest -- Can everyone live with self-contained overload reports?


Strongly N=
O.


 =
;


I can make=
 the same arguments as you are making – "I have yet to see a sin=
gle STRONG argument to justify the use of self-contained OC-OLR".=



 =
;


All the ar=
guments related to software layering, easy for the developers etc. are very=
 specific to the implementation and I don’t agree to define
 protocol solution suitable to a specific architecture.

 =
;


Regards,


Nirav.


 =
;



 


=
Lionel,



I strongly disagree with your conclusion that there is little support for s=
elf-contained OLRs. 




I also object to your assessment that there are strong arguments against se=
lf-contained reports.  I have yet to see a single STRONG argument.



I also object to your attempting to call the question at this point in the =
discussion.



The only arguments I see for the implicit approach is complexity, which I j=
ust sent an email refuting and schedule, about which I also just sent an em=
ail.



Self contained reports work just as well and has advantages both short term=
 in support for non application specific software layering and in the long =
term in allowing for the same overload report to be transported using multi=
ple DOC solutions.



I also don't agree that this has been a particularly long thread.  The=
re are multiple topics being discussed under the same subject line.



If we are to pose a question at this point I would suggest -- Can everyone =
live with self-contained overload reports?



Steve




On 12/5/13 7:28 AM, 
lionel.morand@orange.com wrote:






All,


 


After this=
 LONG thread, it seems that there are strong arguments against the self-con=
tained OLRs and little support.


In the con=
trary, it seems that the principle of OLR related to the application in use=
 is technically OK for everyone.



 


So the que=
stion is quite simple:



 


Could ever=
yone live/survive with the "implicit approach" with the extensibi=
lity mechanism allowing future extensions if needed?


 


If yes, pl=
ease focus on the finalization of the current draft.


If no, let=
 go on the discussion.


 


Regards,


 


Lionel


 


 






De&nb=
sp;: DiME [mailto:dime-bounces@ietf.org]
De la part de Steve Donovan

Envoy=E9 : jeudi 5 d=E9cembre 2013 14:06

=C0 : dime@ietf.org

Objet : Re: [Dime] DOIC: Self-Contained OLRs






 


=
On the schedule question mentioned by JJacques -- any schedule concerns can=
 go away if everyone agrees to self contained overload reports.  This =
discussion would end and we could move on to
 other things.  :-)



I say that somewhat in jest but please don't make the argument that this di=
scussion should be ended because of schedule.  Or if you make that arg=
ument, please don't assert that the person who disagrees with you is puttin=
g the schedule at risk.



We are striving for the best technical solution.  We all understand th=
e schedule pressures.  We need to balance the two.



Steve




On 12/5/13 5:14 AM, TROTTIN, JE=
AN-JACQUES (JEAN-JACQUES) wrote:






Hi 


 


A lot of mails on this topic...I would suggest to=
 introduce an overload control on the Dime email threads:)  


 


 


On my side, I rely on what we have written in the=
  draft for the "baseline" mechanism and that we have to kee=
p as it is simple and efficient, here I join Lionel, Nirav and MCruz' posit=
ions.


 


This thread then addresses extensions  cases=
, I agree that we will have to address such extensions:   Nirav m=
entioned the example with APN that if relevant would  a 3GGP applicati=
on case, I would add the Session Group about which we had some discussion a=
 while ago and  which is a more generic IETF case. There is also the a=
gent overload case. Have you others? Always good to have some use cases in =
mind.


 


What is important for me is that adding extension=
s should not modify the baseline and making it more complex when used alone=
.  I also make a difference between principles and protocol tuning whe=
re we may have to choose between various protocol solution but addressing t=
he same functionality or principle.  


 


About piggybacking, in the baseline,  the pr=
inciple is that OLRs  which  are addressed  to sources of tr=
affic are put in answer messages towards this traffic sources (origin Host)=
 (even if these messages  may be processed by intermediate DAs), which=
 is simple and the OLR can be kept unchanged in the same message  up t=
o the origin Host if no specific process in intermediate DAs.  To have=
 a piggybacking allowing to put any OLR in any message (as it was in draft =
roach)  is adding complexity that is not justified for the baseline an=
d we have not retained it in the existing draft .


 


About extensions, the APN or session group  =
examples address  parts of the traffic between a server and a client (=
so a higher granularity in the throttling than the baseline one), related O=
LRs are conveyed in the messages towards the origin Host so with an implici=
t reference to the Application, the  Origin and Destination Host as fo=
r the baseline, so not requiring self contained OLRs. I also  do not s=
ee the interest to send these new extensions OLR only in answers directly r=
elated to this OLR (as Ulrich proposed), eg only in an answer dealing with =
an APN if the OLR is related to APN throttling.  The main point is tha=
t the OLR takes a direct "train" towards the right destination fo=
r a given application (as for baseline).


 


This does not exclude that we may have other case=
s not entering the above examples characteristics, but as Nirav mentioned, =
we  have to remain pragmatic and see this when such new use cases will=
 be addressed. The extensibility possibilities of  current draft give =
us a lot of flexibility, e.g. if some extensions need more self contained A=
VPs, why not, but this is outside the current draft. 

 


About extensions, I also think that they may need=
 to be identified in the capability part, as the related OLRs should not be=
 sent by a reacting node if the extension is not supported.


 


Last important point, as  Lionel mentioned, =
we have to finalize the draft soon, to be able to start Rel12 3GGP work rel=
ying on this draft. My position is that the current draft is currently well=
 suited for the baseline and that extensions will be addressed separately&n=
bsp; 


 


Best regards


 


JJacques 


 


 


-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de Ben Campbell


Envoy=E9 : mercredi 4 d=E9cembre 2013 22:55<=
o:p>


=C0 : ext lionel.morand@orange.com


Cc : dime@i=
etf.org


Objet : Re: [Dime] DOIC: Self-Contained OLRs=



 


On Dec 3, 2013, at 5:17 PM, lionel.morand@orange.com wrote:


 




Hi Ben,


 


I may be wrong somewhere in my summary but I thin=
k that it was the result of the discussions and agreements reached regardin=
g existing requirements, at least from 3GPP point of view, compared to poss=
ible optimizations for future optimizations not so obvious.




 


We are not the 3GPP. Our requirements are RFC 706=
8. I believe self-contained OLRs do a better job of meeting Req 31 than the=
 contextually-defined OLRs.


 


I've made several technical arguments here--does =
anyone have _technical_ arguments in favor of contextually-defined OLRs?


 




And because the solution offers extensibility via=
 the definition of new algo, new report type and addition of any new AVP in=
 the existing Grouped OLR, the "limitations" of the proposed solu=
tion might be removed by someone if really required according to new requir=
ements.


 




 


It might be worth considering a compromise approa=
ch: Define _optional_ AVPs that allow an OLR to be self-contained. If they =
are not present, then the various values default to those from the enclosin=
g Diameter message. Possibly add support for this to the list of things tha=
t reacting nodes can advertise.


 


This could be in the base, or in a follow on exte=
nsion. (If left for an extension, it's worth considering whether ReportType=
 needs to be in the base, or this or some other extension.) 


 


 




Regards,


 


Lionel


 


-----Message d'origine-----

De : Ben Campbell [mailto:ben@nostrum.com] Envoy=E9 : mardi 3 d=E9cembre <=
/span>


2013 23:56 =C0 : MORAND Lionel IMT/OLN Cc : Steve=
 Donovan; dime@ietf.org 


Objet : Re: [Dime] DOIC: Self-Contained OLRs=



 


 


On Dec 2, 2013, at 10:18 AM, lionel.morand@orange.com wrote:


 




Hi Steve,


 


I think that is not only about few bytes in the a=
nswer. It is also about the solution principles agreed so far:


=B7       &nbs=
p; the current need is for an OLR bound to the application in use


=B7       &nbs=
p; the OLR is received from the node targeted in the request.


=B7       &nbs=
p; the OLR is defined per application




 


I don't think those principles have been well tes=
ted. I don't recall any discussion of their benefits. What benefits do you =
see they have over self-contained OLRs?


 


All I see from these are restrictions in the flex=
ibility of the solution, with very little in return.

 




So all the implicit information (application, ori=
gin-host, origin-realm) are meaningful in this context.

And the actual solution is designed based on thes=
e assumptions. The extensibility of the solution will allow extra info if r=
equired in other use cases but it was agreed to go with a straightforward s=
olution that will satisfy most of us.


 


Regards,


 


Lionel


 


De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan=



Envoy=E9 : lundi 2 d=E9cembre 2013 16:37


=C0 : dime@ietf.=
org


Objet : Re: [Dime] DOIC: Self-Contained OLRs=



 


I don't believe that Ben's proposal was to change=
 the piggybacking assumption in the baseline mechanism.  Ben's proposa=
l is to design the solution in such a way that it is not dependent on the p=
iggybacking transport mechanism.  


 


I share Ben's concern that we have over optimized=
 the content of the overload report in a way that makes implementations bri=
ttle, interoperability more difficult to achieve and extensibility more com=
plex.  And what do we gain from this optimization?  A few bites i=
n answer messages.


 


Self contained overload reports, transported usin=
g the piggybacking mechanism, is a cleaner solution.

 


Steve


 


On 11/29/13 8:31 AM, lionel.morand@orange.com wrote:


I totally agree with Nirav. No need to revert at =
this stage the working assumption on piggybacking of OLR in application ans=
wer messages, especially when the aim is to define a basic mechanism called=
 "reduction".


 


Anyone would be able to further add extra info fo=
r optimization if needed but there is no need at all for the basic mechanis=
m.


 


Regards,


 


Lionel


 


-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot (nsalot)


Envoy=E9 : vendredi 29 novembre 2013 12:24


=C0 : Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Mun=
ich); dime@ietf.org list


Cc : Ben Campbell


Objet : Re: [Dime] DOIC: Self-Contained OLRs=



 


Jouni, Ben,


 


I am totally against the idea of self-contained O=
C-OLR specifically since we have adopted the principles of piggybacking the=
 OC-OLR over existing application message.


Self-contained OC-OLR - which means adding all th=
e information which defines the scope of the OC-OLR into the OC-OLR - does =
not make sense in the piggybacking approach. In fact, it is adding lot of i=
nformation, which is anyway available within the message containing the OC-=
OLR, into the OC-OLR. So it is adding lot of redundant information in a mes=
sage which increases the processing requirement for the sender as well as t=
he receiver. (And this is un-optimization, in my view).

 


Besides, I am not convinced with the other reason=
s provided here:


- One software module within a node can provide O=
C-OLR to another software module in the same node without passing other rel=
ated info


  Within a node, based on the design, lots o=
f information may need to be passed between two software modules and we can=
not optimize those aspects by replicating unnecessary information in a prot=
ocol message.


  In summary, it is node's internal software=
 design issue and we need not optimize that at protocol level.


 


- Once the reporting node realizes that it is ove=
rloaded, it has to wait for right answer to send OC-OLR

 What is the point of sending OC-OLR for a contex=
t for which there is no messaging? Why should the reacting node care if it =
never sends a message for a context for which the reporting node is overloa=
ded?


 So this waiting is justified since it ensures th=
at the overload is reported only when necessary and only to the applicable =
reacting node. Not to all the nodes in the network.


 


- The agent needs to wait for the answer generate=
d by the server and the right context


  The same argument as applicable for the se=
rver applies here. The agent need not send out-of-context overload info to =
a node.


  Why should reacting node receive/process/s=
tore the overload info for the scope for which it is not sending any messag=
es.


 


- For sending OC-OLR in dedicated Diameter applic=
ation???


 Piggybacking was the first basic principle we ag=
reed before putting other principles in place. So we may want to go back th=
e drawing board if we decide to change this principle.

 


Regards,


Nirav.


 


-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen


Sent: Friday, November 29, 2013 2:50 PM


To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org list


Cc: Ben Campbell


Subject: Re: [Dime] DOIC: Self-Contained OLRs


 


 


 


So, are we reaching any level of consensus here?<=
o:p>


 


- JOuni


 


(as a note.. that we are converging back to where=
 we started with OLRs ;)


 


 


 


On Nov 28, 2013, at 12:40 PM, "Wiehe, Ulrich=
 (NSN - DE/Munich)" <ulrich=
.wiehe@nsn.com> wrote:


 


Hi,


 


another question:


 


If we go for explicit self contained OLRs, why wo=
uld we then need the ReportType?


 


The realm-type OLR would explicitly contain appli=
cation-Id, Realm, but no Host whereas the host-type OLR would explicitly co=
ntain application-Id, Host, but probably (I'm not sure) no Realm.


 


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 Ko=
rhonen; Ben Campbell


Cc: dime@ietf.or=
g list


Subject: RE: [Dime] DOIC: Self-Contained OLRs


 


Hi,


 


There is no assumption on which entity is providi=
ng 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 w=
ould know this info by some internal magic.


But in any case, if we assume that the client wil=
l 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=E9 : jeudi 28 novembre 20=
13 10:26 =C0 : 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". I=
f the ReportType is "realm" this indicates to the reacting end po=
int that the reporting end point is an agent (e.g. SFE) rather than a serve=
r. 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<=
/o:p>


To: Ben Campbell


Cc: dime@ietf.or=
g list


Subject: Re: [Dime] DOIC: Self-Contained OLRs


 


 


On Nov 28, 2013, at 12:27 AM, Ben Campbell <ben@nostrum.com> wrote:<=
/span>


 


Hi,


 


I mentioned in another thread that I prefer putti=
ng an explicit 


ReportType AVP in an OLR, rather than<=
/span>


 


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 princi=
ple" we have in the draft. 


It indeed gives more tools to make a host vs. rea=
lm 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 meanin=
g of the OLR from a Diameter request that corresponds to the answer contain=
ing 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 enc=
losing answer, the realm identified by Origin-Realm, and so on. This means =
that the "meaning" of an OLR cannot be determined from the OLR co=
ntents 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 c=
ompletely.


 


I think this approach is a mistake. I would great=
ly prefer that we explicitly include such values in the OLR itself, for mul=
tiple reasons:


 


1) It's more complex to interpret implicit, conte=
xtual values than explicit values. The consumer cannot simply look at the O=
LR; 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 proces=
sing to be separated from application processing. The consumer cannot simpl=
y 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 s=
pec), the number of "context" avps that must be interpreted can g=
row 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.<=
/o:p>


 


2) It's more complex for the reporting node to se=
nd implicit values than explicit values. The sender cannot simply set the c=
ontext 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 e=
rror prone implementations. Self-contained OLRs are simpler to create and s=
end.


 


3) Implicit values don't work at all for certain =
problems. For 


example, if an agent needs to originate an OLR, i=
t 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 com=
es from or refers to 


the node identified by the Origin-Host AVP in the=
 enclosing answer, 


things break. (For examples of when an agent need=
s to send OLRs that 


are distinct from those sent by a server, see Ste=
ve's agent overload 


draft, or my dh/dr example.)

 


OTOH, explicit values will work for all cases whe=
re 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 r=
eason to allow OLRs to be sent out of band, or be sent in a dedicated Diame=
ter application. If overload reports were self-contained, one could just re=
use 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 ne=
w or significantly modified OLR format if we found a need to transport OLRs=
 in different ways. Self-contained OLRs would allow much greater flexibilit=
y.


 


So, in summary, I think that self-contained OLRs =
would lead to simpler implementations, less brittle deployments, and more f=
lexibility 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 don=
c pas etre diffuses, 


exploites ou copies sans autorisation. Si vous av=
ez recu ce message 


par erreur, veuillez le signaler a l'expediteur e=
t le detruire ainsi que les pieces jointes. Les messages electroniques etan=
t susceptibles d'alteration, Orange decline toute responsabilite si ce mess=
age a ete altere, deforme ou falsifie. Merci.


 


This message and its attachments may contain conf=
idential or 


privileged information that may be protected by l=
aw; 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 fo=
r 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

 


_________________________________________________=
________________________________________________________________________


 


Ce message et ses pieces jointes peuvent contenir=
 des informations confidentielles ou privilegiees et ne doivent donc


pas etre diffuses, exploites ou copies sans autor=
isation. Si vous avez recu ce message par erreur, veuillez le signaler=



a l'expediteur et le detruire ainsi que les piece=
s 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 conf=
idential or privileged information that may be protected by law;=



they should not be distributed, used or copied wi=
thout 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 fo=
r 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 autor=
isation. Si vous avez recu ce message par erreur, veuillez le signaler=



a l'expediteur et le detruire ainsi que les piece=
s 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 conf=
idential or privileged information that may be protected by law;=



they should not be distributed, used or copied wi=
thout 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 fo=
r 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 autor=
isation. Si vous avez recu ce message par erreur, veuillez le signaler=



a l'expediteur et le detruire ainsi que les piece=
s 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 conf=
idential or privileged information that may be protected by law;=



they should not be distributed, used or copied wi=
thout 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 fo=
r 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 autor=
isation. Si vous avez recu ce message par erreur, veuillez le signaler=



a l'expediteur et le detruire ainsi que les piece=
s 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 conf=
idential or privileged information that may be protected by law;=



they should not be distributed, used or copied wi=
thout 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 fo=
r messages that have been modified, changed or falsified.=



Thank you.


=







_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.ietf.org/mailman/listinfo/dime



 






--_000_E194C2E18676714DACA9C3A2516265D201CB4AA4FR712WXCHMBA12z_--

From srdonovan@usdonovans.com  Wed Dec 11 05:13:55 2013
Return-Path: 
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 A91021ADBCA for ; Wed, 11 Dec 2013 05:13:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.12
X-Spam-Level: 
X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no
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 PfKKg0jup3NS for ; Wed, 11 Dec 2013 05:13:52 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 94EDB1AD9B6 for ; Wed, 11 Dec 2013 05:13:52 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:49475 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1Vqjbc-0005VE-Nj; Wed, 11 Dec 2013 05:13:43 -0800
Message-ID: <52A864FF.10705@usdonovans.com>
Date: Wed, 11 Dec 2013 07:13:35 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Jouni ,  "Wiehe, Ulrich (NSN - DE/Munich)" 
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DB1B@DEMUMBX014.nsn-intra.net>  <52A5E902.20605@usdonovans.com> <7475B713-1104-4791-96B1-CE97632A0D69@nostrum.com>  <5BCBA1FC2B7F0B4C9D935572D90006681519E476@DEMUMBX014.nsn-intra.net> <1CD20507-B0FE-4367-804A-B831734CF060@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E6DC@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D90006681519E712@DEMUMBX014.nsn-intra.net> <4A151D70-0291-4238-85B1-03BB54B361E6@gmail.com>
In-Reply-To: <4A151D70-0291-4238-85B1-03BB54B361E6@gmail.com>
Content-Type: multipart/alternative; boundary="------------070403000808000502070608"
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com
Cc: Ben Campbell , "dime@ietf.org list" 
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Dec 2013 13:13:55 -0000

This is a multi-part message in MIME format.
--------------070403000808000502070608
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Jouni,

We need the sequence number to be strictly increasing.  I don't see the
need for it to increase in uniform amounts.  Using time does fit these
requirements.  I'm ok with using time as long as we don't call the AVP
timestamp.

Ulrich does bring up an interesting use case, where a client is
receiving realm reports for the same realm from different agents.  We
need to define the clients behavior in this case. 

Presumably the client needs to be able to determine who generated the
realm report.  This cannot be determine based on the content of the
message or the connection on which the message arrived.  It seems like
we might need "Report Generator Diameter ID" in the overload report
specifically for Realm reports. 

Once the client is able to differentiate between realm reports sent by
different agents (or servers) we need logic defining how the client
deals with a new overload report. 

I see a couple of options (others will probably see options I am missing):

- Use the last received realm report - This introduces the possibility
of thrashing between two different reduction values and different
durations.  Note that this approach does not require the source of the
report to be included in the report.

- Only listen to one source of realm overload - The approach would be to
remember who sent the first overload report from the realm and ignore
realm overload reports from other sources.  This behavior would likely
be constrained to a single occurrence of realm overload.  Meaning that
the "memory" of the report source would only last as long as that
overload event persists.  Once the overload event goes away, the report
source would be forgotten and a new source could be used for the next
occurrence.

On the surface, the second approach looks better to me.

Steve

On 12/11/13 2:15 AM, Jouni wrote:
> Ulrich,
>
> I might be slow but.. Section 4.4 says
>
>    control endpoints.  The sequence number is only required to be unique
>    between two overload control endpoints and does not need to be
>
> Unique between two endpoints..
>
> Section 5.1 talks about endpoints:
>
>    of an arbitrary Diameter network.  The overload control information
>    is exchanged over on a "DOIC association" between two communication
>    endpoints.  The endpoints, namely the "reacting node" and the
>    "reporting node" do not need to be adjacent Diameter peer nodes, nor
>
> So if your agents inject realm reports, they need to be endpoints to the
> client. Similar to Figure 5. Therefore the sequence number spaces between
> C-A1 and C-A2 are separate.
>
> Now it is not clear to me, whether in your reasoning the C would see
> the server identity (as the endpoint) when there is an active "DEP
> agent" on the path. That would not clearly work and not be align with
> the endpoint assumption.
>
> Note that at some point of time we had (at least on a discussion level
> in f2f meeting) report originator identity in the OLR. That would make
> endpoint identification trivial. Now a "DEP agent" needs to act as a 
> "server" for its clients in order to appear as an endpoint.
>
> - Jouni
>
> ps: still think the use of Time is simpler..
>
>
> On Dec 11, 2013, at 9:43 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
>> That's not predictable. It may be the same server in some cases, and different servers in other cases.
>>
>> -----Original Message-----
>> From: ext Jouni [mailto:jouni.nospam@gmail.com] 
>> Sent: Wednesday, December 11, 2013 8:38 AM
>> To: Wiehe, Ulrich (NSN - DE/Munich)
>> Cc: Ben Campbell; dime@ietf.org list; Steve Donovan
>> Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3
>>
>>
>> Ulrich,
>>
>> On Dec 11, 2013, at 9:21 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>>
>>> Jouni,
>>>
>>> ad 1. "monotonically" does not express your intention. What we are looking for may be "stepwise with fixed step".
>>>
>>> Ad 2. Is not necessarily a mistake that could result in out-of-sequence sequence numbers. When a client C sends a realm-type requests towards any server in the realm, an agent A1 that selects the server would send back the realm-type OLR with sequence number s1. The next realm-type request sent by C (that survived the throttling) may take a path that does not include A1 but A2. A2 then selects the server and sends back a sequence number s2. Nothing ensures that s1 and s2 are in sequence.
>> Would the server in both cases (via A1 and A2) be the same?
>>
>> - Jouni
>>
>>
>>> Ulrich
>>>
>>>
>>> -----Original Message-----
>>> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] 
>>> Sent: Tuesday, December 10, 2013 10:31 PM
>>> To: Wiehe, Ulrich (NSN - DE/Munich)
>>> Cc: Ben Campbell; dime@ietf.org list; Steve Donovan
>>> Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3
>>>
>>> Ulrich,
>>>
>>> On Dec 10, 2013, at 4:31 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:
>>>
>>>> Jouni,
>>>>
>>>> 1. I find the texts
>>>> a) "The sequence number ... does not need to be monotonically increasing"
>>>> and 
>>> Means the delta from old-seqno to new-seqno can be any non-negative integer
>>> (within the given limits) not something fixed step/delta (like +1). As long as
>>> "new-seqno >= old-seqno" holds we are fine.
>>>
>>>> b) "...the new sequence number MUST be greater or equal than the old sequence number..."
>>>> contradicting.
>>>> Can you please clarify.
>>> See above. (mind the overflow case)
>>>
>>>> 2. The expected behaviour when receiving an out-of-sequence sequence number within OC-OLR is described in 4.3:
>>>> "The receiver SHOULD discard an OC-OLR AVP with a sequence number that is less than previously received one."
>>>> I don't find this very robust. Once a higher sequence number (received erroneously by mistake) is accepted you cannot (easily) recover.
>>> I find it more robust in a sense that I should not care about stale old information.
>>> However, since we are piggybacking (by popular demand) we have little room for seqno
>>> re-sync negotiation.
>>>
>>> What is the mistake you refer here? A misbehaving implementation? In that case, it 
>>> deserves to get a manual intervention once figured out by admins checking alarms and
>>> logs. If the mistake is due other things, like endpoints being out of sync, we currently
>>> have no written down mechanism to survive that.
>>>
>>>> 3. The expected behaviour when receiving an out-of-sequence sequence number within the OC-Supported-Features AVP is not described. What is the intention here?
>>> No intention. Just a sloppy specification. You are right that something needs to be
>>> done & clarified here. (again the semantics of Time would nice..)
>>>
>>> I'll propose something. Others should too ;)
>>>
>>> - Jouni
>>>
>>>> Ulrich
>>>>
>>>> -----Original Message-----
>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Jouni Korhonen
>>>> Sent: Tuesday, December 10, 2013 8:28 AM
>>>> To: Ben Campbell; dime@ietf.org list; Steve Donovan
>>>> Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3
>>>>
>>>>
>>>> Fine.. lets define then the sequence number semantics. Basic
>>>> unsigned integer math. The text proposal is the following:
>>>>
>>>> 4.4.  OC-Sequence-Number AVP
>>>>
>>>> The OC-Sequence-Number AVP (AVP code TBD3) is type of Unsigned64.
>>>> Its usage in the context of the overload control is described in
>>>> Sections 4.1 and 4.3.
>>>>
>>>> From the functionality point of view, the OC-Sequence-Number AVP
>>>> MUST be used as a non-volatile increasing counter between two
>>>> overload control endpoints.  The sequence number is only required
>>>> to be unique between two overload control endpoints and does not
>>>> need to be monotonically increasing.
>>>>
>>>> When comparing two sequence numbers, the new sequence number MUST
>>>> be greater or equal than the old sequence number within a window
>>>> that is half of the size of the maximum sequence number. This
>>>> allows a simple handling of the sequence number overflow using
>>>> unsigned integer arithmeticf:
>>>>
>>>>   #define WINDOW 0x8000000000000000ULL
>>>>
>>>>   bool verify_seqnum( uint64_t newsn, uint64_t oldsn ) {
>>>>       if (newsn - oldsn <= WINDOW)
>>>>           // newsn >= oldsn
>>>>           return true;   
>>>>       } else
>>>>           // outside window or newsn < oldsn
>>>>           return false;  
>>>>       }
>>>>   }
>>>>
>>>>
>>>>
>>>> The above should even work is someone shovels NTP times into
>>>> sequence numbers with a blind typecasting.
>>>>
>>>> - Jouni
>>>>
>>>> On Dec 10, 2013, at 12:34 AM, Ben Campbell  wrote:
>>>>
>>>>> On Dec 9, 2013, at 10:00 AM, Steve Donovan  wrote:
>>>>>
>>>>>> Jouni,
>>>>>>
>>>>>> I propose that we keep the name OC-Sequence-Number but that we use the Time type for OC-Sequence-Number.  It is misleading and potentially confusing to call it OC-Time-Stamp.  
>>>>>>
>>>>> I could live with that, although I would rather just define the expected properties of the sequence number, and leave the implementation up to the implementor. I assume your reasoning for not calling it a timestamp is that you do not want people to try to use it as a time base reference. If so, then we don't require any connection to a clock. We just need it to be monotonically increasing.
>>>>>
>>>>>> We might consider expanding on the format of the AVP to make it something like Session-ID, where it is a concatenation of the Diameter-ID of the generating node and a timestamp.  This might help the reacting node keep track of which sequence number it has received.
>>>>>>
>>>>> Do we need a uniqueness across multiple nodes property? If so, why?
>>>>>
>>>>>> Steve
>>>>>>
>>>>>> On 12/9/13 5:37 AM, Jouni Korhonen wrote:
>>>>>>> Folks
>>>>>>>
>>>>>>> Could we conclude on the sequence number vs. time stamp vs. something else?
>>>>>>> We got more important places to spend our energy than this ;)
>>>>>>>
>>>>>>> My proposal is the following (based on the original pre-00 design):
>>>>>>>
>>>>>>> o We change the OC-Sequence-Number to OC-Time-Stamp in all occurrences
>>>>>>> in the -01.
>>>>>>> o We use RFC6733 Time type for the OC-Time-Stamp. RFC6733 gives us
>>>>>>> already exact definition how to handle the AVP.
>>>>>>> o Define that the OC-Time-Stamp is the time of the creation of the 
>>>>>>> "original" AVP within whose context the time stamp is present.
>>>>>>> o The OC-Time-Stamp AVP uniqueness is still considered to be in scope
>>>>>>> of the communicating endpoints.
>>>>>>> o The time stamp can be used to quickly determine if the content of
>>>>>>> the encapsulating AVP context has changed (among other properties).
>>>>>>> This would be useful specifically in the future when the encapsulating
>>>>>>> grouped AVPs  grow in size and functionality.
>>>>>>>
>>>>>>>
>>>>>>> - Jouni
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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
>


--------------070403000808000502070608
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Jouni,

      

      We need the sequence number to be strictly increasing.  I don't
      see the need for it to increase in uniform amounts.  Using time
      does fit these requirements.  I'm ok with using time as long as we
      don't call the AVP timestamp.

      

      Ulrich does bring up an interesting use case, where a client is
      receiving realm reports for the same realm from different agents. 
      We need to define the clients behavior in this case.  

      

      Presumably the client needs to be able to determine who generated
      the realm report.  This cannot be determine based on the content
      of the message or the connection on which the message arrived.  It
      seems like we might need "Report Generator Diameter ID" in the
      overload report specifically for Realm reports.  

      

      Once the client is able to differentiate between realm reports
      sent by different agents (or servers) we need logic defining how
      the client deals with a new overload report.  

      

      I see a couple of options (others will probably see options I am
      missing):

      

      - Use the last received realm report - This introduces the
      possibility of thrashing between two different reduction values
      and different durations.  Note that this approach does not require
      the source of the report to be included in the report.

      

      - Only listen to one source of realm overload - The approach would
      be to remember who sent the first overload report from the realm
      and ignore realm overload reports from other sources.  This
      behavior would likely be constrained to a single occurrence of
      realm overload.  Meaning that the "memory" of the report source
      would only last as long as that overload event persists.  Once the
      overload event goes away, the report source would be forgotten and
      a new source could be used for the next occurrence.

      

      On the surface, the second approach looks better to me.

      

      Steve

      

    
    
On 12/11/13 2:15 AM, Jouni wrote:

    

    

      
Ulrich,

I might be slow but.. Section 4.4 says

   control endpoints.  The sequence number is only required to be unique
   between two overload control endpoints and does not need to be

Unique between two endpoints..

Section 5.1 talks about endpoints:

   of an arbitrary Diameter network.  The overload control information
   is exchanged over on a "DOIC association" between two communication
   endpoints.  The endpoints, namely the "reacting node" and the
   "reporting node" do not need to be adjacent Diameter peer nodes, nor

So if your agents inject realm reports, they need to be endpoints to the
client. Similar to Figure 5. Therefore the sequence number spaces between
C-A1 and C-A2 are separate.

Now it is not clear to me, whether in your reasoning the C would see
the server identity (as the endpoint) when there is an active "DEP
agent" on the path. That would not clearly work and not be align with
the endpoint assumption.

Note that at some point of time we had (at least on a discussion level
in f2f meeting) report originator identity in the OLR. That would make
endpoint identification trivial. Now a "DEP agent" needs to act as a 
"server" for its clients in order to appear as an endpoint.

- Jouni

ps: still think the use of Time is simpler..


On Dec 11, 2013, at 9:43 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:



      

        
That's not predictable. It may be the same server in some cases, and different servers in other cases.

-----Original Message-----
From: ext Jouni [mailto:jouni.nospam@gmail.com] 
Sent: Wednesday, December 11, 2013 8:38 AM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: Ben Campbell; dime@ietf.org list; Steve Donovan
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3


Ulrich,

On Dec 11, 2013, at 9:21 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:



        

          
Jouni,

ad 1. "monotonically" does not express your intention. What we are looking for may be "stepwise with fixed step".

Ad 2. Is not necessarily a mistake that could result in out-of-sequence sequence numbers. When a client C sends a realm-type requests towards any server in the realm, an agent A1 that selects the server would send back the realm-type OLR with sequence number s1. The next realm-type request sent by C (that survived the throttling) may take a path that does not include A1 but A2. A2 then selects the server and sends back a sequence number s2. Nothing ensures that s1 and s2 are in sequence.


        

        
Would the server in both cases (via A1 and A2) be the same?

- Jouni




        

          
Ulrich


-----Original Message-----
From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] 
Sent: Tuesday, December 10, 2013 10:31 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: Ben Campbell; dime@ietf.org list; Steve Donovan
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3

Ulrich,

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



          

            
Jouni,

1. I find the texts
a) "The sequence number ... does not need to be monotonically increasing"
and 


          

          
Means the delta from old-seqno to new-seqno can be any non-negative integer
(within the given limits) not something fixed step/delta (like +1). As long as
"new-seqno >= old-seqno" holds we are fine.



          

            
b) "...the new sequence number MUST be greater or equal than the old sequence number..."
contradicting.
Can you please clarify.


          

          
See above. (mind the overflow case)



          

            
2. The expected behaviour when receiving an out-of-sequence sequence number within OC-OLR is described in 4.3:
"The receiver SHOULD discard an OC-OLR AVP with a sequence number that is less than previously received one."
I don't find this very robust. Once a higher sequence number (received erroneously by mistake) is accepted you cannot (easily) recover.


          

          
I find it more robust in a sense that I should not care about stale old information.
However, since we are piggybacking (by popular demand) we have little room for seqno
re-sync negotiation.

What is the mistake you refer here? A misbehaving implementation? In that case, it 
deserves to get a manual intervention once figured out by admins checking alarms and
logs. If the mistake is due other things, like endpoints being out of sync, we currently
have no written down mechanism to survive that.



          

            
3. The expected behaviour when receiving an out-of-sequence sequence number within the OC-Supported-Features AVP is not described. What is the intention here?


          

          
No intention. Just a sloppy specification. You are right that something needs to be
done & clarified here. (again the semantics of Time would nice..)

I'll propose something. Others should too ;)

- Jouni



          

            
Ulrich

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Jouni Korhonen
Sent: Tuesday, December 10, 2013 8:28 AM
To: Ben Campbell; dime@ietf.org list; Steve Donovan
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3


Fine.. lets define then the sequence number semantics. Basic
unsigned integer math. The text proposal is the following:

4.4.  OC-Sequence-Number AVP

The OC-Sequence-Number AVP (AVP code TBD3) is type of Unsigned64.
Its usage in the context of the overload control is described in
Sections 4.1 and 4.3.

>From the functionality point of view, the OC-Sequence-Number AVP
MUST be used as a non-volatile increasing counter between two
overload control endpoints.  The sequence number is only required
to be unique between two overload control endpoints and does not
need to be monotonically increasing.

When comparing two sequence numbers, the new sequence number MUST
be greater or equal than the old sequence number within a window
that is half of the size of the maximum sequence number. This
allows a simple handling of the sequence number overflow using
unsigned integer arithmeticf:

  #define WINDOW 0x8000000000000000ULL

  bool verify_seqnum( uint64_t newsn, uint64_t oldsn ) {
      if (newsn - oldsn <= WINDOW)
          // newsn >= oldsn
          return true;   
      } else
          // outside window or newsn < oldsn
          return false;  
      }
  }



The above should even work is someone shovels NTP times into
sequence numbers with a blind typecasting.

- Jouni

On Dec 10, 2013, at 12:34 AM, Ben Campbell <ben@nostrum.com> wrote:



            

              
On Dec 9, 2013, at 10:00 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:



              

                
Jouni,

I propose that we keep the name OC-Sequence-Number but that we use the Time type for OC-Sequence-Number.  It is misleading and potentially confusing to call it OC-Time-Stamp.  



              

              
I could live with that, although I would rather just define the expected properties of the sequence number, and leave the implementation up to the implementor. I assume your reasoning for not calling it a timestamp is that you do not want people to try to use it as a time base reference. If so, then we don't require any connection to a clock. We just need it to be monotonically increasing.



              

                
We might consider expanding on the format of the AVP to make it something like Session-ID, where it is a concatenation of the Diameter-ID of the generating node and a timestamp.  This might help the reacting node keep track of which sequence number it has received.



              

              
Do we need a uniqueness across multiple nodes property? If so, why?



              

                
Steve

On 12/9/13 5:37 AM, Jouni Korhonen wrote:


                

                  
Folks

Could we conclude on the sequence number vs. time stamp vs. something else?
We got more important places to spend our energy than this ;)

My proposal is the following (based on the original pre-00 design):

o We change the OC-Sequence-Number to OC-Time-Stamp in all occurrences
in the -01.
o We use RFC6733 Time type for the OC-Time-Stamp. RFC6733 gives us
already exact definition how to handle the AVP.
o Define that the OC-Time-Stamp is the time of the creation of the 
"original" AVP within whose context the time stamp is present.
o The OC-Time-Stamp AVP uniqueness is still considered to be in scope
of the communicating endpoints.
o The time stamp can be used to quickly determine if the content of
the encapsulating AVP context has changed (among other properties).
This would be useful specifically in the future when the encapsulating
grouped AVPs  grow in size and functionality.


- Jouni

_______________________________________________
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


          

          

        

        

      

      



    

    

  


--------------070403000808000502070608--

From srdonovan@usdonovans.com  Wed Dec 11 05:19:41 2013
Return-Path: 
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 7EE5B1ADBCC for ; Wed, 11 Dec 2013 05:19:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.12
X-Spam-Level: 
X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no
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 mRyaWvwWjCQ7 for ; Wed, 11 Dec 2013 05:19:38 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id AD3D51AD93D for ; Wed, 11 Dec 2013 05:19:38 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:49486 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1VqjhM-0003Jb-3V for dime@ietf.org; Wed, 11 Dec 2013 05:19:33 -0800
Message-ID: <52A86663.30500@usdonovans.com>
Date: Wed, 11 Dec 2013 07:19:31 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: dime@ietf.org
References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <14594_1386204165_529FCC05_14594_12646_1_6B7134B31289DC4FAF731D844122B36E329907@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B920972CCAA@ESESSMB101.ericsson.se>  <52A077CC.3000004@usdonovans.com>  <52A088D0.2020406@usdonovans.com>  <52A091CE.2000104@usdonovans.com> <13081_1386256433_52A09831_13081_8197_1_6B7134B31289DC4FAF! 731D84412 2B36E32B6EB@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B9209739738@ESESSMB101.ericsson.se>  <8FD63E2D-5203-4DA4-A6DA-C4CA181C9CFB@nostrum.com> <26C84DFD55BC3040A45BF70926E55F2587C1D786@SZXEMA512-MBX.china.huawei.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------000008060003030003030704"
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Dec 2013 13:19:41 -0000

This is a multi-part message in MIME format.
--------------000008060003030003030704
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

JJacques,

While the self contained overload report concept may be similar to the
scopes concept in the Roach draft, they are not the same.  As such, I
don't agree with your assertion that the previous rejection of the Roach
draft requires us to reject self contained overload reports as currently
being discussed.

Steve

On 12/11/13 2:27 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:
>
> 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  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  > wrote:
>
>
> OK. Lets call this thread concluded then. I keep the old OC-OLR  semantics
> regarding its information context then unmodified.
>
> - Jouni
>
>  
>
>
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


--------------000008060003030003030704
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    JJacques,

      

      While the self contained overload report concept may be similar to
      the scopes concept in the Roach draft, they are not the same.  As
      such, I don't agree with your assertion that the previous
      rejection of the Roach draft requires us to reject self contained
      overload reports as currently being discussed.

      

      Steve

      

    
    
On 12/11/13 2:27 AM, TROTTIN,
      JEAN-JACQUES (JEAN-JACQUES) wrote:

    

    

      
      
      
      

        
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 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>
          wrote:

          

          

        


          OK. Lets call this thread concluded then. I keep the old
          OC-OLR  semantics

          regarding its information context then unmodified.

          

          - Jouni

        
 

      

      

      

      

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


    

    

  


--------------000008060003030003030704--

From srdonovan@usdonovans.com  Wed Dec 11 05:27:32 2013
Return-Path: 
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 6FA341ADDD3 for ; Wed, 11 Dec 2013 05:27:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.12
X-Spam-Level: 
X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no
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 RNjSjthezvUL for ; Wed, 11 Dec 2013 05:27:28 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id AABA81ADDD1 for ; Wed, 11 Dec 2013 05:27:28 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:49509 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1Vqjov-0002MZ-FP for dime@ietf.org; Wed, 11 Dec 2013 05:27:23 -0800
Message-ID: <52A86839.4010103@usdonovans.com>
Date: Wed, 11 Dec 2013 07:27:21 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: dime@ietf.org
References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com>  <5BCBA1FC2B7F0B4C9D935572D90006681519BC90@DEMUMBX014.nsn-intra.net> <6390_1385631044_52970D44_6390_18593_1_6B7134B31289DC4FAF731D844122B36E30748E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BD19@DEMUMBX014.nsn-intra.net> <26C84DFD55BC3040A45BF70926E55F2587C1D028@SZXEMA512-MBX.china.huawei.com> <5BCBA1FC2B7F0B4C9D935572D90006681519DFC0@DEMUMBX014.nsn-intra.net> <26C84DFD55BC3040A45BF70926E55F2587C1D705@SZXEMA512-MBX.china.huawei.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E2DE@DEMUMBX014.nsn-intra.net> <26C84DFD55BC3040A45BF70926E55F2587C1DC24@SZXEMA512-MBX.china.huawei.com>
In-Reply-To: <26C84DFD55BC3040A45BF70926E55F2587C1DC24@SZXEMA512-MBX.china.huawei.com>
Content-Type: multipart/alternative; boundary="------------090705040806050709050704"
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Dec 2013 13:27:32 -0000

This is a multi-part message in MIME format.
--------------090705040806050709050704
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

Susan,

The use case for an agent that sits between a DOIC client and a DOIC
server is Realm overload, which the agent might be responsible for
reporting.  This will particularly be the case when there are multiple
servers sitting behind the agent.  This might be considered a server
farm, as you indicate, but we don't have a good definition of server
farm, so I'm being explicit.

In this case, the agent must handle to types of occurrences. 

1) Server overload - In this case the agent will receive a node overload
report from the server.  The agent should (I'm not sure if we have
defined this behavior in the draft yet) send the report unchanged to the
client.  The agent will also most likely use the contents of the report
to determine the realm overload state.

2) Realm overload - In this case the agent will insert an overload
report into the appropriate answer messages.

Is this consistent with your thinking?

Regards,

Steve

On 12/11/13 12:24 AM, Shishufeng (Susan) wrote:
> Hi Ulrich,
>
> I'm not sure if you are taking the overload of agent into account for which we decided to not consider for the time being. If not, I couldn't understand why an agent which does not serve for a server farm needs to be a DOIC endpoint between the client and server if both of them support overload control. My understanding is that if there is the need for an agent to take a role of a DOIC endpoint between a specific server and client, it would always do that, otherwise, it just transfer the overload information of the server to the client.
>
> Best Regards,
> Susan
>
> -----Original Message-----
> From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] 
> Sent: Tuesday, December 10, 2013 6:15 PM
> To: Shishufeng (Susan); ext lionel.morand@orange.com; ext Jouni Korhonen; Ben Campbell
> Cc: dime@ietf.org list
> Subject: RE: [Dime] DOIC: Self-Contained OLRs
>
> Hi Susan,
>
> if the agent does not take the role of a DOIC endpont then the feature negotiation/adverisement is between client and server and one host type OLR is sent from server to client. For the agent this is all transparent and there is no need for the agent to support any DOIC feature.
> However, if the agent takes the role of an DOIC endpoint then the feature negotiation/advertisement is between client and agent and a separate feature negotiation/advertisement is between agent and server. An OLR sent from server to agent is in-context with the supported features of server and agent but possibly not in-context with supported features of client and agent and therefore must not be (blindly) sent to the client. And in fact there is also no need to do that. For subsequent requests that contain the desination host of the server, the agent will not take the role of a DOIC endpoint.
>
> Best regards
> Ulrich
>
> -----Original Message-----
> From: ext Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
> Sent: Tuesday, December 10, 2013 4:02 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
>
> Hi Ulrich,
>
> Thanks for your clarification. I understood the scenario, while from my point of view, if the agent that selects the HSS is not configured to serve as a load balancer for the HSS, the agent should not change any supported/negotiated features between C and S, that would be the normal case. If the agent serve as a load balancer for the HSS, the subsequent request from C towards the S would always go via the agent, in this case whatever the associations between C and A, between A and S are the same or not, it doesn't matter. With an E2E solution as we agreed, I don't see the problem with it.
>
> Best Regards,
> Susan
>
> -----Original Message-----
> From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
> Sent: Monday, December 09, 2013 7:43 PM
> To: Shishufeng (Susan); ext lionel.morand@orange.com; ext Jouni Korhonen; Ben Campbell
> Cc: dime@ietf.org list
> Subject: RE: [Dime] DOIC: Self-Contained OLRs
>
> Hi Susan,
>
> let me come back to your S6a example.
>
> The MME (C) sends a request without Destination-Host towards the HPLMN (realm). There must be an agent (A) in the HPLMN (realm) that selects the HSS (S). 
> We would have two distinct DOIC associations: one between C and A, another between A and S (see figure 5 in clause 5.1). The two DOIC associations may have different supported/negotiated features. An OLR sent from S to A based on supported/negotiated features valid for the DOIC association between A and S is at least problematic (out-of context) when sent from A to C.
>
> When the MME (C) sends a subsequent request with Destination-Host towards the HSS (S), there is no agent that selects the HSS (as the HSS is already selected). For this session there is only one DOIC association between C and S (see figure 3 in clause 5.1) and OLRs sent from S to C are not problematic.
>
> Best regards
> Ulrich
>
>
> -----Original Message-----
> From: ext Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
> Sent: Monday, December 09, 2013 11:30 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
>
> Hi Ulrich,
>
> I have different views. In any case, I think the host-type OLR should not be ignored by the clients. On the contrary, the realm-type OLR can be thought as optimization, which may not even be needed at all for all cases, especially in 3GPP. Here is an example of S6a, in the case the first attach request comes from the UE to the MME, the MME can only derive the realm information, and sends a request without Destination-Host towards the HPLMN. Since the subscriber corresponding to the UE belongs to a specific HSS, and the HSS may provide its overload report to the MME, and the MME is able to know how to react regarding the requests towards the HSS, which would be the normal case. Whether Realm report will be provided by the HSS or the agent serving the HSS is kind of optimization which may help the MME to know how to react on the requests towards the realm, not specific to the HSS.
>
> Best Regards,
> Susan
>
> -----Original Message-----
> From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
> Sent: Thursday, November 28, 2013 6:30 PM
> To: ext lionel.morand@orange.com; ext Jouni Korhonen; Ben Campbell
> Cc: dime@ietf.org list
> Subject: 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  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.
>
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>


--------------090705040806050709050704
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Susan,

      

      The use case for an agent that sits between a DOIC client and a
      DOIC server is Realm overload, which the agent might be
      responsible for reporting.  This will particularly be the case
      when there are multiple servers sitting behind the agent.  This
      might be considered a server farm, as you indicate, but we don't
      have a good definition of server farm, so I'm being explicit.

      

      In this case, the agent must handle to types of occurrences.  

      

      1) Server overload - In this case the agent will receive a node
      overload report from the server.  The agent should (I'm not sure
      if we have defined this behavior in the draft yet) send the report
      unchanged to the client.  The agent will also most likely use the
      contents of the report to determine the realm overload state.

      

      2) Realm overload - In this case the agent will insert an overload
      report into the appropriate answer messages.

      

      Is this consistent with your thinking?

      

      Regards,

      

      Steve

      

    
    
On 12/11/13 12:24 AM, Shishufeng
      (Susan) wrote:

    

    

      
Hi Ulrich,

I'm not sure if you are taking the overload of agent into account for which we decided to not consider for the time being. If not, I couldn't understand why an agent which does not serve for a server farm needs to be a DOIC endpoint between the client and server if both of them support overload control. My understanding is that if there is the need for an agent to take a role of a DOIC endpoint between a specific server and client, it would always do that, otherwise, it just transfer the overload information of the server to the client.

Best Regards,
Susan

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] 
Sent: Tuesday, December 10, 2013 6:15 PM
To: Shishufeng (Susan); ext lionel.morand@orange.com; ext Jouni Korhonen; Ben Campbell
Cc: dime@ietf.org list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Hi Susan,

if the agent does not take the role of a DOIC endpont then the feature negotiation/adverisement is between client and server and one host type OLR is sent from server to client. For the agent this is all transparent and there is no need for the agent to support any DOIC feature.
However, if the agent takes the role of an DOIC endpoint then the feature negotiation/advertisement is between client and agent and a separate feature negotiation/advertisement is between agent and server. An OLR sent from server to agent is in-context with the supported features of server and agent but possibly not in-context with supported features of client and agent and therefore must not be (blindly) sent to the client. And in fact there is also no need to do that. For subsequent requests that contain the desination host of the server, the agent will not take the role of a DOIC endpoint.

Best regards
Ulrich

-----Original Message-----
From: ext Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
Sent: Tuesday, December 10, 2013 4:02 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

Hi Ulrich,

Thanks for your clarification. I understood the scenario, while from my point of view, if the agent that selects the HSS is not configured to serve as a load balancer for the HSS, the agent should not change any supported/negotiated features between C and S, that would be the normal case. If the agent serve as a load balancer for the HSS, the subsequent request from C towards the S would always go via the agent, in this case whatever the associations between C and A, between A and S are the same or not, it doesn't matter. With an E2E solution as we agreed, I don't see the problem with it.

Best Regards,
Susan

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
Sent: Monday, December 09, 2013 7:43 PM
To: Shishufeng (Susan); ext lionel.morand@orange.com; ext Jouni Korhonen; Ben Campbell
Cc: dime@ietf.org list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Hi Susan,

let me come back to your S6a example.

The MME (C) sends a request without Destination-Host towards the HPLMN (realm). There must be an agent (A) in the HPLMN (realm) that selects the HSS (S). 
We would have two distinct DOIC associations: one between C and A, another between A and S (see figure 5 in clause 5.1). The two DOIC associations may have different supported/negotiated features. An OLR sent from S to A based on supported/negotiated features valid for the DOIC association between A and S is at least problematic (out-of context) when sent from A to C.

When the MME (C) sends a subsequent request with Destination-Host towards the HSS (S), there is no agent that selects the HSS (as the HSS is already selected). For this session there is only one DOIC association between C and S (see figure 3 in clause 5.1) and OLRs sent from S to C are not problematic.

Best regards
Ulrich


-----Original Message-----
From: ext Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
Sent: Monday, December 09, 2013 11:30 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

Hi Ulrich,

I have different views. In any case, I think the host-type OLR should not be ignored by the clients. On the contrary, the realm-type OLR can be thought as optimization, which may not even be needed at all for all cases, especially in 3GPP. Here is an example of S6a, in the case the first attach request comes from the UE to the MME, the MME can only derive the realm information, and sends a request without Destination-Host towards the HPLMN. Since the subscriber corresponding to the UE belongs to a specific HSS, and the HSS may provide its overload report to the MME, and the MME is able to know how to react regarding the requests towards the HSS, which would be the normal case. Whether Realm report will be provided by the HSS or the agent serving the HSS is kind of optimization which may help the MME to know how to react on the requests towards the realm, not specific to the HSS.

Best Regards,
Susan

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
Sent: Thursday, November 28, 2013 6:30 PM
To: ext lionel.morand@orange.com; ext Jouni Korhonen; Ben Campbell
Cc: dime@ietf.org list
Subject: 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.


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



    

    

  


--------------090705040806050709050704--

From srdonovan@usdonovans.com  Wed Dec 11 05:33:42 2013
Return-Path: 
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 BCABD1ADDD3 for ; Wed, 11 Dec 2013 05:33:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.12
X-Spam-Level: 
X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no
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 5LmsTp3NgWNu for ; Wed, 11 Dec 2013 05:33:40 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 0EBDE1ADDD1 for ; Wed, 11 Dec 2013 05:33:40 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:49518 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1Vqjuv-0000Ty-9w for dime@ietf.org; Wed, 11 Dec 2013 05:33:34 -0800
Message-ID: <52A869AD.6080305@usdonovans.com>
Date: Wed, 11 Dec 2013 07:33:33 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: dime@ietf.org
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DA3E@DEMUMBX014.nsn-intra.net> <6CDCFC84-3048-40B9-91A4-1451FCC65F60@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519DCE5@DEMUMBX014.nsn-intra.net> <09616DA2-D1ED-40EE-8E89-755DFCD81092@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E02B@DEMUMBX014.nsn-intra.net> <1A402C59-E390-4C95-8E30-97F1F9D3EF0F@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E05C@DEMUMBX014.nsn-intra.net> <790F1603-64D5-40E2-BC59-FD4C104EEF1B@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E0D9@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D90006681519E331@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D90006681519E3C4@DEMUMBX014.nsn-intra.net> <0CDBF4BB-4E38-41D6-A5E2-9218FFEFEA43@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E6EF@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681519E6EF@DEMUMBX014.nsn-intra.net>
Content-Type: multipart/alternative; boundary="------------020706050209010501000801"
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com
Subject: Re: [Dime] OVLI: comments to 4.1
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Dec 2013 13:33:43 -0000

This is a multi-part message in MIME format.
--------------020706050209010501000801
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Ulrich,

My email showed how a reporting node could avoid the work of
recalculating capability information on a message by message basis using
the sequence number.  This approach does require maintaining state.

As Ben pointed out, it is also possible to not follow my logic and do as
you propose by ignoring the sequence number and going through the work
of calculating the response every time. 

Which approach to take is clearly an implementation decision.  We should
keep the sequence number to allow for the stateful approach for
implementations that are willing to take advantage of maintaining state
to avoid work.

Steve

On 12/11/13 1:34 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> Jouni,
>
> I do not agree.
>
> My statement was general: reporting node may be server or SFA; supported features may be defined features (default algo) or future extensions.
>
> Ulrich
>
> -----Original Message-----
> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] 
> Sent: Tuesday, December 10, 2013 10:46 PM
> To: Wiehe, Ulrich (NSN - DE/Munich)
> Cc: dime@ietf.org
> Subject: Re: [Dime] OVLI: comments to 4.1
>
> Ulrich,
>
> On Dec 10, 2013, at 2:18 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:
>
>>
>> -----Original Message-----
>> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] 
>> Sent: Tuesday, December 10, 2013 12:32 PM
>> To: Wiehe, Ulrich (NSN - DE/Munich)
>> Cc: dime@ietf.org
>> Subject: Re: [Dime] OVLI: comments to 4.1
>>
>>
>> On Dec 10, 2013, at 12:41 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:
>>
>>> Hi Jouni,
>>>
>>> my understanding from Steve's clarification was that the reporting node would setup and maintain a database of "states", one per reacting node where a state of a reacting node is identified by a sequence number and the database entry would contain the pre-calculated OLR. 
>>> Hard to see how this is done without consuming resources.
>> It is mostly static information. Still I do not see how
>> you would get away without any state.
>> [Wiehe, Ulrich (NSN - DE/Munich)] There is no need for the reporting node to store and maintain information per reacting node because the reacting node actually tells within the request message all information the reporting node needs to know. The reporting node simply fetches the pre-calculated OLR that matches the supported features of the reacting node as indicated in the request and appends it to the answer.
> This could be true for the default algorithm in this spec. However,
> given the extension mechanism we have in place it is quite possible
> that the assumption does not hold for new features.
>
> Also, if I were to implement a server front end agent that would
> definitely need state and still ought to comply the protocol spec.
>
> - Jouni
>
>
>
>
>>> Furthermore,
>>> Why would the reacting node be interested in config changes of the reporting node?
>>> Isn't it so that the reacting node is only interested in OLR changes?
>> Sigh.. say the traffic abatement algorithm changes or new features
>> get added. Those have more impact than just OLR change.
>>
>> - Jouni
>>
>>> Ulrich
>>>
>>> -----Original Message-----
>>> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] 
>>> Sent: Tuesday, December 10, 2013 9:41 AM
>>> To: Wiehe, Ulrich (NSN - DE/Munich)
>>> Cc: dime@ietf.org
>>> Subject: Re: [Dime] OVLI: comments to 4.1
>>>
>>>
>>> On Dec 9, 2013, at 4:43 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:
>>>
>>>> But maintaining a specific state per reacting node is very resource consuming for the (overloaded) reporting node. It is simpler and more efficient to base any processing logic on actual information received in the request rather than on information stored from previous communication.
>>> The "state" in a reporting node is merely the current configuration
>>> and a counter for sequence number. Hard to me see that as resource
>>> consuming function.
>>>
>>> And the earlier comment of mine is done from reacting node point
>>> of view, since it is more interested in the possible config changes
>>> in the reporting node (e.g. S6a is stateless application, configuration
>>> can change at any time).
>>>
>>> - Jouni
>>>
>>>
>>>> Ulrich
>>>>
>>>> -----Original Message-----
>>>> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] 
>>>> Sent: Monday, December 09, 2013 2:25 PM
>>>> To: Wiehe, Ulrich (NSN - DE/Munich)
>>>> Cc: dime@ietf.org
>>>> Subject: Re: [Dime] OVLI: comments to 4.1
>>>>
>>>>
>>>> On Dec 9, 2013, at 3:13 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:
>>>>
>>>>> There is a fundamental difference:
>>>>> OLRs need to be stored, Feature-Vectors not.
>>>> How come feature vector does not need to be stored? I do not
>>>> get that? I would set my implementation to a specific state
>>>> or mode based on the feature vector. When that changes I'd
>>>> like to know that. And then keep functioning based on that.
>>>>
>>>> - Jouni
>>>>
>>>>> When receiving an OLR you may want to know whether its worth the effort to replace an already stored OLR with the received OLR.
>>>>> When receiving a Feature-Vector you just act on it.
>>>>>
>>>>> Ulrich 
>>>>>
>>>>> -----Original Message-----
>>>>> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] 
>>>>> Sent: Monday, December 09, 2013 1:55 PM
>>>>> To: Wiehe, Ulrich (NSN - DE/Munich)
>>>>> Cc: dime@ietf.org
>>>>> Subject: Re: [Dime] OVLI: comments to 4.1
>>>>>
>>>>>
>>>>> In the same vein as folks wanted send OLRs with the new or old information,
>>>>> the feature vector should behave in a same way IMHO. That implies there are
>>>>> situations when a reception of the feature vector does not change anything
>>>>> in an endpoint current behavior.
>>>>>
>>>>> - Jouni
>>>>>
>>>>> On Dec 9, 2013, at 2:47 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:
>>>>>
>>>>>> Isn't it so that the Feature-Vector (if present) always contains something that an implementation needs to act upon?
>>>>>>
>>>>>> Ulrich
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] 
>>>>>> Sent: Monday, December 09, 2013 1:12 PM
>>>>>> To: Wiehe, Ulrich (NSN - DE/Munich)
>>>>>> Cc: dime@ietf.org
>>>>>> Subject: Re: [Dime] OVLI: comments to 4.1
>>>>>>
>>>>>> Ulrich,
>>>>>>
>>>>>> On Dec 6, 2013, at 3:03 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:
>>>>>>
>>>>>>> Hi Jouni,
>>>>>>>
>>>>>>> thank you for your response.
>>>>>>>
>>>>>>> With regard to 3) 
>>>>>>> I still fail to see the usecase for Sequence-Number or TimeStamp within OC-Feature-Vector. Please clarify.
>>>>>> Since we also allow extending the OC-Feature-Vector beyond recognition, 
>>>>>> it has good chances become a rather complex grouped AVP. In that context
>>>>>> the Sequence-Number allows an easy and quick way to check if the feature
>>>>>> vector contains something that an implementation needs to act upon.
>>>>>>
>>>>>>> With regard to 4)
>>>>>>> This was not obvious to me. (The obvious typo is the missing "of" between "one" and "the").
>>>>>> Ack. Fixed the missing 'of'.
>>>>>>
>>>>>> - Jouni
>>>>>>
>>>>>>> Best regards
>>>>>>> Ulrich
>>>>>>>
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] 
>>>>>>> Sent: Friday, December 06, 2013 11:17 AM
>>>>>>> To: Wiehe, Ulrich (NSN - DE/Munich)
>>>>>>> Cc: dime@ietf.org
>>>>>>> Subject: Re: [Dime] OVLI: comments to 4.1
>>>>>>>
>>>>>>>
>>>>>>> On Dec 5, 2013, at 3:23 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:
>>>>>>>
>>>>>>>> Dear all,
>>>>>>>>
>>>>>>>> here are comments to clause 4.1:
>>>>>>>>
>>>>>>>> 1. The OC-Feature-Vector AVP is no longer a vector; the name of the AVP may be misleading. Proposal is to rename it to "OC-Supported-Features AVP"
>>>>>>> OK with me.
>>>>>>>
>>>>>>>> 2. The OC-Feature AVP is a vector of features. Proposal is to rename it to "OC-Feature-Vector AVP"
>>>>>>> OK with me.
>>>>>>>
>>>>>>>> 3. The OC-Sequence-Number within OC-Feature-Vector only makes sense if the receiving reporting endpoint can determine the identity of the reacting endpoint (which is not necessarily the origin host (client),
>>>>>>> My original proposal was to have seqnr as a timestamp. Some folks argued
>>>>>>> it is no good and suggested seqnr. I still think time makes more sense than
>>>>>>> seqnr.
>>>>>>>
>>>>>>>> it may be an agent and it may not always be the same agent), and if the reporting endpoint is required to store the OC-Feature-Vector / reacting-endpoint-identity pair (which I think both is not required). The reporting endpoint can base its processing logic on the actually received OC-Feature-Vector value, no matter whether it is brand-new or old but stil valid. Proposal is to delete OC-Sequence-Number AVP from OC-Feature-Vector.
>>>>>>> Do not agree removing it.
>>>>>>>
>>>>>>>> 4. The text
>>>>>>>>
>>>>>>>> The reporting node that sends the answer also includes the OC-
>>>>>>>> Feature-Vector AVP that describe the capabilities it supports.  The
>>>>>>>> set of capabilities advertised by the reporting node depends on local
>>>>>>>> policies.  At least one the announced capabilities MUST match
>>>>>>>> mutually.  If there is no single matching capability the reacting
>>>>>>>> node MUST act as if it does not implement DOIC and cease inserting
>>>>>>>> any DOIC related AVPs into any Diameter messages with this specific
>>>>>>>> reacting node.
>>>>>>>>
>>>>>>>> is not clear.  Would the reporting node include the OC-Feature-Vector AVP in the answer only if there is at least one matching capability? 
>>>>>>> Because then they have found a way to exchange something that both ends
>>>>>>> know how to handle it.
>>>>>>>
>>>>>>>> Mandating the reacting node to cease for all time inserting OC-Feature-Vector AVPs if it did not get back 
>>>>>>> There is an obvious typo. It should say:
>>>>>>>
>>>>>>> policies.  At least one the announced capabilities MUST match
>>>>>>> mutually.  If there is no single matching capability the reporting
>>>>>>> node MUST act as if it does not implement DOIC and cease inserting
>>>>>>> any DOIC related AVPs into any Diameter messages with this specific
>>>>>>> reacting node.
>>>>>>>
>>>>>>> - JOuni
>>>>>>>
>>>>>>>
>>>>>>>> at least one match is also not ok. The request might have been a realm-type request (i.e. without Destination Host) and the reacting node cannot control whether subsequent requests will take the same path to the same reporting node.
>>>>>>>> Even if the request contains a destination host the reacting node cannot know wether the reacting node's capabilities have been modified by the time a subsequent request is sent. 
>>>>>>>> Proposal is to keep only the first sentence and delete the rest.
>>>>>>>>
>>>>>>>> Ulrich
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> 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
>


--------------020706050209010501000801
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Ulrich,

      

      My email showed how a reporting node could avoid the work of
      recalculating capability information on a message by message basis
      using the sequence number.  This approach does require maintaining
      state.

      

      As Ben pointed out, it is also possible to not follow my logic and
      do as you propose by ignoring the sequence number and going
      through the work of calculating the response every time.  

      

      Which approach to take is clearly an implementation decision.  We
      should keep the sequence number to allow for the stateful approach
      for implementations that are willing to take advantage of
      maintaining state to avoid work.

      

      Steve

      

    
    
On 12/11/13 1:34 AM, Wiehe, Ulrich (NSN
      - DE/Munich) wrote:

    

    

      
Jouni,

I do not agree.

My statement was general: reporting node may be server or SFA; supported features may be defined features (default algo) or future extensions.

Ulrich

-----Original Message-----
From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] 
Sent: Tuesday, December 10, 2013 10:46 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: dime@ietf.org
Subject: Re: [Dime] OVLI: comments to 4.1

Ulrich,

On Dec 10, 2013, at 2:18 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> wrote:



      

        

-----Original Message-----
From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] 
Sent: Tuesday, December 10, 2013 12:32 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: dime@ietf.org
Subject: Re: [Dime] OVLI: comments to 4.1


On Dec 10, 2013, at 12:41 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> wrote:



        

          
Hi Jouni,

my understanding from Steve's clarification was that the reporting node would setup and maintain a database of "states", one per reacting node where a state of a reacting node is identified by a sequence number and the database entry would contain the pre-calculated OLR. 
Hard to see how this is done without consuming resources.


        

        
It is mostly static information. Still I do not see how
you would get away without any state.
[Wiehe, Ulrich (NSN - DE/Munich)] There is no need for the reporting node to store and maintain information per reacting node because the reacting node actually tells within the request message all information the reporting node needs to know. The reporting node simply fetches the pre-calculated OLR that matches the supported features of the reacting node as indicated in the request and appends it to the answer.


      

      
This could be true for the default algorithm in this spec. However,
given the extension mechanism we have in place it is quite possible
that the assumption does not hold for new features.

Also, if I were to implement a server front end agent that would
definitely need state and still ought to comply the protocol spec.

- Jouni






      

        

          
Furthermore,
Why would the reacting node be interested in config changes of the reporting node?
Isn't it so that the reacting node is only interested in OLR changes?


        

        
Sigh.. say the traffic abatement algorithm changes or new features
get added. Those have more impact than just OLR change.

- Jouni



        

          
Ulrich

-----Original Message-----
From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] 
Sent: Tuesday, December 10, 2013 9:41 AM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: dime@ietf.org
Subject: Re: [Dime] OVLI: comments to 4.1


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



          

            
But maintaining a specific state per reacting node is very resource consuming for the (overloaded) reporting node. It is simpler and more efficient to base any processing logic on actual information received in the request rather than on information stored from previous communication.


          

          
The "state" in a reporting node is merely the current configuration
and a counter for sequence number. Hard to me see that as resource
consuming function.

And the earlier comment of mine is done from reacting node point
of view, since it is more interested in the possible config changes
in the reporting node (e.g. S6a is stateless application, configuration
can change at any time).

- Jouni




          

            
Ulrich

-----Original Message-----
From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] 
Sent: Monday, December 09, 2013 2:25 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: dime@ietf.org
Subject: Re: [Dime] OVLI: comments to 4.1


On Dec 9, 2013, at 3:13 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> wrote:



            

              
There is a fundamental difference:
OLRs need to be stored, Feature-Vectors not.


            

            
How come feature vector does not need to be stored? I do not
get that? I would set my implementation to a specific state
or mode based on the feature vector. When that changes I'd
like to know that. And then keep functioning based on that.

- Jouni



            

              
When receiving an OLR you may want to know whether its worth the effort to replace an already stored OLR with the received OLR.
When receiving a Feature-Vector you just act on it.

Ulrich 

-----Original Message-----
From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] 
Sent: Monday, December 09, 2013 1:55 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: dime@ietf.org
Subject: Re: [Dime] OVLI: comments to 4.1


In the same vein as folks wanted send OLRs with the new or old information,
the feature vector should behave in a same way IMHO. That implies there are
situations when a reception of the feature vector does not change anything
in an endpoint current behavior.

- Jouni

On Dec 9, 2013, at 2:47 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> wrote:



              

                
Isn't it so that the Feature-Vector (if present) always contains something that an implementation needs to act upon?

Ulrich

-----Original Message-----
From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] 
Sent: Monday, December 09, 2013 1:12 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: dime@ietf.org
Subject: Re: [Dime] OVLI: comments to 4.1

Ulrich,

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



                

                  
Hi Jouni,

thank you for your response.

With regard to 3) 
I still fail to see the usecase for Sequence-Number or TimeStamp within OC-Feature-Vector. Please clarify.


                

                
Since we also allow extending the OC-Feature-Vector beyond recognition, 
it has good chances become a rather complex grouped AVP. In that context
the Sequence-Number allows an easy and quick way to check if the feature
vector contains something that an implementation needs to act upon.



                

                  
With regard to 4)
This was not obvious to me. (The obvious typo is the missing "of" between "one" and "the").


                

                
Ack. Fixed the missing 'of'.

- Jouni



                

                  
Best regards
Ulrich


-----Original Message-----
From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] 
Sent: Friday, December 06, 2013 11:17 AM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: dime@ietf.org
Subject: Re: [Dime] OVLI: comments to 4.1


On Dec 5, 2013, at 3:23 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> wrote:



                  

                    
Dear all,

here are comments to clause 4.1:

1. The OC-Feature-Vector AVP is no longer a vector; the name of the AVP may be misleading. Proposal is to rename it to "OC-Supported-Features AVP"


                  

                  
OK with me.



                  

                    
2. The OC-Feature AVP is a vector of features. Proposal is to rename it to "OC-Feature-Vector AVP"


                  

                  
OK with me.



                  

                    
3. The OC-Sequence-Number within OC-Feature-Vector only makes sense if the receiving reporting endpoint can determine the identity of the reacting endpoint (which is not necessarily the origin host (client),


                  

                  
My original proposal was to have seqnr as a timestamp. Some folks argued
it is no good and suggested seqnr. I still think time makes more sense than
seqnr.



                  

                    
it may be an agent and it may not always be the same agent), and if the reporting endpoint is required to store the OC-Feature-Vector / reacting-endpoint-identity pair (which I think both is not required). The reporting endpoint can base its processing logic on the actually received OC-Feature-Vector value, no matter whether it is brand-new or old but stil valid. Proposal is to delete OC-Sequence-Number AVP from OC-Feature-Vector.


                  

                  
Do not agree removing it.



                  

                    
4. The text

The reporting node that sends the answer also includes the OC-
Feature-Vector AVP that describe the capabilities it supports.  The
set of capabilities advertised by the reporting node depends on local
policies.  At least one the announced capabilities MUST match
mutually.  If there is no single matching capability the reacting
node MUST act as if it does not implement DOIC and cease inserting
any DOIC related AVPs into any Diameter messages with this specific
reacting node.

is not clear.  Would the reporting node include the OC-Feature-Vector AVP in the answer only if there is at least one matching capability? 


                  

                  
Because then they have found a way to exchange something that both ends
know how to handle it.



                  

                    
Mandating the reacting node to cease for all time inserting OC-Feature-Vector AVPs if it did not get back 


                  

                  
There is an obvious typo. It should say:

policies.  At least one the announced capabilities MUST match
mutually.  If there is no single matching capability the reporting
node MUST act as if it does not implement DOIC and cease inserting
any DOIC related AVPs into any Diameter messages with this specific
reacting node.

- JOuni




                  

                    
at least one match is also not ok. The request might have been a realm-type request (i.e. without Destination Host) and the reacting node cannot control whether subsequent requests will take the same path to the same reporting node.
Even if the request contains a destination host the reacting node cannot know wether the reacting node's capabilities have been modified by the time a subsequent request is sent. 
Proposal is to keep only the first sentence and delete the rest.

Ulrich


_______________________________________________
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



    

    

  


--------------020706050209010501000801--

From srdonovan@usdonovans.com  Wed Dec 11 05:45:30 2013
Return-Path: 
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 E08EB1ADE86 for ; Wed, 11 Dec 2013 05:45:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.12
X-Spam-Level: 
X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no
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 SsbrrSgqpIby for ; Wed, 11 Dec 2013 05:45:29 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 05E681ADDDA for ; Wed, 11 Dec 2013 05:45:29 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:49524 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1Vqk6I-000483-L0; Wed, 11 Dec 2013 05:45:21 -0800
Message-ID: <52A86C6E.4030602@usdonovans.com>
Date: Wed, 11 Dec 2013 07:45:18 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: "Wiehe, Ulrich (NSN - DE/Munich)" ,  Ben Campbell 
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DB1B@DEMUMBX014.nsn-intra.net>  <52A5E902.20605@usdonovans.com> <7475B713-1104-4791-96B1-CE97632A0D69@nostrum.com> <52A71632.7040806@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E48F@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681519E48F@DEMUMBX014.nsn-intra.net>
Content-Type: multipart/alternative; boundary="------------030000090201020008080709"
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com
Cc: "dime@ietf.org list" 
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Dec 2013 13:45:31 -0000

This is a multi-part message in MIME format.
--------------030000090201020008080709
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Ulrich,

Is your question how sequence numbers work when there are DOIC
supporting agents?

The capabilities exchange is between two DOIC endpoints, so in the case
you outline, the server would see capability information from each agent
in the path.  The server should not see the sequence numbers from the
clients.

This does point out that we are likely missing something from the
OC-Feature-Vector AVP.  We likely need the DOIC end-point Diameter ID
included in that AVP.

Steve

On 12/10/13 8:43 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
> Steve,
>
>  
>
> how does this work in scenarios where a non supporting client C sends
> some requests via the DOIC supporting agent A1 to the server S and
> other requests via a different DOIC supporting agent A2 to the same
> server S?
>
>  
>
> Ulrich
>
>  
>
> *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *ext Steve
> Donovan
> *Sent:* Tuesday, December 10, 2013 2:25 PM
> *To:* Ben Campbell
> *Cc:* dime@ietf.org list
> *Subject:* Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI:
> comments to 4.3
>
>  
>
> inline
>
> On 12/9/13 4:34 PM, Ben Campbell wrote:
>
>      
>
>     On Dec 9, 2013, at 10:00 AM, Steve Donovan   wrote:
>
>      
>
>         Jouni,
>
>          
>
>         I propose that we keep the name OC-Sequence-Number but that we use the Time type for OC-Sequence-Number.  It is misleading and potentially confusing to call it OC-Time-Stamp.  
>
>          
>
>      
>
>     I could live with that, although I would rather just define the expected properties of the sequence number, and leave the implementation up to the implementor. I assume your reasoning for not calling it a timestamp is that you do not want people to try to use it as a time base reference. If so, then we don't require any connection to a clock. We just need it to be monotonically increasing.
>
>      
>
>         We might consider expanding on the format of the AVP to make it something like Session-ID, where it is a concatenation of the Diameter-ID of the generating node and a timestamp.  This might help the reacting node keep track of which sequence number it has received.
>
>          
>
>      
>
>     Do we need a uniqueness across multiple nodes property? If so, why?
>
> Strictly speaking, no.  The thought was to make it similar to
> session-id and potentially make it easier for the reacting node to
> keep differentiate sequence numbers from different reporting nodes.
>
>  
>  
>
>     Steve
>
>      
>
>     On 12/9/13 5:37 AM, Jouni Korhonen wrote:
>
>         Folks
>
>          
>
>         Could we conclude on the sequence number vs. time stamp vs. something else?
>
>         We got more important places to spend our energy than this ;)
>
>          
>
>         My proposal is the following (based on the original pre-00 design):
>
>          
>
>         o We change the OC-Sequence-Number to OC-Time-Stamp in all occurrences
>
>           in the -01.
>
>         o We use RFC6733 Time type for the OC-Time-Stamp. RFC6733 gives us
>
>           already exact definition how to handle the AVP.
>
>         o Define that the OC-Time-Stamp is the time of the creation of the 
>
>           "original" AVP within whose context the time stamp is present.
>
>         o The OC-Time-Stamp AVP uniqueness is still considered to be in scope
>
>           of the communicating endpoints.
>
>         o The time stamp can be used to quickly determine if the content of
>
>           the encapsulating AVP context has changed (among other properties).
>
>           This would be useful specifically in the future when the encapsulating
>
>           grouped AVPs  grow in size and functionality.
>
>          
>
>          
>
>         - Jouni
>
>          
>
>         _______________________________________________
>
>         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
>
>  
>  
>
>  
>


--------------030000090201020008080709
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Ulrich,

      

      Is your question how sequence numbers work when there are DOIC
      supporting agents?

      

      The capabilities exchange is between two DOIC endpoints, so in the
      case you outline, the server would see capability information from
      each agent in the path.  The server should not see the sequence
      numbers from the clients.

      

      This does point out that we are likely missing something from the
      OC-Feature-Vector AVP.  We likely need the DOIC end-point Diameter
      ID included in that AVP.

      

      Steve

      

    
    
On 12/10/13 8:43 AM, Wiehe, Ulrich (NSN
      - DE/Munich) wrote:

    

    

      
      
      
      

        
Steve,

        
 

        
how does this work in scenarios where a non
            supporting client C sends some requests via the DOIC
            supporting agent A1 to the server S and other requests via a
            different DOIC supporting agent A2 to the same server S?

        
 

        
Ulrich

        
 

        

          

            
From: DiME [mailto:dime-bounces@ietf.org]
                On Behalf Of ext Steve Donovan

                Sent: Tuesday, December 10, 2013 2:25 PM

                To: Ben Campbell

                Cc: dime@ietf.org list

                Subject: Re: [Dime] Conclusion for Sequence
                Numbers - was Re: OVLI: comments to 4.3

          

        

        
 

        
inline

        

          
On 12/9/13 4:34 PM, Ben Campbell wrote:

        

        

          
 

          
On Dec 9, 2013, at 10:00 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:

          
 

          

            
Jouni,

            
 

            
I propose that we keep the name OC-Sequence-Number but that we use the Time type for OC-Sequence-Number.  It is misleading and potentially confusing to call it OC-Time-Stamp.  

            
 

          

          
 

          
I could live with that, although I would rather just define the expected properties of the sequence number, and leave the implementation up to the implementor. I assume your reasoning for not calling it a timestamp is that you do not want people to try to use it as a time base reference. If so, then we don't require any connection to a clock. We just need it to be monotonically increasing.

          
 

          

            
We might consider expanding on the format of the AVP to make it something like Session-ID, where it is a concatenation of the Diameter-ID of the generating node and a timestamp.  This might help the reacting node keep track of which sequence number it has received.

            
 

          

          
 

          
Do we need a uniqueness across multiple nodes property? If so, why?

        

        
Strictly speaking, no.  The thought was to
          make it similar to session-id and potentially make it easier
          for the reacting node to keep differentiate sequence numbers
          from different reporting nodes.

          

          

        
 

        
 

        

          
Steve

          
 

          
On 12/9/13 5:37 AM, Jouni Korhonen wrote:

          

            
Folks

            
 

            
Could we conclude on the sequence number vs. time stamp vs. something else?

            
We got more important places to spend our energy than this ;)

            
 

            
My proposal is the following (based on the original pre-00 design):

            
 

            
o We change the OC-Sequence-Number to OC-Time-Stamp in all occurrences

            
  in the -01.

            
o We use RFC6733 Time type for the OC-Time-Stamp. RFC6733 gives us

            
  already exact definition how to handle the AVP.

            
o Define that the OC-Time-Stamp is the time of the creation of the 

            
  "original" AVP within whose context the time stamp is present.

            
o The OC-Time-Stamp AVP uniqueness is still considered to be in scope

            
  of the communicating endpoints.

            
o The time stamp can be used to quickly determine if the content of

            
  the encapsulating AVP context has changed (among other properties).

            
  This would be useful specifically in the future when the encapsulating

            
  grouped AVPs  grow in size and functionality.

            
 

            
 

            
- Jouni

            
 

            
_______________________________________________

            
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

        

        
 

        
 

        
 

      

    

    

  


--------------030000090201020008080709--

From nsalot@cisco.com  Wed Dec 11 07:50:42 2013
Return-Path: 
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 848991ADF6D for ; Wed, 11 Dec 2013 07:50:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.501
X-Spam-Level: 
X-Spam-Status: No, score=-9.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.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 uQvmqaArSZZC for ; Wed, 11 Dec 2013 07:50:34 -0800 (PST)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id 525B51ADF70 for ; Wed, 11 Dec 2013 07:50:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=37878; q=dns/txt; s=iport; t=1386777029; x=1387986629; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=H7ngWAc4SsS+vNCEBJyM2hhSRO/vZEf+6KToHfnutuk=; b=k0XrN+T7w5YAesSk4d1VvjLxtEOA0J/Wgd/UQJFRM8GjfwBZSvCEOhdR 8MaHPqj/SJw+qUs9fRNqvQrdPUWvNeOs0x4RyczBuLIUogRGN0Sg3F5rs pbV5Lms43vq0+Q9Tg4Za8zB/01Hlg/1nlyW0T7ULNmGhYNimnpsy74j2S c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AicFAFyJqFKtJXG9/2dsb2JhbABQCYJDRDhTuSCBHRZ0giUBAQEDAQEBARcTQQsFBwQCAQgOAwQBAQsWAQYHIQYLFAkIAgQBDQUIh2gDCQYNuw8NhmcTBIx1gTgqLQQGAQaDG4ETBJQxgXiORYU5gymCKg
X-IronPort-AV: E=Sophos;i="4.93,872,1378857600"; d="scan'208,217";a="6021998"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by alln-iport-4.cisco.com with ESMTP; 11 Dec 2013 15:50:27 +0000
Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id rBBFoRXe006276 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Dec 2013 15:50:27 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.227]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Wed, 11 Dec 2013 09:50:27 -0600
From: "Nirav Salot (nsalot)" 
To: Steve Donovan , Jouni ,  "Wiehe, Ulrich (NSN - DE/Munich)" 
Thread-Topic: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3
Thread-Index: AQHO9nLYu2V9eWNrd0WnJAKaW5lMu5pPI8mA
Date: Wed, 11 Dec 2013 15:50:26 +0000
Message-ID: 
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DB1B@DEMUMBX014.nsn-intra.net>  <52A5E902.20605@usdonovans.com> <7475B713-1104-4791-96B1-CE97632A0D69@nostrum.com>  <5BCBA1FC2B7F0B4C9D935572D90006681519E476@DEMUMBX014.nsn-intra.net> <1CD20507-B0FE-4367-804A-B831734CF060@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E6DC@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D90006681519E712@DEMUMBX014.nsn-intra.net> <4A151D70-0291-4238-85B1-03BB54B361E6@gmail.com> <52A864FF.10705@usdonovans.com>
In-Reply-To: <52A864FF.10705@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.65.44.126]
Content-Type: multipart/alternative; boundary="_000_A9CA33BB78081F478946E4F34BF9AAA014D30775xmbrcdx10ciscoc_"
MIME-Version: 1.0
Cc: Ben Campbell , "dime@ietf.org list" 
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Dec 2013 15:50:42 -0000

--_000_A9CA33BB78081F478946E4F34BF9AAA014D30775xmbrcdx10ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Steve,

> Once the client is able to differentiate between realm reports sent by di=
fferent agents (or servers) we need logic defining how the client deals wit=
h a new overload report.
Why should the realm report be different - irrespective if they are sent by=
 two agents or one agent?

If multiple agents are sending report for the same realm, there should be s=
ome coordination between those agents to generate common view of the realm =
they are serving.

Regards,
Nirav.

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: Wednesday, December 11, 2013 6:44 PM
To: Jouni; Wiehe, Ulrich (NSN - DE/Munich)
Cc: Ben Campbell; dime@ietf.org list
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comment=
s to 4.3

Jouni,

We need the sequence number to be strictly increasing.  I don't see the nee=
d for it to increase in uniform amounts.  Using time does fit these require=
ments.  I'm ok with using time as long as we don't call the AVP timestamp.

Ulrich does bring up an interesting use case, where a client is receiving r=
ealm reports for the same realm from different agents.  We need to define t=
he clients behavior in this case.

Presumably the client needs to be able to determine who generated the realm=
 report.  This cannot be determine based on the content of the message or t=
he connection on which the message arrived.  It seems like we might need "R=
eport Generator Diameter ID" in the overload report specifically for Realm =
reports.

Once the client is able to differentiate between realm reports sent by diff=
erent agents (or servers) we need logic defining how the client deals with =
a new overload report.

I see a couple of options (others will probably see options I am missing):

- Use the last received realm report - This introduces the possibility of t=
hrashing between two different reduction values and different durations.  N=
ote that this approach does not require the source of the report to be incl=
uded in the report.

- Only listen to one source of realm overload - The approach would be to re=
member who sent the first overload report from the realm and ignore realm o=
verload reports from other sources.  This behavior would likely be constrai=
ned to a single occurrence of realm overload.  Meaning that the "memory" of=
 the report source would only last as long as that overload event persists.=
  Once the overload event goes away, the report source would be forgotten a=
nd a new source could be used for the next occurrence.

On the surface, the second approach looks better to me.

Steve
On 12/11/13 2:15 AM, Jouni wrote:

Ulrich,



I might be slow but.. Section 4.4 says



   control endpoints.  The sequence number is only required to be unique

   between two overload control endpoints and does not need to be



Unique between two endpoints..



Section 5.1 talks about endpoints:



   of an arbitrary Diameter network.  The overload control information

   is exchanged over on a "DOIC association" between two communication

   endpoints.  The endpoints, namely the "reacting node" and the

   "reporting node" do not need to be adjacent Diameter peer nodes, nor



So if your agents inject realm reports, they need to be endpoints to the

client. Similar to Figure 5. Therefore the sequence number spaces between

C-A1 and C-A2 are separate.



Now it is not clear to me, whether in your reasoning the C would see

the server identity (as the endpoint) when there is an active "DEP

agent" on the path. That would not clearly work and not be align with

the endpoint assumption.



Note that at some point of time we had (at least on a discussion level

in f2f meeting) report originator identity in the OLR. That would make

endpoint identification trivial. Now a "DEP agent" needs to act as a

"server" for its clients in order to appear as an endpoint.



- Jouni



ps: still think the use of Time is simpler..





On Dec 11, 2013, at 9:43 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:



That's not predictable. It may be the same server in some cases, and differ=
ent servers in other cases.



-----Original Message-----

From: ext Jouni [mailto:jouni.nospam@gmail.com]

Sent: Wednesday, December 11, 2013 8:38 AM

To: Wiehe, Ulrich (NSN - DE/Munich)

Cc: Ben Campbell; dime@ietf.org list; Steve Donovan

Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comment=
s to 4.3





Ulrich,



On Dec 11, 2013, at 9:21 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:



Jouni,



ad 1. "monotonically" does not express your intention. What we are looking =
for may be "stepwise with fixed step".



Ad 2. Is not necessarily a mistake that could result in out-of-sequence seq=
uence numbers. When a client C sends a realm-type requests towards any serv=
er in the realm, an agent A1 that selects the server would send back the re=
alm-type OLR with sequence number s1. The next realm-type request sent by C=
 (that survived the throttling) may take a path that does not include A1 bu=
t A2. A2 then selects the server and sends back a sequence number s2. Nothi=
ng ensures that s1 and s2 are in sequence.



Would the server in both cases (via A1 and A2) be the same?



- Jouni







Ulrich





-----Original Message-----

From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Sent: Tuesday, December 10, 2013 10:31 PM

To: Wiehe, Ulrich (NSN - DE/Munich)

Cc: Ben Campbell; dime@ietf.org list; Steve Donovan

Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comment=
s to 4.3



Ulrich,



On Dec 10, 2013, at 4:31 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:



Jouni,



1. I find the texts

a) "The sequence number ... does not need to be monotonically increasing"

and



Means the delta from old-seqno to new-seqno can be any non-negative integer

(within the given limits) not something fixed step/delta (like +1). As long=
 as

"new-seqno >=3D old-seqno" holds we are fine.



b) "...the new sequence number MUST be greater or equal than the old sequen=
ce number..."

contradicting.

Can you please clarify.



See above. (mind the overflow case)



2. The expected behaviour when receiving an out-of-sequence sequence number=
 within OC-OLR is described in 4.3:

"The receiver SHOULD discard an OC-OLR AVP with a sequence number that is l=
ess than previously received one."

I don't find this very robust. Once a higher sequence number (received erro=
neously by mistake) is accepted you cannot (easily) recover.



I find it more robust in a sense that I should not care about stale old inf=
ormation.

However, since we are piggybacking (by popular demand) we have little room =
for seqno

re-sync negotiation.



What is the mistake you refer here? A misbehaving implementation? In that c=
ase, it

deserves to get a manual intervention once figured out by admins checking a=
larms and

logs. If the mistake is due other things, like endpoints being out of sync,=
 we currently

have no written down mechanism to survive that.



3. The expected behaviour when receiving an out-of-sequence sequence number=
 within the OC-Supported-Features AVP is not described. What is the intenti=
on here?



No intention. Just a sloppy specification. You are right that something nee=
ds to be

done & clarified here. (again the semantics of Time would nice..)



I'll propose something. Others should too ;)



- Jouni





Ulrich



-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Jouni Korhonen

Sent: Tuesday, December 10, 2013 8:28 AM

To: Ben Campbell; dime@ietf.org list; Steve Donovan

Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comment=
s to 4.3





Fine.. lets define then the sequence number semantics. Basic

unsigned integer math. The text proposal is the following:



4.4.  OC-Sequence-Number AVP



The OC-Sequence-Number AVP (AVP code TBD3) is type of Unsigned64.

Its usage in the context of the overload control is described in

Sections 4.1 and 4.3.



>From the functionality point of view, the OC-Sequence-Number AVP

MUST be used as a non-volatile increasing counter between two

overload control endpoints.  The sequence number is only required

to be unique between two overload control endpoints and does not

need to be monotonically increasing.



When comparing two sequence numbers, the new sequence number MUST

be greater or equal than the old sequence number within a window

that is half of the size of the maximum sequence number. This

allows a simple handling of the sequence number overflow using

unsigned integer arithmeticf:



  #define WINDOW 0x8000000000000000ULL



  bool verify_seqnum( uint64_t newsn, uint64_t oldsn ) {

      if (newsn - oldsn <=3D WINDOW)

          // newsn >=3D oldsn

          return true;

      } else

          // outside window or newsn < oldsn

          return false;

      }

  }







The above should even work is someone shovels NTP times into

sequence numbers with a blind typecasting.



- Jouni



On Dec 10, 2013, at 12:34 AM, Ben Campbell  wrote:





On Dec 9, 2013, at 10:00 AM, Steve Donovan  wrote:



Jouni,



I propose that we keep the name OC-Sequence-Number but that we use the Time=
 type for OC-Sequence-Number.  It is misleading and potentially confusing t=
o call it OC-Time-Stamp.





I could live with that, although I would rather just define the expected pr=
operties of the sequence number, and leave the implementation up to the imp=
lementor. I assume your reasoning for not calling it a timestamp is that yo=
u do not want people to try to use it as a time base reference. If so, then=
 we don't require any connection to a clock. We just need it to be monotoni=
cally increasing.



We might consider expanding on the format of the AVP to make it something l=
ike Session-ID, where it is a concatenation of the Diameter-ID of the gener=
ating node and a timestamp.  This might help the reacting node keep track o=
f which sequence number it has received.





Do we need a uniqueness across multiple nodes property? If so, why?



Steve



On 12/9/13 5:37 AM, Jouni Korhonen wrote:

Folks



Could we conclude on the sequence number vs. time stamp vs. something else?

We got more important places to spend our energy than this ;)



My proposal is the following (based on the original pre-00 design):



o We change the OC-Sequence-Number to OC-Time-Stamp in all occurrences

in the -01.

o We use RFC6733 Time type for the OC-Time-Stamp. RFC6733 gives us

already exact definition how to handle the AVP.

o Define that the OC-Time-Stamp is the time of the creation of the

"original" AVP within whose context the time stamp is present.

o The OC-Time-Stamp AVP uniqueness is still considered to be in scope

of the communicating endpoints.

o The time stamp can be used to quickly determine if the content of

the encapsulating AVP context has changed (among other properties).

This would be useful specifically in the future when the encapsulating

grouped AVPs  grow in size and functionality.





- Jouni



_______________________________________________

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










--_000_A9CA33BB78081F478946E4F34BF9AAA014D30775xmbrcdx10ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Steve,<=
/p>

 <=
/p>

> Once the clie=
nt is able to differentiate between realm reports sent by different agents =
(or servers) we need logic defining how the client deals with
 a new overload report. <=
/p>

Why should the realm repo=
rt be different – irrespective if they are sent by two agents or one =
agent?


 <=
/p>

If multiple agents are se=
nding report for the same realm, there should be some coordination between =
those agents to generate common view of the realm they are
 serving.


 <=
/p>

Regards,


Nirav.<=
/p>

 <=
/p>





From: DiME [mailto:dime-bounces@ietf.org]
On Behalf Of Steve Donovan

Sent: Wednesday, December 11, 2013 6:44 PM

To: Jouni; Wiehe, Ulrich (NSN - DE/Munich)

Cc: Ben Campbell; dime@ietf.org list

Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: =
comments to 4.3






 


Jouni,



We need the sequence number to be strictly increasing.  I don't see th=
e need for it to increase in uniform amounts.  Using time does fit the=
se requirements.  I'm ok with using time as long as we don't call the =
AVP timestamp.



Ulrich does bring up an interesting use case, where a client is receiving r=
ealm reports for the same realm from different agents.  We need to def=
ine the clients behavior in this case. 




Presumably the client needs to be able to determine who generated the realm=
 report.  This cannot be determine based on the content of the message=
 or the connection on which the message arrived.  It seems like we mig=
ht need "Report Generator Diameter ID" in
 the overload report specifically for Realm reports.  



Once the client is able to differentiate between realm reports sent by diff=
erent agents (or servers) we need logic defining how the client deals with =
a new overload report. 




I see a couple of options (others will probably see options I am missing):<=
br>


- Use the last received realm report - This introduces the possibility of t=
hrashing between two different reduction values and different durations.&nb=
sp; Note that this approach does not require the source of the report to be=
 included in the report.



- Only listen to one source of realm overload - The approach would be to re=
member who sent the first overload report from the realm and ignore realm o=
verload reports from other sources.  This behavior would likely be con=
strained to a single occurrence of realm
 overload.  Meaning that the "memory" of the report source w=
ould only last as long as that overload event persists.  Once the over=
load event goes away, the report source would be forgotten and a new source=
 could be used for the next occurrence.



On the surface, the second approach looks better to me.



Steve




On 12/11/13 2:15 AM, Jouni wrote:






Ulrich,


 


I might be slow but.. Section 4.4 says


 


   control endpoints.  The sequence number is only requ=
ired to be unique


   between two overload control endpoints and does not need =
to be


 


Unique between two endpoints..


 


Section 5.1 talks about endpoints:


 


   of an arbitrary Diameter network.  The overload cont=
rol information


   is exchanged over on a "DOIC association" betwe=
en two communication


   endpoints.  The endpoints, namely the "reacting=
 node" and the


   "reporting node" do not need to be adjacent Dia=
meter peer nodes, nor


 


So if your agents inject realm reports, they need to be endpoints to t=
he


client. Similar to Figure 5. Therefore the sequence number spaces betw=
een


C-A1 and C-A2 are separate.


 


Now it is not clear to me, whether in your reasoning the C would see


the server identity (as the endpoint) when there is an active "DE=
P


agent" on the path. That would not clearly work and not be align =
with


the endpoint assumption.


 


Note that at some point of time we had (at least on a discussion level=



in f2f meeting) report originator identity in the OLR. That would make=



endpoint identification trivial. Now a "DEP agent" needs to =
act as a 


"server" for its clients in order to appear as an endpoint.<=
o:p>


 


- Jouni


 


ps: still think the use of Time is simpler..


 


 


On Dec 11, 2013, at 9:43 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:


 




That's not predictable. It may be the same server in some cases, and d=
ifferent servers in other cases.


 


-----Original Message-----


From: ext Jouni [mailto:joun=
i.nospam@gmail.com] 


Sent: Wednesday, December 11, 2013 8:38 AM


To: Wiehe, Ulrich (NSN - DE/Munich)


Cc: Ben Campbell; dime@ietf.org l=
ist; Steve Donovan


Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: co=
mments to 4.3


 


 


Ulrich,


 


On Dec 11, 2013, at 9:21 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:


 




Jouni,


 


ad 1. "monotonically" does not express your intention. What =
we are looking for may be "stepwise with fixed step".<=
/pre>

 


Ad 2. Is not necessarily a mistake that could result in out-of-sequenc=
e sequence numbers. When a client C sends a realm-type requests towards any=
 server in the realm, an agent A1 that selects the server would send back t=
he realm-type OLR with sequence number s1. The next realm-type request sent=
 by C (that survived the throttling) may take a path that does not include =
A1 but A2. A2 then selects the server and sends back a sequence number s2. =
Nothing ensures that s1 and s2 are in sequence.




 


Would the server in both cases (via A1 and A2) be the same?=



 


- Jouni


 


 




 


Ulrich


 


 


-----Original Message-----


From: ext Jouni Korhonen [ma=
ilto:jouni.nospam@gmail.com] 


Sent: Tuesday, December 10, 2013 10:31 PM


To: Wiehe, Ulrich (NSN - DE/Munich)


Cc: Ben Campbell; dime@ietf.org l=
ist; Steve Donovan


Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: co=
mments to 4.3


 


Ulrich,


 


On Dec 10, 2013, at 4:31 PM, "Wiehe, Ulrich (NSN - DE/Munich)&quo=
t; <ulrich.wiehe@nsn.com>=
 wrote:


 




Jouni,


 


1. I find the texts


a) "The sequence number ... does not need to be monotonically inc=
reasing"


and 




 


Means the delta from old-seqno to new-seqno can be any non-negative in=
teger


(within the given limits) not something fixed step/delta (like +1)=
. As long as


"new-seqno >=3D old-seqno" holds we are fine.<=
/pre>

 




b) "...the new sequence number MUST be greater or equal than the =
old sequence number..."


contradicting.


Can you please clarify.




 


See above. (mind the overflow case)


 




2. The expected behaviour when receiving an out-of-sequence sequence n=
umber within OC-OLR is described in 4.3:


"The receiver SHOULD discard an OC-OLR AVP with a sequence number=
 that is less than previously received one."


I don't find this very robust. Once a higher sequence number (received=
 erroneously by mistake) is accepted you cannot (easily) recover.




 


I find it more robust in a sense that I should not care about stale ol=
d information.


However, since we are piggybacking (by popular demand) we have little =
room for seqno


re-sync negotiation.


 


What is the mistake you refer here? A misbehaving implementation? In t=
hat case, it 


deserves to get a manual intervention once figured out by admins check=
ing alarms and


logs. If the mistake is due other things, like endpoints being out of =
sync, we currently


have no written down mechanism to survive that.


 




3. The expected behaviour when receiving an out-of-sequence sequence n=
umber within the OC-Supported-Features AVP is not described. What is the in=
tention here?




 


No intention. Just a sloppy specification. You are right that somethin=
g needs to be


done & clarified here. (again the semantics of Time would nice..)<=
o:p>


 


I'll propose something. Others should too ;)


 


- Jouni


 




 


Ulrich


 


-----Original Message-----


From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of ext Jouni Korhonen


Sent: Tuesday, December 10, 2013 8:28 AM


To: Ben Campbell; dime@ietf.org l=
ist; Steve Donovan


Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: co=
mments to 4.3


 


 


Fine.. lets define then the sequence number semantics. Basic


unsigned integer math. The text proposal is the following:<=
/pre>

 


4.4.  OC-Sequence-Number AVP


 


The OC-Sequence-Number AVP (AVP code TBD3) is type of Unsigned64.=



Its usage in the context of the overload control is described in<=
/o:p>


Sections 4.1 and 4.3.


 


From the functionality point of view, the OC-Sequence-Number AVP<=
/o:p>


MUST be used as a non-volatile increasing counter between two


overload control endpoints.  The sequence number is only required=



to be unique between two overload control endpoints and does not<=
/o:p>


need to be monotonically increasing.


 


When comparing two sequence numbers, the new sequence number MUST=



be greater or equal than the old sequence number within a window<=
/o:p>


that is half of the size of the maximum sequence number. This


allows a simple handling of the sequence number overflow using


unsigned integer arithmeticf:


 


  #define WINDOW 0x8000000000000000ULL


 


  bool verify_seqnum( uint64_t newsn, uint64_t oldsn ) {


      if (newsn - oldsn <=3D WINDOW)<=
/o:p>


          // newsn >=
=3D oldsn


          return true;&nb=
sp;  


      } else


          // outside wind=
ow or newsn < oldsn


          return false;&n=
bsp; 


      }


  }


 


 


 


The above should even work is someone shovels NTP times into


sequence numbers with a blind typecasting.


 


- Jouni


 


On Dec 10, 2013, at 12:34 AM, Ben Campbell <ben@nostrum.com> wrote:


 




 


On Dec 9, 2013, at 10:00 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:

 




Jouni,


 


I propose that we keep the name OC-Sequence-Number but that we use the=
 Time type for OC-Sequence-Number.  It is misleading and potentially c=
onfusing to call it OC-Time-Stamp.  


 




 


I could live with that, although I would rather just define the expect=
ed properties of the sequence number, and leave the implementation up to th=
e implementor. I assume your reasoning for not calling it a timestamp is th=
at you do not want people to try to use it as a time base reference. If so,=
 then we don't require any connection to a clock. We just need it to be mon=
otonically increasing.


 




We might consider expanding on the format of the AVP to make it someth=
ing like Session-ID, where it is a concatenation of the Diameter-ID of the =
generating node and a timestamp.  This might help the reacting node ke=
ep track of which sequence number it has received.


 




 


Do we need a uniqueness across multiple nodes property? If so, why?


 




Steve


 


On 12/9/13 5:37 AM, Jouni Korhonen wrote:




Folks


 


Could we conclude on the sequence number vs. time stamp vs. something =
else?


We got more important places to spend our energy than this ;)


 


My proposal is the following (based on the original pre-00 design):


 


o We change the OC-Sequence-Number to OC-Time-Stamp in all occurrences=



in the -01.


o We use RFC6733 Time type for the OC-Time-Stamp. RFC6733 gives us


already exact definition how to handle the AVP.


o Define that the OC-Time-Stamp is the time of the creation of the 


"original" AVP within whose context the time stamp is presen=
t.


o The OC-Time-Stamp AVP uniqueness is still considered to be in scope<=
o:p>


of the communicating endpoints.


o The time stamp can be used to quickly determine if the content of


the encapsulating AVP context has changed (among other properties).


This would be useful specifically in the future when the encapsulating=



grouped AVPs  grow in size and functionality.


 


 


- Jouni


 


_______________________________________________


DiME mailing list


 


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 


 


 




 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime




 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime




 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime




 




 




 


 




 






--_000_A9CA33BB78081F478946E4F34BF9AAA014D30775xmbrcdx10ciscoc_--


From jouni.nospam@gmail.com  Wed Dec 11 07:53:56 2013
Return-Path: 
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 2EAA61ADF68 for ; Wed, 11 Dec 2013 07:53:56 -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 olzP7ZIxQKss for ; Wed, 11 Dec 2013 07:53:53 -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 9B61D1ADF2F for ; Wed, 11 Dec 2013 07:53:52 -0800 (PST)
Received: by mail-la0-f47.google.com with SMTP id ep20so3911183lab.20 for ; Wed, 11 Dec 2013 07:53:46 -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=ZBSSd3P0AjALY8kVLBOUV1JVVC1rLZj1RKKv5Q6Q41U=; b=uBjUR9kS63gHWk9q1aVJQA8YA7yEDaYLrnGRh82DGFbR+Yokr7Nu8h0DBujCWL3pCi pzqjYiFEmm5zALCMIVqRhGoV8Q6qa1rjVhmxlcPgdJc/oiyeiC8PWOlTv/NADwlvxX7W e/7PHrFH89GJrIUgTJl1yVdxOShvJgEUps1oCYP2fa9WOEdv0oBq6NbnkuMgjWWEF/WR YZJw7oLL37gKl51WdIyOpnFWpA873FulJmLqrZYFEcYhGzhHP5UM67dnKKpZCEu/HWZD JTQLz3z70+9UhoUfd5MpdAtSEVX1pZlIhhkmN9Tga+LVFQkCMT4PdKjZ9Ebir76ch3a5 SLTQ==
X-Received: by 10.152.22.228 with SMTP id h4mr748696laf.71.1386777226327; Wed, 11 Dec 2013 07:53:46 -0800 (PST)
Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id a8sm29141056lae.5.2013.12.11.07.53.45 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Dec 2013 07:53:45 -0800 (PST)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jouni Korhonen 
In-Reply-To: <52A864FF.10705@usdonovans.com>
Date: Wed, 11 Dec 2013 17:53:44 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <23887553-5068-477A-AE34-3DC5E3D5AC76@gmail.com>
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DB1B@DEMUMBX014.nsn-intra.net>  <52A5E902.20605@usdonovans.com> <7475B713-1104-4791-96B1-CE97632A0D69@nostrum.com>  <5BCBA1FC2B7F0B4C9D935572D90006681519E476@DEMUMBX014.nsn-intra.net> <1CD20507-B0FE-4367-804A-B831734CF060@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E6DC@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D90006681519E712@DEMUMBX014.nsn-intra.net> <4A151D70-0291-4238-85B1-03BB54B361E6@gmail.com> <52A864FF.10705@usdonovans.com>
To: Steve Donovan 
X-Mailer: Apple Mail (2.1510)
Cc: Ben Campbell , "dime@ietf.org list" 
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Dec 2013 15:53:56 -0000

Steve,

On Dec 11, 2013, at 3:13 PM, Steve Donovan  =
wrote:

> Jouni,
>=20
> We need the sequence number to be strictly increasing.  I don't see =
the need for it to increase in uniform amounts.  Using time does fit =
these requirements.  I'm ok with using time as long as we don't call the =
AVP timestamp.

Ok.

> Ulrich does bring up an interesting use case, where a client is =
receiving realm reports for the same realm from different agents.  We =
need to define the clients behavior in this case. =20

Could we simply say that in this case the agents (or who ever inserts =
the realm report)
MUST share the same view of the realm overload condition? Obviously how =
it is achieved=20
would be implementation specific. I recall we have surfaced this topic =
earlier..

- Jouni


> Presumably the client needs to be able to determine who generated the =
realm report.  This cannot be determine based on the content of the =
message or the connection on which the message arrived.  It seems like =
we might need "Report Generator Diameter ID" in the overload report =
specifically for Realm reports. =20
>=20
> Once the client is able to differentiate between realm reports sent by =
different agents (or servers) we need logic defining how the client =
deals with a new overload report. =20
>=20
> I see a couple of options (others will probably see options I am =
missing):
>=20
> - Use the last received realm report - This introduces the possibility =
of thrashing between two different reduction values and different =
durations.  Note that this approach does not require the source of the =
report to be included in the report.
>=20
> - Only listen to one source of realm overload - The approach would be =
to remember who sent the first overload report from the realm and ignore =
realm overload reports from other sources.  This behavior would likely =
be constrained to a single occurrence of realm overload.  Meaning that =
the "memory" of the report source would only last as long as that =
overload event persists.  Once the overload event goes away, the report =
source would be forgotten and a new source could be used for the next =
occurrence.
>=20
> On the surface, the second approach looks better to me.
>=20
> Steve
>=20
> On 12/11/13 2:15 AM, Jouni wrote:
>> Ulrich,
>>=20
>> I might be slow but.. Section 4.4 says
>>=20
>>    control endpoints.  The sequence number is only required to be =
unique
>>    between two overload control endpoints and does not need to be
>>=20
>> Unique between two endpoints..
>>=20
>> Section 5.1 talks about endpoints:
>>=20
>>    of an arbitrary Diameter network.  The overload control =
information
>>    is exchanged over on a "DOIC association" between two =
communication
>>    endpoints.  The endpoints, namely the "reacting node" and the
>>    "reporting node" do not need to be adjacent Diameter peer nodes, =
nor
>>=20
>> So if your agents inject realm reports, they need to be endpoints to =
the
>> client. Similar to Figure 5. Therefore the sequence number spaces =
between
>> C-A1 and C-A2 are separate.
>>=20
>> Now it is not clear to me, whether in your reasoning the C would see
>> the server identity (as the endpoint) when there is an active "DEP
>> agent" on the path. That would not clearly work and not be align with
>> the endpoint assumption.
>>=20
>> Note that at some point of time we had (at least on a discussion =
level
>> in f2f meeting) report originator identity in the OLR. That would =
make
>> endpoint identification trivial. Now a "DEP agent" needs to act as a=20=

>> "server" for its clients in order to appear as an endpoint.
>>=20
>> - Jouni
>>=20
>> ps: still think the use of Time is simpler..
>>=20
>>=20
>> On Dec 11, 2013, at 9:43 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>>=20
>>=20
>>> That's not predictable. It may be the same server in some cases, and =
different servers in other cases.
>>>=20
>>> -----Original Message-----
>>> From: ext Jouni [
>>> mailto:jouni.nospam@gmail.com
>>> ]=20
>>> Sent: Wednesday, December 11, 2013 8:38 AM
>>> To: Wiehe, Ulrich (NSN - DE/Munich)
>>> Cc: Ben Campbell;=20
>>> dime@ietf.org
>>>  list; Steve Donovan
>>> Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: =
comments to 4.3
>>>=20
>>>=20
>>> Ulrich,
>>>=20
>>> On Dec 11, 2013, at 9:21 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>>>=20
>>>=20
>>>> Jouni,
>>>>=20
>>>> ad 1. "monotonically" does not express your intention. What we are =
looking for may be "stepwise with fixed step".
>>>>=20
>>>> Ad 2. Is not necessarily a mistake that could result in =
out-of-sequence sequence numbers. When a client C sends a realm-type =
requests towards any server in the realm, an agent A1 that selects the =
server would send back the realm-type OLR with sequence number s1. The =
next realm-type request sent by C (that survived the throttling) may =
take a path that does not include A1 but A2. A2 then selects the server =
and sends back a sequence number s2. Nothing ensures that s1 and s2 are =
in sequence.
>>>>=20
>>> Would the server in both cases (via A1 and A2) be the same?
>>>=20
>>> - Jouni
>>>=20
>>>=20
>>>=20
>>>> Ulrich
>>>>=20
>>>>=20
>>>> -----Original Message-----
>>>> From: ext Jouni Korhonen [
>>>> mailto:jouni.nospam@gmail.com
>>>> ]=20
>>>> Sent: Tuesday, December 10, 2013 10:31 PM
>>>> To: Wiehe, Ulrich (NSN - DE/Munich)
>>>> Cc: Ben Campbell;=20
>>>> dime@ietf.org
>>>>  list; Steve Donovan
>>>> Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: =
comments to 4.3
>>>>=20
>>>> Ulrich,
>>>>=20
>>>> On Dec 10, 2013, at 4:31 PM, "Wiehe, Ulrich (NSN - DE/Munich)"=20
>>>> 
>>>>  wrote:
>>>>=20
>>>>=20
>>>>> Jouni,
>>>>>=20
>>>>> 1. I find the texts
>>>>> a) "The sequence number ... does not need to be monotonically =
increasing"
>>>>> and=20
>>>>>=20
>>>> Means the delta from old-seqno to new-seqno can be any non-negative =
integer
>>>> (within the given limits) not something fixed step/delta (like +1). =
As long as
>>>> "new-seqno >=3D old-seqno" holds we are fine.
>>>>=20
>>>>=20
>>>>> b) "...the new sequence number MUST be greater or equal than the =
old sequence number..."
>>>>> contradicting.
>>>>> Can you please clarify.
>>>>>=20
>>>> See above. (mind the overflow case)
>>>>=20
>>>>=20
>>>>> 2. The expected behaviour when receiving an out-of-sequence =
sequence number within OC-OLR is described in 4.3:
>>>>> "The receiver SHOULD discard an OC-OLR AVP with a sequence number =
that is less than previously received one."
>>>>> I don't find this very robust. Once a higher sequence number =
(received erroneously by mistake) is accepted you cannot (easily) =
recover.
>>>>>=20
>>>> I find it more robust in a sense that I should not care about stale =
old information.
>>>> However, since we are piggybacking (by popular demand) we have =
little room for seqno
>>>> re-sync negotiation.
>>>>=20
>>>> What is the mistake you refer here? A misbehaving implementation? =
In that case, it=20
>>>> deserves to get a manual intervention once figured out by admins =
checking alarms and
>>>> logs. If the mistake is due other things, like endpoints being out =
of sync, we currently
>>>> have no written down mechanism to survive that.
>>>>=20
>>>>=20
>>>>> 3. The expected behaviour when receiving an out-of-sequence =
sequence number within the OC-Supported-Features AVP is not described. =
What is the intention here?
>>>>>=20
>>>> No intention. Just a sloppy specification. You are right that =
something needs to be
>>>> done & clarified here. (again the semantics of Time would nice..)
>>>>=20
>>>> I'll propose something. Others should too ;)
>>>>=20
>>>> - Jouni
>>>>=20
>>>>=20
>>>>> Ulrich
>>>>>=20
>>>>> -----Original Message-----
>>>>> From: DiME [
>>>>> mailto:dime-bounces@ietf.org
>>>>> ] On Behalf Of ext Jouni Korhonen
>>>>> Sent: Tuesday, December 10, 2013 8:28 AM
>>>>> To: Ben Campbell;=20
>>>>> dime@ietf.org
>>>>>  list; Steve Donovan
>>>>> Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: =
OVLI: comments to 4.3
>>>>>=20
>>>>>=20
>>>>> Fine.. lets define then the sequence number semantics. Basic
>>>>> unsigned integer math. The text proposal is the following:
>>>>>=20
>>>>> 4.4.  OC-Sequence-Number AVP
>>>>>=20
>>>>> The OC-Sequence-Number AVP (AVP code TBD3) is type of Unsigned64.
>>>>> Its usage in the context of the overload control is described in
>>>>> Sections 4.1 and 4.3.
>>>>>=20
>>>>> =46rom the functionality point of view, the OC-Sequence-Number AVP
>>>>> MUST be used as a non-volatile increasing counter between two
>>>>> overload control endpoints.  The sequence number is only required
>>>>> to be unique between two overload control endpoints and does not
>>>>> need to be monotonically increasing.
>>>>>=20
>>>>> When comparing two sequence numbers, the new sequence number MUST
>>>>> be greater or equal than the old sequence number within a window
>>>>> that is half of the size of the maximum sequence number. This
>>>>> allows a simple handling of the sequence number overflow using
>>>>> unsigned integer arithmeticf:
>>>>>=20
>>>>>   #define WINDOW 0x8000000000000000ULL
>>>>>=20
>>>>>   bool verify_seqnum( uint64_t newsn, uint64_t oldsn ) {
>>>>>       if (newsn - oldsn <=3D WINDOW)
>>>>>           // newsn >=3D oldsn
>>>>>           return true;  =20
>>>>>       } else
>>>>>           // outside window or newsn < oldsn
>>>>>           return false; =20
>>>>>       }
>>>>>   }
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> The above should even work is someone shovels NTP times into
>>>>> sequence numbers with a blind typecasting.
>>>>>=20
>>>>> - Jouni
>>>>>=20
>>>>> On Dec 10, 2013, at 12:34 AM, Ben Campbell=20
>>>>> 
>>>>>  wrote:
>>>>>=20
>>>>>=20
>>>>>> On Dec 9, 2013, at 10:00 AM, Steve Donovan =

>>>>>>  wrote:
>>>>>>=20
>>>>>>=20
>>>>>>> Jouni,
>>>>>>>=20
>>>>>>> I propose that we keep the name OC-Sequence-Number but that we =
use the Time type for OC-Sequence-Number.  It is misleading and =
potentially confusing to call it OC-Time-Stamp. =20
>>>>>>>=20
>>>>>>>=20
>>>>>> I could live with that, although I would rather just define the =
expected properties of the sequence number, and leave the implementation =
up to the implementor. I assume your reasoning for not calling it a =
timestamp is that you do not want people to try to use it as a time base =
reference. If so, then we don't require any connection to a clock. We =
just need it to be monotonically increasing.
>>>>>>=20
>>>>>>=20
>>>>>>> We might consider expanding on the format of the AVP to make it =
something like Session-ID, where it is a concatenation of the =
Diameter-ID of the generating node and a timestamp.  This might help the =
reacting node keep track of which sequence number it has received.
>>>>>>>=20
>>>>>>>=20
>>>>>> Do we need a uniqueness across multiple nodes property? If so, =
why?
>>>>>>=20
>>>>>>=20
>>>>>>> Steve
>>>>>>>=20
>>>>>>> On 12/9/13 5:37 AM, Jouni Korhonen wrote:
>>>>>>>=20
>>>>>>>> Folks
>>>>>>>>=20
>>>>>>>> Could we conclude on the sequence number vs. time stamp vs. =
something else?
>>>>>>>> We got more important places to spend our energy than this ;)
>>>>>>>>=20
>>>>>>>> My proposal is the following (based on the original pre-00 =
design):
>>>>>>>>=20
>>>>>>>> o We change the OC-Sequence-Number to OC-Time-Stamp in all =
occurrences
>>>>>>>> in the -01.
>>>>>>>> o We use RFC6733 Time type for the OC-Time-Stamp. RFC6733 gives =
us
>>>>>>>> already exact definition how to handle the AVP.
>>>>>>>> o Define that the OC-Time-Stamp is the time of the creation of =
the=20
>>>>>>>> "original" AVP within whose context the time stamp is present.
>>>>>>>> o The OC-Time-Stamp AVP uniqueness is still considered to be in =
scope
>>>>>>>> of the communicating endpoints.
>>>>>>>> o The time stamp can be used to quickly determine if the =
content of
>>>>>>>> the encapsulating AVP context has changed (among other =
properties).
>>>>>>>> This would be useful specifically in the future when the =
encapsulating
>>>>>>>> grouped AVPs  grow in size and functionality.
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> - Jouni
>>>>>>>>=20
>>>>>>>> _______________________________________________
>>>>>>>> DiME mailing list
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> DiME@ietf.org
>>>>>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>> _______________________________________________
>>>>>>> DiME mailing list
>>>>>>>=20
>>>>>>> DiME@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>>> _______________________________________________
>>>>>> DiME mailing list
>>>>>>=20
>>>>>> DiME@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>> _______________________________________________
>>>>> DiME mailing list
>>>>>=20
>>>>> DiME@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/dime
>>=20
>=20


From maria.cruz.bartolome@ericsson.com  Wed Dec 11 09:22:38 2013
Return-Path: 
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 CF52B1ADF46 for ; Wed, 11 Dec 2013 09:22:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.24
X-Spam-Level: 
X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no
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 6rtmlQD-vsGl for ; Wed, 11 Dec 2013 09:22:37 -0800 (PST)
Received: from sessmg21.mgmt.ericsson.se (sessmg21.ericsson.net [193.180.251.40]) by ietfa.amsl.com (Postfix) with ESMTP id 3DE171AD75F for ; Wed, 11 Dec 2013 09:22:36 -0800 (PST)
X-AuditID: c1b4fb28-b7f268e000001b97-7f-52a89f56dec3
Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg21.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 0F.F6.07063.65F98A25; Wed, 11 Dec 2013 18:22:30 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.197]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.02.0347.000; Wed, 11 Dec 2013 18:22:30 +0100
From: Maria Cruz Bartolome 
To: Jouni Korhonen , Steve Donovan 
Thread-Topic: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments	to 4.3
Thread-Index: AQHO9ok9YunEgHUBi06/+spHYoNMOZpPPMXQ
Date: Wed, 11 Dec 2013 17:22:29 +0000
Message-ID: <087A34937E64E74E848732CFF8354B920973A7D7@ESESSMB101.ericsson.se>
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DB1B@DEMUMBX014.nsn-intra.net>  <52A5E902.20605@usdonovans.com> <7475B713-1104-4791-96B1-CE97632A0D69@nostrum.com>  <5BCBA1FC2B7F0B4C9D935572D90006681519E476@DEMUMBX014.nsn-intra.net> <1CD20507-B0FE-4367-804A-B831734CF060@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E6DC@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D90006681519E712@DEMUMBX014.nsn-intra.net> <4A151D70-0291-4238-85B1-03BB54B361E6@gmail.com> <52A864FF.10705@usdonovans.com> <23887553-5068-477A-AE34-3DC5E3D5AC76@gmail.com>
In-Reply-To: <23887553-5068-477A-AE34-3DC5E3D5AC76@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.154]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrALMWRmVeSWpSXmKPExsUyM+JvrW7Y/BVBBvdemFnM7zzNbjG3dwWb xf51DUwWG5p4HFg8ds66y+6xZMlPJo9ZO5+weKx628cawBLFZZOSmpNZllqkb5fAlfGudSF7 wTzWisfXt7I3ME5h6WLk5JAQMJE413SYGcIWk7hwbz0biC0kcIJRou2gAIS9hFGic2IWiM0m YCdx6fQLJhBbRCBcYt7UJ6wgNrOAh0TL5EVgtrBAqMSMJafZIWrCJK7u/QY0nwPINpK48R5s JIuAqsTfhafATuAV8JU4dW41UAkX0KozrBJT1m8Cm88pYCuxfdVTsNsYgW77fmoNE8QucYlb T+YzQdwsILFkz3mo+0UlXj7+xwphK0ksuv0Zql5HYsHuT2wQtrbEsoWvmSEWC0qcnPmEZQKj 2CwkY2chaZmFpGUWkpYFjCyrGCWLU4uLc9ONDPVy03NL9FKLMpOLi/Pz9IpTNzECY+3glt8a Oxi7r9kfYpTmYFES562a2RkkJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgZG3ZOO+ZZFHfj6+ ayodGSBwPLXyGvctZc2SRyx3OZtFub4Y6Z8+WWr3/4qiy/qTkz2Xb+ydo7ZQTmlt+PPVf5s/ an9bLyn21p7TUvfek3rf87P/mp9z2iLk+OrmiZinb23kqgV7HhfJpfubPeP+HnBT99zFk5nB Id0zqlhDve5zOCw1/Jl/s0+JpTgj0VCLuag4EQB/D37igwIAAA==
Cc: Ben Campbell , "dime@ietf.org list" 
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments	to 4.3
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Dec 2013 17:22:39 -0000

Dear all,

> [Steve] Ulrich does bring up an interesting use case, where a client is r=
eceiving realm reports for the same realm from different agents.  We need t=
o define the clients behavior in this case. =20

[Jouni] Could we simply say that in this case the agents (or who ever inser=
ts the realm report) MUST share the same view of the realm overload conditi=
on? Obviously how it is achieved would be implementation specific. I recall=
 we have surfaced this topic earlier..

[MCruz] But... isn't simpler to use time instead of sequence? It would solv=
e this case as long as any number of agents serving same realm are time syn=
chronized. =20


From jean-jacques.trottin@alcatel-lucent.com  Wed Dec 11 10:02:02 2013
Return-Path: 
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 BB7F11AD8D5 for ; Wed, 11 Dec 2013 10:02:02 -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 oQJLVJd91-Ji for ; Wed, 11 Dec 2013 10:01:57 -0800 (PST)
Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id B7A841AD72A for ; Wed, 11 Dec 2013 10:01:57 -0800 (PST)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id rBBI1mXG002075 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 11 Dec 2013 12:01:50 -0600 (CST)
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id rBBI1m3J031659 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 11 Dec 2013 19:01:48 +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 19:01:48 +0100
From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
To: "dime@ietf.org" 
Thread-Topic: [Dime] DOIC: Self-Contained OLRs
Thread-Index: AQHO67/uc4Hi6cqE9USGBLWwFB86UZo5m/0AgACzUoCAAAFygIAAE14AgAF8EACAACKcAIAANGaAgATJUgCAAAuAAIACAWkAgAAGHYCAAXsigIAALuKAgAAb/4CAAHc6gIAAOZAAgAAO+4CAAAVNAIAABNCAgAAF6QCAAAecAIAF/9gAgAAFIoCAANV2gIAARHaAgAHlZ9CAAEm9gIAAWSGg
Date: Wed, 11 Dec 2013 18:01:47 +0000
Message-ID: 
References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <14594_1386204165_529FCC05_14594_12646_1_6B7134B31289DC4FAF731D844122B36E329907@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B920972CCAA@ESESSMB101.ericsson.se>  <52A077CC.3000004@usdonovans.com>  <52A088D0.2020406@usdonovans.com>  <52A091CE.2000104@usdonovans.com> <13081_1386256433_52A09831_13081_8197_1_6B7134B31289DC4FAF! 731D84412 2B36E32B6EB@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B9209739738@ESESSMB101.ericsson.se>  <8FD63E2D-5203-4DA4-A6DA-C4CA181C9CFB@nostrum.com> <26C84DFD55BC3040A45BF70926E55F2587C1D786@SZXEMA512-MBX.china.huawei.com>  <52A86663.30500@usdonovans.com>
In-Reply-To: <52A86663.30500@usdonovans.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_E194C2E18676714DACA9C3A2516265D201CB4BC7FR712WXCHMBA12z_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Dec 2013 18:02:02 -0000

--_000_E194C2E18676714DACA9C3A2516265D201CB4BC7FR712WXCHMBA12z_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Steve

I am sorry, Steve,  I do not see the difference between the Draft Roach sco=
pe approach and the self contained OLRs.

With the scope approach in Draft Roach : there is an overload metric AVP  (=
eg containing a % of traffic reduction) coupled with one or several Overlao=
d-Infoscope AVPs, an overlaod infoscope identifying an application or a des=
tination host or... . These Overlaod-Infoscope AVPs can be combined  with a=
lso  the possibility of  multi instances to have a list of applications, a =
list of destination hosts etc  to which the overload metric would apply.
With self contained OLR as you have described them, un OLR will also contai=
n an OC-Reduction-Percentage  AVP coupled with one or several others AVPs (=
the self containment approach) to indicate which application(s), destinatio=
ns host (s) etc the   OC-Reduction-Percentage  AVP applies.

Where is the difference?

So the drawbacks identified for the scope approach also apply with the self=
 contained approach

Best regards

JJacques



De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9 : mercredi 11 d=E9cembre 2013 14:20
=C0 : dime@ietf.org
Objet : Re: [Dime] DOIC: Self-Contained OLRs

JJacques,

While the self contained overload report concept may be similar to the scop=
es concept in the Roach draft, they are not the same.  As such, I don't agr=
ee with your assertion that the previous rejection of the Roach draft requi=
res us to reject self contained overload reports as currently being discuss=
ed.

Steve
On 12/11/13 2:27 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:
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 multip=
ly the number of AVPs in the OLRs (AVPs identifying Application, destinatio=
n 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 sel=
f 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 rec=
reate  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 si=
mple way to proceed, which drove to the current draft content. This decisio=
n is a strong argument that still prevails  for the current baseline descri=
bed in the current draft.

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

As also said, when news requirements will appear (eg session group or APN e=
xamples)  the baseline is extensible to support these new requirements .  I=
 prefer this way of progressive extensions , rather than to create a self c=
ontained 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=E9 : mardi 10 d=E9cembre 2013 04:58
=C0 : 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 righ=
t 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 opti=
mization 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 overloa=
d.

-          The last three pros are mainly for the case of overload of agent=
, if I understood them correctly. Overload of agent is still a controversia=
l scenario, we may need more discussion in the future. But anyway, with def=
inition 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-co=
ntained OLR.

Best Regards,
Susan

From: Ben Campbell [mailto:ben@nostrum.com]
Sent: Tuesday, December 10, 2013 7:53 AM
To: 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 wh=
at we do for a later (or final) version.

So far, I've seen 4 people opposed to self-contained OLRs (Lionel, Nirav, M=
aria, 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 lo=
ok 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 firs=
t group explain what they think the pros of implicit OLRs might be beyond t=
hose 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 application=
s at once, instead of having to signal each one separately.
  *   Allows an easy solution to our "loss" algorithm corner case of not be=
ing able to signal the end of a 100% overload condition
  *   Makes it easier to solve the agent overload problem, without requirin=
g 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 transac=
tion 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 trans=
action context and the report type. [I don't understand why this is valuabl=
e, 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 supporte=
d 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 > wrote:



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

- Jouni





_______________________________________________

DiME mailing list

DiME@ietf.org

https://www.ietf.org/mailman/listinfo/dime


--_000_E194C2E18676714DACA9C3A2516265D201CB4BC7FR712WXCHMBA12z_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hi Steve


 <=
/p>

I am sorry, Steve,  =
I do not see the difference between the Draft Roach scope approach and the =
self contained OLRs.


 <=
/p>

With the scope approach i=
n Draft Roach : there is an overload metric AVP  (eg containing a % of=
 traffic reduction) coupled with one or several Overlaod-Infoscope
 AVPs, an overlaod infoscope identifying an application or a destination ho=
st or… . These Overlaod-Infoscope AVPs can be combined  with als=
o  the possibility of  multi instances to have a list of applicat=
ions, a list of destination hosts etc  to which the overload
 metric would apply.




With self contained OLR a=
s you have described them, un OLR will also contain an OC-Reduction-Percent=
age
 AVP coupled with one or several oth=
ers AVPs (the self containment approach) to indicate which application(s), =
destinations host (s) etc the   OC-Reduction-Percentage
 AVP applies.



 <=
/p>

Where is the difference?<=
o:p>


 <=
/p>

So the drawbacks identifi=
ed for the scope approach also apply with the self contained approach



 <=
/p>

Best regards


 <=
/p>

JJacques



 <=
/p>

 <=
/p>

 <=
/p>





De =
: DiME [mailto:dime-bou=
nces@ietf.org]
De la part de Steve Donovan

Envoy=E9 : mercredi 11 d=E9cembre 2013 14:20

=C0 : dime@ietf.org

Objet : Re: [Dime] DOIC: Self-Contained OLRs<=
/p>





 


JJacques,



While the self contained overload report concept may be similar to the scop=
es concept in the Roach draft, they are not the same.  As such, I don'=
t agree with your assertion that the previous rejection of the Roach draft =
requires us to reject self contained
 overload reports as currently being discussed.



Steve




On 12/11/13 2:27 AM, TROTTIN, JEAN-JACQUES (JEAN-JAC=
QUES) wrote:






Hi Ben and all



 <=
/p>

I remind my mail of 05/12=
, where the self contained OLRs approach is quite similar to the self conta=
ined 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 i=
n draft Roach).  


This also result in a pig=
gybacking  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 ho=
p, the self contained  OLRs are opened to be reprocessed in order to r=
ecreate  new self contained OLR(s)  to various destinations.



I remind that, now 6 mont=
hs 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 con=
tent. This decision is a strong argument that still prevails  for the =
current baseline described in the current draft.


 


This is why I remain in f=
avor of the baseline  described in the current  draft, as as I ha=
ve always and regularly  expressed for  a while.


 <=
/p>

As also said, when news r=
equirements will appear (eg session group or APN examples)  the baseli=
ne is extensible to support these new requirements .  I prefer
 this way of progressive extensions , rather than to create a self containe=
d OLR  with an  immediate and not needed complexity   &=
nbsp;


 <=
/p>

Best regards<=
/o:p>


 <=
/p>

JJacques


 <=
/p>

 <=
/p>





De : DiME [mailto:d=
ime-bounces@ietf.org]
De la part de Shishufeng (Susan)

Envoy=E9 : mardi 10 d=E9cembre 2013 04:58

=C0 : Ben Campbell; dime@ietf.=
org list

Objet : Re: [Dime] DOIC: Self-Contained OLRs<=
/p>





 


Hi Ben,=



 <=
/p>

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



 <=
/p>

Quick thinking on the pro=
s you listed for self-contained OLR.


 <=
/p>


-       &nb=
sp; 
The first two pro=
s can be seen as optimization, on which we are still arguing if these optim=
ization are worth doing or not, since such optimization
 brings extra cost.



-       &nb=
sp; 
The third one is =
not a key issue, which could be addressed with several ways as discussed. A=
s a last resort, the overloaded server may send something
 in a request towards the client to inform the end of the overload.<=
o:p>



-       &nb=
sp; 
The last three pr=
os are mainly for the case of overload of agent, if I understood them corre=
ctly. 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.


 <=
/p>

Best Regards,=



Susan

 <=
/p>





From: Ben Camp=
bell [mailto:ben@nostrum.com]


Sent: Tuesday, December 10, 2013 7:53 AM

To: dime@ietf.org list

Subject: Re: [Dime] DOIC: Self-Contained OLRs






 




I am willing to call the discussion concluded for th=
e 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 conse=
nsus. 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 explai=
n 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 no=
t already weighed into this.






 






Self-Contained O=
LRS:






 






Pros:






    

  • 
Allows an easy, generic solution to Maria's "all-application" sco=
ped overload use case.
  • 
Allows an overloaded node to signal overload for multiple applications at o=
nce, instead of having to signal each one separately.
  • 
Allows an easy solution to our "loss" algorithm corner case of no=
t being able to signal the end of a 100% overload condition
    • =

  • 
Makes it easier to solve the agent overload problem, without requiring inco=
nsistent behavior.
  • 
Allows out-of-band transmission of OLRs without a new format
  • 
Makes it easier to do things like adding a dedicated application for overlo=
ad, 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 i=
n 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" s=
cope.
  • 
An overloaded node needs to send a separate report for every supported appl=
ication.
  • 
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.
  •  
    







 






 




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










OK. Lets call this thread concluded then. I keep the old OC-OLR  seman=
tics

regarding its information context then unmodified.



- Jouni


 











_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime



 






--_000_E194C2E18676714DACA9C3A2516265D201CB4BC7FR712WXCHMBA12z_--


From maria.cruz.bartolome@ericsson.com  Wed Dec 11 10:22:19 2013
Return-Path: 
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 458441AD791 for ; Wed, 11 Dec 2013 10:22:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.85
X-Spam-Level: 
X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, 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 Ek1hHs0g55wU for ; Wed, 11 Dec 2013 10:22:14 -0800 (PST)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id DDEEB1A1F66 for ; Wed, 11 Dec 2013 10:22:12 -0800 (PST)
X-AuditID: c1b4fb25-b7eff8e000000eda-29-52a8ad4eac40
Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 68.CB.03802.E4DA8A25; Wed, 11 Dec 2013 19:22:06 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.197]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.02.0347.000; Wed, 11 Dec 2013 19:22:05 +0100
From: Maria Cruz Bartolome 
To: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" , "dime@ietf.org" 
Thread-Topic: [Dime] DOIC: Self-Contained OLRs
Thread-Index: AQHO8HrX2PaAGa/GgUyaCwjRxXVUh5o5m/0AgACzUoCAAAFygIAAE14AgAF8EACAACKcAIAANGaAgATJUgCAAAuAAIACAWkAgAAGHYCAAXsigIAALuKAgAAb/4CAAHc6gIAAOZAAgAAO+4CAAAVNAIAABNCAgAAF6QCAAAecAIAF/9gAgAAFIoCAANV2gIAARHaAgAHlZ9CAAEm9gIAAWSGggAACrFA=
Date: Wed, 11 Dec 2013 18:22:05 +0000
Message-ID: <087A34937E64E74E848732CFF8354B920973A81A@ESESSMB101.ericsson.se>
References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <14594_1386204165_529FCC05_14594_12646_1_6B7134B31289DC4FAF731D844122B36E329907@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B920972CCAA@ESESSMB101.ericsson.se>  <52A077CC.3000004@usdonovans.com>  <52A088D0.2020406@usdonovans.com>  <52A091CE.2000104@usdonovans.com> <13081_1386256433_52A09831_13081_8197_1_6B7134B31289DC4FAF! 731D84412 2B36E32B6EB@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B9209739738@ESESSMB101.ericsson.se>  <8FD63E2D-5203-4DA4-A6DA-C4CA181C9CFB@nostrum.com> <26C84DFD55BC3040A45BF70926E55F2587C1D786@SZXEMA512-MBX.china.huawei.com>  <52A86663.30500@usdonovans.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.154]
Content-Type: multipart/alternative; boundary="_000_087A34937E64E74E848732CFF8354B920973A81AESESSMB101erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrNLMWRmVeSWpSXmKPExsUyM+Jvra7f2hVBBruPC1vM7V3BZrHp/DoW ByaP1md7WT2WLPnJFMAUxWWTkpqTWZZapG+XwJXRPmUhe8GW40wV8x6GNjA+nMfUxcjJISFg IrFhdx+ULSZx4d56NhBbSOAQo8TrKwJdjFxA9hJGid8/HzODJNgE7CQunX4B1iAiUC6xtfkE C4gtLKArse3UB2aIuJ7Ei5MrmUCaRQTeMUrceL4CbCqLgKrE+v2XwJp5BXwltqxZwgax4SuH xKULZ9hBEpwCsRL/L51iBLEZgU76fmoNWAOzgLjErSfzoU4VkFiy5zwzhC0q8fLxP1YIW0li 0e3PUPX5EjcvfINaJihxcuYTlgmMIrOQjJqFpGwWkjKIuJ7EjalT2CBsbYllC18zQ9i6EjP+ HWJBFl/AyL6KkT03MTMnvdxoEyMwgg5u+a26g/HOOZFDjNIcLErivB/eOgcJCaQnlqRmp6YW pBbFF5XmpBYfYmTi4JRqYFTsN16otzSu+nOlefLUXbnLjn6wfPDypoCljmfjlWOW4QyerP3i 2jYcMt8eX3x9v/S3W/sDxbUb/7fu1p6/qava7WOynNLW04c1T9/cK7JJ/NmzP1OdkyRLnV+p 5k+4u+PHw2+tywvTZu2JOC2YfvNrwOScQsWNM/iYriw46jHpeKvZU37PAxxKLMUZiYZazEXF iQDhN122bgIAAA==
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Dec 2013 18:22:19 -0000

--_000_087A34937E64E74E848732CFF8354B920973A81AESESSMB101erics_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello,



From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE=
S (JEAN-JACQUES)
Sent: mi=E9rcoles, 11 de diciembre de 2013 19:02
To: dime@ietf.org
Subject: Re: [Dime] DOIC: Self-Contained OLRs

Hi Steve

I am sorry, Steve,  I do not see the difference between the Draft Roach sco=
pe approach and the self contained OLRs.

With the scope approach in Draft Roach : there is an overload metric AVP  (=
eg containing a % of traffic reduction) coupled with one or several Overlao=
d-Infoscope AVPs, an overlaod infoscope identifying an application or a des=
tination host or... . These Overlaod-Infoscope AVPs can be combined  with a=
lso  the possibility of  multi instances to have a list of applications, a =
list of destination hosts etc  to which the overload metric would apply.

With self contained OLR as you have described them, un OLR will also contai=
n an OC-Reduction-Percentage  AVP coupled with one or several others AVPs (=
the self containment approach) to indicate which application(s), destinatio=
ns host (s) etc the   OC-Reduction-Percentage  AVP applies.

Where is the difference?

So the drawbacks identified for the scope approach also apply with the self=
 contained approach

Best regards

JJacques



De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9 : mercredi 11 d=E9cembre 2013 14:20
=C0 : dime@ietf.org
Objet : Re: [Dime] DOIC: Self-Contained OLRs

JJacques,

While the self contained overload report concept may be similar to the scop=
es concept in the Roach draft, they are not the same.  As such, I don't agr=
ee with your assertion that the previous rejection of the Roach draft requi=
res us to reject self contained overload reports as currently being discuss=
ed.

Steve
On 12/11/13 2:27 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:
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 multip=
ly the number of AVPs in the OLRs (AVPs identifying Application, destinatio=
n 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 sel=
f 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 rec=
reate  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 si=
mple way to proceed, which drove to the current draft content. This decisio=
n is a strong argument that still prevails  for the current baseline descri=
bed in the current draft.

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

As also said, when news requirements will appear (eg session group or APN e=
xamples)  the baseline is extensible to support these new requirements .  I=
 prefer this way of progressive extensions , rather than to create a self c=
ontained 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=E9 : mardi 10 d=E9cembre 2013 04:58
=C0 : 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 righ=
t 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 opti=
mization 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 overloa=
d.

-          The last three pros are mainly for the case of overload of agent=
, if I understood them correctly. Overload of agent is still a controversia=
l scenario, we may need more discussion in the future. But anyway, with def=
inition 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-co=
ntained OLR.

Best Regards,
Susan

From: Ben Campbell [mailto:ben@nostrum.com]
Sent: Tuesday, December 10, 2013 7:53 AM
To: 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 wh=
at we do for a later (or final) version.

So far, I've seen 4 people opposed to self-contained OLRs (Lionel, Nirav, M=
aria, 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 lo=
ok 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 firs=
t group explain what they think the pros of implicit OLRs might be beyond t=
hose 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 application=
s at once, instead of having to signal each one separately.
  *   Allows an easy solution to our "loss" algorithm corner case of not be=
ing able to signal the end of a 100% overload condition
  *   Makes it easier to solve the agent overload problem, without requirin=
g 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 transac=
tion 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 trans=
action context and the report type. [I don't understand why this is valuabl=
e, 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 supporte=
d 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 > wrote:


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

- Jouni




_______________________________________________

DiME mailing list

DiME@ietf.org

https://www.ietf.org/mailman/listinfo/dime


--_000_087A34937E64E74E848732CFF8354B920973A81AESESSMB101erics_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hello,<=
/p>

 <=
/p>

 <=
/p>

 <=
/p>





From: DiME [mailto:dime-bounces@ietf.org]
On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)

Sent: mi=E9rcoles, 11 de diciembre de 2013 19:02

To: dime@ietf.org

Subject: Re: [Dime] DOIC: Self-Contained OLRs






 


Hi Steve


 <=
/p>

I am sorry, Steve,  =
I do not see the difference between the Draft Roach scope approach and the =
self contained OLRs.


 <=
/p>

With the scope approach i=
n Draft Roach : there is an overload metric AVP  (eg containing a % of=
 traffic reduction) coupled with one or several Overlaod-Infoscope
 AVPs, an overlaod infoscope identifying an application or a destination ho=
st or… . These Overlaod-Infoscope AVPs can be combined  with als=
o  the possibility of  multi instances to have a list of applicat=
ions, a list of destination hosts etc  to which the overload
 metric would apply.


 <=
/p>

With self contained OLR a=
s you have described them, un OLR will also contain an OC-Reduction-Percent=
age
 AVP coupled with one or several oth=
ers AVPs (the self containment approach) to indicate which application(s), =
destinations host (s) etc the   OC-Reduction-Percentage
 AVP applies.



 <=
/p>

Where is the difference?<=
o:p>


 <=
/p>

So the drawbacks identifi=
ed for the scope approach also apply with the self contained approach



 <=
/p>

Best regards


 <=
/p>

JJacques



 <=
/p>

 <=
/p>

 <=
/p>





De =
: DiME [mailto:dime-bou=
nces@ietf.org]
De la part de Steve Donovan

Envoy=E9 : mercredi 11 d=E9cembre 2013 14:20

=C0 : dime@ietf.org

Objet : Re: [Dime] DOIC: Self-Contained OLRs<=
/p>





 


JJacques,



While the self contained overload report concept may be similar to the scop=
es concept in the Roach draft, they are not the same.  As such, I don'=
t agree with your assertion that the previous rejection of the Roach draft =
requires us to reject self contained
 overload reports as currently being discussed.



Steve




On 12/11/13 2:27 AM, TROTTIN, JEAN-JACQUES (JEAN-JAC=
QUES) wrote:






Hi Ben and all



 <=
/p>

I remind my mail of 05/12=
, where the self contained OLRs approach is quite similar to the self conta=
ined 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 i=
n draft Roach).  


This also result in a pig=
gybacking  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 ho=
p, the self contained  OLRs are opened to be reprocessed in order to r=
ecreate  new self contained OLR(s)  to various destinations.



I remind that, now 6 mont=
hs 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 con=
tent. This decision is a strong argument that still prevails  for the =
current baseline described in the current draft.


 


This is why I remain in f=
avor of the baseline  described in the current  draft, as as I ha=
ve always and regularly  expressed for  a while.


 <=
/p>

As also said, when news r=
equirements will appear (eg session group or APN examples)  the baseli=
ne is extensible to support these new requirements .  I prefer
 this way of progressive extensions , rather than to create a self containe=
d OLR  with an  immediate and not needed complexity   &=
nbsp;


 <=
/p>

Best regards<=
/o:p>


 <=
/p>

JJacques


 <=
/p>

 <=
/p>





De : DiME [mailto:d=
ime-bounces@ietf.org]
De la part de Shishufeng (Susan)

Envoy=E9 : mardi 10 d=E9cembre 2013 04:58

=C0 : Ben Campbell; dime@ietf.=
org list

Objet : Re: [Dime] DOIC: Self-Contained OLRs<=
/p>





 


Hi Ben,=



 <=
/p>

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



 <=
/p>

Quick thinking on the pro=
s you listed for self-contained OLR.


 <=
/p>


-       &nb=
sp; 
The first two pro=
s can be seen as optimization, on which we are still arguing if these optim=
ization are worth doing or not, since such optimization
 brings extra cost.



-       &nb=
sp; 
The third one is =
not a key issue, which could be addressed with several ways as discussed. A=
s a last resort, the overloaded server may send something
 in a request towards the client to inform the end of the overload.<=
o:p>



-       &nb=
sp; 
The last three pr=
os are mainly for the case of overload of agent, if I understood them corre=
ctly. 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.


 <=
/p>

Best Regards,=



Susan

 <=
/p>





From: Ben Camp=
bell [mailto:ben@nostrum.com]


Sent: Tuesday, December 10, 2013 7:53 AM

To: dime@ietf.org list

Subject: Re: [Dime] DOIC: Self-Contained OLRs






 




I am willing to call the discussion concluded for th=
e 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 conse=
nsus. 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 explai=
n 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 no=
t already weighed into this.






 






Self-Contained O=
LRS:






 






Pros:






    

  • 
Allows an easy, generic solution to Maria's "all-application" sco=
ped overload use case.
  • 
Allows an overloaded node to signal overload for multiple applications at o=
nce, instead of having to signal each one separately.
  • 
Allows an easy solution to our "loss" algorithm corner case of no=
t being able to signal the end of a 100% overload condition
    • =

  • 
Makes it easier to solve the agent overload problem, without requiring inco=
nsistent behavior.
  • 
Allows out-of-band transmission of OLRs without a new format
  • 
Makes it easier to do things like adding a dedicated application for overlo=
ad, 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 i=
n 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" s=
cope.
  • 
An overloaded node needs to send a separate report for every supported appl=
ication.
  • 
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.
  •  
    







 






 




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








OK. Lets call this thread concluded then. I keep the old OC-OLR  seman=
tics

regarding its information context then unmodified.



- Jouni


 









_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime



 






--_000_087A34937E64E74E848732CFF8354B920973A81AESESSMB101erics_--


From maria.cruz.bartolome@ericsson.com  Wed Dec 11 10:25:24 2013
Return-Path: 
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 0F89C1A1F66 for ; Wed, 11 Dec 2013 10:25:24 -0800 (PST)
X-Quarantine-ID: 
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Improper folded header field made up entirely of whitespace (char 20 hex): References: ...B4BC7@FR712WXCHMBA12.zeu.alcatel-lucent.com>\n 
X-Spam-Flag: NO
X-Spam-Score: -1.239
X-Spam-Level: 
X-Spam-Status: No, score=-1.239 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
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 dYzXW8Fo8ulu for ; Wed, 11 Dec 2013 10:25:19 -0800 (PST)
Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 82CEA1ADFBC for ; Wed, 11 Dec 2013 10:25:18 -0800 (PST)
X-AuditID: c1b4fb32-b7f108e0000030dd-ba-52a8ae0797c6
Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 39.0A.12509.70EA8A25; Wed, 11 Dec 2013 19:25:12 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.197]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0347.000; Wed, 11 Dec 2013 19:25:11 +0100
From: Maria Cruz Bartolome 
To: "dime@ietf.org" 
Thread-Topic: [Dime] DOIC: Self-Contained OLRs
Thread-Index: AQHO8HrX2PaAGa/GgUyaCwjRxXVUh5o5m/0AgACzUoCAAAFygIAAE14AgAF8EACAACKcAIAANGaAgATJUgCAAAuAAIACAWkAgAAGHYCAAXsigIAALuKAgAAb/4CAAHc6gIAAOZAAgAAO+4CAAAVNAIAABNCAgAAF6QCAAAecAIAF/9gAgAAFIoCAANV2gIAARHaAgAHlZ9CAAEm9gIAAWSGggAACrFCAAAAqoA==
Date: Wed, 11 Dec 2013 18:25:10 +0000
Message-ID: <087A34937E64E74E848732CFF8354B920973A82A@ESESSMB101.ericsson.se>
References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <14594_1386204165_529FCC05_14594_12646_1_6B7134B31289DC4FAF731D844122B36E329907@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B920972CCAA@ESESSMB101.ericsson.se>  <52A077CC.3000004@usdonovans.com>  <52A088D0.2020406@usdonovans.com>  <52A091CE.2000104@usdonovans.com> <13081_1386256433_52A09831_13081_8197_1_6B7134B31289DC4FAF! 731D84412 2B36E32B6EB@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B9209739738@ESESSMB101.ericsson.se>  <8FD63E2D-5203-4DA4-A6DA-C4CA181C9CFB@nostrum.com> <26C84DFD55BC3040A45BF70926E55F2587C1D786@SZXEMA512-MBX.china.huawei.com>  <52A86663.30500@usdonovans.com> 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.154]
Content-Type: multipart/alternative; boundary="_000_087A34937E64E74E848732CFF8354B920973A82AESESSMB101erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyM+JvrS7HuhVBBo928ljM7V3B5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujOmtDYwFi+8wVUzc+JexgfH8BqYuRk4OCQETiabGW2wQtpjE hXvrgWwuDiGBE4wSjZsXQzlLGCVmdaxkBaliE7CTuHT6BVA3B4eIgLLE6V8OIGFhAV2Jbac+ MIPYIgJ6Ei9OrmQC6RUR+MYo8a77MSNIgkVAVeLEmm6wIl4BX4m+p2vB4kICPzgkTnaAxRmB rvh+ag3YdcwC4hK3nsyHulRAYsme88wQtqjEy8f/WCFsJYlFtz9D1edLzJh7hAVivqDEyZlP WCYwCs9CMmoWkrJZSMog4noSN6ZOYYOwtSWWLXzNDGHrSsz4d4gFWXwBI/sqRsni1OLi3HQj A73c9NwSvdSizOTi4vw8veLUTYzAyDm45bfRDsaTe+wPMUpzsCiJ815nrQkSEkhPLEnNTk0t SC2KLyrNSS0+xMjEwSnVwNjm6mrcHbn0iu+7tWkv0+er7Xy2+u+0hu9aeTEmnc8e3efSuLzZ 3vPoXTvDBZfKkkO/yxw31L293VdDPluxz1h/Zbqs3bxFlvwCB1kyFi9Ruqt13PngAYZrT9V8 tUWfX/ym0dJpeN9509/EKM3TzwyCQv8GcH68t/aJqkn49oY7a5/oFvc39SixFGckGmoxFxUn AgAWf0LCagIAAA==
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Dec 2013 18:25:24 -0000

--_000_087A34937E64E74E848732CFF8354B920973A82AESESSMB101erics_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello (and something else now :), fast key combination, I won't be able to =
repeat,  was the responsible)



As mentioned before, something else on cons side for self-contained:



A part from that,  one concern with "self-contained OLRs" is that some data=
 is duplicated. Duplication should be avoided, since then we need to assure=
 consistency, and error handing in case implicit and explicit data values a=
re different for any reason... what means that it may always be required to=
 check both implicit and explicit data.



Also, I think this is a pure implementation proposal. Regardless how the da=
ta is transported it could be packed in a "self-contained OLRs" within the =
diameter application, if for any implementation this is preferred.

Best regards
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE=
S (JEAN-JACQUES)
Sent: mi=E9rcoles, 11 de diciembre de 2013 19:02
To: dime@ietf.org
Subject: Re: [Dime] DOIC: Self-Contained OLRs

Hi Steve

I am sorry, Steve,  I do not see the difference between the Draft Roach sco=
pe approach and the self contained OLRs.

With the scope approach in Draft Roach : there is an overload metric AVP  (=
eg containing a % of traffic reduction) coupled with one or several Overlao=
d-Infoscope AVPs, an overlaod infoscope identifying an application or a des=
tination host or... . These Overlaod-Infoscope AVPs can be combined  with a=
lso  the possibility of  multi instances to have a list of applications, a =
list of destination hosts etc  to which the overload metric would apply.

With self contained OLR as you have described them, un OLR will also contai=
n an OC-Reduction-Percentage  AVP coupled with one or several others AVPs (=
the self containment approach) to indicate which application(s), destinatio=
ns host (s) etc the   OC-Reduction-Percentage  AVP applies.

Where is the difference?

So the drawbacks identified for the scope approach also apply with the self=
 contained approach

Best regards

JJacques



De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9 : mercredi 11 d=E9cembre 2013 14:20
=C0 : dime@ietf.org
Objet : Re: [Dime] DOIC: Self-Contained OLRs

JJacques,

While the self contained overload report concept may be similar to the scop=
es concept in the Roach draft, they are not the same.  As such, I don't agr=
ee with your assertion that the previous rejection of the Roach draft requi=
res us to reject self contained overload reports as currently being discuss=
ed.

Steve
On 12/11/13 2:27 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:
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 multip=
ly the number of AVPs in the OLRs (AVPs identifying Application, destinatio=
n 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 sel=
f 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 rec=
reate  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 si=
mple way to proceed, which drove to the current draft content. This decisio=
n is a strong argument that still prevails  for the current baseline descri=
bed in the current draft.

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

As also said, when news requirements will appear (eg session group or APN e=
xamples)  the baseline is extensible to support these new requirements .  I=
 prefer this way of progressive extensions , rather than to create a self c=
ontained 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=E9 : mardi 10 d=E9cembre 2013 04:58
=C0 : 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 righ=
t 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 opti=
mization 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 overloa=
d.

-          The last three pros are mainly for the case of overload of agent=
, if I understood them correctly. Overload of agent is still a controversia=
l scenario, we may need more discussion in the future. But anyway, with def=
inition 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-co=
ntained OLR.

Best Regards,
Susan

From: Ben Campbell [mailto:ben@nostrum.com]
Sent: Tuesday, December 10, 2013 7:53 AM
To: 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 wh=
at we do for a later (or final) version.

So far, I've seen 4 people opposed to self-contained OLRs (Lionel, Nirav, M=
aria, 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 lo=
ok 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 firs=
t group explain what they think the pros of implicit OLRs might be beyond t=
hose 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 application=
s at once, instead of having to signal each one separately.
  *   Allows an easy solution to our "loss" algorithm corner case of not be=
ing able to signal the end of a 100% overload condition
  *   Makes it easier to solve the agent overload problem, without requirin=
g 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 transac=
tion 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 trans=
action context and the report type. [I don't understand why this is valuabl=
e, 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 supporte=
d 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 > wrote:

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

- Jouni



_______________________________________________

DiME mailing list

DiME@ietf.org

https://www.ietf.org/mailman/listinfo/dime


--_000_087A34937E64E74E848732CFF8354B920973A82AESESSMB101erics_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hello (and something else now 
J, fast key combination, I won’t be able to repeat,  was =
the responsible)


 


As mentioned before, something else on cons side =
for self-contained:


 


A part from that,&nb=
sp; one concern with "self-contained OLRs" is that some data is d=
uplicated. Duplication should be avoided, since then we need to assure cons=
istency, and error handing in case implicit and explicit
 data values are different for any reason... what means that it may always =
be required to check both implicit and explicit data.


 

Also, I think this i=
s a pure implementation proposal. Regardless how the data is transported it=
 could be packed in a "self-contained OLRs" within the diameter a=
pplication, if for any implementation this is
 preferred.


 <=
/p>

Best regards


/MCruz


 <=
/p>





From: DiME [mailto:dime-bounces@ietf.org]
On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)

Sent: mi=E9rcoles, 11 de diciembre de 2013 19:02

To: dime@ietf.org

Subject: Re: [Dime] DOIC: Self-Contained OLRs






 


Hi Steve


 <=
/p>

I am sorry, Steve,  =
I do not see the difference between the Draft Roach scope approach and the =
self contained OLRs.


 <=
/p>

With the scope approach i=
n Draft Roach : there is an overload metric AVP  (eg containing a % of=
 traffic reduction) coupled with one or several Overlaod-Infoscope
 AVPs, an overlaod infoscope identifying an application or a destination ho=
st or… . These Overlaod-Infoscope AVPs can be combined  with als=
o  the possibility of  multi instances to have a list of applicat=
ions, a list of destination hosts etc  to which the overload
 metric would apply.


 <=
/p>

With self contained OLR a=
s you have described them, un OLR will also contain an OC-Reduction-Percent=
age
 AVP coupled with one or several oth=
ers AVPs (the self containment approach) to indicate which application(s), =
destinations host (s) etc the   OC-Reduction-Percentage
 AVP applies.



 <=
/p>

Where is the difference?<=
o:p>


 <=
/p>

So the drawbacks identifi=
ed for the scope approach also apply with the self contained approach



 <=
/p>

Best regards


 <=
/p>

JJacques



 <=
/p>

 <=
/p>

 <=
/p>





De =
: DiME [mailto:dime-bou=
nces@ietf.org]
De la part de Steve Donovan

Envoy=E9 : mercredi 11 d=E9cembre 2013 14:20

=C0 : dime@ietf.org

Objet : Re: [Dime] DOIC: Self-Contained OLRs<=
/p>





 


JJacques,



While the self contained overload report concept may be similar to the scop=
es concept in the Roach draft, they are not the same.  As such, I don'=
t agree with your assertion that the previous rejection of the Roach draft =
requires us to reject self contained
 overload reports as currently being discussed.



Steve




On 12/11/13 2:27 AM, TROTTIN, JEAN-JACQUES (JEAN-JAC=
QUES) wrote:






Hi Ben and all



 <=
/p>

I remind my mail of 05/12=
, where the self contained OLRs approach is quite similar to the self conta=
ined 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 i=
n draft Roach).  


This also result in a pig=
gybacking  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 ho=
p, the self contained  OLRs are opened to be reprocessed in order to r=
ecreate  new self contained OLR(s)  to various destinations.



I remind that, now 6 mont=
hs 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 con=
tent. This decision is a strong argument that still prevails  for the =
current baseline described in the current draft.


 


This is why I remain in f=
avor of the baseline  described in the current  draft, as as I ha=
ve always and regularly  expressed for  a while.


 <=
/p>

As also said, when news r=
equirements will appear (eg session group or APN examples)  the baseli=
ne is extensible to support these new requirements .  I prefer
 this way of progressive extensions , rather than to create a self containe=
d OLR  with an  immediate and not needed complexity   &=
nbsp;


 <=
/p>

Best regards<=
/o:p>


 <=
/p>

JJacques


 <=
/p>

 <=
/p>





De : DiME [mailto:d=
ime-bounces@ietf.org]
De la part de Shishufeng (Susan)

Envoy=E9 : mardi 10 d=E9cembre 2013 04:58

=C0 : Ben Campbell; dime@ietf.=
org list

Objet : Re: [Dime] DOIC: Self-Contained OLRs<=
/p>





 


Hi Ben,=



 <=
/p>

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



 <=
/p>

Quick thinking on the pro=
s you listed for self-contained OLR.


 <=
/p>


-       &nb=
sp; 
The first two pro=
s can be seen as optimization, on which we are still arguing if these optim=
ization are worth doing or not, since such optimization
 brings extra cost.



-       &nb=
sp; 
The third one is =
not a key issue, which could be addressed with several ways as discussed. A=
s a last resort, the overloaded server may send something
 in a request towards the client to inform the end of the overload.<=
o:p>



-       &nb=
sp; 
The last three pr=
os are mainly for the case of overload of agent, if I understood them corre=
ctly. 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.


 <=
/p>

Best Regards,=



Susan

 <=
/p>





From: Ben Camp=
bell [mailto:ben@nostrum.com]


Sent: Tuesday, December 10, 2013 7:53 AM

To: dime@ietf.org list

Subject: Re: [Dime] DOIC: Self-Contained OLRs






 




I am willing to call the discussion concluded for th=
e 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 conse=
nsus. 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 explai=
n 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 no=
t already weighed into this.






 






Self-Contained O=
LRS:






 






Pros:






    

  • 
Allows an easy, generic solution to Maria's "all-application" sco=
ped overload use case.
  • 
Allows an overloaded node to signal overload for multiple applications at o=
nce, instead of having to signal each one separately.
  • 
Allows an easy solution to our "loss" algorithm corner case of no=
t being able to signal the end of a 100% overload condition
    • =

  • 
Makes it easier to solve the agent overload problem, without requiring inco=
nsistent behavior.
  • 
Allows out-of-band transmission of OLRs without a new format
  • 
Makes it easier to do things like adding a dedicated application for overlo=
ad, 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 i=
n 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" s=
cope.
  • 
An overloaded node needs to send a separate report for every supported appl=
ication.
  • 
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.
  •  
    







 






 




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




OK. Lets call this thread concluded then. I keep the old OC-OLR  seman=
tics

regarding its information context then unmodified.



- Jouni


 


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime



 






--_000_087A34937E64E74E848732CFF8354B920973A82AESESSMB101erics_--


From srdonovan@usdonovans.com  Wed Dec 11 11:04:52 2013
Return-Path: 
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 187B11AE039 for ; Wed, 11 Dec 2013 11:04:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.12
X-Spam-Level: 
X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no
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 RCGjIyIkmi1S for ; Wed, 11 Dec 2013 11:04:47 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 273DE1AE033 for ; Wed, 11 Dec 2013 11:04:47 -0800 (PST)
Received: from [4.30.77.1] (port=50540 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1Vqp5K-0007iA-DA for dime@ietf.org; Wed, 11 Dec 2013 11:04:40 -0800
Message-ID: <52A8B744.5010902@usdonovans.com>
Date: Wed, 11 Dec 2013 13:04:36 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: dime@ietf.org
References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <087A34937E64E74E848732CFF8354B920972CCAA@ESESSMB101.ericsson.se>  <52A077CC.3000004@usdonovans.com>  <52A088D0.2020406@usdonovans.com>  <52A091CE.2000104@usdonovans.com> <13081_1386256433_52A09831_13081_8197_1_6B7134B31289DC4FAF! 731D84412 2B36E32B6EB@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B9209739738@ESESSMB101.ericsson.se>  <8FD63E2D-5203-4DA4-A6DA-C4CA181C9CFB@nostrum.com> <26C84DFD55BC3040A45BF70926E55F2587C1D786@SZXEMA512-MBX.china.huawei.com>  <52A86663.30500@usdonovans.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------000004090201090506030505"
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Dec 2013 19:04:52 -0000

This is a multi-part message in MIME format.
--------------000004090201090506030505
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

JJacques,

The self contained OLR proposal is about including host, realm and
application-id in the overload report.  There is nothing about
"Overload-Infoscope" AVPs in what I understand to be the self contained
OLRs.

It is true that what was specified in the Roach draft could be used for
self contained OLRs.  That is not, however, what is being proposed here.

Steve

On 12/11/13 12:01 PM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:
>
> Hi Steve
>
>  
>
> I am sorry, Steve,  I do not see the difference between the Draft
> Roach scope approach and the self contained OLRs.
>
>  
>
> With the scope approach in Draft Roach : there is an overload metric
> AVP  (eg containing a % of traffic reduction) coupled with one or
> several Overlaod-Infoscope AVPs, an overlaod infoscope identifying an
> application or a destination host or... . These Overlaod-Infoscope
> AVPs can be combined  with also  the possibility of  multi instances
> to have a list of applications, a list of destination hosts etc  to
> which the overload metric would apply.
>
> With self contained OLR as you have described them, un OLR will also
> contain an OC-Reduction-Percentage AVP coupled with one or several
> others AVPs (the self containment approach) to indicate which
> application(s), destinations host (s) etc the
>   OC-Reduction-Percentage AVP applies.
>
>  
>
> Where is the difference?
>
>  
>
> So the drawbacks identified for the scope approach also apply with the
> self contained approach
>
>  
>
> Best regards
>
>  
>
> JJacques
>
>  
>
>  
>
>  
>
> *De :*DiME [mailto:dime-bounces@ietf.org] *De la part de* Steve Donovan
> *Envoyé :* mercredi 11 décembre 2013 14:20
> *À :* dime@ietf.org
> *Objet :* Re: [Dime] DOIC: Self-Contained OLRs
>
>  
>
> JJacques,
>
> While the self contained overload report concept may be similar to the
> scopes concept in the Roach draft, they are not the same.  As such, I
> don't agree with your assertion that the previous rejection of the
> Roach draft requires us to reject self contained overload reports as
> currently being discussed.
>
> Steve
>
> On 12/11/13 2:27 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:
>
>     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  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      > wrote:
>
>
>
>     OK. Lets call this thread concluded then. I keep the old OC-OLR
>      semantics
>     regarding its information context then unmodified.
>
>     - Jouni
>
>      
>
>
>
>
>     _______________________________________________
>
>     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


--------------000004090201090506030505
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    JJacques,

      

      The self contained OLR proposal is about including host, realm and
      application-id in the overload report.  There is nothing about
      "Overload-Infoscope" AVPs in what I understand to be the self
      contained OLRs. 

      

      It is true that what was specified in the Roach draft could be
      used for self contained OLRs.  That is not, however, what is being
      proposed here.

      

      Steve

      

    
    
On 12/11/13 12:01 PM, TROTTIN,
      JEAN-JACQUES (JEAN-JACQUES) wrote:

    

    

      
      
      
      

        
Hi
            Steve

        
 

        
I
            am sorry, Steve,  I do not see the difference between the
            Draft Roach scope approach and the self contained OLRs.

        
 

        
With
            the scope approach in Draft Roach : there is an overload
            metric AVP  (eg containing a % of traffic reduction) coupled
            with one or several Overlaod-Infoscope AVPs, an overlaod
            infoscope identifying an application or a destination host
            or… . These Overlaod-Infoscope AVPs can be combined  with
            also  the possibility of  multi instances to have a list of
            applications, a list of destination hosts etc  to which the
            overload metric would apply.

        

        
With
            self contained OLR as you have described them, un OLR will
            also contain an OC-Reduction-Percentage
           AVP
            coupled with one or several others AVPs (the self
            containment approach) to indicate which application(s),
            destinations host (s) etc the   OC-Reduction-Percentage
           AVP
            applies.
            

        
 

        
Where
            is the difference?

        
 

        
So
            the drawbacks identified for the scope approach also apply
            with the self contained approach
            

        
 

        
Best
            regards

        
 

        
JJacques
            

        
 

        
 

        
 

        

          

            
De : DiME [mailto:dime-bounces@ietf.org]
                De la part de Steve Donovan

                Envoyé : mercredi 11 décembre 2013 14:20

                À : dime@ietf.org

                Objet : Re: [Dime] DOIC: Self-Contained OLRs

          

        

        
 

        
JJacques,

          

          While the self contained overload report concept may be
          similar to the scopes concept in the Roach draft, they are not
          the same.  As such, I don't agree with your assertion that the
          previous rejection of the Roach draft requires us to reject
          self contained overload reports as currently being discussed.

          

          Steve

        

          
On 12/11/13 2:27 AM, TROTTIN,
            JEAN-JACQUES (JEAN-JACQUES) wrote:

        

        

          
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 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>
            wrote:

            

            

            

          


            OK. Lets call this thread concluded then. I keep the old
            OC-OLR  semantics

            regarding its information context then unmodified.

            

            - Jouni

          
 

          


            

            

            

          
_______________________________________________

          
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


    

    

  


--------------000004090201090506030505--


From srdonovan@usdonovans.com  Wed Dec 11 11:09:44 2013
Return-Path: 
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 8FF281AE109 for ; Wed, 11 Dec 2013 11:09:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.12
X-Spam-Level: 
X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no
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 elowRyvUwZ1A for ; Wed, 11 Dec 2013 11:09:38 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id A73551AE100 for ; Wed, 11 Dec 2013 11:09:38 -0800 (PST)
Received: from [4.30.77.1] (port=50545 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1Vqp9u-0005SW-RP for dime@ietf.org; Wed, 11 Dec 2013 11:09:32 -0800
Message-ID: <52A8B862.5040207@usdonovans.com>
Date: Wed, 11 Dec 2013 13:09:22 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: dime@ietf.org
References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com>  <52A077CC.3000004@usdonovans.com>  <52A088D0.2020406@usdonovans.com>  <52A091CE.2000104@usdonovans.com> <13081_1386256433_52A09831_13081_8197_1_6B7134B31289DC4FAF! 731D84412 2B36E32B6EB@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B9209739738@ESESSMB101.ericsson.se>  <8FD63E2D-5203-4DA4-A6DA-C4CA181C9CFB@nostrum.com> <26C84DFD55BC3040A45BF70926E55F2587C1D786@SZXEMA512-MBX.china.huawei.com>  <52A86663.30500@usdonovans.com>  <087A34937E64E74E848732CFF8354B920973A82A@ESESSMB101.ericsson.se>
In-Reply-To: <087A34937E64E74E848732CFF8354B920973A82A@ESESSMB101.ericsson.se>
Content-Type: multipart/alternative; boundary="------------000506080307030508030107"
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Dec 2013 19:09:44 -0000

This is a multi-part message in MIME format.
--------------000506080307030508030107
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

Maria Cruz,

I don't agree with the assertion that self-contained OLRs results in the
potential for data inconsistency.  If a reactor receives an overload
report for an application that is not supported by the reactor then the
reactor can and should ignore that OLR. 

The concept of self-contained overload reports would explicitly allow
for the contents of the overload report to be different than the message
that is carrying the OLR.  As with application-ids, if the reactor
doesn't send messages to a reported host or realm then the reactor
ignores that part of the overload report.  As such, there is no need to
check the implicit data when receiving a self-contained OLR.

Steve

On 12/11/13 12:25 PM, Maria Cruz Bartolome wrote:
>
> Hello (and something else now J, fast key combination, I won't be able
> to repeat,  was the responsible)
>
>  
>
> As mentioned before, something else on cons side for self-contained:
>
>  
>
> A part from that,  one concern with "self-contained OLRs" is that some
> data is duplicated. Duplication should be avoided, since then we need
> to assure consistency, and error handing in case implicit and explicit
> data values are different for any reason... what means that it may
> always be required to check both implicit and explicit data.
>
>  
>
> Also, I think this is a pure implementation proposal. Regardless how
> the data is transported it could be packed in a "self-contained OLRs"
> within the diameter application, if for any implementation this is
> preferred.
>
>  
>
> Best regards
>
> /MCruz
>
>  
>
> *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *TROTTIN,
> JEAN-JACQUES (JEAN-JACQUES)
> *Sent:* miércoles, 11 de diciembre de 2013 19:02
> *To:* dime@ietf.org
> *Subject:* Re: [Dime] DOIC: Self-Contained OLRs
>
>  
>
> Hi Steve
>
>  
>
> I am sorry, Steve,  I do not see the difference between the Draft
> Roach scope approach and the self contained OLRs.
>
>  
>
> With the scope approach in Draft Roach : there is an overload metric
> AVP  (eg containing a % of traffic reduction) coupled with one or
> several Overlaod-Infoscope AVPs, an overlaod infoscope identifying an
> application or a destination host or... . These Overlaod-Infoscope
> AVPs can be combined  with also  the possibility of  multi instances
> to have a list of applications, a list of destination hosts etc  to
> which the overload metric would apply.
>
>  
>
> With self contained OLR as you have described them, un OLR will also
> contain an OC-Reduction-Percentage AVP coupled with one or several
> others AVPs (the self containment approach) to indicate which
> application(s), destinations host (s) etc the
>   OC-Reduction-Percentage AVP applies.
>
>  
>
> Where is the difference?
>
>  
>
> So the drawbacks identified for the scope approach also apply with the
> self contained approach
>
>  
>
> Best regards
>
>  
>
> JJacques
>
>  
>
>  
>
>  
>
> *De :*DiME [mailto:dime-bounces@ietf.org] *De la part de* Steve Donovan
> *Envoyé :* mercredi 11 décembre 2013 14:20
> *À :* dime@ietf.org
> *Objet :* Re: [Dime] DOIC: Self-Contained OLRs
>
>  
>
> JJacques,
>
> While the self contained overload report concept may be similar to the
> scopes concept in the Roach draft, they are not the same.  As such, I
> don't agree with your assertion that the previous rejection of the
> Roach draft requires us to reject self contained overload reports as
> currently being discussed.
>
> Steve
>
> On 12/11/13 2:27 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:
>
>     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  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      > wrote:
>
>
>     OK. Lets call this thread concluded then. I keep the old OC-OLR
>      semantics
>     regarding its information context then unmodified.
>
>     - Jouni
>
>      
>
>      
>
>     _______________________________________________
>
>     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


--------------000506080307030508030107
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Maria Cruz,

      

      I don't agree with the assertion that self-contained OLRs results
      in the potential for data inconsistency.  If a reactor receives an
      overload report for an application that is not supported by the
      reactor then the reactor can and should ignore that OLR.  

      

      The concept of self-contained overload reports would explicitly
      allow for the contents of the overload report to be different than
      the message that is carrying the OLR.  As with application-ids, if
      the reactor doesn't send messages to a reported host or realm then
      the reactor ignores that part of the overload report.  As such,
      there is no need to check the implicit data when receiving a
      self-contained OLR.

      

      Steve

      

    
    
On 12/11/13 12:25 PM, Maria Cruz
      Bartolome wrote:

    

    

      
      
      
      

        
Hello (and something else now 
            J, fast key combination, I won’t be able to repeat,
           was the responsible)

        
 

        
As mentioned before, something else on
          cons side for self-contained:

        
 

        
A part from
          that,  one concern with "self-contained OLRs" is that some
          data is duplicated. Duplication should be avoided, since then
          we need to assure consistency, and error handing in case
          implicit and explicit data values are different for any
          reason... what means that it may always be required to check
          both implicit and explicit data.

        
 

        
Also, I think
          this is a pure implementation proposal. Regardless how the
          data is transported it could be packed in a "self-contained
          OLRs" within the diameter application, if for any
          implementation this is preferred.

        
 

        
Best
            regards

        
/MCruz

        
 

        

          

            
From:
                DiME [mailto:dime-bounces@ietf.org]
                On Behalf Of TROTTIN, JEAN-JACQUES
                (JEAN-JACQUES)

                Sent: miércoles, 11 de diciembre de 2013 19:02

                To: dime@ietf.org

                Subject: Re: [Dime] DOIC: Self-Contained OLRs

          

        

        
 

        
Hi
            Steve

        
 

        
I
            am sorry, Steve,  I do not see the difference between the
            Draft Roach scope approach and the self contained OLRs.

        
 

        
With
            the scope approach in Draft Roach : there is an overload
            metric AVP  (eg containing a % of traffic reduction) coupled
            with one or several Overlaod-Infoscope AVPs, an overlaod
            infoscope identifying an application or a destination host
            or… . These Overlaod-Infoscope AVPs can be combined  with
            also  the possibility of  multi instances to have a list of
            applications, a list of destination hosts etc  to which the
            overload metric would apply.

        
 

        
With
            self contained OLR as you have described them, un OLR will
            also contain an OC-Reduction-Percentage
           AVP
            coupled with one or several others AVPs (the self
            containment approach) to indicate which application(s),
            destinations host (s) etc the   OC-Reduction-Percentage
           AVP
            applies.
            

        
 

        
Where
            is the difference?

        
 

        
So
            the drawbacks identified for the scope approach also apply
            with the self contained approach
            

        
 

        
Best
            regards

        
 

        
JJacques
            

        
 

        
 

        
 

        

          

            
De : DiME [mailto:dime-bounces@ietf.org]
                De la part de Steve Donovan

                Envoyé : mercredi 11 décembre 2013 14:20

                À : dime@ietf.org

                Objet : Re: [Dime] DOIC: Self-Contained OLRs

          

        

        
 

        
JJacques,

          

          While the self contained overload report concept may be
          similar to the scopes concept in the Roach draft, they are not
          the same.  As such, I don't agree with your assertion that the
          previous rejection of the Roach draft requires us to reject
          self contained overload reports as currently being discussed.

          

          Steve

        

          
On 12/11/13 2:27 AM, TROTTIN,
            JEAN-JACQUES (JEAN-JACQUES) wrote:

        

        

          
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 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>
            wrote:

          


            OK. Lets call this thread concluded then. I keep the old
            OC-OLR  semantics

            regarding its information context then unmodified.

            

            - Jouni

          
 

          
 

          
_______________________________________________

          
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


    

    

  


--------------000506080307030508030107--

From jouni.nospam@gmail.com  Wed Dec 11 13:39:06 2013
Return-Path: 
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 C443D1AE0E3 for ; Wed, 11 Dec 2013 13:39:06 -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 bpPG_9ROVTYV for ; Wed, 11 Dec 2013 13:39:05 -0800 (PST)
Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 0207F1AE068 for ; Wed, 11 Dec 2013 13:39:04 -0800 (PST)
Received: by mail-la0-f46.google.com with SMTP id eh20so4260562lab.33 for ; Wed, 11 Dec 2013 13:38:58 -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=bfLgm2El72iaftTViP89IWaPm/zAGHlfHUII0cAvcbw=; b=f2PkOOxJloeLizvDvJ0txASpJE+cGPuuFbND24TONDDiFEP5UnVFdH09PkMYli0R3o vwleP3Sg0yD7VKjZY4TG20IEUVSgAZvaS1FlzB5D9IPLQuuf0N9nVj9OhC9COb+l1mbQ 3Y03G5UnH/X94hQJ6Awc4w/E/wt7xEUHrPqsZ1jtDORokaL1krRt/ktFbFOfxy8Vk1mM OnwanbBlT4kVf+Bui3pHGuB7gtxzOhc/FOxLkFxbz1/K3HA5QwV2C8kkWNejMC0nxt3p hJEXGyw9ttTuQQ42WE/eITQlPo0RHd1mrzIgr/ELSfG8CepajsBYe7vt36ikobuerWX6 X9Hg==
X-Received: by 10.152.21.38 with SMTP id s6mr834564lae.80.1386797938613; Wed, 11 Dec 2013 13:38:58 -0800 (PST)
Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id ld10sm30694613lab.8.2013.12.11.13.38.55 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Dec 2013 13:38:55 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jouni Korhonen 
In-Reply-To: <087A34937E64E74E848732CFF8354B920973A7D7@ESESSMB101.ericsson.se>
Date: Wed, 11 Dec 2013 23:38:54 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <465BD57E-98C6-43CA-AC92-85550301B48A@gmail.com>
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DB1B@DEMUMBX014.nsn-intra.net>  <52A5E902.20605@usdonovans.com> <7475B713-1104-4791-96B1-CE97632A0D69@nostrum.com>  <5BCBA1FC2B7F0B4C9D935572D90006681519E476@DEMUMBX014.nsn-intra.net> <1CD20507-B0FE-4367-804A-B831734CF060@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E6DC@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D90006681519E712@DEMUMBX014.nsn-intra.net> <4A151D70-0291-4238-85B1-03BB54B361E6@gmail.com> <52A864FF.10705@usdonovans.com> <23887553-5068-477A-AE34-3DC5E3D5AC76@gmail.com> <087A34937E64E74E848732CFF8354B920973A7D7@ESESSMB101.ericsson.se>
To: Maria Cruz Bartolome 
X-Mailer: Apple Mail (2.1510)
Cc: "dime@ietf.org list" , Ben Campbell 
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Dec 2013 21:39:06 -0000

Hi,

On Dec 11, 2013, at 7:22 PM, Maria Cruz Bartolome =
 wrote:

> Dear all,
>=20
>> [Steve] Ulrich does bring up an interesting use case, where a client =
is receiving realm reports for the same realm from different agents.  We =
need to define the clients behavior in this case. =20
>=20
> [Jouni] Could we simply say that in this case the agents (or who ever =
inserts the realm report) MUST share the same view of the realm overload =
condition? Obviously how it is achieved would be implementation =
specific. I recall we have surfaced this topic earlier..
>=20
> [MCruz] But... isn't simpler to use time instead of sequence? It would =
solve this case as long as any number of agents serving same realm are =
time synchronized. =20

Well.. time is what I have been preferring. Now Steve is also OK with =
that
as long as we do not name is as a "timestamp".

Just to note that clocks typically get synchronized using NTP. That =
would
equal to central sequence number source with some local skew tolerance =
;-)

- Jouni=

From ben@nostrum.com  Wed Dec 11 14:35:55 2013
Return-Path: 
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 180AB1AE17E for ; Wed, 11 Dec 2013 14:35:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Level: 
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no
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 g91ElRe1NM8t for ; Wed, 11 Dec 2013 14:35:54 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9F5581AE113 for ; Wed, 11 Dec 2013 14:35:53 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rBBMZeH8067603 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 11 Dec 2013 16:35:41 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Ben Campbell 
In-Reply-To: 
Date: Wed, 11 Dec 2013 16:35:39 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <14594_1386204165_529FCC05_14594_12646_1_6B7134B31289DC4FAF731D844122B36E329907@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B920972CCAA@ESESSMB101.ericsson.se>  <52A077CC.3000004@usdonovans.com>  <52A088D0.2020406@usdonovans.com>  <52A091CE.2000104@usdonovans.com> <13081_1386256433_52A09831_13081_8197_1_6B7134B31289DC4FAF! 731D84412 2B36E32B6EB@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B9209739738@ESESSMB101.ericsson.se>  <8FD63E2D-5203-4DA4-A6DA-C4CA181C9CFB@nostrum.com> <26C84DFD55BC3040A45BF70926E55F2587C1D786@SZXEMA512-MBX.china.huawei.com>  <52A86663.30500@usdonovans.com> 
To: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
X-Mailer: Apple Mail (2.1822)
Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism)
Cc: "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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Dec 2013 22:35:55 -0000

On Dec 11, 2013, at 12:01 PM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) =
 wrote:

> So the drawbacks identified for the scope approach also apply with the =
self contained approach
>=20

The drawbacks identified for the scope approach, if I recall correctly, =
were along the lines of "this is too complex", without any (despite my =
repeated request) descriptions of the specific complexities people were =
worried about. If I've missed some actual, technical description of the =
complexities, please point them out.

That being said, I do not agree that self-contained OLRs are necessarily =
of the same complexity as scopes in the roach draft. It all depends on =
what rules we specify for about how you can combine values, and how one =
deals with (or prevents) conflicts.=

From ben@nostrum.com  Wed Dec 11 14:42:21 2013
Return-Path: 
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 171621AE18C for ; Wed, 11 Dec 2013 14:42:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Level: 
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no
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 Y5VDRnx530cx for ; Wed, 11 Dec 2013 14:42:19 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 51F421AE053 for ; Wed, 11 Dec 2013 14:42:19 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rBBMg8X8067845 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 11 Dec 2013 16:42:09 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Ben Campbell 
In-Reply-To: <26C84DFD55BC3040A45BF70926E55F2587C1D786@SZXEMA512-MBX.china.huawei.com>
Date: Wed, 11 Dec 2013 16:42:07 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: 
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>  <14594_1386204165_529FCC05_14594_12646_1_6B7134B31289DC4FAF731D844122B36E329907@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B920972CCAA@ESESSMB101.ericsson.se>  <52A077CC.3000004@usdonovans.com>  <52A088D0.2020406@usdonovans.com>  <52A091CE.2000104@usdonovans.com> <13081_1386256433_52A09831_13081_8197_1_6B7134B31289DC4FAF! ! 731D84412 2B36E32B6EB@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B9209739738@ESESSMB101.ericsson.se>  <8FD63E2D-5203-4DA4-A6DA-C4CA181C9CFB@nostrum.com> <26C84DFD55BC3040A45BF70926E55F2587C1D786@SZXEMA512-MBX.china.huawei.com>
To: "Shishufeng (Susan)" 
X-Mailer: Apple Mail (2.1822)
Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism)
Cc: "dime@ietf.org list" 
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Dec 2013 22:42:21 -0000

On Dec 9, 2013, at 9:58 PM, Shishufeng (Susan) =
 wrote:

> Hi Ben,
> =20
> 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.
> =20
> Quick thinking on the pros you listed for self-contained OLR.
> =20
> -          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.

I think the reason it may not be a key issue is that we didn't have a =
solution for it. I am personally not fond of having to treat 100% =
overload as different from all other cases.

We currently do not allow OLRs in requests, although the solution I had =
in mind might actually need to do that. But if we need to send OLRs in =
requests, we will need something like self-contained OLRs, or we have to =
limit ourselves to application specific solutions.


> -          The last three pros are mainly for the case of overload of =
agent, if I understood them correctly.

The 4th one is. The last 2 are not specific to agents. (If anything, the =
last one is inspired more for true end-to-end overload indication.)

> 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.

I'm not sure I follow your last sentence. If you mean AVPs for =
application-id, etc, that go _in_ the OLR, then that's pretty much the =
same thing as (at least partially) self-contained OLRs




> =20
> Best Regards,
> Susan
> =20
> From: Ben Campbell [mailto:ben@nostrum.com]=20
> Sent: Tuesday, December 10, 2013 7:53 AM
> To: dime@ietf.org list
> Subject: Re: [Dime] DOIC: Self-Contained OLRs
> =20
> 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.
> =20
> 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.
> =20
> It would also be good to hear from anyone who has not already weighed =
into this.
> =20
> Self-Contained OLRS:
> =20
> Pros:
> 	=95 Allows an easy, generic solution to Maria's =
"all-application" scoped overload use case.
> 	=95 Allows an overloaded node to signal overload for multiple =
applications at once, instead of having to signal each one separately.
> 	=95 Allows an easy solution to our "loss" algorithm corner case =
of not being able to signal the end of a 100% overload condition
> 	=95 Makes it easier to solve the agent overload problem, without =
requiring inconsistent behavior.
> 	=95 Allows out-of-band transmission of OLRs without a new format
> 	=95 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:=20
> =20
> 	=95 The recipient cannot assume an OLR matches the context of =
the transaction in which it is received. =20
> 	=95 It's different than what's in the draft.
> =20
> Implicit OLRs:
> =20
> Pros:
> 	=95 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.]
> 	=95 Currently described in the draft.
> Cons:
> 	=95 Would need special-case behavior to allow the =
"all-application" scope.
> 	=95 An overloaded node needs to send a separate report for every =
supported application.
> 	=95 Needs special-case behavior to solve agent overload
> 	=95 Cannot signal the end of a loss algorithm 100% overload =
condition
> 	=95 cannot be used out-of-band.
> 	=95 cannot be used with dedicated applications.
> =20
> =20
> =20
> On Dec 9, 2013, at 5:09 AM, Jouni Korhonen  =
wrote:
>=20
>=20
>=20
> OK. Lets call this thread concluded then. I keep the old OC-OLR  =
semantics
> regarding its information context then unmodified.
>=20
> - Jouni
>=20
> =20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From maria.cruz.bartolome@ericsson.com  Wed Dec 11 23:26:57 2013
Return-Path: 
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 1FF231AE00B for ; Wed, 11 Dec 2013 23:26:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.85
X-Spam-Level: 
X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, 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 SU8F3DGoVbpF for ; Wed, 11 Dec 2013 23:26:50 -0800 (PST)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id CAAAE1AE1C5 for ; Wed, 11 Dec 2013 23:26:48 -0800 (PST)
X-AuditID: c1b4fb2d-b7f1c8e000005ceb-d6-52a96532e142
Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id EA.69.23787.23569A25; Thu, 12 Dec 2013 08:26:42 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.197]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.02.0347.000; Thu, 12 Dec 2013 08:26:41 +0100
From: Maria Cruz Bartolome 
To: "dime@ietf.org" 
Thread-Topic: [Dime] DOIC: Self-Contained OLRs
Thread-Index: AQHO8HrX2PaAGa/GgUyaCwjRxXVUh5o5m/0AgACzUoCAAAFygIAAE14AgAF8EACAACKcAIAANGaAgATJUgCAAAuAAIACAWkAgAAGHYCAAXsigIAALuKAgAAb/4CAAHc6gIAAOZAAgAAO+4CAAAVNAIAABNCAgAAF6QCAAAecAIAF/9gAgAAFIoCAANV2gIAARHaAgAHlZ9CAAEm9gIAAWSGggAACrFCAAAAqoP///FIAgADcoyA=
Date: Thu, 12 Dec 2013 07:26:41 +0000
Message-ID: <087A34937E64E74E848732CFF8354B920973AAF5@ESESSMB101.ericsson.se>
References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com>  <52A077CC.3000004@usdonovans.com>  <52A088D0.2020406@usdonovans.com>  <52A091CE.2000104@usdonovans.com> <13081_1386256433_52A09831_13081_8197_1_6B7134B31289DC4FAF! 731D84412 2B36E32B6EB@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B9209739738@ESESSMB101.ericsson.se>  <8FD63E2D-5203-4DA4-A6DA-C4CA181C9CFB@nostrum.com> <26C84DFD55BC3040A45BF70926E55F2587C1D786@SZXEMA512-MBX.china.huawei.com>  <52A86663.30500@usdonovans.com>  <087A34937E64E74E848732CFF8354B920973A82A@ESESSMB101.ericsson.se> <52A8B862.5040207@usdonovans.com>
In-Reply-To: <52A8B862.5040207@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.154]
Content-Type: multipart/alternative; boundary="_000_087A34937E64E74E848732CFF8354B920973AAF5ESESSMB101erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrILMWRmVeSWpSXmKPExsUyM+Jvra5R6sogg6a14hZze1ewOTB6LFny kymAMYrLJiU1J7MstUjfLoEro+PjB/aCPR3MFb9W3GJvYFx6namLkZNDQsBE4v3H+WwQtpjE hXvrgWwuDiGBQ4wS2/ZfZ4ZwljBKnDz3ixWkik3ATuLS6RdA3RwcIgLKEqd/OYCEhQV0Jbad +sAMYosI6Em8OLmSCaRXRKCJSaLh4AJ2kASLgKrE7ClXwObwCvhK/Pl9nB1iwRwOiW3T17GD DOUE6l58IgekhhHoou+n1oBdyiwgLnHryXyoqwUkluw5zwxhi0q8fPyPFcJWklh0+zNUfb5E y5tVULsEJU7OfMIygVFkFpJRs5CUzUJSBhHXk7gxdQobhK0tsWzha2YIW1dixr9DLMjiCxjZ VzGy5yZm5qSXG25iBEbLwS2/dXcwnjoncohRmoNFSZz3w1vnICGB9MSS1OzU1ILUovii0pzU 4kOMTBycUg2MoUYZ3X9m3jmWp5P4p8Bz3euYYK+377/M+17aJqITOY/PeW9+qF1wfmzrLinX 535h8/LPvpZfwHk/wCbtHpP3aenVtVN8/oe/zzG1SHtv1vFg1zaWhwyTvz48Nnvpr1eJjlHp mUXJhUsEEv8a8p+YMYfzS3r6zduay/z+C9dy/5XjVlG8/SxaiaU4I9FQi7moOBEAvEXCUmQC AAA=
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Dec 2013 07:26:57 -0000

--_000_087A34937E64E74E848732CFF8354B920973AAF5ESESSMB101erics_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Yes, I agree consistency is not any longer a problem, since now your intent=
ion is that _any_ (and multiple) application data could be conveyed within =
the same message.
But as mentioned a few times, I consider this not necessary since OLR is se=
nt in every answer.
A part from that, as mentioned by Lionel, this implies a cross-application =
procedure at both endpoints, that increases complexity and it is not requir=
ed for our work (RFC7068)

Cheers
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: mi=E9rcoles, 11 de diciembre de 2013 20:09
To: dime@ietf.org
Subject: Re: [Dime] DOIC: Self-Contained OLRs

Maria Cruz,

I don't agree with the assertion that self-contained OLRs results in the po=
tential for data inconsistency.  If a reactor receives an overload report f=
or an application that is not supported by the reactor then the reactor can=
 and should ignore that OLR.

The concept of self-contained overload reports would explicitly allow for t=
he contents of the overload report to be different than the message that is=
 carrying the OLR.  As with application-ids, if the reactor doesn't send me=
ssages to a reported host or realm then the reactor ignores that part of th=
e overload report.  As such, there is no need to check the implicit data wh=
en receiving a self-contained OLR.

Steve
On 12/11/13 12:25 PM, Maria Cruz Bartolome wrote:

Hello (and something else now :), fast key combination, I won't be able to =
repeat,  was the responsible)



As mentioned before, something else on cons side for self-contained:



A part from that,  one concern with "self-contained OLRs" is that some data=
 is duplicated. Duplication should be avoided, since then we need to assure=
 consistency, and error handing in case implicit and explicit data values a=
re different for any reason... what means that it may always be required to=
 check both implicit and explicit data.



Also, I think this is a pure implementation proposal. Regardless how the da=
ta is transported it could be packed in a "self-contained OLRs" within the =
diameter application, if for any implementation this is preferred.

Best regards
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE=
S (JEAN-JACQUES)
Sent: mi=E9rcoles, 11 de diciembre de 2013 19:02
To: dime@ietf.org
Subject: Re: [Dime] DOIC: Self-Contained OLRs

Hi Steve

I am sorry, Steve,  I do not see the difference between the Draft Roach sco=
pe approach and the self contained OLRs.

With the scope approach in Draft Roach : there is an overload metric AVP  (=
eg containing a % of traffic reduction) coupled with one or several Overlao=
d-Infoscope AVPs, an overlaod infoscope identifying an application or a des=
tination host or... . These Overlaod-Infoscope AVPs can be combined  with a=
lso  the possibility of  multi instances to have a list of applications, a =
list of destination hosts etc  to which the overload metric would apply.

With self contained OLR as you have described them, un OLR will also contai=
n an OC-Reduction-Percentage  AVP coupled with one or several others AVPs (=
the self containment approach) to indicate which application(s), destinatio=
ns host (s) etc the   OC-Reduction-Percentage  AVP applies.

Where is the difference?

So the drawbacks identified for the scope approach also apply with the self=
 contained approach

Best regards

JJacques



De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9 : mercredi 11 d=E9cembre 2013 14:20
=C0 : dime@ietf.org
Objet : Re: [Dime] DOIC: Self-Contained OLRs

JJacques,

While the self contained overload report concept may be similar to the scop=
es concept in the Roach draft, they are not the same.  As such, I don't agr=
ee with your assertion that the previous rejection of the Roach draft requi=
res us to reject self contained overload reports as currently being discuss=
ed.

Steve
On 12/11/13 2:27 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:
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 multip=
ly the number of AVPs in the OLRs (AVPs identifying Application, destinatio=
n 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 sel=
f 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 rec=
reate  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 si=
mple way to proceed, which drove to the current draft content. This decisio=
n is a strong argument that still prevails  for the current baseline descri=
bed in the current draft.

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

As also said, when news requirements will appear (eg session group or APN e=
xamples)  the baseline is extensible to support these new requirements .  I=
 prefer this way of progressive extensions , rather than to create a self c=
ontained 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=E9 : mardi 10 d=E9cembre 2013 04:58
=C0 : 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 righ=
t 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 opti=
mization 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 overloa=
d.

-          The last three pros are mainly for the case of overload of agent=
, if I understood them correctly. Overload of agent is still a controversia=
l scenario, we may need more discussion in the future. But anyway, with def=
inition 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-co=
ntained OLR.

Best Regards,
Susan

From: Ben Campbell [mailto:ben@nostrum.com]
Sent: Tuesday, December 10, 2013 7:53 AM
To: 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 wh=
at we do for a later (or final) version.

So far, I've seen 4 people opposed to self-contained OLRs (Lionel, Nirav, M=
aria, 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 lo=
ok 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 firs=
t group explain what they think the pros of implicit OLRs might be beyond t=
hose 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 application=
s at once, instead of having to signal each one separately.
  *   Allows an easy solution to our "loss" algorithm corner case of not be=
ing able to signal the end of a 100% overload condition
  *   Makes it easier to solve the agent overload problem, without requirin=
g 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 transac=
tion 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 trans=
action context and the report type. [I don't understand why this is valuabl=
e, 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 supporte=
d 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 > wrote:

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

- Jouni



_______________________________________________

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


--_000_087A34937E64E74E848732CFF8354B920973AAF5ESESSMB101erics_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Yes, I agree consistency =
is not any longer a problem, since now your intention is that _any_ =
(and multiple) application data could be conveyed within
 the same message.


But as mentioned a few ti=
mes, I consider this not necessary since OLR is sent in every answer.



A part from that, as ment=
ioned by Lionel, this implies a cross-application procedure at both endpoin=
ts, that increases complexity and it is not required for
 our work (RFC7068)


 <=
/p>

Cheers<=
/p>

/MCruz<=
/p>

 <=
/p>





From: DiME [mailto:dime-bounces@ietf.org]
On Behalf Of Steve Donovan

Sent: mi=E9rcoles, 11 de diciembre de 2013 20:09

To: dime@ietf.org

Subject: Re: [Dime] DOIC: Self-Contained OLRs






 


Maria Cruz,



I don't agree with the assertion that self-contained OLRs results in the po=
tential for data inconsistency.  If a reactor receives an overload rep=
ort for an application that is not supported by the reactor then the reacto=
r can and should ignore that OLR. 




The concept of self-contained overload reports would explicitly allow for t=
he contents of the overload report to be different than the message that is=
 carrying the OLR.  As with application-ids, if the reactor doesn't se=
nd messages to a reported host or realm
 then the reactor ignores that part of the overload report.  As such, =
there is no need to check the implicit data when receiving a self-contained=
 OLR.



Steve




On 12/11/13 12:25 PM, Maria Cruz Bartolome wrote:






Hello (and something else now 
J, fast key combination, I won’t be able to repeat,  was =
the responsible)


 


As mentioned before, something else on cons side =
for self-contained:


 


A part from that,&nb=
sp; one concern with "self-contained OLRs" is that some data is d=
uplicated. Duplication should be avoided, since then we need to assure cons=
istency, and error handing in case implicit and explicit
 data values are different for any reason... what means that it may always =
be required to check both implicit and explicit data.


 

Also, I think this i=
s a pure implementation proposal. Regardless how the data is transported it=
 could be packed in a "self-contained OLRs" within the diameter a=
pplication, if for any implementation this is
 preferred.


 <=
/p>

Best regards<=
/o:p>


/MCruz<=
/p>

 <=
/p>





From: DiME [ma=
ilto:dime-bounces@ietf.org]
On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)

Sent: mi=E9rcoles, 11 de diciembre de 2013 19:02

To: dime@ietf.org

Subject: Re: [Dime] DOIC: Self-Contained OLRs






 


Hi Steve


 <=
/p>

I am sorry, Steve,  =
I do not see the difference between the Draft Roach scope approach and the =
self contained OLRs.


 <=
/p>

With the scope approach i=
n Draft Roach : there is an overload metric AVP  (eg containing a % of=
 traffic reduction) coupled with one or several Overlaod-Infoscope
 AVPs, an overlaod infoscope identifying an application or a destination ho=
st or… . These Overlaod-Infoscope AVPs can be combined  with als=
o  the possibility of  multi instances to have a list of applicat=
ions, a list of destination hosts etc  to which the overload
 metric would apply.


 <=
/p>

With self contained OLR a=
s you have described them, un OLR will also contain an OC-Reduction-Percent=
age
 AVP coupled with one or several oth=
ers AVPs (the self containment approach) to indicate which application(s), =
destinations host (s) etc the   OC-Reduction-Percentage
 AVP applies.



 <=
/p>

Where is the difference?<=
/span>


 <=
/p>

So the drawbacks identifi=
ed for the scope approach also apply with the self contained approach



 <=
/p>

Best regards<=
/o:p>


 <=
/p>

JJacques



 <=
/p>

 <=
/p>

 <=
/p>





De =
: DiME [mailto:dime-bounces@ietf.org]
De la part de Steve Donovan

Envoy=E9 : mercredi 11 d=E9cembre 2013 14:20

=C0 : dime@ietf.org

Objet : Re: [Dime] DOIC: Self-Contained OLRs<=
/p>





 


JJacques,



While the self contained overload report concept may be similar to the scop=
es concept in the Roach draft, they are not the same.  As such, I don'=
t agree with your assertion that the previous rejection of the Roach draft =
requires us to reject self contained
 overload reports as currently being discussed.



Steve




On 12/11/13 2:27 AM, TROTTIN, JEAN-JACQUES (JEAN-JAC=
QUES) wrote:






Hi Ben and all



 <=
/p>

I remind my mail of 05/12=
, where the self contained OLRs approach is quite similar to the self conta=
ined 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 i=
n draft Roach).  


This also result in a pig=
gybacking  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 ho=
p, the self contained  OLRs are opened to be reprocessed in order to r=
ecreate  new self contained OLR(s)  to various destinations.



I remind that, now 6 mont=
hs 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 con=
tent. This decision is a strong argument that still prevails  for the =
current baseline described in the current draft.


 


This is why I remain in f=
avor of the baseline  described in the current  draft, as as I ha=
ve always and regularly  expressed for  a while.


 <=
/p>

As also said, when news r=
equirements will appear (eg session group or APN examples)  the baseli=
ne is extensible to support these new requirements .  I prefer
 this way of progressive extensions , rather than to create a self containe=
d OLR  with an  immediate and not needed complexity   &=
nbsp;


 <=
/p>

Best regards<=
/o:p>


 <=
/p>

JJacques


 <=
/p>

 <=
/p>





De : DiME [mailto:d=
ime-bounces@ietf.org]
De la part de Shishufeng (Susan)

Envoy=E9 : mardi 10 d=E9cembre 2013 04:58

=C0 : Ben Campbell; dime@ietf.=
org list

Objet : Re: [Dime] DOIC: Self-Contained OLRs<=
/p>





 


Hi Ben,=



 <=
/p>

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



 <=
/p>

Quick thinking on the pro=
s you listed for self-contained OLR.


 <=
/p>


-       &nb=
sp; 
The first two pro=
s can be seen as optimization, on which we are still arguing if these optim=
ization are worth doing or not, since such optimization
 brings extra cost.



-       &nb=
sp; 
The third one is =
not a key issue, which could be addressed with several ways as discussed. A=
s a last resort, the overloaded server may send something
 in a request towards the client to inform the end of the overload.<=
o:p>



-       &nb=
sp; 
The last three pr=
os are mainly for the case of overload of agent, if I understood them corre=
ctly. 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.


 <=
/p>

Best Regards,=



Susan

 <=
/p>





From: Ben Camp=
bell [mailto:ben@nostrum.com]


Sent: Tuesday, December 10, 2013 7:53 AM

To: dime@ietf.org list

Subject: Re: [Dime] DOIC: Self-Contained OLRs






 




I am willing to call the discussion concluded for th=
e 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 conse=
nsus. 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 explai=
n 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 no=
t already weighed into this.






 






Self-Contained O=
LRS:






 






Pros:






    

  • 
Allows an easy, generic solution to Maria's "all-application" sco=
ped overload use case.
  • 
Allows an overloaded node to signal overload for multiple applications at o=
nce, instead of having to signal each one separately.
  • 
Allows an easy solution to our "loss" algorithm corner case of no=
t being able to signal the end of a 100% overload condition
    • =

  • 
Makes it easier to solve the agent overload problem, without requiring inco=
nsistent behavior.
  • 
Allows out-of-band transmission of OLRs without a new format
  • 
Makes it easier to do things like adding a dedicated application for overlo=
ad, 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 i=
n 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" s=
cope.
  • 
An overloaded node needs to send a separate report for every supported appl=
ication.
  • 
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.
  •  
    







 






 




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




OK. Lets call this thread concluded then. I keep the old OC-OLR  seman=
tics

regarding its information context then unmodified.



- Jouni


 


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime



 











_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime



 






--_000_087A34937E64E74E848732CFF8354B920973AAF5ESESSMB101erics_--


From maria.cruz.bartolome@ericsson.com  Wed Dec 11 23:53:55 2013
Return-Path: 
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 3D6D11AE0F9 for ; Wed, 11 Dec 2013 23:53:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.239
X-Spam-Level: 
X-Spam-Status: No, score=-1.239 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
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 aC-JP7xhTtwa for ; Wed, 11 Dec 2013 23:53:54 -0800 (PST)
Received: from sessmg21.mgmt.ericsson.se (sessmg21.ericsson.net [193.180.251.40]) by ietfa.amsl.com (Postfix) with ESMTP id 505A51AD7C5 for ; Wed, 11 Dec 2013 23:53:52 -0800 (PST)
X-AuditID: c1b4fb28-b7f268e000001b97-00-52a96b8a8421
Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg21.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 55.3C.07063.A8B69A25; Thu, 12 Dec 2013 08:53:46 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.197]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.02.0347.000; Thu, 12 Dec 2013 08:53:46 +0100
From: Maria Cruz Bartolome 
To: "dime@ietf.org" 
Thread-Topic: OVLI: OC-Validity-Duration
Thread-Index: Ac73DRNgVjMdaw2ATnC3EBEvo4YB4g==
Date: Thu, 12 Dec 2013 07:53:45 +0000
Message-ID: <087A34937E64E74E848732CFF8354B920973AB4B@ESESSMB101.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.154]
Content-Type: multipart/alternative; boundary="_000_087A34937E64E74E848732CFF8354B920973AB4BESESSMB101erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrKLMWRmVeSWpSXmKPExsUyM+JvrW5X9sogg/e9hhZze1ewOTB6LFny kymAMYrLJiU1J7MstUjfLoErY8LEG4wFN0wrOideYG1gnK/fxcjJISFgIjHl4ndWCFtM4sK9 9WxdjFwcQgInGCWur3/JDuEsYZRYt2oKC0gVm4CdxKXTL5i6GDk4RASUJU7/cgAJCwOZGztW sIHYIgIaEjNfnWCHsPUkvqxrYAMpZxFQlbg9TwEkzCvgK9Hc/QpsLyPQ3u+n1jCB2MwC4hK3 nsxngrhHQGLJnvPMELaoxMvH/6DuVJJYdPsz2AXMAvkSDyekQ4wUlDg58wnLBEahWUgmzUKo moWkCqJER2LB7k9sELa2xLKFr5lh7DMHHjMhiy9gZF/FKFmcWlycm25kqJebnluil1qUmVxc nJ+nV5y6iREYFQe3/NbYwdh9zf4QozQHi5I4b9XMziAhgfTEktTs1NSC1KL4otKc1OJDjEwc nFINjNpiPYdl29aklAnWyX6bx1H1dS677oKHNy8kW3dtydXdUxAX2O4huXD7Vgc7reRi28zE jX8zfwiveyH91qSEbe1ra5nye4vL1a/fzmj7PGdjhP2dKyu2Mjw7ZeZgxPXfp0d06cwrSm/S 587rW/NN9mbRqQMqV02mZ62Q2l3nk3DC/1XbQiPGBiWW4oxEQy3mouJEAFSPeWVYAgAA
Subject: [Dime] OVLI: OC-Validity-Duration
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Dec 2013 07:53:55 -0000

--_000_087A34937E64E74E848732CFF8354B920973AB4BESESSMB101erics_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Dear all,

I would like to reconsider the real need for the OC-Validity-Duration AVP t=
o be included into overload report.
Overload mechanism is being design with a principle in mind: as soon as rep=
orting node determines a reacting node overload behavior should change, rep=
orting node sends a fresh overload report to this reacting node.
Therefore, latest overload report received will be always applicable until =
a new report is received, and then I do not see the value, but just complex=
ity, of including a Duration in the report.

Let me know your views.
Best regards
/MCruz






--_000_087A34937E64E74E848732CFF8354B920973AB4BESESSMB101erics_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Dear all,


 


I would like to recons=
ider the real need for the OC-Validity-Duration AVP to be included into ove=
rload report.


Overload mechanism is =
being design with a principle in mind: as soon as reporting node determines=
 a reacting node overload behavior should change, reporting node sends a fr=
esh overload report to this reacting
 node. 


Therefore, latest over=
load report received will be always applicable until a new report is receiv=
ed, and then I do not see the value, but just complexity, of including a Du=
ration in the report.


 


Let me know your views=
.


Best regards


/MCruz


 


 


 


 


 






--_000_087A34937E64E74E848732CFF8354B920973AB4BESESSMB101erics_--

From susan.shishufeng@huawei.com  Thu Dec 12 00:38:11 2013
Return-Path: 
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 8B5CB1AE13E for ; Thu, 12 Dec 2013 00:38:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level: 
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 kMk0QbsqmpJS for ; Thu, 12 Dec 2013 00:38:09 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id AF4481ADF44 for ; Thu, 12 Dec 2013 00:38:08 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBH34150; Thu, 12 Dec 2013 08:38:02 +0000 (GMT)
Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 12 Dec 2013 08:37:36 +0000
Received: from SZXEMA403-HUB.china.huawei.com (10.82.72.35) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 12 Dec 2013 08:37:49 +0000
Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.155]) by SZXEMA403-HUB.china.huawei.com ([10.82.72.35]) with mapi id 14.03.0158.001; Thu, 12 Dec 2013 16:37:39 +0800
From: "Shishufeng (Susan)" 
To: Ben Campbell 
Thread-Topic: [Dime] DOIC: Self-Contained OLRs
Thread-Index: AQHO9VIQot3HeYq6iU+vru+Aq+dgEZpMw4UwgAJQK4CAASXBYA==
Date: Thu, 12 Dec 2013 08:37:38 +0000
Message-ID: <26C84DFD55BC3040A45BF70926E55F2587C1E060@SZXEMA512-MBX.china.huawei.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>  <14594_1386204165_529FCC05_14594_12646_1_6B7134B31289DC4FAF731D844122B36E329907@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B920972CCAA@ESESSMB101.ericsson.se>  <52A077CC.3000004@usdonovans.com>  <52A088D0.2020406@usdonovans.com>  <52A091CE.2000104@usdonovans.com> <13081_1386256433_52A09831_13081_8197_1_6B7134B31289DC4FAF! ! 731D84412 2B36E32B6EB@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B9209739738@ESESSMB101.ericsson.se>  <8FD63E2D-5203-4DA4-A6DA-C4CA181C9CFB@nostrum.com> <26C84DFD55BC3040A45BF70926E55F2587C1D786@SZXEMA512-MBX.china.huawei.com> 
In-Reply-To: 
Accept-Language: en-GB, zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.146.62.57]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "dime@ietf.org list" 
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Dec 2013 08:38:11 -0000

Hi Ben,

For the last one, what I meant was that with the mechanism proposed in the =
base document, it can be extended to address the out-of-band transmission o=
r adding a dedicated application as listed in your last two pros when neede=
d in the future.=20

There might be some benefit with use of self-contained OLR if we are sure t=
hat the use cases for out-of-band transmission and dedicated application ne=
ed to be addressed. While so far the implicit OLRs can satisfy the requirem=
ents from 3GPP, and other use cases for out-of-band transmission and dedica=
ted application are not clear to 3GPP and may never be addressed. A right s=
olution is what we need for now.

Best Regards,
Susan

-----Original Message-----
From: Ben Campbell [mailto:ben@nostrum.com]=20
Sent: Thursday, December 12, 2013 6:42 AM
To: Shishufeng (Susan)
Cc: dime@ietf.org list
Subject: Re: [Dime] DOIC: Self-Contained OLRs


On Dec 9, 2013, at 9:58 PM, Shishufeng (Susan)  wrote:

> Hi Ben,
> =20
> Each solution has its pros and cons. The key point here is to select a ri=
ght one which could satisfy the requirements but with less resource consumi=
ng.
> =20
> Quick thinking on the pros you listed for self-contained OLR.
> =20
> -          The first two pros can be seen as optimization, on which we ar=
e still arguing if these optimization are worth doing or not, since such op=
timization brings extra cost.
> -          The third one is not a key issue, which could be addressed wit=
h several ways as discussed. As a last resort, the overloaded server may se=
nd something in a request towards the client to inform the end of the overl=
oad.

I think the reason it may not be a key issue is that we didn't have a solut=
ion for it. I am personally not fond of having to treat 100% overload as di=
fferent from all other cases.

We currently do not allow OLRs in requests, although the solution I had in =
mind might actually need to do that. But if we need to send OLRs in request=
s, we will need something like self-contained OLRs, or we have to limit our=
selves to application specific solutions.


> -          The last three pros are mainly for the case of overload of age=
nt, if I understood them correctly.

The 4th one is. The last 2 are not specific to agents. (If anything, the la=
st one is inspired more for true end-to-end overload indication.)

> Overload of agent is still a controversial scenario, we may need more dis=
cussion in the future. But anyway, with definition of new AVPs containing t=
he application-id, host, realm information as implied by the piggybacking m=
essages in the draft, as complement to the OLR so far defined, they could r=
each the same intention as with the self-contained OLR.

I'm not sure I follow your last sentence. If you mean AVPs for application-=
id, etc, that go _in_ the OLR, then that's pretty much the same thing as (a=
t least partially) self-contained OLRs




> =20
> Best Regards,
> Susan
> =20
> From: Ben Campbell [mailto:ben@nostrum.com]
> Sent: Tuesday, December 10, 2013 7:53 AM
> To: dime@ietf.org list
> Subject: Re: [Dime] DOIC: Self-Contained OLRs
> =20
> I am willing to call the discussion concluded for the purposes of what go=
es 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.
> =20
> 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 fi=
rst 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 layerin=
g, since people disputed that already.
> =20
> It would also be good to hear from anyone who has not already weighed int=
o this.
> =20
> Self-Contained OLRS:
> =20
> Pros:
> 	* Allows an easy, generic solution to Maria's "all-application" scoped o=
verload 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 bei=
ng 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=20
> for overload, without a new format. (Yes, I think there's still a use=20
> case for that, and I will detail it shortly.)
> Cons:=20
> =20
> 	* The recipient cannot assume an OLR matches the context of the transact=
ion in which it is received. =20
> 	* It's different than what's in the draft.
> =20
> Implicit OLRs:
> =20
> Pros:
> 	* The recipient can infer the OLR scope from a combination of the transa=
ction 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.
> =20
> =20
> =20
> On Dec 9, 2013, at 5:09 AM, Jouni Korhonen  wrote=
:
>=20
>=20
>=20
> OK. Lets call this thread concluded then. I keep the old OC-OLR =20
> semantics regarding its information context then unmodified.
>=20
> - Jouni
>=20
> =20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From jouni.nospam@gmail.com  Thu Dec 12 00:38:44 2013
Return-Path: 
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 33C131AE13E for ; Thu, 12 Dec 2013 00:38:44 -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 xwoQMqYt4xtv for ; Thu, 12 Dec 2013 00:38:42 -0800 (PST)
Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 3115C1AE1F7 for ; Thu, 12 Dec 2013 00:38:41 -0800 (PST)
Received: by mail-la0-f41.google.com with SMTP id eo20so62806lab.14 for ; Thu, 12 Dec 2013 00:38:35 -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=UmtFBjeKHfHMcMvhKtzBmQhh9FgtK1VCdnOMdPxyrjQ=; b=ITpLut5iFQdYGEDWmtNkL8OFbALeGIfP5Xg+Vr5735U3/cvZyJmIi7qkBSVAit0r50 a79QibV3NPbueWmh5op/TkuSIJjg9OfQM47mbHroVNcQZRbkRqQQCpH7Lg+wStZxYP0z UMsA9gbbIie+Ul+1YeGytRBb7tc23kJtXM4Rg8mjz62kcYAGySuLqDeKjnOo9zOxzuCG NcfHKrSp/SVmZ2JTqo4N4d1YZbauMr8U84mHTrwkSk9rFDY3SiiPhhIH4qseeDcmUYmj aNdbhTSx4Mvg8ZP0K2AEe9pAKRu6J8EuQPVkNetfx/wUW1SlU0cLXyf3g0Ym/Vm0gbVs OmUw==
X-Received: by 10.152.115.230 with SMTP id jr6mr2977628lab.45.1386837515482; Thu, 12 Dec 2013 00:38:35 -0800 (PST)
Received: from [192.168.250.53] ([194.100.71.98]) by mx.google.com with ESMTPSA id di11sm33353408lac.0.2013.12.12.00.38.34 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Dec 2013 00:38:34 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jouni Korhonen 
In-Reply-To: <087A34937E64E74E848732CFF8354B920973AB4B@ESESSMB101.ericsson.se>
Date: Thu, 12 Dec 2013 10:38:34 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <087A34937E64E74E848732CFF8354B920973AB4B@ESESSMB101.ericsson.se>
To: Maria Cruz Bartolome 
X-Mailer: Apple Mail (2.1510)
Cc: "dime@ietf.org" 
Subject: Re: [Dime] OVLI: OC-Validity-Duration
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Dec 2013 08:38:44 -0000

Hi,

I kind of like scheduled cleanups.. just to make sure there is no
stuff left hanging around when something unpredictable happens in
the network system.

Again, I would say this is a wrong place to "optimize".


- Jouni

On Dec 12, 2013, at 9:53 AM, Maria Cruz Bartolome =
 wrote:

> Dear all,
> =20
> I would like to reconsider the real need for the OC-Validity-Duration =
AVP to be included into overload report.
> Overload mechanism is being design with a principle in mind: as soon =
as reporting node determines a reacting node overload behavior should =
change, reporting node sends a fresh overload report to this reacting =
node.
> Therefore, latest overload report received will be always applicable =
until a new report is received, and then I do not see the value, but =
just complexity, of including a Duration in the report.
> =20
> Let me know your views.
> Best regards
> /MCruz
> =20
> =20
> =20
> =20
> =20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From ulrich.wiehe@nsn.com  Thu Dec 12 01:24:37 2013
Return-Path: 
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 B48E51AE09B for ; Thu, 12 Dec 2013 01:24:37 -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 hWpF-3JpO7SK for ; Thu, 12 Dec 2013 01:24: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 35ADE1AE09D for ; Thu, 12 Dec 2013 01:24:31 -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 rBC9OG45002224 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 12 Dec 2013 10:24:16 +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 rBC9OF84003380 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Dec 2013 10:24:16 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.152]) by DEMUHTC001.nsn-intra.net ([10.159.42.32]) with mapi id 14.03.0123.003; Thu, 12 Dec 2013 10:24:15 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Steve Donovan , Ben Campbell 
Thread-Topic: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3
Thread-Index: AQHO9atFkoRa3B+doUWxxFMNrNdzoppNfy7wgAFzLACAAUbUgA==
Date: Thu, 12 Dec 2013 09:24:14 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519E888@DEMUMBX014.nsn-intra.net>
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DB1B@DEMUMBX014.nsn-intra.net>  <52A5E902.20605@usdonovans.com> <7475B713-1104-4791-96B1-CE97632A0D69@nostrum.com> <52A71632.7040806@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E48F@DEMUMBX014.nsn-intra.net> <52A86C6E.4030602@usdonovans.com>
In-Reply-To: <52A86C6E.4030602@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.106]
Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D90006681519E888DEMUMBX014nsnin_"
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: 27494
X-purgate-ID: 151667::1386840262-00001A6F-4A20A8C1/0-0/0-0
Cc: "dime@ietf.org list" 
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Dec 2013 09:24:37 -0000

--_000_5BCBA1FC2B7F0B4C9D935572D90006681519E888DEMUMBX014nsnin_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Steve,

not sure if I correctly understand your second paragraph; please see inline=
.

Anyway I agree with your conclusion: Something is missing in the concept of=
 "sequence-number in OC-Supported-Features". We WOULD need the DOIC end-poi=
nt Diameter ID included in that AVP. I said WOULD because things are becomi=
ng more and more complex and complicated. This all is not worth the effort.=
  Let's remove sequence number from Supported-Features.

A Reporting node that does not support any extension (i.e. supports only OL=
R_DEFAULT_ALGO)  only needs to know whether there is a reacting node down s=
tream that supports OLR_DEFAULT_ALGO    in order to decide whether or not a=
 pre-calculated (default-algo-type) OLR must be returned or not. This can s=
imply be done by checking bit 0 of the received Feature-Vector.
The alternative

-          to setup and maintain a database of DOIC end-point ID / sequence=
-number pairs containing the pre-calculated (last-known-supported-feature-t=
ype) OLR , and

-          to check, when receiving a request, whether the included DOIC en=
d-point ID / sequence-number pair is present in the database and if so retu=
rn the corresponding OLR;
is over-overkill.

Also there is no need for the reporting node (which still only supports OLR=
_DEFAULT_ALGO ) to detect that the reacting nodes capabilities have been up=
dated e.g. from "support of   OLR_DEFAULT_ALGO" to "support of  OLR_DEFAULT=
_ALGO   and   OLR_SOMETHING_NEW "


Ulrich


From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Wednesday, December 11, 2013 2:45 PM
To: Wiehe, Ulrich (NSN - DE/Munich); Ben Campbell
Cc: dime@ietf.org list
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comment=
s to 4.3

Ulrich,

Is your question how sequence numbers work when there are DOIC supporting a=
gents?
[Wiehe, Ulrich (NSN - DE/Munich)] yes, when there are more than one DOIC su=
pporting agents that do DOIC on behalf of a (single) non-DOIC-supporting Cl=
ient.

The capabilities exchange is between two DOIC endpoints,
[Wiehe, Ulrich (NSN - DE/Munich)] I agree
so in the case you outline, the server would see capability information fro=
m each agent in the path
[Wiehe, Ulrich (NSN - DE/Munich)] the server would see capability informati=
on in a received request but does not know which downstream node included t=
he capability information. Not more than one node in a path will incude cap=
ability information.
.  The server should not see the sequence numbers from the clients.
[Wiehe, Ulrich (NSN - DE/Munich)] in the example there is only one client, =
and that does not support DOIC, so I don't understand "sequence numbers fro=
m the clients"


This does point out that we are likely missing something from the OC-Featur=
e-Vector AVP.  We likely need the DOIC end-point Diameter ID included in th=
at AVP.

Steve
On 12/10/13 8:43 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
Steve,

how does this work in scenarios where a non supporting client C sends some =
requests via the DOIC supporting agent A1 to the server S and other request=
s via a different DOIC supporting agent A2 to the same server S?

Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Tuesday, December 10, 2013 2:25 PM
To: Ben Campbell
Cc: dime@ietf.org list
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comment=
s to 4.3

inline
On 12/9/13 4:34 PM, Ben Campbell wrote:



On Dec 9, 2013, at 10:00 AM, Steve Donovan  wrote:



Jouni,



I propose that we keep the name OC-Sequence-Number but that we use the Time=
 type for OC-Sequence-Number.  It is misleading and potentially confusing t=
o call it OC-Time-Stamp.





I could live with that, although I would rather just define the expected pr=
operties of the sequence number, and leave the implementation up to the imp=
lementor. I assume your reasoning for not calling it a timestamp is that yo=
u do not want people to try to use it as a time base reference. If so, then=
 we don't require any connection to a clock. We just need it to be monotoni=
cally increasing.



We might consider expanding on the format of the AVP to make it something l=
ike Session-ID, where it is a concatenation of the Diameter-ID of the gener=
ating node and a timestamp.  This might help the reacting node keep track o=
f which sequence number it has received.





Do we need a uniqueness across multiple nodes property? If so, why?
Strictly speaking, no.  The thought was to make it similar to session-id an=
d potentially make it easier for the reacting node to keep differentiate se=
quence numbers from different reporting nodes.







Steve



On 12/9/13 5:37 AM, Jouni Korhonen wrote:

Folks



Could we conclude on the sequence number vs. time stamp vs. something else?

We got more important places to spend our energy than this ;)



My proposal is the following (based on the original pre-00 design):



o We change the OC-Sequence-Number to OC-Time-Stamp in all occurrences

  in the -01.

o We use RFC6733 Time type for the OC-Time-Stamp. RFC6733 gives us

  already exact definition how to handle the AVP.

o Define that the OC-Time-Stamp is the time of the creation of the

  "original" AVP within whose context the time stamp is present.

o The OC-Time-Stamp AVP uniqueness is still considered to be in scope

  of the communicating endpoints.

o The time stamp can be used to quickly determine if the content of

  the encapsulating AVP context has changed (among other properties).

  This would be useful specifically in the future when the encapsulating

  grouped AVPs  grow in size and functionality.





- Jouni



_______________________________________________

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







--_000_5BCBA1FC2B7F0B4C9D935572D90006681519E888DEMUMBX014nsnin_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Steve,<=
/p>

 <=
/p>

not sure i=
f I correctly understand your second paragraph; please see inline.


 =
;


Anyway I a=
gree with your conclusion: Something is missing in the concept of “se=
quence-number in OC-Supported-Features”. We WOULD need the DOIC
 end-point Diameter ID included in that AVP. I said WOULD because things ar=
e becoming more and more complex and complicated. This all is not worth the=
 effort. 
Let’s remove sequence number from Supported-Features.


 =
;


A Reportin=
g node that does not support any extension (i.e. supports only
OLR_DEFAULT_ALGO=
)  only needs to know whethe=
r there is a reacting node down stream that supports
OLR_DEFAULT_ALGO=
    in order to de=
cide whether or not a pre-calculated (default-algo-type) OLR must be return=
ed
 or not. This can simply be done by checking bit 0 of the received Feature-=
Vector.



The altern=
ative



-         
to=
 setup and maintain a database of DOIC end-point ID / sequence-number pairs=
 containing the pre-calculated (last-known-supported-feature-type)
 OLR , and


-         
to=
 check, when receiving a request, whether the included DOIC end-point ID / =
sequence-number pair is present in the database and if so
 return the corresponding OLR;


is over-ov=
erkill.


 =
;


Also there=
 is no need for the reporting node (which still only supports
OLR_DEFAULT_ALGO=
 ) to detect that the reacting no=
des capabilities have been updated e.g. from “support of  
OLR_DEFAULT_ALGO=
“ to “support of &nbs=
p;OLR_DEFAULT_ALGO
  and  &nbs=
p;OLR_SOMETHING_NEW
 “


 =
;


 =
;


Ulrich


 =
;


 =
;






From:=
 ext Steve Donovan [=
mailto:srdonovan@usdonovans.com]


Sent: Wednesday, December 11, 2013 2:45 PM

To: Wiehe, Ulrich (NSN - DE/Munich); Ben Campbell

Cc: dime@ietf.org list

Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: =
comments to 4.3






 


Ulrich,



Is your question how sequence numbers work when there are DOIC supporting a=
gents?


[Wiehe, Ulrich (NSN - DE/Munich)] yes, when ther=
e are more than one DOIC supporting agents that do DOIC on behalf
 of a (single) non-DOIC-supporting Client.



The capabilities exchange is between two DOIC endpoints,


[Wiehe, Ulrich (NSN - DE/Munich)] I agree


=
so in the case you outline, the server would see capability information fro=
m each agent in the path


[Wiehe, Ulrich (NSN - DE/Munich)] the server wou=
ld see capability information in a received request but does
 not know which downstream node included the capability information. Not mo=
re than one node in a path will incude capability information.


=
.  The server should not see the sequence numbers from the clie=
nts.


[Wiehe, Ulrich (NSN - DE/Munich)] in the example=
 there is only one client, and that does not support DOIC, so
 I don’t understand “sequence numbers from the clients”


=




This does point out that we are likely missing something from the OC-Featur=
e-Vector AVP. 
We likely need the DOIC end-point Diameter ID included in that AVP.<=
br>


Steve




On 12/10/13 8:43 AM, Wiehe, Ulrich (NSN - DE/Munich)=
 wrote:






Steve,


 


how does t=
his work in scenarios where a non supporting client C sends some requests v=
ia the DOIC supporting agent A1 to the server S and other
 requests via a different DOIC supporting agent A2 to the same server S?


 


Ulrich


 






From:=
 DiME [mailto:dime-bounces@ietf.org]
On Behalf Of ext Steve Donovan

Sent: Tuesday, December 10, 2013 2:25 PM

To: Ben Campbell

Cc: dime@ietf.org list

Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: =
comments to 4.3






 


inline




On 12/9/13 4:34 PM, Ben Campbell wrote:





 


On Dec 9, 2013, at 10:00 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:

 




Jouni,


 


I propose that we keep the name OC-Sequence-Number but that we use the=
 Time type for OC-Sequence-Number.  It is misleading and potentially c=
onfusing to call it OC-Time-Stamp.  


 




 


I could live with that, although I would rather just define the expect=
ed properties of the sequence number, and leave the implementation up to th=
e implementor. I assume your reasoning for not calling it a timestamp is th=
at you do not want people to try to use it as a time base reference. If so,=
 then we don't require any connection to a clock. We just need it to be mon=
otonically increasing.


 




We might consider expanding on the format of the AVP to make it someth=
ing like Session-ID, where it is a concatenation of the Diameter-ID of the =
generating node and a timestamp.  This might help the reacting node ke=
ep track of which sequence number it has received.


 




 


Do we need a uniqueness across multiple nodes property? If so, why?




Strictly speaking, no.  The thought was to make=
 it similar to session-id and potentially make it easier for the reacting n=
ode to keep differentiate sequence numbers from different reporting nodes.<=
br>







 


 




Steve


 


On 12/9/13 5:37 AM, Jouni Korhonen wrote:




Folks


 


Could we conclude on the sequence number vs. time stamp vs. something =
else?


We got more important places to spend our energy than this ;)


 


My proposal is the following (based on the original pre-00 design):


 


o We change the OC-Sequence-Number to OC-Time-Stamp in all occurrences=



  in the -01.


o We use RFC6733 Time type for the OC-Time-Stamp. RFC6733 gives us


  already exact definition how to handle the AVP.

o Define that the OC-Time-Stamp is the time of the creation of the 


  "original" AVP within whose context the time sta=
mp is present.


o The OC-Time-Stamp AVP uniqueness is still considered to be in scope<=
o:p>


  of the communicating endpoints.


o The time stamp can be used to quickly determine if the content of


  the encapsulating AVP context has changed (among other properti=
es).


  This would be useful specifically in the future when the encaps=
ulating


  grouped AVPs  grow in size and functionality.

 


 


- Jouni


 


_______________________________________________


DiME mailing list


 


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 


 


 




 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime




 


 


 




 






--_000_5BCBA1FC2B7F0B4C9D935572D90006681519E888DEMUMBX014nsnin_--

From ulrich.wiehe@nsn.com  Thu Dec 12 01:30:27 2013
Return-Path: 
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 69B7E1AE09D for ; Thu, 12 Dec 2013 01:30:27 -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 iYLX8FkVn8bP for ; Thu, 12 Dec 2013 01:30:18 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id F3F7E1AE208 for ; Thu, 12 Dec 2013 01:30:17 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rBC9UAj5003287 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 12 Dec 2013 10:30:10 +0100
Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rBC9U9EE020294 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Dec 2013 10:30:09 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.152]) by DEMUHTC004.nsn-intra.net ([10.159.42.35]) with mapi id 14.03.0123.003; Thu, 12 Dec 2013 10:30:09 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Steve Donovan , "dime@ietf.org" 
Thread-Topic: [Dime] OVLI: comments to 4.1
Thread-Index: Ac7xvTHHIECkLcDwSDuVAh2ACeOasAAprlMAAAaV6CAAlFJBAAADLijg///yiAD//+yxwIAAG3gA///jPWCAAV/bAP//0rCwAAujOgD//+gx4P//PIoA//3FKSD/+zWWgP/1DNgg
Date: Thu, 12 Dec 2013 09:30:09 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519E89B@DEMUMBX014.nsn-intra.net>
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DA3E@DEMUMBX014.nsn-intra.net> <6CDCFC84-3048-40B9-91A4-1451FCC65F60@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519DCE5@DEMUMBX014.nsn-intra.net> <09616DA2-D1ED-40EE-8E89-755DFCD81092@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E02B@DEMUMBX014.nsn-intra.net> <1A402C59-E390-4C95-8E30-97F1F9D3EF0F@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E05C@DEMUMBX014.nsn-intra.net> <790F1603-64D5-40E2-BC59-FD4C104EEF1B@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E0D9@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D90006681519E331@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D90006681519E3C4@DEMUMBX014.nsn-intra.net> <0CDBF4BB-4E38-41D6-A5E2-9218FFEFEA43@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E6EF@DEMUMBX014.nsn-intra.net> <52A869AD.6080305@usdonovans.com>
In-Reply-To: <52A869AD.6080305@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.106]
Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D90006681519E89BDEMUMBX014nsnin_"
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: 36270
X-purgate-ID: 151667::1386840610-00000661-36BF969C/0-0/0-0
Subject: Re: [Dime] OVLI: comments to 4.1
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Dec 2013 09:30:27 -0000

--_000_5BCBA1FC2B7F0B4C9D935572D90006681519E89BDEMUMBX014nsnin_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Steve,

do you mean " keep sequence number in OC-Supported-Features as an optional =
AVP that may be ignored by the receiver and need notbe included by the send=
er"?

Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Wednesday, December 11, 2013 2:34 PM
To: dime@ietf.org
Subject: Re: [Dime] OVLI: comments to 4.1

Ulrich,

My email showed how a reporting node could avoid the work of recalculating =
capability information on a message by message basis using the sequence num=
ber.  This approach does require maintaining state.

As Ben pointed out, it is also possible to not follow my logic and do as yo=
u propose by ignoring the sequence number and going through the work of cal=
culating the response every time.

Which approach to take is clearly an implementation decision.  We should ke=
ep the sequence number to allow for the stateful approach for implementatio=
ns that are willing to take advantage of maintaining state to avoid work.

Steve
On 12/11/13 1:34 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:

Jouni,



I do not agree.



My statement was general: reporting node may be server or SFA; supported fe=
atures may be defined features (default algo) or future extensions.



Ulrich



-----Original Message-----

From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Sent: Tuesday, December 10, 2013 10:46 PM

To: Wiehe, Ulrich (NSN - DE/Munich)

Cc: dime@ietf.org

Subject: Re: [Dime] OVLI: comments to 4.1



Ulrich,



On Dec 10, 2013, at 2:18 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:







-----Original Message-----

From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Sent: Tuesday, December 10, 2013 12:32 PM

To: Wiehe, Ulrich (NSN - DE/Munich)

Cc: dime@ietf.org

Subject: Re: [Dime] OVLI: comments to 4.1





On Dec 10, 2013, at 12:41 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:



Hi Jouni,



my understanding from Steve's clarification was that the reporting node wou=
ld setup and maintain a database of "states", one per reacting node where a=
 state of a reacting node is identified by a sequence number and the databa=
se entry would contain the pre-calculated OLR.

Hard to see how this is done without consuming resources.



It is mostly static information. Still I do not see how

you would get away without any state.

[Wiehe, Ulrich (NSN - DE/Munich)] There is no need for the reporting node t=
o store and maintain information per reacting node because the reacting nod=
e actually tells within the request message all information the reporting n=
ode needs to know. The reporting node simply fetches the pre-calculated OLR=
 that matches the supported features of the reacting node as indicated in t=
he request and appends it to the answer.



This could be true for the default algorithm in this spec. However,

given the extension mechanism we have in place it is quite possible

that the assumption does not hold for new features.



Also, if I were to implement a server front end agent that would

definitely need state and still ought to comply the protocol spec.



- Jouni









Furthermore,

Why would the reacting node be interested in config changes of the reportin=
g node?

Isn't it so that the reacting node is only interested in OLR changes?



Sigh.. say the traffic abatement algorithm changes or new features

get added. Those have more impact than just OLR change.



- Jouni





Ulrich



-----Original Message-----

From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Sent: Tuesday, December 10, 2013 9:41 AM

To: Wiehe, Ulrich (NSN - DE/Munich)

Cc: dime@ietf.org

Subject: Re: [Dime] OVLI: comments to 4.1





On Dec 9, 2013, at 4:43 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:



But maintaining a specific state per reacting node is very resource consumi=
ng for the (overloaded) reporting node. It is simpler and more efficient to=
 base any processing logic on actual information received in the request ra=
ther than on information stored from previous communication.



The "state" in a reporting node is merely the current configuration

and a counter for sequence number. Hard to me see that as resource

consuming function.



And the earlier comment of mine is done from reacting node point

of view, since it is more interested in the possible config changes

in the reporting node (e.g. S6a is stateless application, configuration

can change at any time).



- Jouni







Ulrich



-----Original Message-----

From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Sent: Monday, December 09, 2013 2:25 PM

To: Wiehe, Ulrich (NSN - DE/Munich)

Cc: dime@ietf.org

Subject: Re: [Dime] OVLI: comments to 4.1





On Dec 9, 2013, at 3:13 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:



There is a fundamental difference:

OLRs need to be stored, Feature-Vectors not.



How come feature vector does not need to be stored? I do not

get that? I would set my implementation to a specific state

or mode based on the feature vector. When that changes I'd

like to know that. And then keep functioning based on that.



- Jouni



When receiving an OLR you may want to know whether its worth the effort to =
replace an already stored OLR with the received OLR.

When receiving a Feature-Vector you just act on it.



Ulrich



-----Original Message-----

From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Sent: Monday, December 09, 2013 1:55 PM

To: Wiehe, Ulrich (NSN - DE/Munich)

Cc: dime@ietf.org

Subject: Re: [Dime] OVLI: comments to 4.1





In the same vein as folks wanted send OLRs with the new or old information,

the feature vector should behave in a same way IMHO. That implies there are

situations when a reception of the feature vector does not change anything

in an endpoint current behavior.



- Jouni



On Dec 9, 2013, at 2:47 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:



Isn't it so that the Feature-Vector (if present) always contains something =
that an implementation needs to act upon?



Ulrich



-----Original Message-----

From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Sent: Monday, December 09, 2013 1:12 PM

To: Wiehe, Ulrich (NSN - DE/Munich)

Cc: dime@ietf.org

Subject: Re: [Dime] OVLI: comments to 4.1



Ulrich,



On Dec 6, 2013, at 3:03 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:



Hi Jouni,



thank you for your response.



With regard to 3)

I still fail to see the usecase for Sequence-Number or TimeStamp within OC-=
Feature-Vector. Please clarify.



Since we also allow extending the OC-Feature-Vector beyond recognition,

it has good chances become a rather complex grouped AVP. In that context

the Sequence-Number allows an easy and quick way to check if the feature

vector contains something that an implementation needs to act upon.



With regard to 4)

This was not obvious to me. (The obvious typo is the missing "of" between "=
one" and "the").



Ack. Fixed the missing 'of'.



- Jouni





Best regards

Ulrich





-----Original Message-----

From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Sent: Friday, December 06, 2013 11:17 AM

To: Wiehe, Ulrich (NSN - DE/Munich)

Cc: dime@ietf.org

Subject: Re: [Dime] OVLI: comments to 4.1





On Dec 5, 2013, at 3:23 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:



Dear all,



here are comments to clause 4.1:



1. The OC-Feature-Vector AVP is no longer a vector; the name of the AVP may=
 be misleading. Proposal is to rename it to "OC-Supported-Features AVP"



OK with me.



2. The OC-Feature AVP is a vector of features. Proposal is to rename it to =
"OC-Feature-Vector AVP"



OK with me.



3. The OC-Sequence-Number within OC-Feature-Vector only makes sense if the =
receiving reporting endpoint can determine the identity of the reacting end=
point (which is not necessarily the origin host (client),



My original proposal was to have seqnr as a timestamp. Some folks argued

it is no good and suggested seqnr. I still think time makes more sense than

seqnr.



it may be an agent and it may not always be the same agent), and if the rep=
orting endpoint is required to store the OC-Feature-Vector / reacting-endpo=
int-identity pair (which I think both is not required). The reporting endpo=
int can base its processing logic on the actually received OC-Feature-Vecto=
r value, no matter whether it is brand-new or old but stil valid. Proposal =
is to delete OC-Sequence-Number AVP from OC-Feature-Vector.



Do not agree removing it.



4. The text



The reporting node that sends the answer also includes the OC-

Feature-Vector AVP that describe the capabilities it supports.  The

set of capabilities advertised by the reporting node depends on local

policies.  At least one the announced capabilities MUST match

mutually.  If there is no single matching capability the reacting

node MUST act as if it does not implement DOIC and cease inserting

any DOIC related AVPs into any Diameter messages with this specific

reacting node.



is not clear.  Would the reporting node include the OC-Feature-Vector AVP i=
n the answer only if there is at least one matching capability?



Because then they have found a way to exchange something that both ends

know how to handle it.



Mandating the reacting node to cease for all time inserting OC-Feature-Vect=
or AVPs if it did not get back



There is an obvious typo. It should say:



policies.  At least one the announced capabilities MUST match

mutually.  If there is no single matching capability the reporting

node MUST act as if it does not implement DOIC and cease inserting

any DOIC related AVPs into any Diameter messages with this specific

reacting node.



- JOuni





at least one match is also not ok. The request might have been a realm-type=
 request (i.e. without Destination Host) and the reacting node cannot contr=
ol whether subsequent requests will take the same path to the same reportin=
g node.

Even if the request contains a destination host the reacting node cannot kn=
ow wether the reacting node's capabilities have been modified by the time a=
 subsequent request is sent.

Proposal is to keep only the first sentence and delete the rest.



Ulrich





_______________________________________________

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




--_000_5BCBA1FC2B7F0B4C9D935572D90006681519E89BDEMUMBX014nsnin_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Steve,


 =
;


do you mea=
n „ keep sequence number in OC-Supported-Features as an optional AVP =
that may be ignored by the receiver and need notbe included by the
 sender”?


 =
;


Ulrich


 =
;






From:=
 DiME [mailto:dime-b=
ounces@ietf.org]
On Behalf Of ext Steve Donovan

Sent: Wednesday, December 11, 2013 2:34 PM

To: dime@ietf.org

Subject: Re: [Dime] OVLI: comments to 4.1






 


Ulrich,



My email showed how a reporting node could avoid the work of recalculating =
capability information on a message by message basis using the sequence num=
ber.  This approach does require maintaining state.



As Ben pointed out, it is also possible to not follow my logic and do as yo=
u propose by ignoring the sequence number and going through the work of cal=
culating the response every time. 




Which approach to take is clearly an implementation decision.  We shou=
ld keep the sequence number to allow for the stateful approach for implemen=
tations that are willing to take advantage of maintaining state to avoid wo=
rk.



Steve




On 12/11/13 1:34 AM, Wiehe, Ulrich (NSN - DE/Munich)=
 wrote:






Jouni,


 


I do not agree.


 


My statement was general: reporting node may be server or SFA; support=
ed features may be defined features (default algo) or future extensions.


 


Ulrich


 


-----Original Message-----


From: ext Jouni Korhonen [ma=
ilto:jouni.nospam@gmail.com] 


Sent: Tuesday, December 10, 2013 10:46 PM


To: Wiehe, Ulrich (NSN - DE/Munich)


Cc: dime@ietf.org

Subject: Re: [Dime] OVLI: comments to 4.1


 


Ulrich,


 


On Dec 10, 2013, at 2:18 PM, "Wiehe, Ulrich (NSN - DE/Munich)&quo=
t; <ulrich.wiehe@nsn.com>=
 wrote:


 




 


 


-----Original Message-----


From: ext Jouni Korhonen [ma=
ilto:jouni.nospam@gmail.com] 


Sent: Tuesday, December 10, 2013 12:32 PM


To: Wiehe, Ulrich (NSN - DE/Munich)


Cc: dime@ietf.org

Subject: Re: [Dime] OVLI: comments to 4.1


 


 


On Dec 10, 2013, at 12:41 PM, "Wiehe, Ulrich (NSN - DE/Munich)&qu=
ot; <ulrich.wiehe@nsn.com> wrote:


 




Hi Jouni,


 


my understanding from Steve's clarification was that the reporting nod=
e would setup and maintain a database of "states", one per reacti=
ng node where a state of a reacting node is identified by a sequence number=
 and the database entry would contain the pre-calculated OLR. 

Hard to see how this is done without consuming resources.



 


It is mostly static information. Still I do not see how

you would get away without any state.


[Wiehe, Ulrich (NSN - DE/Munich)] There is no need for the reporting n=
ode to store and maintain information per reacting node because the reactin=
g node actually tells within the request message all information the report=
ing node needs to know. The reporting node simply fetches the pre-calculate=
d OLR that matches the supported features of the reacting node as indicated=
 in the request and appends it to the answer.




 


This could be true for the default algorithm in this spec. However,


given the extension mechanism we have in place it is quite possible


that the assumption does not hold for new features.


 


Also, if I were to implement a server front end agent that would<=
/o:p>


definitely need state and still ought to comply the protocol spec.


 


- Jouni


 


 


 


 






Furthermore,


Why would the reacting node be interested in config changes of the rep=
orting node?


Isn't it so that the reacting node is only interested in OLR changes?<=
o:p>




 


Sigh.. say the traffic abatement algorithm changes or new features


get added. Those have more impact than just OLR change.

 


- Jouni


 




 


Ulrich


 


-----Original Message-----


From: ext Jouni Korhonen [ma=
ilto:jouni.nospam@gmail.com] 


Sent: Tuesday, December 10, 2013 9:41 AM


To: Wiehe, Ulrich (NSN - DE/Munich)


Cc: dime@ietf.org

Subject: Re: [Dime] OVLI: comments to 4.1


 


 


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


 




But maintaining a specific state per reacting node is very resource co=
nsuming for the (overloaded) reporting node. It is simpler and more efficie=
nt to base any processing logic on actual information received in the reque=
st rather than on information stored from previous communication.




 


The "state" in a reporting node is merely the current config=
uration


and a counter for sequence number. Hard to me see that as resource


consuming function.


 


And the earlier comment of mine is done from reacting node point<=
/o:p>


of view, since it is more interested in the possible config changes


in the reporting node (e.g. S6a is stateless application, configuratio=
n


can change at any time).


 


- Jouni


 


 




 


Ulrich


 


-----Original Message-----


From: ext Jouni Korhonen [ma=
ilto:jouni.nospam@gmail.com] 


Sent: Monday, December 09, 2013 2:25 PM


To: Wiehe, Ulrich (NSN - DE/Munich)


Cc: dime@ietf.org

Subject: Re: [Dime] OVLI: comments to 4.1


 


 


On Dec 9, 2013, at 3:13 PM, "Wiehe, Ulrich (NSN - DE/Munich)"=
; <ulrich.wiehe@nsn.com> =
wrote:


 




There is a fundamental difference:


OLRs need to be stored, Feature-Vectors not.




 


How come feature vector does not need to be stored? I do not


get that? I would set my implementation to a specific state=



or mode based on the feature vector. When that changes I'd<=
/pre>

like to know that. And then keep functioning based on that.=



 


- Jouni


 




When receiving an OLR you may want to know whether its worth the effor=
t to replace an already stored OLR with the received OLR.


When receiving a Feature-Vector you just act on it.


 


Ulrich 


 


-----Original Message-----


From: ext Jouni Korhonen [ma=
ilto:jouni.nospam@gmail.com] 


Sent: Monday, December 09, 2013 1:55 PM


To: Wiehe, Ulrich (NSN - DE/Munich)


Cc: dime@ietf.org

Subject: Re: [Dime] OVLI: comments to 4.1


 


 


In the same vein as folks wanted send OLRs with the new or old informa=
tion,


the feature vector should behave in a same way IMHO. That implies ther=
e are


situations when a reception of the feature vector does not change anyt=
hing


in an endpoint current behavior.


 


- Jouni


 


On Dec 9, 2013, at 2:47 PM, "Wiehe, Ulrich (NSN - DE/Munich)"=
; <ulrich.wiehe@nsn.com> =
wrote:


 




Isn't it so that the Feature-Vector (if present) always contains somet=
hing that an implementation needs to act upon?


 


Ulrich


 


-----Original Message-----


From: ext Jouni Korhonen [ma=
ilto:jouni.nospam@gmail.com] 


Sent: Monday, December 09, 2013 1:12 PM


To: Wiehe, Ulrich (NSN - DE/Munich)


Cc: dime@ietf.org

Subject: Re: [Dime] OVLI: comments to 4.1


 


Ulrich,


 


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


 




Hi Jouni,


 


thank you for your response.


 


With regard to 3) 


I still fail to see the usecase for Sequence-Number or TimeStamp withi=
n OC-Feature-Vector. Please clarify.




 


Since we also allow extending the OC-Feature-Vector beyond recognition=
, 


it has good chances become a rather complex grouped AVP. In that conte=
xt


the Sequence-Number allows an easy and quick way to check if the featu=
re


vector contains something that an implementation needs to act upon.


 




With regard to 4)


This was not obvious to me. (The obvious typo is the missing "of&=
quot; between "one" and "the").




 


Ack. Fixed the missing 'of'.


 


- Jouni


 




 


Best regards


Ulrich


 


 


-----Original Message-----


From: ext Jouni Korhonen [ma=
ilto:jouni.nospam@gmail.com] 


Sent: Friday, December 06, 2013 11:17 AM


To: Wiehe, Ulrich (NSN - DE/Munich)


Cc: dime@ietf.org

Subject: Re: [Dime] OVLI: comments to 4.1


 


 


On Dec 5, 2013, at 3:23 PM, "Wiehe, Ulrich (NSN - DE/Munich)"=
; <ulrich.wiehe@nsn.com> =
wrote:


 




Dear all,


 


here are comments to clause 4.1:


 


1. The OC-Feature-Vector AVP is no longer a vector; the name of the AV=
P may be misleading. Proposal is to rename it to "OC-Supported-Feature=
s AVP"




 


OK with me.


 




2. The OC-Feature AVP is a vector of features. Proposal is to rename i=
t to "OC-Feature-Vector AVP"




 


OK with me.


 




3. The OC-Sequence-Number within OC-Feature-Vector only makes sense if=
 the receiving reporting endpoint can determine the identity of the reactin=
g endpoint (which is not necessarily the origin host (client),



 


My original proposal was to have seqnr as a timestamp. Some folks argu=
ed


it is no good and suggested seqnr. I still think time makes more sense=
 than


seqnr.


 




it may be an agent and it may not always be the same agent), and if th=
e reporting endpoint is required to store the OC-Feature-Vector / reacting-=
endpoint-identity pair (which I think both is not required). The reporting =
endpoint can base its processing logic on the actually received OC-Feature-=
Vector value, no matter whether it is brand-new or old but stil valid. Prop=
osal is to delete OC-Sequence-Number AVP from OC-Feature-Vector.=





 


Do not agree removing it.


 




4. The text


 


The reporting node that sends the answer also includes the OC-


Feature-Vector AVP that describe the capabilities it supports.  T=
he


set of capabilities advertised by the reporting node depends on local<=
o:p>


policies.  At least one the announced capabilities MUST match


mutually.  If there is no single matching capability the reacting=



node MUST act as if it does not implement DOIC and cease inserting


any DOIC related AVPs into any Diameter messages with this specific


reacting node.


 


is not clear.  Would the reporting node include the OC-Feature-Ve=
ctor AVP in the answer only if there is at least one matching capability? <=
o:p>




 


Because then they have found a way to exchange something that both end=
s


know how to handle it.


 




Mandating the reacting node to cease for all time inserting OC-Feature=
-Vector AVPs if it did not get back 




 


There is an obvious typo. It should say:


 


policies.  At least one the announced capabilities MUST match


mutually.  If there is no single matching capability the reportin=
g


node MUST act as if it does not implement DOIC and cease inserting


any DOIC related AVPs into any Diameter messages with this specific


reacting node.


 


- JOuni


 


 




at least one match is also not ok. The request might have been a realm=
-type request (i.e. without Destination Host) and the reacting node cannot =
control whether subsequent requests will take the same path to the same rep=
orting node.


Even if the request contains a destination host the reacting node cann=
ot know wether the reacting node's capabilities have been modified by the t=
ime a subsequent request is sent. 


Proposal is to keep only the first sentence and delete the rest.<=
/o:p>


 


Ulrich


 


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime




 




 




 




 




 




 




 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 




 






--_000_5BCBA1FC2B7F0B4C9D935572D90006681519E89BDEMUMBX014nsnin_--

From ulrich.wiehe@nsn.com  Thu Dec 12 02:29:40 2013
Return-Path: 
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 C83CA1AE124 for ; Thu, 12 Dec 2013 02:29:40 -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 fkM4j84QjzqM for ; Thu, 12 Dec 2013 02:29:38 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 1920A1AE14E for ; Thu, 12 Dec 2013 02:29:37 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rBCATTmc029494 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 12 Dec 2013 11:29:29 +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 rBCATOGf030030 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Dec 2013 11:29:28 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.152]) by DEMUHTC001.nsn-intra.net ([10.159.42.32]) with mapi id 14.03.0123.003; Thu, 12 Dec 2013 11:29:24 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Maria Cruz Bartolome , "Jouni Korhonen" , Steve Donovan 
Thread-Topic: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments	to 4.3
Thread-Index: AQHO9pWZ7YfhbdfaPk+qdX0KkzOyj5pQVpIg
Date: Thu, 12 Dec 2013 10:29:23 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519E8D9@DEMUMBX014.nsn-intra.net>
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DB1B@DEMUMBX014.nsn-intra.net>  <52A5E902.20605@usdonovans.com> <7475B713-1104-4791-96B1-CE97632A0D69@nostrum.com>  <5BCBA1FC2B7F0B4C9D935572D90006681519E476@DEMUMBX014.nsn-intra.net> <1CD20507-B0FE-4367-804A-B831734CF060@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E6DC@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D90006681519E712@DEMUMBX014.nsn-intra.net> <4A151D70-0291-4238-85B1-03BB54B361E6@gmail.com> <52A864FF.10705@usdonovans.com> <23887553-5068-477A-AE34-3DC5E3D5AC76@gmail.com> <087A34937E64E74E848732CFF8354B920973A7D7@ESESSMB101.ericsson.se>
In-Reply-To: <087A34937E64E74E848732CFF8354B920973A7D7@ESESSMB101.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.104]
Content-Type: text/plain; charset="us-ascii"
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: 1882
X-purgate-ID: 151667::1386844169-00000661-142D943D/0-0/0-0
Cc: Ben Campbell , "dime@ietf.org list" 
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI:	comments	to 4.3
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Dec 2013 10:29:41 -0000

Jouni,

I dont find it acceptable to say "well, the concept of real-type OLRs has u=
nresolved issues; implementatios are expected to resolve those."
Also, there may be deployments where agent A1 has connections to Servers S1=
 and S2 but not S3, A2 has connections to S1 and S3 but not S2, A3 has conn=
ections to S1 and S3 but not S2.

Note there are still other open issue of realm type concept e.g. like parti=
tioned servers.


MCruz,
I'm afraid TimeStamp does not help. Even if the agents are 100% time synchr=
onized it is not guaranteed that all agents will go into the (same) overloa=
d state exactly at the same time. Also: with the deployment scenario outlin=
ed above different agents  may be in different overload states.

Ulrich


-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto=
lome
Sent: Wednesday, December 11, 2013 6:22 PM
To: Jouni Korhonen; Steve Donovan
Cc: Ben Campbell; dime@ietf.org list
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comment=
s to 4.3

Dear all,

> [Steve] Ulrich does bring up an interesting use case, where a client is r=
eceiving realm reports for the same realm from different agents.  We need t=
o define the clients behavior in this case. =20

[Jouni] Could we simply say that in this case the agents (or who ever inser=
ts the realm report) MUST share the same view of the realm overload conditi=
on? Obviously how it is achieved would be implementation specific. I recall=
 we have surfaced this topic earlier..

[MCruz] But... isn't simpler to use time instead of sequence? It would solv=
e this case as long as any number of agents serving same realm are time syn=
chronized. =20

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

From jouni.nospam@gmail.com  Thu Dec 12 02:58:19 2013
Return-Path: 
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 21ACF1ACCDC for ; Thu, 12 Dec 2013 02:58:19 -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 n-m0MD9i1yay for ; Thu, 12 Dec 2013 02:58:17 -0800 (PST)
Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id A9C9A1AE087 for ; Thu, 12 Dec 2013 02:58:16 -0800 (PST)
Received: by mail-la0-f48.google.com with SMTP id n7so170447lam.7 for ; Thu, 12 Dec 2013 02:58:09 -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=i3VoWj4aljehsq+oV06nrqjylKI9lD8LDXutkRSXol8=; b=vfo25oUgtK7tknVen73kTcyk+cy6Kz7J+ZHgSWQiQVQzLNYwbtedx8oMxxNWupehfh dicZcI9AwwtQATjGGcjwFKGwf+g3gj2d8O/f9xn4Ref+r5eYp1goh95DYcccFmzULrHO CQsC+bvH6EcSuUDi2IZ/3JF8Y8wtMJ6APT7loxddtXicfy2JbeVjO0+htXEEr90mrzvK LFa79ZMRq3lDVQLPKsUAu4V9PXDDcMj5v/ZAS8WArRqdr3nwjOJco/DpD4wO0kkLxuXN O/v35mT6a8aLzRkQnWxA1ONDSZSvkZfvtm6n+AoP/Tl2tSVo4ywOcPyLayQsHfZ/lOQ0 q6hQ==
X-Received: by 10.152.180.228 with SMTP id dr4mr3402935lac.32.1386845889782; Thu, 12 Dec 2013 02:58:09 -0800 (PST)
Received: from [192.168.250.53] ([194.100.71.98]) by mx.google.com with ESMTPSA id a8sm34007195lae.5.2013.12.12.02.58.05 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Dec 2013 02:58:06 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jouni Korhonen 
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681519E8D9@DEMUMBX014.nsn-intra.net>
Date: Thu, 12 Dec 2013 12:58:05 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <4A51393B-7AC4-4185-BA29-93801F6811D0@gmail.com>
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DB1B@DEMUMBX014.nsn-intra.net>  <52A5E902.20605@usdonovans.com> <7475B713-1104-4791-96B1-CE97632A0D69@nostrum.com>  <5BCBA1FC2B7F0B4C9D935572D90006681519E476@DEMUMBX014.nsn-intra.net> <1CD20507-B0FE-4367-804A-B831734CF060@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E6DC@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D90006681519E712@DEMUMBX014.nsn-intra.net> <4A151D70-0291-4238-85B1-03BB54B361E6@gmail.com> <52A864FF.10705@usdonovans.com> <23887553-5068-477A-AE34-3DC5E3D5AC76@gmail.com> <087A34937E64E74E848732CFF8354B920973A7D7@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D90006681519E8D9@DEMUMBX014.nsn-intra.net>
To: "Wiehe, Ulrich (NSN - DE/Munich)" 
X-Mailer: Apple Mail (2.1510)
Cc: Ben Campbell , "dime@ietf.org list" 
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI:	comments to 4.3
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Dec 2013 10:58:19 -0000

Ulrich,

On Dec 12, 2013, at 12:29 PM, "Wiehe, Ulrich (NSN - DE/Munich)" =
 wrote:

> Jouni,
>=20
> I dont find it acceptable to say "well, the concept of real-type OLRs =
has unresolved issues; implementatios are expected to resolve those."

If you need synchronisation for one thing.. then you achieve it
somehow. Just like in you example how you would keep realm reports
in sync between agents? It is equivalent issue unless you are fine
with conflicting reports..

It is not necessarily our job to define how some things at the=20
deployment level are achieved. We already made rather rough=20
assumptions how front ends and such work.


> Also, there may be deployments where agent A1 has connections to =
Servers S1 and S2 but not S3, A2 has connections to S1 and S3 but not =
S2, A3 has connections to S1 and S3 but not S2.

So? How would that change the situation? The realm status should=20
be the same for all reports representing the same realm.

> Note there are still other open issue of realm type concept e.g. like =
partitioned servers.
>=20
>=20
> MCruz,
> I'm afraid TimeStamp does not help. Even if the agents are 100% time =
synchronized it is not guaranteed that all agents will go into the =
(same) overload state exactly at the same time. Also: with the =
deployment scenario outlined above different agents  may be in different =
overload states.

So now you are saying that it would be acceptable that multiple
sources (agents) from the same realm tell different truth about
the realm state to the reacting node? I would find that somewhat=20
unacceptable assumption.

- Jouni



>=20
> Ulrich
>=20
>=20
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz =
Bartolome
> Sent: Wednesday, December 11, 2013 6:22 PM
> To: Jouni Korhonen; Steve Donovan
> Cc: Ben Campbell; dime@ietf.org list
> Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: =
comments to 4.3
>=20
> Dear all,
>=20
>> [Steve] Ulrich does bring up an interesting use case, where a client =
is receiving realm reports for the same realm from different agents.  We =
need to define the clients behavior in this case. =20
>=20
> [Jouni] Could we simply say that in this case the agents (or who ever =
inserts the realm report) MUST share the same view of the realm overload =
condition? Obviously how it is achieved would be implementation =
specific. I recall we have surfaced this topic earlier..
>=20
> [MCruz] But... isn't simpler to use time instead of sequence? It would =
solve this case as long as any number of agents serving same realm are =
time synchronized. =20
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From ulrich.wiehe@nsn.com  Thu Dec 12 03:17:48 2013
Return-Path: 
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 6C7DB1A1F19 for ; Thu, 12 Dec 2013 03:17:48 -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 VBnZvVWt658p for ; Thu, 12 Dec 2013 03:17:38 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id C44491AE0D5 for ; Thu, 12 Dec 2013 03:17:36 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rBCBHTYe032029 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 12 Dec 2013 12:17:29 +0100
Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rBCBHTJx013922 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Dec 2013 12:17:29 +0100
Received: from DEMUHTC012.nsn-intra.net (10.159.42.43) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 12 Dec 2013 12:17:28 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.152]) by DEMUHTC012.nsn-intra.net ([10.159.42.43]) with mapi id 14.03.0123.003; Thu, 12 Dec 2013 12:17:28 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Steve Donovan , "dime@ietf.org" 
Thread-Topic: [Dime] DOIC: Self-Contained OLRs
Thread-Index: AQHO67/t2PaAGa/GgUyaCwjRxXVUh5o5m/0AgAC8o/D///ghgIAAFu+wgBFDRACAABmHcIAA+40AgACAkLCAAUpWAIAAdj+AgAF3KaA=
Date: Thu, 12 Dec 2013 11:17:27 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519E931@DEMUMBX014.nsn-intra.net>
References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com>  <5BCBA1FC2B7F0B4C9D935572D90006681519BC90@DEMUMBX014.nsn-intra.net> <6390_1385631044_52970D44_6390_18593_1_6B7134B31289DC4FAF731D844122B36E30748E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BD19@DEMUMBX014.nsn-intra.net> <26C84DFD55BC3040A45BF70926E55F2587C1D028@SZXEMA512-MBX.china.huawei.com> <5BCBA1FC2B7F0B4C9D935572D90006681519DFC0@DEMUMBX014.nsn-intra.net> <26C84DFD55BC3040A45BF70926E55F2587C1D705@SZXEMA512-MBX.china.huawei.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E2DE@DEMUMBX014.nsn-intra.net> <26C84DFD55BC3040A45BF70926E55F2587C1DC24@SZXEMA512-MBX.china.huawei.com> <52A86839.4010103@usdonovans.com>
In-Reply-To: <52A86839.4010103@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.104]
Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D90006681519E931DEMUMBX014nsnin_"
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: 47532
X-purgate-ID: 151667::1386847050-00000661-0C7AF83E/0-0/0-0
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Dec 2013 11:17:48 -0000

--_000_5BCBA1FC2B7F0B4C9D935572D90006681519E931DEMUMBX014nsnin_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Steve,

Isn't it so that the agent may decide (e.g. based on the absence of Destina=
tion host in the received request and based of its ability/willingness to s=
elect the server)
either a) to take the role of an endpoint or b) to be transparent with rega=
rd to OC AVPs.
In case a) we end up with two DOIC associations, one between client and age=
nt, another one between agent and server. Different DOIC associations may h=
ave different advertised/negotiated features i.e. agent and server may use =
window algorithm, but client and agent use loss algorithm. Therefore the ho=
st-type window OLR must not be sent unchanged to the client.
In case b) being transparent includes not inserting realm-type AVPs.

We end up with receiving not more than one OLR at the client.

Ulrich




From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Wednesday, December 11, 2013 2:27 PM
To: dime@ietf.org
Subject: Re: [Dime] DOIC: Self-Contained OLRs

Susan,

The use case for an agent that sits between a DOIC client and a DOIC server=
 is Realm overload, which the agent might be responsible for reporting.  Th=
is will particularly be the case when there are multiple servers sitting be=
hind the agent.  This might be considered a server farm, as you indicate, b=
ut we don't have a good definition of server farm, so I'm being explicit.

In this case, the agent must handle to types of occurrences.

1) Server overload - In this case the agent will receive a node overload re=
port from the server.  The agent should (I'm not sure if we have defined th=
is behavior in the draft yet) send the report unchanged to the client.  The=
 agent will also most likely use the contents of the report to determine th=
e realm overload state.

2) Realm overload - In this case the agent will insert an overload report i=
nto the appropriate answer messages.

Is this consistent with your thinking?

Regards,

Steve
On 12/11/13 12:24 AM, Shishufeng (Susan) wrote:

Hi Ulrich,



I'm not sure if you are taking the overload of agent into account for which=
 we decided to not consider for the time being. If not, I couldn't understa=
nd why an agent which does not serve for a server farm needs to be a DOIC e=
ndpoint between the client and server if both of them support overload cont=
rol. My understanding is that if there is the need for an agent to take a r=
ole of a DOIC endpoint between a specific server and client, it would alway=
s do that, otherwise, it just transfer the overload information of the serv=
er to the client.



Best Regards,

Susan



-----Original Message-----

From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]

Sent: Tuesday, December 10, 2013 6:15 PM

To: Shishufeng (Susan); ext lionel.morand@orange.com; ext Jouni Korhonen; Ben Campbell

Cc: dime@ietf.org list

Subject: RE: [Dime] DOIC: Self-Contained OLRs



Hi Susan,



if the agent does not take the role of a DOIC endpont then the feature nego=
tiation/adverisement is between client and server and one host type OLR is =
sent from server to client. For the agent this is all transparent and there=
 is no need for the agent to support any DOIC feature.

However, if the agent takes the role of an DOIC endpoint then the feature n=
egotiation/advertisement is between client and agent and a separate feature=
 negotiation/advertisement is between agent and server. An OLR sent from se=
rver to agent is in-context with the supported features of server and agent=
 but possibly not in-context with supported features of client and agent an=
d therefore must not be (blindly) sent to the client. And in fact there is =
also no need to do that. For subsequent requests that contain the desinatio=
n host of the server, the agent will not take the role of a DOIC endpoint.



Best regards

Ulrich



-----Original Message-----

From: ext Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]

Sent: Tuesday, December 10, 2013 4:02 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



Hi Ulrich,



Thanks for your clarification. I understood the scenario, while from my poi=
nt of view, if the agent that selects the HSS is not configured to serve as=
 a load balancer for the HSS, the agent should not change any supported/neg=
otiated features between C and S, that would be the normal case. If the age=
nt serve as a load balancer for the HSS, the subsequent request from C towa=
rds the S would always go via the agent, in this case whatever the associat=
ions between C and A, between A and S are the same or not, it doesn't matte=
r. With an E2E solution as we agreed, I don't see the problem with it.



Best Regards,

Susan



-----Original Message-----

From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]

Sent: Monday, December 09, 2013 7:43 PM

To: Shishufeng (Susan); ext lionel.morand@orange.com; ext Jouni Korhonen; Ben Campbell

Cc: dime@ietf.org list

Subject: RE: [Dime] DOIC: Self-Contained OLRs



Hi Susan,



let me come back to your S6a example.



The MME (C) sends a request without Destination-Host towards the HPLMN (rea=
lm). There must be an agent (A) in the HPLMN (realm) that selects the HSS (=
S).

We would have two distinct DOIC associations: one between C and A, another =
between A and S (see figure 5 in clause 5.1). The two DOIC associations may=
 have different supported/negotiated features. An OLR sent from S to A base=
d on supported/negotiated features valid for the DOIC association between A=
 and S is at least problematic (out-of context) when sent from A to C.



When the MME (C) sends a subsequent request with Destination-Host towards t=
he HSS (S), there is no agent that selects the HSS (as the HSS is already s=
elected). For this session there is only one DOIC association between C and=
 S (see figure 3 in clause 5.1) and OLRs sent from S to C are not problemat=
ic.



Best regards

Ulrich





-----Original Message-----

From: ext Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]

Sent: Monday, December 09, 2013 11:30 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



Hi Ulrich,



I have different views. In any case, I think the host-type OLR should not b=
e ignored by the clients. On the contrary, the realm-type OLR can be though=
t as optimization, which may not even be needed at all for all cases, espec=
ially in 3GPP. Here is an example of S6a, in the case the first attach requ=
est comes from the UE to the MME, the MME can only derive the realm informa=
tion, and sends a request without Destination-Host towards the HPLMN. Since=
 the subscriber corresponding to the UE belongs to a specific HSS, and the =
HSS may provide its overload report to the MME, and the MME is able to know=
 how to react regarding the requests towards the HSS, which would be the no=
rmal case. Whether Realm report will be provided by the HSS or the agent se=
rving the HSS is kind of optimization which may help the MME to know how to=
 react on the requests towards the realm, not specific to the HSS.



Best Regards,

Susan



-----Original Message-----

From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]

Sent: Thursday, November 28, 2013 6:30 PM

To: ext lionel.morand@orange.com; ext Joun=
i Korhonen; Ben Campbell

Cc: dime@ietf.org list

Subject: 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 act=
ual OLR created by the reporting end point and which OLR is an additional O=
LR created by another node.



We have two cases:

a) The request sent by the client (reacting end point) contains no Destinat=
ion Host. The agent (reporting node) (after forwarding the request to the s=
elected server and receiving the answer) returns a realm-type OLR as the ac=
tual 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 Destinat=
ion 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 stat=
us. It could be provided an agent inserting this info in answers received f=
rom a server behind but also from a server that would know this info by som=
e internal magic.

But in any case, if we assume that the client will received a successful an=
swer from the server for an initial request with only Dest-Realm AVP, it sh=
ould be possible to have both report types in the answer: one for the serve=
r itself, one for the realm for new request sent to the realm with only Des=
t-Realm AVP.



Lionel



-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN -=
 DE/Munich) Envoy=E9 : jeudi 28 novembre 2013 10:26 =C0 : ext Jouni Korhone=
n; 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 a=
ligned with the "endpoint principle". If the ReportType is "realm" this ind=
icates 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  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 endpoin=
ts, the more it makes sense to me to keep the ReportType in the OC-OLR. Eve=
n if the baseline does not have agent overload etc, the ReportType fits wel=
l to the "endpoint principle" we have in the draft. It indeed gives more to=
ols to make a host vs. realm base decision on the reacting node and is plai=
n 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 Diamet=
er request that corresponds to the answer containing the OLR. My reasons fo=
r 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 i=
dentified by Origin-Realm, and so on. This means that the "meaning" of an O=
LR 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 answe=
r to another, it's meaning may change completely.



I think this approach is a mistake. I would greatly prefer that we explicit=
ly 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 variou=
s other AVPs to find all the information it needs. For example, I think a c=
ommon software design for overload control processing to be separated from =
application processing. The consumer cannot simply hand the OLR to that mod=
ule and expect things to work. The OC module must not only parse the OLR, b=
ut parse any other AVPs that are relevant. As OLR contents get extended (as=
sumedly following the same strategy as the base spec), the number of "conte=
xt" avps that must be interpreted can grow large. This approach is error pr=
one, and will likely encourage brittle, hard-to-maintain code. Self-contain=
ed OLRs would keep all the information related to overload in one place. ma=
king for simpler implementations.



2) It's more complex for the reporting node to send implicit values than ex=
plicit values. The sender cannot simply set the context to match the OLR--a=
ll those other AVPs have application or protocol layer meanings. Once a rep=
orting node realizes that it is overloade, it has to wait for the right ans=
wer that contains the right context before it can send the OLR. This is par=
ticularly 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 sig=
nificantly. 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 so=
me 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 overlo=
ad reports were self-contained, one could just reuse the report format we s=
pecify here. But if the meaning of an OLR depends on the way it's transport=
ed, this won't work. We would have to create a new or significantly modifie=
d OLR format if we found a need to transport OLRs in different ways. Self-c=
ontained OLRs would allow much greater flexibility.



So, in summary, I think that self-contained OLRs would lead to simpler impl=
ementations, less brittle deployments, and more flexibility for future evol=
ution 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 confiden=
tielles 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. Le=
s messages electroniques etant susceptibles d'alteration, Orange decline to=
ute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged inf=
ormation 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 dele=
te 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




--_000_5BCBA1FC2B7F0B4C9D935572D90006681519E931DEMUMBX014nsnin_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Steve,<=
/p>

 <=
/p>

Isn’=
t it so that the agent may decide (e.g. based on the absence of Destination=
 host in the received request and based of its ability/willingness
 to select the server)


either a) =
to take the role of an endpoint or b) to be transparent with regard to OC A=
VPs.


In case a)=
 we end up with two DOIC associations, one between client and agent, anothe=
r one between agent and server. Different DOIC associations
 may have different advertised/negotiated features i.e. agent and server ma=
y use window algorithm, but client and agent use loss algorithm. Therefore =
the host-type window OLR must not be sent unchanged to the client.


In case b)=
 being transparent includes not inserting realm-type AVPs.


 =
;


We end up =
with receiving not more than one OLR at the client.


 =
;


Ulrich


 =
;


 =
;


 =
;




 =
;






From:=
 DiME [mailto:dime-b=
ounces@ietf.org]
On Behalf Of ext Steve Donovan

Sent: Wednesday, December 11, 2013 2:27 PM

To: dime@ietf.org

Subject: Re: [Dime] DOIC: Self-Contained OLRs






 


Susan,



The use case for an agent that sits between a DOIC client and a DOIC server=
 is Realm overload, which the agent might be responsible for reporting.&nbs=
p; This will particularly be the case when there are multiple servers sitti=
ng behind the agent.  This might be considered
 a server farm, as you indicate, but we don't have a good definition of ser=
ver farm, so I'm being explicit.



In this case, the agent must handle to types of occurrences.  



1) Server overload - In this case the agent will receive a node overload re=
port from the server.  The agent should (I'm not sure if we have defin=
ed this behavior in the draft yet) send the report unchanged to the client.=
  The agent will also most likely use
 the contents of the report to determine the realm overload state.



2) Realm overload - In this case the agent will insert an overload report i=
nto the appropriate answer messages.



Is this consistent with your thinking?



Regards,



Steve




On 12/11/13 12:24 AM, Shishufeng (Susan) wrote:=







Hi Ulrich,


 


I'm not sure if you are taking the overload of agent into account for =
which we decided to not consider for the time being. If not, I couldn't und=
erstand why an agent which does not serve for a server farm needs to be a D=
OIC endpoint between the client and server if both of them support overload=
 control. My understanding is that if there is the need for an agent to tak=
e a role of a DOIC endpoint between a specific server and client, it would =
always do that, otherwise, it just transfer the overload information of the=
 server to the client.


 


Best Regards,


Susan


 


-----Original Message-----


From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] 


Sent: Tuesday, December 10, 2013 6:15 PM


To: Shishufeng (Susan); ext lionel.morand@orange.com; ext Jouni Korhonen; Ben Campbell=



Cc: dime@ietf.org list=



Subject: RE: [Dime] DOIC: Self-Contained OLRs


 


Hi Susan,


 


if the agent does not take the role of a DOIC endpont then the feature=
 negotiation/adverisement is between client and server and one host type OL=
R is sent from server to client. For the agent this is all transparent and =
there is no need for the agent to support any DOIC feature.

However, if the agent takes the role of an DOIC endpoint then the feat=
ure negotiation/advertisement is between client and agent and a separate fe=
ature negotiation/advertisement is between agent and server. An OLR sent fr=
om server to agent is in-context with the supported features of server and =
agent but possibly not in-context with supported features of client and age=
nt and therefore must not be (blindly) sent to the client. And in fact ther=
e is also no need to do that. For subsequent requests that contain the desi=
nation host of the server, the agent will not take the role of a DOIC endpo=
int.


 


Best regards


Ulrich


 


-----Original Message-----


From: ext Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]


Sent: Tuesday, December 10, 2013 4:02 AM


To: Wiehe, Ulrich (NSN - DE/Munich); ext lionel.morand@orange.com; ext Jouni Korhonen; Ben Campbe=
ll


Cc: dime@ietf.org list=



Subject: RE: [Dime] DOIC: Self-Contained OLRs


 


Hi Ulrich,


 


Thanks for your clarification. I understood the scenario, while from m=
y point of view, if the agent that selects the HSS is not configured to ser=
ve as a load balancer for the HSS, the agent should not change any supporte=
d/negotiated features between C and S, that would be the normal case. If th=
e agent serve as a load balancer for the HSS, the subsequent request from C=
 towards the S would always go via the agent, in this case whatever the ass=
ociations between C and A, between A and S are the same or not, it doesn't =
matter. With an E2E solution as we agreed, I don't see the problem with it.=



 


Best Regards,


Susan


 


-----Original Message-----


From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]


Sent: Monday, December 09, 2013 7:43 PM


To: Shishufeng (Susan); ext lionel.morand@orange.com; ext Jouni Korhonen; Ben Campbell=



Cc: dime@ietf.org list=



Subject: RE: [Dime] DOIC: Self-Contained OLRs


 


Hi Susan,


 


let me come back to your S6a example.


 


The MME (C) sends a request without Destination-Host towards the HPLMN=
 (realm). There must be an agent (A) in the HPLMN (realm) that selects the =
HSS (S). 


We would have two distinct DOIC associations: one between C and A, ano=
ther between A and S (see figure 5 in clause 5.1). The two DOIC association=
s may have different supported/negotiated features. An OLR sent from S to A=
 based on supported/negotiated features valid for the DOIC association betw=
een A and S is at least problematic (out-of context) when sent from A to C.=



 


When the MME (C) sends a subsequent request with Destination-Host towa=
rds the HSS (S), there is no agent that selects the HSS (as the HSS is alre=
ady selected). For this session there is only one DOIC association between =
C and S (see figure 3 in clause 5.1) and OLRs sent from S to C are not prob=
lematic.


 


Best regards


Ulrich


 


 


-----Original Message-----


From: ext Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]


Sent: Monday, December 09, 2013 11:30 AM


To: Wiehe, Ulrich (NSN - DE/Munich); ext lionel.morand@orange.com; ext Jouni Korhonen; Ben Campbe=
ll


Cc: dime@ietf.org list=



Subject: RE: [Dime] DOIC: Self-Contained OLRs


 


Hi Ulrich,


 


I have different views. In any case, I think the host-type OLR should =
not be ignored by the clients. On the contrary, the realm-type OLR can be t=
hought as optimization, which may not even be needed at all for all cases, =
especially in 3GPP. Here is an example of S6a, in the case the first attach=
 request comes from the UE to the MME, the MME can only derive the realm in=
formation, and sends a request without Destination-Host towards the HPLMN. =
Since the subscriber corresponding to the UE belongs to a specific HSS, and=
 the HSS may provide its overload report to the MME, and the MME is able to=
 know how to react regarding the requests towards the HSS, which would be t=
he normal case. Whether Realm report will be provided by the HSS or the age=
nt serving the HSS is kind of optimization which may help the MME to know h=
ow to react on the requests towards the realm, not specific to the HSS.


 


Best Regards,


Susan


 


-----Original Message-----


From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]


Sent: Thursday, November 28, 2013 6:30 PM


To: ext lionel.morand@oran=
ge.com; ext Jouni Korhonen; Ben Campbell


Cc: dime@ietf.org list=



Subject: 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 th=
e actual OLR created by the reporting end point and which OLR is an additio=
nal OLR created by another node.


 


We have two cases:


a) The request sent by the client (reacting end point) contains no Des=
tination Host. The agent (reporting node) (after forwarding the request to =
the selected server and receiving the answer) returns a realm-type OLR as t=
he actual reporting-node-created OLR and optionally in addition a host-type=
 OLR as learned from the selected server.  The client may ignore the a=
dditional OLR.


b) The request sent by the client (reacting endpoint) contains the Des=
tination Host. The Server (reporting node) returns a host-type OLR as the a=
ctual reporting-node-created OLR in the answer. The agent may optionally in=
sert a realm-type OLR as additional OLR to the answer. The client may ignor=
e the additional OLR.


 


Ulrich


 


 


 


-----Original Message-----


From: ext lionel.morand@or=
ange.com [mailto:lionel.mor=
and@orange.com]


Sent: Thursday, November 28, 2013 10:31 AM


To: Wiehe, Ulrich (NSN - DE/Munich); ext Jouni Korhonen; Ben Campbell<=
o:p>


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 recei=
ved from a server behind but also from a server that would know this info b=
y some internal magic.


But in any case, if we assume that the client will received a successf=
ul 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 onl=
y Dest-Realm AVP.


 


Lionel


 


-----Message d'origine-----


De : DiME [mailto:dime-b=
ounces@ietf.org] De la part de Wiehe, Ulrich (NSN - DE/Munich) Envoy=E9=
 : jeudi 28 novembre 2013 10:26 =C0 : ext Jouni Korhonen; Ben Cam=
pbell Cc : dime@ietf.org list Obj=
et : 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 &=
quot;realm" this indicates to the reacting end point that the reportin=
g 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 repor=
ting end point is a server. How can the reporting end point be both agent a=
nd server?


 


Ulrich


 


-----Original Message-----


From: DiME [mailto:dime-bounc=
es@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 <=
/o:p>


ReportType AVP in an OLR, rather than




 


The more I spent time thinking/writing the actual procedures on the en=
dpoints, 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 fit=
s well to the "endpoint principle" we have in the draft. It indee=
d gives more tools to make a host vs. realm base decision on the reacting n=
ode 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 D=
iameter request that corresponds to the answer containing the OLR. My reaso=
ns 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 applica=
tion identified by the Application-Id field of the enclosing answer, the re=
alm identified by Origin-Realm, and so on. This means that the "meanin=
g" of an OLR cannot be determined from the OLR contents alone; OLRs on=
ly 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 exp=
licitly include such values in the OLR itself, for multiple reasons:


 


1) It's more complex to interpret implicit, contextual values than exp=
licit values. The consumer cannot simply look at the OLR; it must look in v=
arious other AVPs to find all the information it needs. For example, I thin=
k a common software design for overload control processing to be separated =
from application processing. The consumer cannot simply hand the OLR to tha=
t module and expect things to work. The OC module must not only parse the O=
LR, but parse any other AVPs that are relevant. As OLR contents get extende=
d (assumedly following the same strategy as the base spec), the number of &=
quot;context" avps that must be interpreted can grow large. This appro=
ach is error prone, and will likely encourage brittle, hard-to-maintain cod=
e. Self-contained OLRs would keep all the information related to overload i=
n one place. making for simpler implementations.


 


2) It's more complex for the reporting node to send implicit values th=
an explicit values. The sender cannot simply set the context to match the O=
LR--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 righ=
t answer that contains the right context before it can send the OLR. This i=
s particularly troublesome for agents, since they will typically have to in=
sert OLRs into answers created by other nodes. 


 


If the reporting node screws this up, the meaning of the OLR may chang=
e significantly. So again, implicit meaning gives us error prone implementa=
tions. 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.<=
o:p>


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 <=
o:p>


are distinct from those sent by a server, see Steve's agent overload <=
o:p>


draft, or my dh/dr example.)


 


OTOH, explicit values will work for all cases where we need to associa=
te some arbitrary value with an OLR.


 


4) Implicit values seriously constrain the future evolution of Diamete=
r OC standards. For example, lets say we find a good reason to allow OLRs t=
o be sent out of band, or be sent in a dedicated Diameter application. If o=
verload 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 tran=
sported, this won't work. We would have to create a new or significantly mo=
dified OLR format if we found a need to transport OLRs in different ways. S=
elf-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.iet=
f.org/mailman/listinfo/dime




 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 


______________________________________________________________________=
___________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploite=
s ou copies sans autorisation. Si vous avez recu ce message par erreur, veu=
illez le signaler a l'expediteur et le detruire ainsi que les pieces jointe=
s. Les messages electroniques etant susceptibles d'alteration, Orange decli=
ne toute responsabilite si ce message a ete altere, deforme ou falsifie. Me=
rci.


 


This message and its attachments may contain confidential or privilege=
d 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.iet=
f.org/mailman/listinfo/dime


 




 






--_000_5BCBA1FC2B7F0B4C9D935572D90006681519E931DEMUMBX014nsnin_--


From jouni.nospam@gmail.com  Thu Dec 12 03:36:31 2013
Return-Path: 
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 559031A1F48 for ; Thu, 12 Dec 2013 03:36:31 -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 bRgaxYb1o7PL for ; Thu, 12 Dec 2013 03:36:28 -0800 (PST)
Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 6E0B11A1F3E for ; Thu, 12 Dec 2013 03:36:27 -0800 (PST)
Received: by mail-la0-f51.google.com with SMTP id ec20so207476lab.10 for ; Thu, 12 Dec 2013 03:36:20 -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=Mv+U7rqi9u5LwRpohCqTwosGmrDeh2xa+KyXHYKNl78=; b=suRzA+UolWxkpowAMVuUSk8XCCn8oIlpaYWBaZf+4r9pnZTFRJ4TQEGvDEI/uIeatJ 3FKj7F4fHkvSaP9RkHinjoRod43beStRsq63pQEqogx7P0cB633ilqwrOtKbh/0WsB3E gg1mDX49xXLIHxK+tqD36jYd/BCSjOmEI+472UVEe0GBS+LX8UJR8w0mepP+8M3a9ui+ 89QsRXrfvcLnRht05yIVXpBD50tVD1yNkLcx7KnixunA/xYaQpBdDI0zwaObcTjx3Jc9 Xs9tTKmfUC1YAzn7LOMTSXze/hls4p0il+Za4GWboFm8l69KkmFFors+bbYjTORdBlsA ga1w==
X-Received: by 10.152.28.230 with SMTP id e6mr3410000lah.3.1386848180547; Thu, 12 Dec 2013 03:36:20 -0800 (PST)
Received: from [192.168.250.53] ([194.100.71.98]) by mx.google.com with ESMTPSA id c8sm34203127lag.3.2013.12.12.03.36.19 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Dec 2013 03:36:19 -0800 (PST)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jouni Korhonen 
In-Reply-To: <52A864FF.10705@usdonovans.com>
Date: Thu, 12 Dec 2013 13:36:18 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DB1B@DEMUMBX014.nsn-intra.net>  <52A5E902.20605@usdonovans.com> <7475B713-1104-4791-96B1-CE97632A0D69@nostrum.com>  <5BCBA1FC2B7F0B4C9D935572D90006681519E476@DEMUMBX014.nsn-intra.net> <1CD20507-B0FE-4367-804A-B831734CF060@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E6DC@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D90006681519E712@DEMUMBX014.nsn-intra.net> <4A151D70-0291-4238-85B1-03BB54B361E6@gmail.com> <52A864FF.10705@usdonovans.com>
To: Steve Donovan 
X-Mailer: Apple Mail (2.1510)
Cc: Ben Campbell , "dime@ietf.org list" 
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Dec 2013 11:36:31 -0000

Steve,

On Dec 11, 2013, at 3:13 PM, Steve Donovan  =
wrote:

> Jouni,
>=20
> We need the sequence number to be strictly increasing.  I don't see =
the need for it to increase in uniform amounts.  Using time does fit =
these requirements.  I'm ok with using time as long as we don't call the =
AVP timestamp.
>=20
> Ulrich does bring up an interesting use case, where a client is =
receiving realm reports for the same realm from different agents.  We =
need to define the clients behavior in this case. =20

Any suggestions? I mean agents may have hugely different view of the
realm if they are acting on their own.

> Presumably the client needs to be able to determine who generated the =
realm report.  This cannot be determine based on the content of the =
message or the connection on which the message arrived.  It seems like =
we might need "Report Generator Diameter ID" in the overload report =
specifically for Realm reports. =20
>=20
> Once the client is able to differentiate between realm reports sent by =
different agents (or servers) we need logic defining how the client =
deals with a new overload report. =20

I need now to check one of the basic assumptions on DOIC now
so that we have the same understanding. I went back to the
endpoint text in Section 5.1. There, for example in Figures=20
4 and 5 the DOIC association and the endpoint assumption does
does not work IMHO because we have no endpoint identity in the
OLR. In order the endpoint assumption to work (as I drew it on
the white board in Porto), it would require as many Diameter
level sessions as there are DOIC associations.

So.. has assumptions shifted in a meanwhile and I have just
not paid attention?

> I see a couple of options (others will probably see options I am =
missing):
>=20
> - Use the last received realm report - This introduces the possibility =
of thrashing between two different reduction values and different =
durations.  Note that this approach does not require the source of the =
report to be included in the report.
>=20
> - Only listen to one source of realm overload - The approach would be =
to remember who sent the first overload report from the realm and ignore =
realm overload reports from other sources.  This behavior would likely =
be constrained to a single occurrence of realm overload.  Meaning that =
the "memory" of the report source would only last as long as that =
overload event persists.  Once the overload event goes away, the report =
source would be forgotten and a new source could be used for the next =
occurrence.
>=20
> On the surface, the second approach looks better to me.

Or add the identity of the OLR originator explicitly if it
cannot be determined implicitly (i.e. from the Diameter
message's Origin-Host/Realm).

Or assume the endpoint really is the endpoint in DOIC and
Diameter session sense.

- Jouni

>=20
> Steve
>=20
> On 12/11/13 2:15 AM, Jouni wrote:
>> Ulrich,
>>=20
>> I might be slow but.. Section 4.4 says
>>=20
>>    control endpoints.  The sequence number is only required to be =
unique
>>    between two overload control endpoints and does not need to be
>>=20
>> Unique between two endpoints..
>>=20
>> Section 5.1 talks about endpoints:
>>=20
>>    of an arbitrary Diameter network.  The overload control =
information
>>    is exchanged over on a "DOIC association" between two =
communication
>>    endpoints.  The endpoints, namely the "reacting node" and the
>>    "reporting node" do not need to be adjacent Diameter peer nodes, =
nor
>>=20
>> So if your agents inject realm reports, they need to be endpoints to =
the
>> client. Similar to Figure 5. Therefore the sequence number spaces =
between
>> C-A1 and C-A2 are separate.
>>=20
>> Now it is not clear to me, whether in your reasoning the C would see
>> the server identity (as the endpoint) when there is an active "DEP
>> agent" on the path. That would not clearly work and not be align with
>> the endpoint assumption.
>>=20
>> Note that at some point of time we had (at least on a discussion =
level
>> in f2f meeting) report originator identity in the OLR. That would =
make
>> endpoint identification trivial. Now a "DEP agent" needs to act as a=20=

>> "server" for its clients in order to appear as an endpoint.
>>=20
>> - Jouni
>>=20
>> ps: still think the use of Time is simpler..
>>=20
>>=20
>> On Dec 11, 2013, at 9:43 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>>=20
>>=20
>>> That's not predictable. It may be the same server in some cases, and =
different servers in other cases.
>>>=20
>>> -----Original Message-----
>>> From: ext Jouni [
>>> mailto:jouni.nospam@gmail.com
>>> ]=20
>>> Sent: Wednesday, December 11, 2013 8:38 AM
>>> To: Wiehe, Ulrich (NSN - DE/Munich)
>>> Cc: Ben Campbell;=20
>>> dime@ietf.org
>>>  list; Steve Donovan
>>> Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: =
comments to 4.3
>>>=20
>>>=20
>>> Ulrich,
>>>=20
>>> On Dec 11, 2013, at 9:21 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>>>=20
>>>=20
>>>> Jouni,
>>>>=20
>>>> ad 1. "monotonically" does not express your intention. What we are =
looking for may be "stepwise with fixed step".
>>>>=20
>>>> Ad 2. Is not necessarily a mistake that could result in =
out-of-sequence sequence numbers. When a client C sends a realm-type =
requests towards any server in the realm, an agent A1 that selects the =
server would send back the realm-type OLR with sequence number s1. The =
next realm-type request sent by C (that survived the throttling) may =
take a path that does not include A1 but A2. A2 then selects the server =
and sends back a sequence number s2. Nothing ensures that s1 and s2 are =
in sequence.
>>>>=20
>>> Would the server in both cases (via A1 and A2) be the same?
>>>=20
>>> - Jouni
>>>=20
>>>=20
>>>=20
>>>> Ulrich
>>>>=20
>>>>=20
>>>> -----Original Message-----
>>>> From: ext Jouni Korhonen [
>>>> mailto:jouni.nospam@gmail.com
>>>> ]=20
>>>> Sent: Tuesday, December 10, 2013 10:31 PM
>>>> To: Wiehe, Ulrich (NSN - DE/Munich)
>>>> Cc: Ben Campbell;=20
>>>> dime@ietf.org
>>>>  list; Steve Donovan
>>>> Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: =
comments to 4.3
>>>>=20
>>>> Ulrich,
>>>>=20
>>>> On Dec 10, 2013, at 4:31 PM, "Wiehe, Ulrich (NSN - DE/Munich)"=20
>>>> 
>>>>  wrote:
>>>>=20
>>>>=20
>>>>> Jouni,
>>>>>=20
>>>>> 1. I find the texts
>>>>> a) "The sequence number ... does not need to be monotonically =
increasing"
>>>>> and=20
>>>>>=20
>>>> Means the delta from old-seqno to new-seqno can be any non-negative =
integer
>>>> (within the given limits) not something fixed step/delta (like +1). =
As long as
>>>> "new-seqno >=3D old-seqno" holds we are fine.
>>>>=20
>>>>=20
>>>>> b) "...the new sequence number MUST be greater or equal than the =
old sequence number..."
>>>>> contradicting.
>>>>> Can you please clarify.
>>>>>=20
>>>> See above. (mind the overflow case)
>>>>=20
>>>>=20
>>>>> 2. The expected behaviour when receiving an out-of-sequence =
sequence number within OC-OLR is described in 4.3:
>>>>> "The receiver SHOULD discard an OC-OLR AVP with a sequence number =
that is less than previously received one."
>>>>> I don't find this very robust. Once a higher sequence number =
(received erroneously by mistake) is accepted you cannot (easily) =
recover.
>>>>>=20
>>>> I find it more robust in a sense that I should not care about stale =
old information.
>>>> However, since we are piggybacking (by popular demand) we have =
little room for seqno
>>>> re-sync negotiation.
>>>>=20
>>>> What is the mistake you refer here? A misbehaving implementation? =
In that case, it=20
>>>> deserves to get a manual intervention once figured out by admins =
checking alarms and
>>>> logs. If the mistake is due other things, like endpoints being out =
of sync, we currently
>>>> have no written down mechanism to survive that.
>>>>=20
>>>>=20
>>>>> 3. The expected behaviour when receiving an out-of-sequence =
sequence number within the OC-Supported-Features AVP is not described. =
What is the intention here?
>>>>>=20
>>>> No intention. Just a sloppy specification. You are right that =
something needs to be
>>>> done & clarified here. (again the semantics of Time would nice..)
>>>>=20
>>>> I'll propose something. Others should too ;)
>>>>=20
>>>> - Jouni
>>>>=20
>>>>=20
>>>>> Ulrich
>>>>>=20
>>>>> -----Original Message-----
>>>>> From: DiME [
>>>>> mailto:dime-bounces@ietf.org
>>>>> ] On Behalf Of ext Jouni Korhonen
>>>>> Sent: Tuesday, December 10, 2013 8:28 AM
>>>>> To: Ben Campbell;=20
>>>>> dime@ietf.org
>>>>>  list; Steve Donovan
>>>>> Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: =
OVLI: comments to 4.3
>>>>>=20
>>>>>=20
>>>>> Fine.. lets define then the sequence number semantics. Basic
>>>>> unsigned integer math. The text proposal is the following:
>>>>>=20
>>>>> 4.4.  OC-Sequence-Number AVP
>>>>>=20
>>>>> The OC-Sequence-Number AVP (AVP code TBD3) is type of Unsigned64.
>>>>> Its usage in the context of the overload control is described in
>>>>> Sections 4.1 and 4.3.
>>>>>=20
>>>>> =46rom the functionality point of view, the OC-Sequence-Number AVP
>>>>> MUST be used as a non-volatile increasing counter between two
>>>>> overload control endpoints.  The sequence number is only required
>>>>> to be unique between two overload control endpoints and does not
>>>>> need to be monotonically increasing.
>>>>>=20
>>>>> When comparing two sequence numbers, the new sequence number MUST
>>>>> be greater or equal than the old sequence number within a window
>>>>> that is half of the size of the maximum sequence number. This
>>>>> allows a simple handling of the sequence number overflow using
>>>>> unsigned integer arithmeticf:
>>>>>=20
>>>>>   #define WINDOW 0x8000000000000000ULL
>>>>>=20
>>>>>   bool verify_seqnum( uint64_t newsn, uint64_t oldsn ) {
>>>>>       if (newsn - oldsn <=3D WINDOW)
>>>>>           // newsn >=3D oldsn
>>>>>           return true;  =20
>>>>>       } else
>>>>>           // outside window or newsn < oldsn
>>>>>           return false; =20
>>>>>       }
>>>>>   }
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> The above should even work is someone shovels NTP times into
>>>>> sequence numbers with a blind typecasting.
>>>>>=20
>>>>> - Jouni
>>>>>=20
>>>>> On Dec 10, 2013, at 12:34 AM, Ben Campbell=20
>>>>> 
>>>>>  wrote:
>>>>>=20
>>>>>=20
>>>>>> On Dec 9, 2013, at 10:00 AM, Steve Donovan =

>>>>>>  wrote:
>>>>>>=20
>>>>>>=20
>>>>>>> Jouni,
>>>>>>>=20
>>>>>>> I propose that we keep the name OC-Sequence-Number but that we =
use the Time type for OC-Sequence-Number.  It is misleading and =
potentially confusing to call it OC-Time-Stamp. =20
>>>>>>>=20
>>>>>>>=20
>>>>>> I could live with that, although I would rather just define the =
expected properties of the sequence number, and leave the implementation =
up to the implementor. I assume your reasoning for not calling it a =
timestamp is that you do not want people to try to use it as a time base =
reference. If so, then we don't require any connection to a clock. We =
just need it to be monotonically increasing.
>>>>>>=20
>>>>>>=20
>>>>>>> We might consider expanding on the format of the AVP to make it =
something like Session-ID, where it is a concatenation of the =
Diameter-ID of the generating node and a timestamp.  This might help the =
reacting node keep track of which sequence number it has received.
>>>>>>>=20
>>>>>>>=20
>>>>>> Do we need a uniqueness across multiple nodes property? If so, =
why?
>>>>>>=20
>>>>>>=20
>>>>>>> Steve
>>>>>>>=20
>>>>>>> On 12/9/13 5:37 AM, Jouni Korhonen wrote:
>>>>>>>=20
>>>>>>>> Folks
>>>>>>>>=20
>>>>>>>> Could we conclude on the sequence number vs. time stamp vs. =
something else?
>>>>>>>> We got more important places to spend our energy than this ;)
>>>>>>>>=20
>>>>>>>> My proposal is the following (based on the original pre-00 =
design):
>>>>>>>>=20
>>>>>>>> o We change the OC-Sequence-Number to OC-Time-Stamp in all =
occurrences
>>>>>>>> in the -01.
>>>>>>>> o We use RFC6733 Time type for the OC-Time-Stamp. RFC6733 gives =
us
>>>>>>>> already exact definition how to handle the AVP.
>>>>>>>> o Define that the OC-Time-Stamp is the time of the creation of =
the=20
>>>>>>>> "original" AVP within whose context the time stamp is present.
>>>>>>>> o The OC-Time-Stamp AVP uniqueness is still considered to be in =
scope
>>>>>>>> of the communicating endpoints.
>>>>>>>> o The time stamp can be used to quickly determine if the =
content of
>>>>>>>> the encapsulating AVP context has changed (among other =
properties).
>>>>>>>> This would be useful specifically in the future when the =
encapsulating
>>>>>>>> grouped AVPs  grow in size and functionality.
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> - Jouni
>>>>>>>>=20
>>>>>>>> _______________________________________________
>>>>>>>> DiME mailing list
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> DiME@ietf.org
>>>>>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>> _______________________________________________
>>>>>>> DiME mailing list
>>>>>>>=20
>>>>>>> DiME@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>>> _______________________________________________
>>>>>> DiME mailing list
>>>>>>=20
>>>>>> DiME@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>> _______________________________________________
>>>>> DiME mailing list
>>>>>=20
>>>>> DiME@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/dime
>>=20
>=20


From nsalot@cisco.com  Thu Dec 12 04:40:58 2013
Return-Path: 
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 9E4A41AE284 for ; Thu, 12 Dec 2013 04:40:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.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 npLSm117tgLL for ; Thu, 12 Dec 2013 04:40:55 -0800 (PST)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 558DD1AE28D for ; Thu, 12 Dec 2013 04:40:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14861; q=dns/txt; s=iport; t=1386852049; x=1388061649; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=mRjSogulDgU0zh0KfyphKvaDCSLbuGNoVEMmDmcMYI4=; b=LrRliQXSWLqJeyi4Iq24NYCzjri9SRA0JygPAiZXT80Jtd+Rchp3F4h6 RcM85Fvn3uoT/8ESaaYG/WZbuxQICoqfQk2PegScKArgCh6wJEJUlPdfv sw8bG5v2/rHbgMa+mHFr4MiOQKCC2e3VCQkA2wBfM/VKVk/GGkGr9A8CS w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhUFAK+tqVKtJV2Y/2dsb2JhbABQCYMKOFW4W4EdFnSCJQEBAQMBAQEBNzQLBQcEAgEIEQQBAQEKFAkHIQYLFAkIAgQBDQUIh2gDCQgNuycNhxITBI0AgTkqMQcGgxuBEwSUMoF4jkWFOoMpgio
X-IronPort-AV: E=Sophos;i="4.93,878,1378857600"; d="scan'208";a="291056281"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP; 12 Dec 2013 12:40:48 +0000
Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rBCCemlV002385 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Dec 2013 12:40:49 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.227]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0123.003; Thu, 12 Dec 2013 06:40:47 -0600
From: "Nirav Salot (nsalot)" 
To: Jouni Korhonen , Steve Donovan 
Thread-Topic: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments	to 4.3
Thread-Index: AQHO9y5nqA8R5HNBA0aXifd4dh+mxppQf7GQ
Date: Thu, 12 Dec 2013 12:40:48 +0000
Message-ID: 
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DB1B@DEMUMBX014.nsn-intra.net>  <52A5E902.20605@usdonovans.com> <7475B713-1104-4791-96B1-CE97632A0D69@nostrum.com>  <5BCBA1FC2B7F0B4C9D935572D90006681519E476@DEMUMBX014.nsn-intra.net> <1CD20507-B0FE-4367-804A-B831734CF060@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E6DC@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D90006681519E712@DEMUMBX014.nsn-intra.net> <4A151D70-0291-4238-85B1-03BB54B361E6@gmail.com> <52A864FF.10705@usdonovans.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.65.36.240]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Ben Campbell , "dime@ietf.org list" 
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments	to 4.3
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Dec 2013 12:40:58 -0000

All,

I do not understand this discussion regarding different agents of the same =
realm having different view of the realm and provide different overload rep=
ort.
Additionally, I also do not understand the proposal of adding identity of t=
he agent generating "realm report" into the report.
What is the use of this identity at the reacting node when the report is re=
alm report? Why should the reacting node care who generated the realm repor=
t?

Regards,
Nirav.

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen
Sent: Thursday, December 12, 2013 5:06 PM
To: Steve Donovan
Cc: Ben Campbell; dime@ietf.org list
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comment=
s to 4.3

Steve,

On Dec 11, 2013, at 3:13 PM, Steve Donovan  wrote=
:

> Jouni,
>=20
> We need the sequence number to be strictly increasing.  I don't see the n=
eed for it to increase in uniform amounts.  Using time does fit these requi=
rements.  I'm ok with using time as long as we don't call the AVP timestamp=
.
>=20
> Ulrich does bring up an interesting use case, where a client is receiving=
 realm reports for the same realm from different agents.  We need to define=
 the clients behavior in this case. =20

Any suggestions? I mean agents may have hugely different view of the realm =
if they are acting on their own.

> Presumably the client needs to be able to determine who generated the rea=
lm report.  This cannot be determine based on the content of the message or=
 the connection on which the message arrived.  It seems like we might need =
"Report Generator Diameter ID" in the overload report specifically for Real=
m reports. =20
>=20
> Once the client is able to differentiate between realm reports sent by di=
fferent agents (or servers) we need logic defining how the client deals wit=
h a new overload report. =20

I need now to check one of the basic assumptions on DOIC now so that we hav=
e the same understanding. I went back to the endpoint text in Section 5.1. =
There, for example in Figures
4 and 5 the DOIC association and the endpoint assumption does does not work=
 IMHO because we have no endpoint identity in the OLR. In order the endpoin=
t assumption to work (as I drew it on the white board in Porto), it would r=
equire as many Diameter level sessions as there are DOIC associations.

So.. has assumptions shifted in a meanwhile and I have just not paid attent=
ion?

> I see a couple of options (others will probably see options I am missing)=
:
>=20
> - Use the last received realm report - This introduces the possibility of=
 thrashing between two different reduction values and different durations. =
 Note that this approach does not require the source of the report to be in=
cluded in the report.
>=20
> - Only listen to one source of realm overload - The approach would be to =
remember who sent the first overload report from the realm and ignore realm=
 overload reports from other sources.  This behavior would likely be constr=
ained to a single occurrence of realm overload.  Meaning that the "memory" =
of the report source would only last as long as that overload event persist=
s.  Once the overload event goes away, the report source would be forgotten=
 and a new source could be used for the next occurrence.
>=20
> On the surface, the second approach looks better to me.

Or add the identity of the OLR originator explicitly if it cannot be determ=
ined implicitly (i.e. from the Diameter message's Origin-Host/Realm).

Or assume the endpoint really is the endpoint in DOIC and Diameter session =
sense.

- Jouni

>=20
> Steve
>=20
> On 12/11/13 2:15 AM, Jouni wrote:
>> Ulrich,
>>=20
>> I might be slow but.. Section 4.4 says
>>=20
>>    control endpoints.  The sequence number is only required to be unique
>>    between two overload control endpoints and does not need to be
>>=20
>> Unique between two endpoints..
>>=20
>> Section 5.1 talks about endpoints:
>>=20
>>    of an arbitrary Diameter network.  The overload control information
>>    is exchanged over on a "DOIC association" between two communication
>>    endpoints.  The endpoints, namely the "reacting node" and the
>>    "reporting node" do not need to be adjacent Diameter peer nodes,=20
>> nor
>>=20
>> So if your agents inject realm reports, they need to be endpoints to=20
>> the client. Similar to Figure 5. Therefore the sequence number spaces=20
>> between
>> C-A1 and C-A2 are separate.
>>=20
>> Now it is not clear to me, whether in your reasoning the C would see=20
>> the server identity (as the endpoint) when there is an active "DEP=20
>> agent" on the path. That would not clearly work and not be align with=20
>> the endpoint assumption.
>>=20
>> Note that at some point of time we had (at least on a discussion=20
>> level in f2f meeting) report originator identity in the OLR. That=20
>> would make endpoint identification trivial. Now a "DEP agent" needs=20
>> to act as a "server" for its clients in order to appear as an endpoint.
>>=20
>> - Jouni
>>=20
>> ps: still think the use of Time is simpler..
>>=20
>>=20
>> On Dec 11, 2013, at 9:43 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>>=20
>>=20
>>> That's not predictable. It may be the same server in some cases, and di=
fferent servers in other cases.
>>>=20
>>> -----Original Message-----
>>> From: ext Jouni [
>>> mailto:jouni.nospam@gmail.com
>>> ]
>>> Sent: Wednesday, December 11, 2013 8:38 AM
>>> To: Wiehe, Ulrich (NSN - DE/Munich)
>>> Cc: Ben Campbell;
>>> dime@ietf.org
>>>  list; Steve Donovan
>>> Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI:=20
>>> comments to 4.3
>>>=20
>>>=20
>>> Ulrich,
>>>=20
>>> On Dec 11, 2013, at 9:21 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>>>=20
>>>=20
>>>> Jouni,
>>>>=20
>>>> ad 1. "monotonically" does not express your intention. What we are loo=
king for may be "stepwise with fixed step".
>>>>=20
>>>> Ad 2. Is not necessarily a mistake that could result in out-of-sequenc=
e sequence numbers. When a client C sends a realm-type requests towards any=
 server in the realm, an agent A1 that selects the server would send back t=
he realm-type OLR with sequence number s1. The next realm-type request sent=
 by C (that survived the throttling) may take a path that does not include =
A1 but A2. A2 then selects the server and sends back a sequence number s2. =
Nothing ensures that s1 and s2 are in sequence.
>>>>=20
>>> Would the server in both cases (via A1 and A2) be the same?
>>>=20
>>> - Jouni
>>>=20
>>>=20
>>>=20
>>>> Ulrich
>>>>=20
>>>>=20
>>>> -----Original Message-----
>>>> From: ext Jouni Korhonen [
>>>> mailto:jouni.nospam@gmail.com
>>>> ]
>>>> Sent: Tuesday, December 10, 2013 10:31 PM
>>>> To: Wiehe, Ulrich (NSN - DE/Munich)
>>>> Cc: Ben Campbell;
>>>> dime@ietf.org
>>>>  list; Steve Donovan
>>>> Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI:=20
>>>> comments to 4.3
>>>>=20
>>>> Ulrich,
>>>>=20
>>>> On Dec 10, 2013, at 4:31 PM, "Wiehe, Ulrich (NSN - DE/Munich)"=20
>>>> 
>>>>  wrote:
>>>>=20
>>>>=20
>>>>> Jouni,
>>>>>=20
>>>>> 1. I find the texts
>>>>> a) "The sequence number ... does not need to be monotonically increas=
ing"
>>>>> and
>>>>>=20
>>>> Means the delta from old-seqno to new-seqno can be any non-negative=20
>>>> integer (within the given limits) not something fixed step/delta=20
>>>> (like +1). As long as "new-seqno >=3D old-seqno" holds we are fine.
>>>>=20
>>>>=20
>>>>> b) "...the new sequence number MUST be greater or equal than the old =
sequence number..."
>>>>> contradicting.
>>>>> Can you please clarify.
>>>>>=20
>>>> See above. (mind the overflow case)
>>>>=20
>>>>=20
>>>>> 2. The expected behaviour when receiving an out-of-sequence sequence =
number within OC-OLR is described in 4.3:
>>>>> "The receiver SHOULD discard an OC-OLR AVP with a sequence number tha=
t is less than previously received one."
>>>>> I don't find this very robust. Once a higher sequence number (receive=
d erroneously by mistake) is accepted you cannot (easily) recover.
>>>>>=20
>>>> I find it more robust in a sense that I should not care about stale ol=
d information.
>>>> However, since we are piggybacking (by popular demand) we have=20
>>>> little room for seqno re-sync negotiation.
>>>>=20
>>>> What is the mistake you refer here? A misbehaving implementation?=20
>>>> In that case, it deserves to get a manual intervention once figured=20
>>>> out by admins checking alarms and logs. If the mistake is due other=20
>>>> things, like endpoints being out of sync, we currently have no written=
 down mechanism to survive that.
>>>>=20
>>>>=20
>>>>> 3. The expected behaviour when receiving an out-of-sequence sequence =
number within the OC-Supported-Features AVP is not described. What is the i=
ntention here?
>>>>>=20
>>>> No intention. Just a sloppy specification. You are right that=20
>>>> something needs to be done & clarified here. (again the semantics=20
>>>> of Time would nice..)
>>>>=20
>>>> I'll propose something. Others should too ;)
>>>>=20
>>>> - Jouni
>>>>=20
>>>>=20
>>>>> Ulrich
>>>>>=20
>>>>> -----Original Message-----
>>>>> From: DiME [
>>>>> mailto:dime-bounces@ietf.org
>>>>> ] On Behalf Of ext Jouni Korhonen
>>>>> Sent: Tuesday, December 10, 2013 8:28 AM
>>>>> To: Ben Campbell;
>>>>> dime@ietf.org
>>>>>  list; Steve Donovan
>>>>> Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re:=20
>>>>> OVLI: comments to 4.3
>>>>>=20
>>>>>=20
>>>>> Fine.. lets define then the sequence number semantics. Basic=20
>>>>> unsigned integer math. The text proposal is the following:
>>>>>=20
>>>>> 4.4.  OC-Sequence-Number AVP
>>>>>=20
>>>>> The OC-Sequence-Number AVP (AVP code TBD3) is type of Unsigned64.
>>>>> Its usage in the context of the overload control is described in=20
>>>>> Sections 4.1 and 4.3.
>>>>>=20
>>>>> From the functionality point of view, the OC-Sequence-Number AVP=20
>>>>> MUST be used as a non-volatile increasing counter between two=20
>>>>> overload control endpoints.  The sequence number is only required=20
>>>>> to be unique between two overload control endpoints and does not=20
>>>>> need to be monotonically increasing.
>>>>>=20
>>>>> When comparing two sequence numbers, the new sequence number MUST=20
>>>>> be greater or equal than the old sequence number within a window=20
>>>>> that is half of the size of the maximum sequence number. This=20
>>>>> allows a simple handling of the sequence number overflow using=20
>>>>> unsigned integer arithmeticf:
>>>>>=20
>>>>>   #define WINDOW 0x8000000000000000ULL
>>>>>=20
>>>>>   bool verify_seqnum( uint64_t newsn, uint64_t oldsn ) {
>>>>>       if (newsn - oldsn <=3D WINDOW)
>>>>>           // newsn >=3D oldsn
>>>>>           return true;  =20
>>>>>       } else
>>>>>           // outside window or newsn < oldsn
>>>>>           return false; =20
>>>>>       }
>>>>>   }
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> The above should even work is someone shovels NTP times into=20
>>>>> sequence numbers with a blind typecasting.
>>>>>=20
>>>>> - Jouni
>>>>>=20
>>>>> On Dec 10, 2013, at 12:34 AM, Ben Campbell 
>>>>>  wrote:
>>>>>=20
>>>>>=20
>>>>>> On Dec 9, 2013, at 10:00 AM, Steve Donovan 
>>>>>>  wrote:
>>>>>>=20
>>>>>>=20
>>>>>>> Jouni,
>>>>>>>=20
>>>>>>> I propose that we keep the name OC-Sequence-Number but that we use =
the Time type for OC-Sequence-Number.  It is misleading and potentially con=
fusing to call it OC-Time-Stamp. =20
>>>>>>>=20
>>>>>>>=20
>>>>>> I could live with that, although I would rather just define the expe=
cted properties of the sequence number, and leave the implementation up to =
the implementor. I assume your reasoning for not calling it a timestamp is =
that you do not want people to try to use it as a time base reference. If s=
o, then we don't require any connection to a clock. We just need it to be m=
onotonically increasing.
>>>>>>=20
>>>>>>=20
>>>>>>> We might consider expanding on the format of the AVP to make it som=
ething like Session-ID, where it is a concatenation of the Diameter-ID of t=
he generating node and a timestamp.  This might help the reacting node keep=
 track of which sequence number it has received.
>>>>>>>=20
>>>>>>>=20
>>>>>> Do we need a uniqueness across multiple nodes property? If so, why?
>>>>>>=20
>>>>>>=20
>>>>>>> Steve
>>>>>>>=20
>>>>>>> On 12/9/13 5:37 AM, Jouni Korhonen wrote:
>>>>>>>=20
>>>>>>>> Folks
>>>>>>>>=20
>>>>>>>> Could we conclude on the sequence number vs. time stamp vs. someth=
ing else?
>>>>>>>> We got more important places to spend our energy than this ;)
>>>>>>>>=20
>>>>>>>> My proposal is the following (based on the original pre-00 design)=
:
>>>>>>>>=20
>>>>>>>> o We change the OC-Sequence-Number to OC-Time-Stamp in all occurre=
nces
>>>>>>>> in the -01.
>>>>>>>> o We use RFC6733 Time type for the OC-Time-Stamp. RFC6733 gives us
>>>>>>>> already exact definition how to handle the AVP.
>>>>>>>> o Define that the OC-Time-Stamp is the time of the creation of the=
=20
>>>>>>>> "original" AVP within whose context the time stamp is present.
>>>>>>>> o The OC-Time-Stamp AVP uniqueness is still considered to be in sc=
ope
>>>>>>>> of the communicating endpoints.
>>>>>>>> o The time stamp can be used to quickly determine if the content o=
f
>>>>>>>> the encapsulating AVP context has changed (among other properties)=
.
>>>>>>>> This would be useful specifically in the future when the encapsula=
ting
>>>>>>>> grouped AVPs  grow in size and functionality.
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> - Jouni
>>>>>>>>=20
>>>>>>>> _______________________________________________
>>>>>>>> DiME mailing list
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> DiME@ietf.org
>>>>>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>> _______________________________________________
>>>>>>> DiME mailing list
>>>>>>>=20
>>>>>>> DiME@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>>> _______________________________________________
>>>>>> DiME mailing list
>>>>>>=20
>>>>>> DiME@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>> _______________________________________________
>>>>> DiME mailing list
>>>>>=20
>>>>> DiME@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/dime
>>=20
>=20

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

From srdonovan@usdonovans.com  Thu Dec 12 05:46:21 2013
Return-Path: 
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 365A91AE226 for ; Thu, 12 Dec 2013 05:46:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.12
X-Spam-Level: 
X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no
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 KTptePtLSi-6 for ; Thu, 12 Dec 2013 05:46:16 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 76E4A1AE21B for ; Thu, 12 Dec 2013 05:46:16 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:52313 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1Vr6ae-0001Va-Hx for dime@ietf.org; Thu, 12 Dec 2013 05:46:10 -0800
Message-ID: <52A9BE1F.7020201@usdonovans.com>
Date: Thu, 12 Dec 2013 07:46:07 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: dime@ietf.org
References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com>  <52A088D0.2020406@usdonovans.com>  <52A091CE.2000104@usdonovans.com> <13081_1386256433_52A09831_13081_8197_1_6B7134B31289DC4FAF! 731D84412 2B36E32B6EB@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B9209739738@ESESSMB101.ericsson.se>  <8FD63E2D-5203-4DA4-A6DA-C4CA181C9CFB@nostrum.com> <26C84DFD55BC3040A45BF70926E55F2587C1D786@SZXEMA512-MBX.china.huawei.com>  <52A86663.30500@usdonovans.com>  <087A34937E64E74E848732CFF8354B920973A82A@ESESSMB101.ericsson.se> <52A8B862.5040207@usdonovans.com> <087A34937E64E74E848732CFF8354B920973AAF5@ESESSMB101.ericsson.se>
In-Reply-To: <087A34937E64E74E848732CFF8354B920973AAF5@ESESSMB101.ericsson.se>
Content-Type: multipart/alternative; boundary="------------050409060207020705060102"
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Dec 2013 13:46:21 -0000

This is a multi-part message in MIME format.
--------------050409060207020705060102
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

Maria Cruz,

Can you explain the complexity behind the cross-application procedure. 
The work required is to ignore any application that the Diameter node
does not understand.  I don't see this as very complex.

Steve

On 12/12/13 1:26 AM, Maria Cruz Bartolome wrote:
>
> Yes, I agree consistency is not any longer a problem, since now your
> intention is that _/any/_ (and multiple) application data could be
> conveyed within the same message.
>
> But as mentioned a few times, I consider this not necessary since OLR
> is sent in every answer.
>
> A part from that, as mentioned by Lionel, this implies a
> cross-application procedure at both endpoints, that increases
> complexity and it is not required for our work (RFC7068)
>
>  
>
> Cheers
>
> /MCruz
>
>  
>
> *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *Steve Donovan
> *Sent:* miércoles, 11 de diciembre de 2013 20:09
> *To:* dime@ietf.org
> *Subject:* Re: [Dime] DOIC: Self-Contained OLRs
>
>  
>
> Maria Cruz,
>
> I don't agree with the assertion that self-contained OLRs results in
> the potential for data inconsistency.  If a reactor receives an
> overload report for an application that is not supported by the
> reactor then the reactor can and should ignore that OLR. 
>
> The concept of self-contained overload reports would explicitly allow
> for the contents of the overload report to be different than the
> message that is carrying the OLR.  As with application-ids, if the
> reactor doesn't send messages to a reported host or realm then the
> reactor ignores that part of the overload report.  As such, there is
> no need to check the implicit data when receiving a self-contained OLR.
>
> Steve
>
> On 12/11/13 12:25 PM, Maria Cruz Bartolome wrote:
>
>     Hello (and something else now J, fast key combination, I won't be
>     able to repeat,  was the responsible)
>
>      
>
>     As mentioned before, something else on cons side for self-contained:
>
>      
>
>     A part from that,  one concern with "self-contained OLRs" is that
>     some data is duplicated. Duplication should be avoided, since then
>     we need to assure consistency, and error handing in case implicit
>     and explicit data values are different for any reason... what
>     means that it may always be required to check both implicit and
>     explicit data.
>
>      
>
>     Also, I think this is a pure implementation proposal. Regardless
>     how the data is transported it could be packed in a
>     "self-contained OLRs" within the diameter application, if for any
>     implementation this is preferred.
>
>      
>
>     Best regards
>
>     /MCruz
>
>      
>
>     *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *TROTTIN,
>     JEAN-JACQUES (JEAN-JACQUES)
>     *Sent:* miércoles, 11 de diciembre de 2013 19:02
>     *To:* dime@ietf.org 
>     *Subject:* Re: [Dime] DOIC: Self-Contained OLRs
>
>      
>
>     Hi Steve
>
>      
>
>     I am sorry, Steve,  I do not see the difference between the Draft
>     Roach scope approach and the self contained OLRs.
>
>      
>
>     With the scope approach in Draft Roach : there is an overload
>     metric AVP  (eg containing a % of traffic reduction) coupled with
>     one or several Overlaod-Infoscope AVPs, an overlaod infoscope
>     identifying an application or a destination host or... . These
>     Overlaod-Infoscope AVPs can be combined  with also  the
>     possibility of  multi instances to have a list of applications, a
>     list of destination hosts etc  to which the overload metric would
>     apply.
>
>      
>
>     With self contained OLR as you have described them, un OLR will
>     also contain an OC-Reduction-Percentage AVP coupled with one or
>     several others AVPs (the self containment approach) to indicate
>     which application(s), destinations host (s) etc the
>       OC-Reduction-Percentage AVP applies.
>
>      
>
>     Where is the difference?
>
>      
>
>     So the drawbacks identified for the scope approach also apply with
>     the self contained approach
>
>      
>
>     Best regards
>
>      
>
>     JJacques
>
>      
>
>      
>
>      
>
>     *De :*DiME [mailto:dime-bounces@ietf.org] *De la part de* Steve
>     Donovan
>     *Envoyé :* mercredi 11 décembre 2013 14:20
>     *À :* dime@ietf.org 
>     *Objet :* Re: [Dime] DOIC: Self-Contained OLRs
>
>      
>
>     JJacques,
>
>     While the self contained overload report concept may be similar to
>     the scopes concept in the Roach draft, they are not the same.  As
>     such, I don't agree with your assertion that the previous
>     rejection of the Roach draft requires us to reject self contained
>     overload reports as currently being discussed.
>
>     Steve
>
>     On 12/11/13 2:27 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:
>
>         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  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
>         > wrote:
>
>
>         OK. Lets call this thread concluded then. I keep the old
>         OC-OLR  semantics
>         regarding its information context then unmodified.
>
>         - Jouni
>
>          
>
>          
>
>         _______________________________________________
>
>         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


--------------050409060207020705060102
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Maria Cruz,

      

      Can you explain the complexity behind the cross-application
      procedure.  The work required is to ignore any application that
      the Diameter node does not understand.  I don't see this as very
      complex.

      

      Steve

      

    
    
On 12/12/13 1:26 AM, Maria Cruz
      Bartolome wrote:

    

    

      
      
      
      

        
Yes,
            I agree consistency is not any longer a problem, since now
            your intention is that _any_ (and multiple)
            application data could be conveyed within the same message.

        
But
            as mentioned a few times, I consider this not necessary
            since OLR is sent in every answer.
            

        
A
            part from that, as mentioned by Lionel, this implies a
            cross-application procedure at both endpoints, that
            increases complexity and it is not required for our work
            (RFC7068)

        
 

        
Cheers

        
/MCruz

        
 

        

          

            
From:
                DiME [mailto:dime-bounces@ietf.org]
                On Behalf Of Steve Donovan

                Sent: miércoles, 11 de diciembre de 2013 20:09

                To: dime@ietf.org

                Subject: Re: [Dime] DOIC: Self-Contained OLRs

          

        

        
 

        
Maria Cruz,

          

          I don't agree with the assertion that self-contained OLRs
          results in the potential for data inconsistency.  If a reactor
          receives an overload report for an application that is not
          supported by the reactor then the reactor can and should
          ignore that OLR. 
          

          

          The concept of self-contained overload reports would
          explicitly allow for the contents of the overload report to be
          different than the message that is carrying the OLR.  As with
          application-ids, if the reactor doesn't send messages to a
          reported host or realm then the reactor ignores that part of
          the overload report.  As such, there is no need to check the
          implicit data when receiving a self-contained OLR.

          

          Steve

        

          
On 12/11/13 12:25 PM, Maria Cruz
            Bartolome wrote:

        

        

          
Hello (and something else now 
              J, fast key combination, I won’t be able to repeat,
             was the responsible)

          
 

          
As mentioned before, something else on
            cons side for self-contained:

          
 

          
A part from
            that,  one concern with "self-contained OLRs" is that some
            data is duplicated. Duplication should be avoided, since
            then we need to assure consistency, and error handing in
            case implicit and explicit data values are different for any
            reason... what means that it may always be required to check
            both implicit and explicit data.

          
 

          
Also, I
            think this is a pure implementation proposal. Regardless how
            the data is transported it could be packed in a
            "self-contained OLRs" within the diameter application, if
            for any implementation this is preferred.

          
 

          
Best
              regards

          
/MCruz

          
 

          

            

              
From:
                  DiME [mailto:dime-bounces@ietf.org]
                  On Behalf Of TROTTIN, JEAN-JACQUES
                  (JEAN-JACQUES)

                  Sent: miércoles, 11 de diciembre de 2013 19:02

                  To: dime@ietf.org

                  Subject: Re: [Dime] DOIC: Self-Contained OLRs

            

          

          
 

          
Hi
              Steve

          
 

          
I
              am sorry, Steve,  I do not see the difference between the
              Draft Roach scope approach and the self contained OLRs.

          
 

          
With
              the scope approach in Draft Roach : there is an overload
              metric AVP  (eg containing a % of traffic reduction)
              coupled with one or several Overlaod-Infoscope AVPs, an
              overlaod infoscope identifying an application or a
              destination host or… . These Overlaod-Infoscope AVPs can
              be combined  with also  the possibility of  multi
              instances to have a list of applications, a list of
              destination hosts etc  to which the overload metric would
              apply.

          
 

          
With
              self contained OLR as you have described them, un OLR will
              also contain an OC-Reduction-Percentage
             AVP
              coupled with one or several others AVPs (the self
              containment approach) to indicate which application(s),
              destinations host (s) etc the   OC-Reduction-Percentage
             AVP
              applies.
            

          
 

          
Where
              is the difference?

          
 

          
So
              the drawbacks identified for the scope approach also apply
              with the self contained approach
            

          
 

          
Best
              regards

          
 

          
JJacques
            

          
 

          
 

          
 

          

            

              
De : DiME [mailto:dime-bounces@ietf.org]
                  De la part de Steve Donovan

                  Envoyé : mercredi 11 décembre 2013 14:20

                  À : dime@ietf.org

                  Objet : Re: [Dime] DOIC: Self-Contained OLRs

            

          

          
 

          
JJacques,

            

            While the self contained overload report concept may be
            similar to the scopes concept in the Roach draft, they are
            not the same.  As such, I don't agree with your assertion
            that the previous rejection of the Roach draft requires us
            to reject self contained overload reports as currently being
            discussed.

            

            Steve

          

            
On 12/11/13 2:27 AM, TROTTIN,
              JEAN-JACQUES (JEAN-JACQUES) wrote:

          

          

            
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 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>
              wrote:

            


              OK. Lets call this thread concluded then. I keep the old
              OC-OLR  semantics

              regarding its information context then unmodified.

              

              - Jouni

            
 

            
 

            
_______________________________________________

            
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


    

    

  


--------------050409060207020705060102--

From srdonovan@usdonovans.com  Thu Dec 12 05:52:44 2013
Return-Path: 
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 9FBD81ADDAC for ; Thu, 12 Dec 2013 05:52:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.12
X-Spam-Level: 
X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no
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 8XeE3QCyhX0r for ; Thu, 12 Dec 2013 05:52:38 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 2E8E51AC7F0 for ; Thu, 12 Dec 2013 05:52:38 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:52316 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1Vr6gi-0007li-EP; Thu, 12 Dec 2013 05:52:30 -0800
Message-ID: <52A9BF98.6090805@usdonovans.com>
Date: Thu, 12 Dec 2013 07:52:24 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: "Wiehe, Ulrich (NSN - DE/Munich)" ,  "dime@ietf.org" 
References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com>  <5BCBA1FC2B7F0B4C9D935572D90006681519BC90@DEMUMBX014.nsn-intra.net> <6390_1385631044_52970D44_6390_18593_1_6B7134B31289DC4FAF731D844122B36E30748E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BD19@DEMUMBX014.nsn-intra.net> <26C84DFD55BC3040A45BF70926E55F2587C1D028@SZXEMA512-MBX.china.huawei.com> <5BCBA1FC2B7F0B4C9D935572D90006681519DFC0@DEMUMBX014.nsn-intra.net> <26C84DFD55BC3040A45BF70926E55F2587C1D705@SZXEMA512-MBX.china.huawei.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E2DE@DEMUMBX014.nsn-intra.net> <26C84DFD55BC3040A45BF70926E55F2587C1DC24@SZXEMA512-MBX.china.huawei.com> <52A86839.4010103@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E931@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681519E931@DEMUMBX014.nsn-intra.net>
Content-Type: multipart/alternative; boundary="------------010309020606080009000907"
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Dec 2013 13:52:44 -0000

This is a multi-part message in MIME format.
--------------010309020606080009000907
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

Ulrich,

My assumption is that and end-point is an end-point for all messages
sent between the two end-points.

Steve

On 12/12/13 5:17 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
> Steve,
>
>  
>
> Isn't it so that the agent may decide (e.g. based on the absence of
> Destination host in the received request and based of its
> ability/willingness to select the server)
>
> either a) to take the role of an endpoint or b) to be transparent with
> regard to OC AVPs.
>
> In case a) we end up with two DOIC associations, one between client
> and agent, another one between agent and server. Different DOIC
> associations may have different advertised/negotiated features i.e.
> agent and server may use window algorithm, but client and agent use
> loss algorithm. Therefore the host-type window OLR must not be sent
> unchanged to the client.
>
> In case b) being transparent includes not inserting realm-type AVPs.
>
>  
>
> We end up with receiving not more than one OLR at the client.
>
>  
>
> Ulrich
>
>  
>
>  
>
>  
>
>  
>
> *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *ext Steve
> Donovan
> *Sent:* Wednesday, December 11, 2013 2:27 PM
> *To:* dime@ietf.org
> *Subject:* Re: [Dime] DOIC: Self-Contained OLRs
>
>  
>
> Susan,
>
> The use case for an agent that sits between a DOIC client and a DOIC
> server is Realm overload, which the agent might be responsible for
> reporting.  This will particularly be the case when there are multiple
> servers sitting behind the agent.  This might be considered a server
> farm, as you indicate, but we don't have a good definition of server
> farm, so I'm being explicit.
>
> In this case, the agent must handle to types of occurrences. 
>
> 1) Server overload - In this case the agent will receive a node
> overload report from the server.  The agent should (I'm not sure if we
> have defined this behavior in the draft yet) send the report unchanged
> to the client.  The agent will also most likely use the contents of
> the report to determine the realm overload state.
>
> 2) Realm overload - In this case the agent will insert an overload
> report into the appropriate answer messages.
>
> Is this consistent with your thinking?
>
> Regards,
>
> Steve
>
> On 12/11/13 12:24 AM, Shishufeng (Susan) wrote:
>
>     Hi Ulrich,
>
>      
>
>     I'm not sure if you are taking the overload of agent into account for which we decided to not consider for the time being. If not, I couldn't understand why an agent which does not serve for a server farm needs to be a DOIC endpoint between the client and server if both of them support overload control. My understanding is that if there is the need for an agent to take a role of a DOIC endpoint between a specific server and client, it would always do that, otherwise, it just transfer the overload information of the server to the client.
>
>      
>
>     Best Regards,
>
>     Susan
>
>      
>
>     -----Original Message-----
>
>     From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] 
>
>     Sent: Tuesday, December 10, 2013 6:15 PM
>
>     To: Shishufeng (Susan); ext lionel.morand@orange.com ; ext Jouni Korhonen; Ben Campbell
>
>     Cc: dime@ietf.org  list
>
>     Subject: RE: [Dime] DOIC: Self-Contained OLRs
>
>      
>
>     Hi Susan,
>
>      
>
>     if the agent does not take the role of a DOIC endpont then the feature negotiation/adverisement is between client and server and one host type OLR is sent from server to client. For the agent this is all transparent and there is no need for the agent to support any DOIC feature.
>
>     However, if the agent takes the role of an DOIC endpoint then the feature negotiation/advertisement is between client and agent and a separate feature negotiation/advertisement is between agent and server. An OLR sent from server to agent is in-context with the supported features of server and agent but possibly not in-context with supported features of client and agent and therefore must not be (blindly) sent to the client. And in fact there is also no need to do that. For subsequent requests that contain the desination host of the server, the agent will not take the role of a DOIC endpoint.
>
>      
>
>     Best regards
>
>     Ulrich
>
>      
>
>     -----Original Message-----
>
>     From: ext Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
>
>     Sent: Tuesday, December 10, 2013 4:02 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
>
>      
>
>     Hi Ulrich,
>
>      
>
>     Thanks for your clarification. I understood the scenario, while from my point of view, if the agent that selects the HSS is not configured to serve as a load balancer for the HSS, the agent should not change any supported/negotiated features between C and S, that would be the normal case. If the agent serve as a load balancer for the HSS, the subsequent request from C towards the S would always go via the agent, in this case whatever the associations between C and A, between A and S are the same or not, it doesn't matter. With an E2E solution as we agreed, I don't see the problem with it.
>
>      
>
>     Best Regards,
>
>     Susan
>
>      
>
>     -----Original Message-----
>
>     From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
>
>     Sent: Monday, December 09, 2013 7:43 PM
>
>     To: Shishufeng (Susan); ext lionel.morand@orange.com ; ext Jouni Korhonen; Ben Campbell
>
>     Cc: dime@ietf.org  list
>
>     Subject: RE: [Dime] DOIC: Self-Contained OLRs
>
>      
>
>     Hi Susan,
>
>      
>
>     let me come back to your S6a example.
>
>      
>
>     The MME (C) sends a request without Destination-Host towards the HPLMN (realm). There must be an agent (A) in the HPLMN (realm) that selects the HSS (S). 
>
>     We would have two distinct DOIC associations: one between C and A, another between A and S (see figure 5 in clause 5.1). The two DOIC associations may have different supported/negotiated features. An OLR sent from S to A based on supported/negotiated features valid for the DOIC association between A and S is at least problematic (out-of context) when sent from A to C.
>
>      
>
>     When the MME (C) sends a subsequent request with Destination-Host towards the HSS (S), there is no agent that selects the HSS (as the HSS is already selected). For this session there is only one DOIC association between C and S (see figure 3 in clause 5.1) and OLRs sent from S to C are not problematic.
>
>      
>
>     Best regards
>
>     Ulrich
>
>      
>
>      
>
>     -----Original Message-----
>
>     From: ext Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
>
>     Sent: Monday, December 09, 2013 11:30 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
>
>      
>
>     Hi Ulrich,
>
>      
>
>     I have different views. In any case, I think the host-type OLR should not be ignored by the clients. On the contrary, the realm-type OLR can be thought as optimization, which may not even be needed at all for all cases, especially in 3GPP. Here is an example of S6a, in the case the first attach request comes from the UE to the MME, the MME can only derive the realm information, and sends a request without Destination-Host towards the HPLMN. Since the subscriber corresponding to the UE belongs to a specific HSS, and the HSS may provide its overload report to the MME, and the MME is able to know how to react regarding the requests towards the HSS, which would be the normal case. Whether Realm report will be provided by the HSS or the agent serving the HSS is kind of optimization which may help the MME to know how to react on the requests towards the realm, not specific to the HSS.
>
>      
>
>     Best Regards,
>
>     Susan
>
>      
>
>     -----Original Message-----
>
>     From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
>
>     Sent: Thursday, November 28, 2013 6:30 PM
>
>     To: ext lionel.morand@orange.com ; ext Jouni Korhonen; Ben Campbell
>
>     Cc: dime@ietf.org  list
>
>     Subject: 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   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.
>
>      
>
>      
>
>     _______________________________________________
>
>     DiME mailing list
>
>     DiME@ietf.org 
>
>     https://www.ietf.org/mailman/listinfo/dime
>
>      
>
>  
>


--------------010309020606080009000907
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Ulrich,

      

      My assumption is that and end-point is an end-point for all
      messages sent between the two end-points.

      

      Steve

      

    
    
On 12/12/13 5:17 AM, Wiehe, Ulrich (NSN
      - DE/Munich) wrote:

    

    

      
      
      
      

        
Steve,

        
 

        
Isn’t it so that the agent may decide (e.g.
            based on the absence of Destination host in the received
            request and based of its ability/willingness to select the
            server)

        
either a) to take the role of an endpoint or b)
            to be transparent with regard to OC AVPs.

        
In case a) we end up with two DOIC
            associations, one between client and agent, another one
            between agent and server. Different DOIC associations may
            have different advertised/negotiated features i.e. agent and
            server may use window algorithm, but client and agent use
            loss algorithm. Therefore the host-type window OLR must not
            be sent unchanged to the client.

        
In case b) being transparent includes not
            inserting realm-type AVPs.

        
 

        
We end up with receiving not more than one OLR
            at the client.

        
 

        
Ulrich

        
 

        
 

        
 

        

        
 

        

          

            
From: DiME [mailto:dime-bounces@ietf.org]
                On Behalf Of ext Steve Donovan

                Sent: Wednesday, December 11, 2013 2:27 PM

                To: dime@ietf.org

                Subject: Re: [Dime] DOIC: Self-Contained OLRs

          

        

        
 

        
Susan,

          

          The use case for an agent that sits between a DOIC client and
          a DOIC server is Realm overload, which the agent might be
          responsible for reporting.  This will particularly be the case
          when there are multiple servers sitting behind the agent. 
          This might be considered a server farm, as you indicate, but
          we don't have a good definition of server farm, so I'm being
          explicit.

          

          In this case, the agent must handle to types of occurrences. 
          

          

          1) Server overload - In this case the agent will receive a
          node overload report from the server.  The agent should (I'm
          not sure if we have defined this behavior in the draft yet)
          send the report unchanged to the client.  The agent will also
          most likely use the contents of the report to determine the
          realm overload state.

          

          2) Realm overload - In this case the agent will insert an
          overload report into the appropriate answer messages.

          

          Is this consistent with your thinking?

          

          Regards,

          

          Steve

        

          
On 12/11/13 12:24 AM, Shishufeng (Susan)
            wrote:

        

        

          
Hi Ulrich,

          
 

          
I'm not sure if you are taking the overload of agent into account for which we decided to not consider for the time being. If not, I couldn't understand why an agent which does not serve for a server farm needs to be a DOIC endpoint between the client and server if both of them support overload control. My understanding is that if there is the need for an agent to take a role of a DOIC endpoint between a specific server and client, it would always do that, otherwise, it just transfer the overload information of the server to the client.

          
 

          
Best Regards,

          
Susan

          
 

          
-----Original Message-----

          
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] 

          
Sent: Tuesday, December 10, 2013 6:15 PM

          
To: Shishufeng (Susan); ext lionel.morand@orange.com; ext Jouni Korhonen; Ben Campbell

          
Cc: dime@ietf.org list

          
Subject: RE: [Dime] DOIC: Self-Contained OLRs

          
 

          
Hi Susan,

          
 

          
if the agent does not take the role of a DOIC endpont then the feature negotiation/adverisement is between client and server and one host type OLR is sent from server to client. For the agent this is all transparent and there is no need for the agent to support any DOIC feature.

          
However, if the agent takes the role of an DOIC endpoint then the feature negotiation/advertisement is between client and agent and a separate feature negotiation/advertisement is between agent and server. An OLR sent from server to agent is in-context with the supported features of server and agent but possibly not in-context with supported features of client and agent and therefore must not be (blindly) sent to the client. And in fact there is also no need to do that. For subsequent requests that contain the desination host of the server, the agent will not take the role of a DOIC endpoint.

          
 

          
Best regards

          
Ulrich

          
 

          
-----Original Message-----

          
From: ext Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]

          
Sent: Tuesday, December 10, 2013 4:02 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

          
 

          
Hi Ulrich,

          
 

          
Thanks for your clarification. I understood the scenario, while from my point of view, if the agent that selects the HSS is not configured to serve as a load balancer for the HSS, the agent should not change any supported/negotiated features between C and S, that would be the normal case. If the agent serve as a load balancer for the HSS, the subsequent request from C towards the S would always go via the agent, in this case whatever the associations between C and A, between A and S are the same or not, it doesn't matter. With an E2E solution as we agreed, I don't see the problem with it.

          
 

          
Best Regards,

          
Susan

          
 

          
-----Original Message-----

          
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]

          
Sent: Monday, December 09, 2013 7:43 PM

          
To: Shishufeng (Susan); ext lionel.morand@orange.com; ext Jouni Korhonen; Ben Campbell

          
Cc: dime@ietf.org list

          
Subject: RE: [Dime] DOIC: Self-Contained OLRs

          
 

          
Hi Susan,

          
 

          
let me come back to your S6a example.

          
 

          
The MME (C) sends a request without Destination-Host towards the HPLMN (realm). There must be an agent (A) in the HPLMN (realm) that selects the HSS (S). 

          
We would have two distinct DOIC associations: one between C and A, another between A and S (see figure 5 in clause 5.1). The two DOIC associations may have different supported/negotiated features. An OLR sent from S to A based on supported/negotiated features valid for the DOIC association between A and S is at least problematic (out-of context) when sent from A to C.

          
 

          
When the MME (C) sends a subsequent request with Destination-Host towards the HSS (S), there is no agent that selects the HSS (as the HSS is already selected). For this session there is only one DOIC association between C and S (see figure 3 in clause 5.1) and OLRs sent from S to C are not problematic.

          
 

          
Best regards

          
Ulrich

          
 

          
 

          
-----Original Message-----

          
From: ext Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]

          
Sent: Monday, December 09, 2013 11:30 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

          
 

          
Hi Ulrich,

          
 

          
I have different views. In any case, I think the host-type OLR should not be ignored by the clients. On the contrary, the realm-type OLR can be thought as optimization, which may not even be needed at all for all cases, especially in 3GPP. Here is an example of S6a, in the case the first attach request comes from the UE to the MME, the MME can only derive the realm information, and sends a request without Destination-Host towards the HPLMN. Since the subscriber corresponding to the UE belongs to a specific HSS, and the HSS may provide its overload report to the MME, and the MME is able to know how to react regarding the requests towards the HSS, which would be the normal case. Whether Realm report will be provided by the HSS or the agent serving the HSS is kind of optimization which may help the MME to know how to react on the requests towards the realm, not specific to the HSS.

          
 

          
Best Regards,

          
Susan

          
 

          
-----Original Message-----

          
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]

          
Sent: Thursday, November 28, 2013 6:30 PM

          
To: ext lionel.morand@orange.com; ext Jouni Korhonen; Ben Campbell

          
Cc: dime@ietf.org list

          
Subject: 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.

          
 

          
 

          
_______________________________________________

          
DiME mailing list

          
DiME@ietf.org

          
https://www.ietf.org/mailman/listinfo/dime

          
 

        

        
 

      

    

    

  


--------------010309020606080009000907--

From srdonovan@usdonovans.com  Thu Dec 12 05:53:22 2013
Return-Path: 
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 973111AE2DA for ; Thu, 12 Dec 2013 05:53:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.779
X-Spam-Level: 
X-Spam-Status: No, score=0.779 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no
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 iC6GNmBP5Svj for ; Thu, 12 Dec 2013 05:53:21 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 8C9D31AC7F0 for ; Thu, 12 Dec 2013 05:53:21 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:52319 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1Vr6hW-0000Nc-NO for dime@ietf.org; Thu, 12 Dec 2013 05:53:15 -0800
Message-ID: <52A9BFCA.1040904@usdonovans.com>
Date: Thu, 12 Dec 2013 07:53:14 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: dime@ietf.org
References: <087A34937E64E74E848732CFF8354B920973AB4B@ESESSMB101.ericsson.se> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------080806050701030409000407"
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com
Subject: Re: [Dime] OVLI: OC-Validity-Duration
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Dec 2013 13:53:23 -0000

This is a multi-part message in MIME format.
--------------080806050701030409000407
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

+1

On 12/12/13 2:38 AM, Jouni Korhonen wrote:
> Hi,
>
> I kind of like scheduled cleanups.. just to make sure there is no
> stuff left hanging around when something unpredictable happens in
> the network system.
>
> Again, I would say this is a wrong place to "optimize".
>
>
> - Jouni
>
> On Dec 12, 2013, at 9:53 AM, Maria Cruz Bartolome  wrote:
>
>> Dear all,
>>  
>> I would like to reconsider the real need for the OC-Validity-Duration AVP to be included into overload report.
>> Overload mechanism is being design with a principle in mind: as soon as reporting node determines a reacting node overload behavior should change, reporting node sends a fresh overload report to this reacting node.
>> Therefore, latest overload report received will be always applicable until a new report is received, and then I do not see the value, but just complexity, of including a Duration in the report.
>>  
>> Let me know your views.
>> Best regards
>> /MCruz
>>  
>>  
>>  
>>  
>>  
>> _______________________________________________
>> 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
>


--------------080806050701030409000407
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    +1

      

    
    
On 12/12/13 2:38 AM, Jouni Korhonen
      wrote:

    

    

      
Hi,

I kind of like scheduled cleanups.. just to make sure there is no
stuff left hanging around when something unpredictable happens in
the network system.

Again, I would say this is a wrong place to "optimize".


- Jouni

On Dec 12, 2013, at 9:53 AM, Maria Cruz Bartolome <maria.cruz.bartolome@ericsson.com> wrote:



      

        
Dear all,
 
I would like to reconsider the real need for the OC-Validity-Duration AVP to be included into overload report.
Overload mechanism is being design with a principle in mind: as soon as reporting node determines a reacting node overload behavior should change, reporting node sends a fresh overload report to this reacting node.
Therefore, latest overload report received will be always applicable until a new report is received, and then I do not see the value, but just complexity, of including a Duration in the report.
 
Let me know your views.
Best regards
/MCruz
 
 
 
 
 
_______________________________________________
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



    

    

  


--------------080806050701030409000407--

From srdonovan@usdonovans.com  Thu Dec 12 05:55:30 2013
Return-Path: 
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 889B21AE1F3 for ; Thu, 12 Dec 2013 05:55:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.12
X-Spam-Level: 
X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no
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 XD4of9dX01HS for ; Thu, 12 Dec 2013 05:55:25 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 6E9101ADDAC for ; Thu, 12 Dec 2013 05:55:24 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:52323 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1Vr6jQ-0002ua-Dt; Thu, 12 Dec 2013 05:55:18 -0800
Message-ID: <52A9C040.40206@usdonovans.com>
Date: Thu, 12 Dec 2013 07:55:12 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: "Wiehe, Ulrich (NSN - DE/Munich)" ,  "dime@ietf.org" 
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DA3E@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681519DCE5@DEMUMBX014.nsn-intra.net> <09616DA2-D1ED-40EE-8E89-755DFCD81092@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E02B@DEMUMBX014.nsn-intra.net> <1A402C59-E390-4C95-8E30-97F1F9D3EF0F@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E05C@DEMUMBX014.nsn-intra.net> <790F1603-64D5-40E2-BC59-FD4C104EEF1B@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E0D9@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D90006681519E331@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D90006681519E3C4@DEMUMBX014.nsn-intra.net> <0CDBF4BB-4E38-41D6-A5E2-9218FFEFEA43@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E6EF@DEMUMBX014.nsn-intra.net> <52A869AD.6080305@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E89B@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681519E89B@DEMUMBX014.nsn-intra.net>
Content-Type: multipart/alternative; boundary="------------090105050205060503010300"
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com
Subject: Re: [Dime] OVLI: comments to 4.1
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Dec 2013 13:55:30 -0000

This is a multi-part message in MIME format.
--------------090105050205060503010300
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Ulrich,

No, the sequence number can't be mandatory.  It always needs to be sent
to allow for end-points that what to use the logic I proposed.

An endpoint that receives the sequence number can choose to ignore it,
but endpoints must always send sequence numbers.

Steve

On 12/12/13 3:30 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
> Steve,
>
>  
>
> do you mean " keep sequence number in OC-Supported-Features as an
> optional AVP that may be ignored by the receiver and need notbe
> included by the sender"?
>
>  
>
> Ulrich
>
>  
>
> *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *ext Steve
> Donovan
> *Sent:* Wednesday, December 11, 2013 2:34 PM
> *To:* dime@ietf.org
> *Subject:* Re: [Dime] OVLI: comments to 4.1
>
>  
>
> Ulrich,
>
> My email showed how a reporting node could avoid the work of
> recalculating capability information on a message by message basis
> using the sequence number.  This approach does require maintaining state.
>
> As Ben pointed out, it is also possible to not follow my logic and do
> as you propose by ignoring the sequence number and going through the
> work of calculating the response every time. 
>
> Which approach to take is clearly an implementation decision.  We
> should keep the sequence number to allow for the stateful approach for
> implementations that are willing to take advantage of maintaining
> state to avoid work.
>
> Steve
>
> On 12/11/13 1:34 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
>     Jouni,
>
>      
>
>     I do not agree.
>
>      
>
>     My statement was general: reporting node may be server or SFA; supported features may be defined features (default algo) or future extensions.
>
>      
>
>     Ulrich
>
>      
>
>     -----Original Message-----
>
>     From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] 
>
>     Sent: Tuesday, December 10, 2013 10:46 PM
>
>     To: Wiehe, Ulrich (NSN - DE/Munich)
>
>     Cc: dime@ietf.org 
>
>     Subject: Re: [Dime] OVLI: comments to 4.1
>
>      
>
>     Ulrich,
>
>      
>
>     On Dec 10, 2013, at 2:18 PM, "Wiehe, Ulrich (NSN - DE/Munich)"   wrote:
>
>      
>
>          
>
>          
>
>         -----Original Message-----
>
>         From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] 
>
>         Sent: Tuesday, December 10, 2013 12:32 PM
>
>         To: Wiehe, Ulrich (NSN - DE/Munich)
>
>         Cc: dime@ietf.org 
>
>         Subject: Re: [Dime] OVLI: comments to 4.1
>
>          
>
>          
>
>         On Dec 10, 2013, at 12:41 PM, "Wiehe, Ulrich (NSN - DE/Munich)"   wrote:
>
>          
>
>             Hi Jouni,
>
>              
>
>             my understanding from Steve's clarification was that the reporting node would setup and maintain a database of "states", one per reacting node where a state of a reacting node is identified by a sequence number and the database entry would contain the pre-calculated OLR. 
>
>             Hard to see how this is done without consuming resources.
>
>          
>
>         It is mostly static information. Still I do not see how
>
>         you would get away without any state.
>
>         [Wiehe, Ulrich (NSN - DE/Munich)] There is no need for the reporting node to store and maintain information per reacting node because the reacting node actually tells within the request message all information the reporting node needs to know. The reporting node simply fetches the pre-calculated OLR that matches the supported features of the reacting node as indicated in the request and appends it to the answer.
>
>      
>
>     This could be true for the default algorithm in this spec. However,
>
>     given the extension mechanism we have in place it is quite possible
>
>     that the assumption does not hold for new features.
>
>      
>
>     Also, if I were to implement a server front end agent that would
>
>     definitely need state and still ought to comply the protocol spec.
>
>      
>
>     - Jouni
>
>      
>
>      
>
>      
>
>      
>
>             Furthermore,
>
>             Why would the reacting node be interested in config changes of the reporting node?
>
>             Isn't it so that the reacting node is only interested in OLR changes?
>
>          
>
>         Sigh.. say the traffic abatement algorithm changes or new features
>
>         get added. Those have more impact than just OLR change.
>
>          
>
>         - Jouni
>
>          
>
>              
>
>             Ulrich
>
>              
>
>             -----Original Message-----
>
>             From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] 
>
>             Sent: Tuesday, December 10, 2013 9:41 AM
>
>             To: Wiehe, Ulrich (NSN - DE/Munich)
>
>             Cc: dime@ietf.org 
>
>             Subject: Re: [Dime] OVLI: comments to 4.1
>
>              
>
>              
>
>             On Dec 9, 2013, at 4:43 PM, "Wiehe, Ulrich (NSN - DE/Munich)"   wrote:
>
>              
>
>                 But maintaining a specific state per reacting node is very resource consuming for the (overloaded) reporting node. It is simpler and more efficient to base any processing logic on actual information received in the request rather than on information stored from previous communication.
>
>              
>
>             The "state" in a reporting node is merely the current configuration
>
>             and a counter for sequence number. Hard to me see that as resource
>
>             consuming function.
>
>              
>
>             And the earlier comment of mine is done from reacting node point
>
>             of view, since it is more interested in the possible config changes
>
>             in the reporting node (e.g. S6a is stateless application, configuration
>
>             can change at any time).
>
>              
>
>             - Jouni
>
>              
>
>              
>
>                  
>
>                 Ulrich
>
>                  
>
>                 -----Original Message-----
>
>                 From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] 
>
>                 Sent: Monday, December 09, 2013 2:25 PM
>
>                 To: Wiehe, Ulrich (NSN - DE/Munich)
>
>                 Cc: dime@ietf.org 
>
>                 Subject: Re: [Dime] OVLI: comments to 4.1
>
>                  
>
>                  
>
>                 On Dec 9, 2013, at 3:13 PM, "Wiehe, Ulrich (NSN - DE/Munich)"   wrote:
>
>                  
>
>                     There is a fundamental difference:
>
>                     OLRs need to be stored, Feature-Vectors not.
>
>                  
>
>                 How come feature vector does not need to be stored? I do not
>
>                 get that? I would set my implementation to a specific state
>
>                 or mode based on the feature vector. When that changes I'd
>
>                 like to know that. And then keep functioning based on that.
>
>                  
>
>                 - Jouni
>
>                  
>
>                     When receiving an OLR you may want to know whether its worth the effort to replace an already stored OLR with the received OLR.
>
>                     When receiving a Feature-Vector you just act on it.
>
>                      
>
>                     Ulrich 
>
>                      
>
>                     -----Original Message-----
>
>                     From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] 
>
>                     Sent: Monday, December 09, 2013 1:55 PM
>
>                     To: Wiehe, Ulrich (NSN - DE/Munich)
>
>                     Cc: dime@ietf.org 
>
>                     Subject: Re: [Dime] OVLI: comments to 4.1
>
>                      
>
>                      
>
>                     In the same vein as folks wanted send OLRs with the new or old information,
>
>                     the feature vector should behave in a same way IMHO. That implies there are
>
>                     situations when a reception of the feature vector does not change anything
>
>                     in an endpoint current behavior.
>
>                      
>
>                     - Jouni
>
>                      
>
>                     On Dec 9, 2013, at 2:47 PM, "Wiehe, Ulrich (NSN - DE/Munich)"   wrote:
>
>                      
>
>                         Isn't it so that the Feature-Vector (if present) always contains something that an implementation needs to act upon?
>
>                          
>
>                         Ulrich
>
>                          
>
>                         -----Original Message-----
>
>                         From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] 
>
>                         Sent: Monday, December 09, 2013 1:12 PM
>
>                         To: Wiehe, Ulrich (NSN - DE/Munich)
>
>                         Cc: dime@ietf.org 
>
>                         Subject: Re: [Dime] OVLI: comments to 4.1
>
>                          
>
>                         Ulrich,
>
>                          
>
>                         On Dec 6, 2013, at 3:03 PM, "Wiehe, Ulrich (NSN - DE/Munich)"   wrote:
>
>                          
>
>                             Hi Jouni,
>
>                              
>
>                             thank you for your response.
>
>                              
>
>                             With regard to 3) 
>
>                             I still fail to see the usecase for Sequence-Number or TimeStamp within OC-Feature-Vector. Please clarify.
>
>                          
>
>                         Since we also allow extending the OC-Feature-Vector beyond recognition, 
>
>                         it has good chances become a rather complex grouped AVP. In that context
>
>                         the Sequence-Number allows an easy and quick way to check if the feature
>
>                         vector contains something that an implementation needs to act upon.
>
>                          
>
>                             With regard to 4)
>
>                             This was not obvious to me. (The obvious typo is the missing "of" between "one" and "the").
>
>                          
>
>                         Ack. Fixed the missing 'of'.
>
>                          
>
>                         - Jouni
>
>                          
>
>                              
>
>                             Best regards
>
>                             Ulrich
>
>                              
>
>                              
>
>                             -----Original Message-----
>
>                             From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] 
>
>                             Sent: Friday, December 06, 2013 11:17 AM
>
>                             To: Wiehe, Ulrich (NSN - DE/Munich)
>
>                             Cc: dime@ietf.org 
>
>                             Subject: Re: [Dime] OVLI: comments to 4.1
>
>                              
>
>                              
>
>                             On Dec 5, 2013, at 3:23 PM, "Wiehe, Ulrich (NSN - DE/Munich)"   wrote:
>
>                              
>
>                                 Dear all,
>
>                                  
>
>                                 here are comments to clause 4.1:
>
>                                  
>
>                                 1. The OC-Feature-Vector AVP is no longer a vector; the name of the AVP may be misleading. Proposal is to rename it to "OC-Supported-Features AVP"
>
>                              
>
>                             OK with me.
>
>                              
>
>                                 2. The OC-Feature AVP is a vector of features. Proposal is to rename it to "OC-Feature-Vector AVP"
>
>                              
>
>                             OK with me.
>
>                              
>
>                                 3. The OC-Sequence-Number within OC-Feature-Vector only makes sense if the receiving reporting endpoint can determine the identity of the reacting endpoint (which is not necessarily the origin host (client),
>
>                              
>
>                             My original proposal was to have seqnr as a timestamp. Some folks argued
>
>                             it is no good and suggested seqnr. I still think time makes more sense than
>
>                             seqnr.
>
>                              
>
>                                 it may be an agent and it may not always be the same agent), and if the reporting endpoint is required to store the OC-Feature-Vector / reacting-endpoint-identity pair (which I think both is not required). The reporting endpoint can base its processing logic on the actually received OC-Feature-Vector value, no matter whether it is brand-new or old but stil valid. Proposal is to delete OC-Sequence-Number AVP from OC-Feature-Vector.
>
>                              
>
>                             Do not agree removing it.
>
>                              
>
>                                 4. The text
>
>                                  
>
>                                 The reporting node that sends the answer also includes the OC-
>
>                                 Feature-Vector AVP that describe the capabilities it supports.  The
>
>                                 set of capabilities advertised by the reporting node depends on local
>
>                                 policies.  At least one the announced capabilities MUST match
>
>                                 mutually.  If there is no single matching capability the reacting
>
>                                 node MUST act as if it does not implement DOIC and cease inserting
>
>                                 any DOIC related AVPs into any Diameter messages with this specific
>
>                                 reacting node.
>
>                                  
>
>                                 is not clear.  Would the reporting node include the OC-Feature-Vector AVP in the answer only if there is at least one matching capability? 
>
>                              
>
>                             Because then they have found a way to exchange something that both ends
>
>                             know how to handle it.
>
>                              
>
>                                 Mandating the reacting node to cease for all time inserting OC-Feature-Vector AVPs if it did not get back 
>
>                              
>
>                             There is an obvious typo. It should say:
>
>                              
>
>                             policies.  At least one the announced capabilities MUST match
>
>                             mutually.  If there is no single matching capability the reporting
>
>                             node MUST act as if it does not implement DOIC and cease inserting
>
>                             any DOIC related AVPs into any Diameter messages with this specific
>
>                             reacting node.
>
>                              
>
>                             - JOuni
>
>                              
>
>                              
>
>                                 at least one match is also not ok. The request might have been a realm-type request (i.e. without Destination Host) and the reacting node cannot control whether subsequent requests will take the same path to the same reporting node.
>
>                                 Even if the request contains a destination host the reacting node cannot know wether the reacting node's capabilities have been modified by the time a subsequent request is sent. 
>
>                                 Proposal is to keep only the first sentence and delete the rest.
>
>                                  
>
>                                 Ulrich
>
>                                  
>
>                                  
>
>                                 _______________________________________________
>
>                                 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
>
>      
>
>  
>


--------------090105050205060503010300
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Ulrich,

      

      No, the sequence number can't be mandatory.  It always needs to be
      sent to allow for end-points that what to use the logic I
      proposed.

      

      An endpoint that receives the sequence number can choose to ignore
      it, but endpoints must always send sequence numbers.

      

      Steve

      

    
    
On 12/12/13 3:30 AM, Wiehe, Ulrich (NSN
      - DE/Munich) wrote:

    

    

      
      
      
      

        
Steve,

        
 

        
do you mean „ keep sequence number in
            OC-Supported-Features as an optional AVP that may be ignored
            by the receiver and need notbe included by the sender”?

        
 

        
Ulrich

        
 

        

          

            
From: DiME [mailto:dime-bounces@ietf.org]
                On Behalf Of ext Steve Donovan

                Sent: Wednesday, December 11, 2013 2:34 PM

                To: dime@ietf.org

                Subject: Re: [Dime] OVLI: comments to 4.1

          

        

        
 

        
Ulrich,

          

          My email showed how a reporting node could avoid the work of
          recalculating capability information on a message by message
          basis using the sequence number.  This approach does require
          maintaining state.

          

          As Ben pointed out, it is also possible to not follow my logic
          and do as you propose by ignoring the sequence number and
          going through the work of calculating the response every
          time. 
          

          

          Which approach to take is clearly an implementation decision. 
          We should keep the sequence number to allow for the stateful
          approach for implementations that are willing to take
          advantage of maintaining state to avoid work.

          

          Steve

        

          
On 12/11/13 1:34 AM, Wiehe, Ulrich (NSN -
            DE/Munich) wrote:

        

        

          
Jouni,

          
 

          
I do not agree.

          
 

          
My statement was general: reporting node may be server or SFA; supported features may be defined features (default algo) or future extensions.

          
 

          
Ulrich

          
 

          
-----Original Message-----

          
From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] 

          
Sent: Tuesday, December 10, 2013 10:46 PM

          
To: Wiehe, Ulrich (NSN - DE/Munich)

          
Cc: dime@ietf.org

          
Subject: Re: [Dime] OVLI: comments to 4.1

          
 

          
Ulrich,

          
 

          
On Dec 10, 2013, at 2:18 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> wrote:

          
 

          

            
 

            
 

            
-----Original Message-----

            
From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] 

            
Sent: Tuesday, December 10, 2013 12:32 PM

            
To: Wiehe, Ulrich (NSN - DE/Munich)

            
Cc: dime@ietf.org

            
Subject: Re: [Dime] OVLI: comments to 4.1

            
 

            
 

            
On Dec 10, 2013, at 12:41 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> wrote:

            
 

            

              
Hi Jouni,

              
 

              
my understanding from Steve's clarification was that the reporting node would setup and maintain a database of "states", one per reacting node where a state of a reacting node is identified by a sequence number and the database entry would contain the pre-calculated OLR. 

              
Hard to see how this is done without consuming resources.

            

            
 

            
It is mostly static information. Still I do not see how

            
you would get away without any state.

            
[Wiehe, Ulrich (NSN - DE/Munich)] There is no need for the reporting node to store and maintain information per reacting node because the reacting node actually tells within the request message all information the reporting node needs to know. The reporting node simply fetches the pre-calculated OLR that matches the supported features of the reacting node as indicated in the request and appends it to the answer.

          

          
 

          
This could be true for the default algorithm in this spec. However,

          
given the extension mechanism we have in place it is quite possible

          
that the assumption does not hold for new features.

          
 

          
Also, if I were to implement a server front end agent that would

          
definitely need state and still ought to comply the protocol spec.

          
 

          
- Jouni

          
 

          
 

          
 

          
 

          

            

              
Furthermore,

              
Why would the reacting node be interested in config changes of the reporting node?

              
Isn't it so that the reacting node is only interested in OLR changes?

            

            
 

            
Sigh.. say the traffic abatement algorithm changes or new features

            
get added. Those have more impact than just OLR change.

            
 

            
- Jouni

            
 

            

              
 

              
Ulrich

              
 

              
-----Original Message-----

              
From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] 

              
Sent: Tuesday, December 10, 2013 9:41 AM

              
To: Wiehe, Ulrich (NSN - DE/Munich)

              
Cc: dime@ietf.org

              
Subject: Re: [Dime] OVLI: comments to 4.1

              
 

              
 

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

              
 

              

                
But maintaining a specific state per reacting node is very resource consuming for the (overloaded) reporting node. It is simpler and more efficient to base any processing logic on actual information received in the request rather than on information stored from previous communication.

              

              
 

              
The "state" in a reporting node is merely the current configuration

              
and a counter for sequence number. Hard to me see that as resource

              
consuming function.

              
 

              
And the earlier comment of mine is done from reacting node point

              
of view, since it is more interested in the possible config changes

              
in the reporting node (e.g. S6a is stateless application, configuration

              
can change at any time).

              
 

              
- Jouni

              
 

              
 

              

                
 

                
Ulrich

                
 

                
-----Original Message-----

                
From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] 

                
Sent: Monday, December 09, 2013 2:25 PM

                
To: Wiehe, Ulrich (NSN - DE/Munich)

                
Cc: dime@ietf.org

                
Subject: Re: [Dime] OVLI: comments to 4.1

                
 

                
 

                
On Dec 9, 2013, at 3:13 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> wrote:

                
 

                

                  
There is a fundamental difference:

                  
OLRs need to be stored, Feature-Vectors not.

                

                
 

                
How come feature vector does not need to be stored? I do not

                
get that? I would set my implementation to a specific state

                
or mode based on the feature vector. When that changes I'd

                
like to know that. And then keep functioning based on that.

                
 

                
- Jouni

                
 

                

                  
When receiving an OLR you may want to know whether its worth the effort to replace an already stored OLR with the received OLR.

                  
When receiving a Feature-Vector you just act on it.

                  
 

                  
Ulrich 

                  
 

                  
-----Original Message-----

                  
From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] 

                  
Sent: Monday, December 09, 2013 1:55 PM

                  
To: Wiehe, Ulrich (NSN - DE/Munich)

                  
Cc: dime@ietf.org

                  
Subject: Re: [Dime] OVLI: comments to 4.1

                  
 

                  
 

                  
In the same vein as folks wanted send OLRs with the new or old information,

                  
the feature vector should behave in a same way IMHO. That implies there are

                  
situations when a reception of the feature vector does not change anything

                  
in an endpoint current behavior.

                  
 

                  
- Jouni

                  
 

                  
On Dec 9, 2013, at 2:47 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> wrote:

                  
 

                  

                    
Isn't it so that the Feature-Vector (if present) always contains something that an implementation needs to act upon?

                    
 

                    
Ulrich

                    
 

                    
-----Original Message-----

                    
From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] 

                    
Sent: Monday, December 09, 2013 1:12 PM

                    
To: Wiehe, Ulrich (NSN - DE/Munich)

                    
Cc: dime@ietf.org

                    
Subject: Re: [Dime] OVLI: comments to 4.1

                    
 

                    
Ulrich,

                    
 

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

                    
 

                    

                      
Hi Jouni,

                      
 

                      
thank you for your response.

                      
 

                      
With regard to 3) 

                      
I still fail to see the usecase for Sequence-Number or TimeStamp within OC-Feature-Vector. Please clarify.

                    

                    
 

                    
Since we also allow extending the OC-Feature-Vector beyond recognition, 

                    
it has good chances become a rather complex grouped AVP. In that context

                    
the Sequence-Number allows an easy and quick way to check if the feature

                    
vector contains something that an implementation needs to act upon.

                    
 

                    

                      
With regard to 4)

                      
This was not obvious to me. (The obvious typo is the missing "of" between "one" and "the").

                    

                    
 

                    
Ack. Fixed the missing 'of'.

                    
 

                    
- Jouni

                    
 

                    

                      
 

                      
Best regards

                      
Ulrich

                      
 

                      
 

                      
-----Original Message-----

                      
From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] 

                      
Sent: Friday, December 06, 2013 11:17 AM

                      
To: Wiehe, Ulrich (NSN - DE/Munich)

                      
Cc: dime@ietf.org

                      
Subject: Re: [Dime] OVLI: comments to 4.1

                      
 

                      
 

                      
On Dec 5, 2013, at 3:23 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> wrote:

                      
 

                      

                        
Dear all,

                        
 

                        
here are comments to clause 4.1:

                        
 

                        
1. The OC-Feature-Vector AVP is no longer a vector; the name of the AVP may be misleading. Proposal is to rename it to "OC-Supported-Features AVP"

                      

                      
 

                      
OK with me.

                      
 

                      

                        
2. The OC-Feature AVP is a vector of features. Proposal is to rename it to "OC-Feature-Vector AVP"

                      

                      
 

                      
OK with me.

                      
 

                      

                        
3. The OC-Sequence-Number within OC-Feature-Vector only makes sense if the receiving reporting endpoint can determine the identity of the reacting endpoint (which is not necessarily the origin host (client),

                      

                      
 

                      
My original proposal was to have seqnr as a timestamp. Some folks argued

                      
it is no good and suggested seqnr. I still think time makes more sense than

                      
seqnr.

                      
 

                      

                        
it may be an agent and it may not always be the same agent), and if the reporting endpoint is required to store the OC-Feature-Vector / reacting-endpoint-identity pair (which I think both is not required). The reporting endpoint can base its processing logic on the actually received OC-Feature-Vector value, no matter whether it is brand-new or old but stil valid. Proposal is to delete OC-Sequence-Number AVP from OC-Feature-Vector.

                      

                      
 

                      
Do not agree removing it.

                      
 

                      

                        
4. The text

                        
 

                        
The reporting node that sends the answer also includes the OC-

                        
Feature-Vector AVP that describe the capabilities it supports.  The

                        
set of capabilities advertised by the reporting node depends on local

                        
policies.  At least one the announced capabilities MUST match

                        
mutually.  If there is no single matching capability the reacting

                        
node MUST act as if it does not implement DOIC and cease inserting

                        
any DOIC related AVPs into any Diameter messages with this specific

                        
reacting node.

                        
 

                        
is not clear.  Would the reporting node include the OC-Feature-Vector AVP in the answer only if there is at least one matching capability? 

                      

                      
 

                      
Because then they have found a way to exchange something that both ends

                      
know how to handle it.

                      
 

                      

                        
Mandating the reacting node to cease for all time inserting OC-Feature-Vector AVPs if it did not get back 

                      

                      
 

                      
There is an obvious typo. It should say:

                      
 

                      
policies.  At least one the announced capabilities MUST match

                      
mutually.  If there is no single matching capability the reporting

                      
node MUST act as if it does not implement DOIC and cease inserting

                      
any DOIC related AVPs into any Diameter messages with this specific

                      
reacting node.

                      
 

                      
- JOuni

                      
 

                      
 

                      

                        
at least one match is also not ok. The request might have been a realm-type request (i.e. without Destination Host) and the reacting node cannot control whether subsequent requests will take the same path to the same reporting node.

                        
Even if the request contains a destination host the reacting node cannot know wether the reacting node's capabilities have been modified by the time a subsequent request is sent. 

                        
Proposal is to keep only the first sentence and delete the rest.

                        
 

                        
Ulrich

                        
 

                        
 

                        
_______________________________________________

                        
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

          
 

        

        
 

      

    

    

  


--------------090105050205060503010300--


From srdonovan@usdonovans.com  Thu Dec 12 05:59:17 2013
Return-Path: 
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 AE87E1AE2F4 for ; Thu, 12 Dec 2013 05:59:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.12
X-Spam-Level: 
X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no
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 b1KWwrxyY7KX for ; Thu, 12 Dec 2013 05:59:15 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 5CEA41AE2F6 for ; Thu, 12 Dec 2013 05:59:15 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:52327 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1Vr6nC-0006Zb-6A; Thu, 12 Dec 2013 05:59:07 -0800
Message-ID: <52A9C129.30501@usdonovans.com>
Date: Thu, 12 Dec 2013 07:59:05 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: "Wiehe, Ulrich (NSN - DE/Munich)" ,  Ben Campbell 
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DB1B@DEMUMBX014.nsn-intra.net>  <52A5E902.20605@usdonovans.com> <7475B713-1104-4791-96B1-CE97632A0D69@nostrum.com> <52A71632.7040806@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E48F@DEMUMBX014.nsn-intra.net> <52A86C6E.4030602@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E888@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681519E888@DEMUMBX014.nsn-intra.net>
Content-Type: multipart/alternative; boundary="------------060703000405090102080007"
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com
Cc: "dime@ietf.org list" 
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Dec 2013 13:59:17 -0000

This is a multi-part message in MIME format.
--------------060703000405090102080007
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Ulrich,

I don't understand your last statement.  How do new algorithms or
features get introduced to a network if the reporting node does not
detect that reacting nodes start supporting new features.

As I've said in other messages, the sequence number does not force
anyone to keep a state database.  It allows it but does not require it.

Steve

On 12/12/13 3:24 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
> Steve,
>
>  
>
> not sure if I correctly understand your second paragraph; please see
> inline.
>
>  
>
> Anyway I agree with your conclusion: Something is missing in the
> concept of "sequence-number in OC-Supported-Features". We WOULD need
> the DOIC end-point Diameter ID included in that AVP. I said WOULD
> because things are becoming more and more complex and complicated.
> This all is not worth the effort.  *Let's remove sequence number from
> Supported-Features*.
>
>  
>
> A Reporting node that does not support any extension (i.e. supports
> only OLR_DEFAULT_ALGO)  only needs to know whether there is a reacting
> node down stream that supports OLR_DEFAULT_ALGO    in order to decide
> whether or not a pre-calculated (default-algo-type) OLR must be
> returned or not. This can simply be done by checking bit 0 of the
> received Feature-Vector.
>
> The alternative
>
> -          to setup and maintain a database of DOIC end-point ID /
> sequence-number pairs containing the pre-calculated
> (last-known-supported-feature-type) OLR , and
>
> -          to check, when receiving a request, whether the included
> DOIC end-point ID / sequence-number pair is present in the database
> and if so return the corresponding OLR;
>
> is over-overkill.
>
>  
>
> Also there is no need for the reporting node (which still only
> supports OLR_DEFAULT_ALGO) to detect that the reacting nodes
> capabilities have been updated e.g. from "support of  
> OLR_DEFAULT_ALGO" to "support of  OLR_DEFAULT_ALGO   and
>   OLR_SOMETHING_NEW"
>
>  
>
>  
>
> Ulrich
>
>  
>
>  
>
> *From:*ext Steve Donovan [mailto:srdonovan@usdonovans.com]
> *Sent:* Wednesday, December 11, 2013 2:45 PM
> *To:* Wiehe, Ulrich (NSN - DE/Munich); Ben Campbell
> *Cc:* dime@ietf.org list
> *Subject:* Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI:
> comments to 4.3
>
>  
>
> Ulrich,
>
> Is your question how sequence numbers work when there are DOIC
> supporting agents?
>
> */[Wiehe, Ulrich (NSN - DE/Munich)] yes, when there are more than one
> DOIC supporting agents that do DOIC on behalf of a (single)
> non-DOIC-supporting Client./*
>
> The capabilities exchange is between two DOIC endpoints,
>
> */[Wiehe, Ulrich (NSN - DE/Munich)] I agree/*
>
> so in the case you outline, the server would see capability
> information from each agent in the path
>
> */[Wiehe, Ulrich (NSN - DE/Munich)] the server would see capability
> information in a received request but does not know which downstream
> node included the capability information. Not more than one node in a
> path will incude capability information./*
>
> .  The server should not see the sequence numbers from the clients.
>
> */[Wiehe, Ulrich (NSN - DE/Munich)] in the example there is only one
> client, and that does not support DOIC, so I don't understand
> "sequence numbers from the clients"/*
>
>
>
> This does point out that we are likely missing something from the
> OC-Feature-Vector AVP.  We likely need the DOIC end-point Diameter ID
> included in that AVP.
>
> Steve
>
> On 12/10/13 8:43 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
>     Steve,
>
>      
>
>     how does this work in scenarios where a non supporting client C
>     sends some requests via the DOIC supporting agent A1 to the server
>     S and other requests via a different DOIC supporting agent A2 to
>     the same server S?
>
>      
>
>     Ulrich
>
>      
>
>     *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *ext
>     Steve Donovan
>     *Sent:* Tuesday, December 10, 2013 2:25 PM
>     *To:* Ben Campbell
>     *Cc:* dime@ietf.org  list
>     *Subject:* Re: [Dime] Conclusion for Sequence Numbers - was Re:
>     OVLI: comments to 4.3
>
>      
>
>     inline
>
>     On 12/9/13 4:34 PM, Ben Campbell wrote:
>
>          
>
>         On Dec 9, 2013, at 10:00 AM, Steve Donovan   wrote:
>
>          
>
>             Jouni,
>
>              
>
>             I propose that we keep the name OC-Sequence-Number but that we use the Time type for OC-Sequence-Number.  It is misleading and potentially confusing to call it OC-Time-Stamp.  
>
>              
>
>          
>
>         I could live with that, although I would rather just define the expected properties of the sequence number, and leave the implementation up to the implementor. I assume your reasoning for not calling it a timestamp is that you do not want people to try to use it as a time base reference. If so, then we don't require any connection to a clock. We just need it to be monotonically increasing.
>
>          
>
>             We might consider expanding on the format of the AVP to make it something like Session-ID, where it is a concatenation of the Diameter-ID of the generating node and a timestamp.  This might help the reacting node keep track of which sequence number it has received.
>
>              
>
>          
>
>         Do we need a uniqueness across multiple nodes property? If so, why?
>
>     Strictly speaking, no.  The thought was to make it similar to
>     session-id and potentially make it easier for the reacting node to
>     keep differentiate sequence numbers from different reporting nodes.
>
>
>      
>
>      
>
>         Steve
>
>          
>
>         On 12/9/13 5:37 AM, Jouni Korhonen wrote:
>
>             Folks
>
>              
>
>             Could we conclude on the sequence number vs. time stamp vs. something else?
>
>             We got more important places to spend our energy than this ;)
>
>              
>
>             My proposal is the following (based on the original pre-00 design):
>
>              
>
>             o We change the OC-Sequence-Number to OC-Time-Stamp in all occurrences
>
>               in the -01.
>
>             o We use RFC6733 Time type for the OC-Time-Stamp. RFC6733 gives us
>
>               already exact definition how to handle the AVP.
>
>             o Define that the OC-Time-Stamp is the time of the creation of the 
>
>               "original" AVP within whose context the time stamp is present.
>
>             o The OC-Time-Stamp AVP uniqueness is still considered to be in scope
>
>               of the communicating endpoints.
>
>             o The time stamp can be used to quickly determine if the content of
>
>               the encapsulating AVP context has changed (among other properties).
>
>               This would be useful specifically in the future when the encapsulating
>
>               grouped AVPs  grow in size and functionality.
>
>              
>
>              
>
>             - Jouni
>
>              
>
>             _______________________________________________
>
>             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
>
>      
>
>      
>
>      
>
>  
>


--------------060703000405090102080007
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Ulrich,

      

      I don't understand your last statement.  How do new algorithms or
      features get introduced to a network if the reporting node does
      not detect that reacting nodes start supporting new features.

      

      As I've said in other messages, the sequence number does not force
      anyone to keep a state database.  It allows it but does not
      require it.

      

      Steve

      

    
    
On 12/12/13 3:24 AM, Wiehe, Ulrich (NSN
      - DE/Munich) wrote:

    

    

      
      
      
      

        
Steve,

        
 

        
not sure if I correctly understand your second
            paragraph; please see inline.

        
 

        
Anyway I agree with your conclusion: Something
            is missing in the concept of “sequence-number in
            OC-Supported-Features”. We WOULD need the DOIC end-point
            Diameter ID included in that AVP. I said WOULD because
            things are becoming more and more complex and complicated.
            This all is not worth the effort. 
            Let’s remove sequence number from Supported-Features.

        
 

        
A Reporting node that does not support any
            extension (i.e. supports only
          OLR_DEFAULT_ALGO)  only needs to know whether there is a
            reacting node down stream that supports
          OLR_DEFAULT_ALGO    in order to decide whether or not a
            pre-calculated (default-algo-type) OLR must be returned or
            not. This can simply be done by checking bit 0 of the
            received Feature-Vector.
            

        
The alternative
            

        
-         
              to setup and maintain a database of DOIC
            end-point ID / sequence-number pairs containing the
            pre-calculated (last-known-supported-feature-type) OLR , and

        
-         
              to check, when receiving a request, whether the
            included DOIC end-point ID / sequence-number pair is present
            in the database and if so return the corresponding OLR;

        
is over-overkill.

        
 

        
Also there is no need for the reporting node
            (which still only supports
          OLR_DEFAULT_ALGO ) to detect that the reacting nodes
            capabilities have been updated e.g. from “support of  
          OLR_DEFAULT_ALGO“ to “support of  OLR_DEFAULT_ALGO
            and   OLR_SOMETHING_NEW “

        
 

        
 

        
Ulrich

        
 

        
 

        

          

            
From: ext Steve Donovan
                [mailto:srdonovan@usdonovans.com]
                

                Sent: Wednesday, December 11, 2013 2:45 PM

                To: Wiehe, Ulrich (NSN - DE/Munich); Ben Campbell

                Cc: dime@ietf.org list

                Subject: Re: [Dime] Conclusion for Sequence
                Numbers - was Re: OVLI: comments to 4.3

          

        

        
 

        
Ulrich,

          

          Is your question how sequence numbers work when there are DOIC
          supporting agents?

        
[Wiehe, Ulrich (NSN - DE/Munich)] yes, when
                there are more than one DOIC supporting agents that do
                DOIC on behalf of a (single) non-DOIC-supporting Client.

            

            The capabilities exchange is between two DOIC endpoints,

        
[Wiehe, Ulrich (NSN - DE/Munich)] I agree

        
so in the case you outline, the server would
            see capability information from each agent in the path

        
[Wiehe, Ulrich (NSN - DE/Munich)] the
                server would see capability information in a received
                request but does not know which downstream node included
                the capability information. Not more than one node in a
                path will incude capability information.

        
.  The server should not see the
          sequence numbers from the clients.

        
[Wiehe, Ulrich (NSN - DE/Munich)] in the
                example there is only one client, and that does not
                support DOIC, so I don’t understand “sequence numbers
                from the clients”

        


            

            This does point out that we are likely missing something
            from the OC-Feature-Vector AVP. 
          We likely need the DOIC end-point Diameter ID included
          in that AVP.

          

          Steve

        

          
On 12/10/13 8:43 AM, Wiehe, Ulrich (NSN -
            DE/Munich) wrote:

        

        

          
Steve,

          
 

          
how does this work in scenarios where a non
              supporting client C sends some requests via the DOIC
              supporting agent A1 to the server S and other requests via
              a different DOIC supporting agent A2 to the same server S?

          
 

          
Ulrich

          
 

          

            

              
From: DiME [mailto:dime-bounces@ietf.org]
                  On Behalf Of ext Steve Donovan

                  Sent: Tuesday, December 10, 2013 2:25 PM

                  To: Ben Campbell

                  Cc: dime@ietf.org list

                  Subject: Re: [Dime] Conclusion for Sequence
                  Numbers - was Re: OVLI: comments to 4.3

            

          

          
 

          
inline

          

            
On 12/9/13 4:34 PM, Ben Campbell wrote:

          

          

            
 

            
On Dec 9, 2013, at 10:00 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:

            
 

            

              
Jouni,

              
 

              
I propose that we keep the name OC-Sequence-Number but that we use the Time type for OC-Sequence-Number.  It is misleading and potentially confusing to call it OC-Time-Stamp.  

              
 

            

            
 

            
I could live with that, although I would rather just define the expected properties of the sequence number, and leave the implementation up to the implementor. I assume your reasoning for not calling it a timestamp is that you do not want people to try to use it as a time base reference. If so, then we don't require any connection to a clock. We just need it to be monotonically increasing.

            
 

            

              
We might consider expanding on the format of the AVP to make it something like Session-ID, where it is a concatenation of the Diameter-ID of the generating node and a timestamp.  This might help the reacting node keep track of which sequence number it has received.

              
 

            

            
 

            
Do we need a uniqueness across multiple nodes property? If so, why?

          

          
Strictly speaking, no.  The thought was
            to make it similar to session-id and potentially make it
            easier for the reacting node to keep differentiate sequence
            numbers from different reporting nodes.

            

            

            

          
 

          
 

          

            
Steve

            
 

            
On 12/9/13 5:37 AM, Jouni Korhonen wrote:

            

              
Folks

              
 

              
Could we conclude on the sequence number vs. time stamp vs. something else?

              
We got more important places to spend our energy than this ;)

              
 

              
My proposal is the following (based on the original pre-00 design):

              
 

              
o We change the OC-Sequence-Number to OC-Time-Stamp in all occurrences

              
  in the -01.

              
o We use RFC6733 Time type for the OC-Time-Stamp. RFC6733 gives us

              
  already exact definition how to handle the AVP.

              
o Define that the OC-Time-Stamp is the time of the creation of the 

              
  "original" AVP within whose context the time stamp is present.

              
o The OC-Time-Stamp AVP uniqueness is still considered to be in scope

              
  of the communicating endpoints.

              
o The time stamp can be used to quickly determine if the content of

              
  the encapsulating AVP context has changed (among other properties).

              
  This would be useful specifically in the future when the encapsulating

              
  grouped AVPs  grow in size and functionality.

              
 

              
 

              
- Jouni

              
 

              
_______________________________________________

              
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

          

          
 

          
 

          
 

        

        
 

      

    

    

  


--------------060703000405090102080007--

From srdonovan@usdonovans.com  Thu Dec 12 06:03:06 2013
Return-Path: 
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 53F5E1AE2E7 for ; Thu, 12 Dec 2013 06:03:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.12
X-Spam-Level: 
X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no
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 oo4-1skXCaJ7 for ; Thu, 12 Dec 2013 06:03:04 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id D4CCC1AE2E0 for ; Thu, 12 Dec 2013 06:03:04 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:52333 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1Vr6qs-0002SX-6M; Thu, 12 Dec 2013 06:02:58 -0800
Message-ID: <52A9C20D.3030109@usdonovans.com>
Date: Thu, 12 Dec 2013 08:02:53 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Jouni Korhonen ,  Maria Cruz Bartolome 
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DB1B@DEMUMBX014.nsn-intra.net>  <52A5E902.20605@usdonovans.com> <7475B713-1104-4791-96B1-CE97632A0D69@nostrum.com>  <5BCBA1FC2B7F0B4C9D935572D90006681519E476@DEMUMBX014.nsn-intra.net> <1CD20507-B0FE-4367-804A-B831734CF060@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E6DC@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D90006681519E712@DEMUMBX014.nsn-intra.net> <4A151D70-0291-4238-85B1-03BB54B361E6@gmail.com> <52A864FF.10705@usdonovans.com> <23887553-5068-477A-AE34-3DC5E3D5AC76@gmail.com> <087A34937E64E74E848732CFF8354B920973A7D7@ESESSMB101.ericsson.se> <465BD57E-98C6-43CA-AC92-85550301B48A@gmail.com>
In-Reply-To: <465BD57E-98C6-43CA-AC92-85550301B48A@gmail.com>
Content-Type: multipart/alternative; boundary="------------030904020705060101040500"
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com
Cc: Ben Campbell , "dime@ietf.org list" 
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Dec 2013 14:03:06 -0000

This is a multi-part message in MIME format.
--------------030904020705060101040500
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Even if we state that senders of realm reports should only send
synchronized information, the protocol still needs to handle the
situation where the information isn't synchronized.  Otherwise we face
the potential for thrashing.

I also don't think we can make the broad assumption that all Diameter
networks are going to properly use NTP. 

Steve

On 12/11/13 3:38 PM, Jouni Korhonen wrote:
> Hi,
>
> On Dec 11, 2013, at 7:22 PM, Maria Cruz Bartolome  wrote:
>
>> Dear all,
>>
>>> [Steve] Ulrich does bring up an interesting use case, where a client is receiving realm reports for the same realm from different agents.  We need to define the clients behavior in this case.  
>> [Jouni] Could we simply say that in this case the agents (or who ever inserts the realm report) MUST share the same view of the realm overload condition? Obviously how it is achieved would be implementation specific. I recall we have surfaced this topic earlier..
>>
>> [MCruz] But... isn't simpler to use time instead of sequence? It would solve this case as long as any number of agents serving same realm are time synchronized.  
> Well.. time is what I have been preferring. Now Steve is also OK with that
> as long as we do not name is as a "timestamp".
>
> Just to note that clocks typically get synchronized using NTP. That would
> equal to central sequence number source with some local skew tolerance ;-)
>
> - Jouni


--------------030904020705060101040500
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Even if we state that
      senders of realm reports should only send synchronized
      information, the protocol still needs to handle the situation
      where the information isn't synchronized.  Otherwise we face the
      potential for thrashing.

      

      I also don't think we can make the broad assumption that all
      Diameter networks are going to properly use NTP.  

      

      Steve

      

    
    
On 12/11/13 3:38 PM, Jouni Korhonen
      wrote:

    

    

      
Hi,

On Dec 11, 2013, at 7:22 PM, Maria Cruz Bartolome <maria.cruz.bartolome@ericsson.com> wrote:



      

        
Dear all,



        

          
[Steve] Ulrich does bring up an interesting use case, where a client is receiving realm reports for the same realm from different agents.  We need to define the clients behavior in this case.  


        

        
[Jouni] Could we simply say that in this case the agents (or who ever inserts the realm report) MUST share the same view of the realm overload condition? Obviously how it is achieved would be implementation specific. I recall we have surfaced this topic earlier..

[MCruz] But... isn't simpler to use time instead of sequence? It would solve this case as long as any number of agents serving same realm are time synchronized.  


      

      
Well.. time is what I have been preferring. Now Steve is also OK with that
as long as we do not name is as a "timestamp".

Just to note that clocks typically get synchronized using NTP. That would
equal to central sequence number source with some local skew tolerance ;-)

- Jouni


    

    

  


--------------030904020705060101040500--

From srdonovan@usdonovans.com  Thu Dec 12 06:13:31 2013
Return-Path: 
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 9ECB41AE2A5 for ; Thu, 12 Dec 2013 06:13:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.12
X-Spam-Level: 
X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no
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 ZgXLQZB7qMPG for ; Thu, 12 Dec 2013 06:13:26 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id F2D8A1ADEC0 for ; Thu, 12 Dec 2013 06:13:25 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:52342 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1Vr70u-00057D-Ks; Thu, 12 Dec 2013 06:13:19 -0800
Message-ID: <52A9C47C.7060903@usdonovans.com>
Date: Thu, 12 Dec 2013 08:13:16 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Jouni Korhonen 
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DB1B@DEMUMBX014.nsn-intra.net>  <52A5E902.20605@usdonovans.com> <7475B713-1104-4791-96B1-CE97632A0D69@nostrum.com>  <5BCBA1FC2B7F0B4C9D935572D90006681519E476@DEMUMBX014.nsn-intra.net> <1CD20507-B0FE-4367-804A-B831734CF060@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E6DC@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D90006681519E712@DEMUMBX014.nsn-intra.net> <4A151D70-0291-4238-85B1-03BB54B361E6@gmail.com> <52A864FF.10705@usdonovans.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------040807010507040107080108"
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com
Cc: Ben Campbell , "dime@ietf.org list" 
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Dec 2013 14:13:31 -0000

This is a multi-part message in MIME format.
--------------040807010507040107080108
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

See inline.

Steve
On 12/12/13 5:36 AM, Jouni Korhonen wrote:
> Steve,
>
> On Dec 11, 2013, at 3:13 PM, Steve Donovan  wrote:
>
>> Jouni,
>>
>> We need the sequence number to be strictly increasing.  I don't see the need for it to increase in uniform amounts.  Using time does fit these requirements.  I'm ok with using time as long as we don't call the AVP timestamp.
>>
>> Ulrich does bring up an interesting use case, where a client is receiving realm reports for the same realm from different agents.  We need to define the clients behavior in this case.  
> Any suggestions? I mean agents may have hugely different view of the
> realm if they are acting on their own.
I think it is ok to say that senders of Realm reports should attempt to
send the same information.  I don't however, think this is sufficient. 
There are likely to be lags in exchanging of information between agents
sending the Realm reports. 

As I said in another email, I think we need to define the behavior for a
reacting node that receives realm reports from multiple sources.  This
probably requires including the endpoint ID in the reports.
>
>> Presumably the client needs to be able to determine who generated the realm report.  This cannot be determine based on the content of the message or the connection on which the message arrived.  It seems like we might need "Report Generator Diameter ID" in the overload report specifically for Realm reports.  
>>
>> Once the client is able to differentiate between realm reports sent by different agents (or servers) we need logic defining how the client deals with a new overload report.  
> I need now to check one of the basic assumptions on DOIC now
> so that we have the same understanding. I went back to the
> endpoint text in Section 5.1. There, for example in Figures 
> 4 and 5 the DOIC association and the endpoint assumption does
> does not work IMHO because we have no endpoint identity in the
> OLR. In order the endpoint assumption to work (as I drew it on
> the white board in Porto), it would require as many Diameter
> level sessions as there are DOIC associations.
>
> So.. has assumptions shifted in a meanwhile and I have just
> not paid attention?
SRD> I don't know if it has drifted or if people walked away with
different understandings.  We are just working through behavior text,
which is needed to fully understand the concept.  I do think we need
endpoint ID in the report, as mentioned above.
>
>> I see a couple of options (others will probably see options I am missing):
>>
>> - Use the last received realm report - This introduces the possibility of thrashing between two different reduction values and different durations.  Note that this approach does not require the source of the report to be included in the report.
>>
>> - Only listen to one source of realm overload - The approach would be to remember who sent the first overload report from the realm and ignore realm overload reports from other sources.  This behavior would likely be constrained to a single occurrence of realm overload.  Meaning that the "memory" of the report source would only last as long as that overload event persists.  Once the overload event goes away, the report source would be forgotten and a new source could be used for the next occurrence.
>>
>> On the surface, the second approach looks better to me.
> Or add the identity of the OLR originator explicitly if it
> cannot be determined implicitly (i.e. from the Diameter
> message's Origin-Host/Realm).
Yes, it might work to only require the end-point ID in realm reports.
>
> Or assume the endpoint really is the endpoint in DOIC and
> Diameter session sense.
Please explain what you mean here.  I don't understand how making
sessions and associations the same helps.
>
> - Jouni
>
>> Steve
>>
>> On 12/11/13 2:15 AM, Jouni wrote:
>>> Ulrich,
>>>
>>> I might be slow but.. Section 4.4 says
>>>
>>>    control endpoints.  The sequence number is only required to be unique
>>>    between two overload control endpoints and does not need to be
>>>
>>> Unique between two endpoints..
>>>
>>> Section 5.1 talks about endpoints:
>>>
>>>    of an arbitrary Diameter network.  The overload control information
>>>    is exchanged over on a "DOIC association" between two communication
>>>    endpoints.  The endpoints, namely the "reacting node" and the
>>>    "reporting node" do not need to be adjacent Diameter peer nodes, nor
>>>
>>> So if your agents inject realm reports, they need to be endpoints to the
>>> client. Similar to Figure 5. Therefore the sequence number spaces between
>>> C-A1 and C-A2 are separate.
>>>
>>> Now it is not clear to me, whether in your reasoning the C would see
>>> the server identity (as the endpoint) when there is an active "DEP
>>> agent" on the path. That would not clearly work and not be align with
>>> the endpoint assumption.
>>>
>>> Note that at some point of time we had (at least on a discussion level
>>> in f2f meeting) report originator identity in the OLR. That would make
>>> endpoint identification trivial. Now a "DEP agent" needs to act as a 
>>> "server" for its clients in order to appear as an endpoint.
>>>
>>> - Jouni
>>>
>>> ps: still think the use of Time is simpler..
>>>
>>>
>>> On Dec 11, 2013, at 9:43 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>>>
>>>
>>>> That's not predictable. It may be the same server in some cases, and different servers in other cases.
>>>>
>>>> -----Original Message-----
>>>> From: ext Jouni [
>>>> mailto:jouni.nospam@gmail.com
>>>> ] 
>>>> Sent: Wednesday, December 11, 2013 8:38 AM
>>>> To: Wiehe, Ulrich (NSN - DE/Munich)
>>>> Cc: Ben Campbell; 
>>>> dime@ietf.org
>>>>  list; Steve Donovan
>>>> Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3
>>>>
>>>>
>>>> Ulrich,
>>>>
>>>> On Dec 11, 2013, at 9:21 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>>>>
>>>>
>>>>> Jouni,
>>>>>
>>>>> ad 1. "monotonically" does not express your intention. What we are looking for may be "stepwise with fixed step".
>>>>>
>>>>> Ad 2. Is not necessarily a mistake that could result in out-of-sequence sequence numbers. When a client C sends a realm-type requests towards any server in the realm, an agent A1 that selects the server would send back the realm-type OLR with sequence number s1. The next realm-type request sent by C (that survived the throttling) may take a path that does not include A1 but A2. A2 then selects the server and sends back a sequence number s2. Nothing ensures that s1 and s2 are in sequence.
>>>>>
>>>> Would the server in both cases (via A1 and A2) be the same?
>>>>
>>>> - Jouni
>>>>
>>>>
>>>>
>>>>> Ulrich
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: ext Jouni Korhonen [
>>>>> mailto:jouni.nospam@gmail.com
>>>>> ] 
>>>>> Sent: Tuesday, December 10, 2013 10:31 PM
>>>>> To: Wiehe, Ulrich (NSN - DE/Munich)
>>>>> Cc: Ben Campbell; 
>>>>> dime@ietf.org
>>>>>  list; Steve Donovan
>>>>> Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3
>>>>>
>>>>> Ulrich,
>>>>>
>>>>> On Dec 10, 2013, at 4:31 PM, "Wiehe, Ulrich (NSN - DE/Munich)" 
>>>>> 
>>>>>  wrote:
>>>>>
>>>>>
>>>>>> Jouni,
>>>>>>
>>>>>> 1. I find the texts
>>>>>> a) "The sequence number ... does not need to be monotonically increasing"
>>>>>> and 
>>>>>>
>>>>> Means the delta from old-seqno to new-seqno can be any non-negative integer
>>>>> (within the given limits) not something fixed step/delta (like +1). As long as
>>>>> "new-seqno >= old-seqno" holds we are fine.
>>>>>
>>>>>
>>>>>> b) "...the new sequence number MUST be greater or equal than the old sequence number..."
>>>>>> contradicting.
>>>>>> Can you please clarify.
>>>>>>
>>>>> See above. (mind the overflow case)
>>>>>
>>>>>
>>>>>> 2. The expected behaviour when receiving an out-of-sequence sequence number within OC-OLR is described in 4.3:
>>>>>> "The receiver SHOULD discard an OC-OLR AVP with a sequence number that is less than previously received one."
>>>>>> I don't find this very robust. Once a higher sequence number (received erroneously by mistake) is accepted you cannot (easily) recover.
>>>>>>
>>>>> I find it more robust in a sense that I should not care about stale old information.
>>>>> However, since we are piggybacking (by popular demand) we have little room for seqno
>>>>> re-sync negotiation.
>>>>>
>>>>> What is the mistake you refer here? A misbehaving implementation? In that case, it 
>>>>> deserves to get a manual intervention once figured out by admins checking alarms and
>>>>> logs. If the mistake is due other things, like endpoints being out of sync, we currently
>>>>> have no written down mechanism to survive that.
>>>>>
>>>>>
>>>>>> 3. The expected behaviour when receiving an out-of-sequence sequence number within the OC-Supported-Features AVP is not described. What is the intention here?
>>>>>>
>>>>> No intention. Just a sloppy specification. You are right that something needs to be
>>>>> done & clarified here. (again the semantics of Time would nice..)
>>>>>
>>>>> I'll propose something. Others should too ;)
>>>>>
>>>>> - Jouni
>>>>>
>>>>>
>>>>>> Ulrich
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: DiME [
>>>>>> mailto:dime-bounces@ietf.org
>>>>>> ] On Behalf Of ext Jouni Korhonen
>>>>>> Sent: Tuesday, December 10, 2013 8:28 AM
>>>>>> To: Ben Campbell; 
>>>>>> dime@ietf.org
>>>>>>  list; Steve Donovan
>>>>>> Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3
>>>>>>
>>>>>>
>>>>>> Fine.. lets define then the sequence number semantics. Basic
>>>>>> unsigned integer math. The text proposal is the following:
>>>>>>
>>>>>> 4.4.  OC-Sequence-Number AVP
>>>>>>
>>>>>> The OC-Sequence-Number AVP (AVP code TBD3) is type of Unsigned64.
>>>>>> Its usage in the context of the overload control is described in
>>>>>> Sections 4.1 and 4.3.
>>>>>>
>>>>>> From the functionality point of view, the OC-Sequence-Number AVP
>>>>>> MUST be used as a non-volatile increasing counter between two
>>>>>> overload control endpoints.  The sequence number is only required
>>>>>> to be unique between two overload control endpoints and does not
>>>>>> need to be monotonically increasing.
>>>>>>
>>>>>> When comparing two sequence numbers, the new sequence number MUST
>>>>>> be greater or equal than the old sequence number within a window
>>>>>> that is half of the size of the maximum sequence number. This
>>>>>> allows a simple handling of the sequence number overflow using
>>>>>> unsigned integer arithmeticf:
>>>>>>
>>>>>>   #define WINDOW 0x8000000000000000ULL
>>>>>>
>>>>>>   bool verify_seqnum( uint64_t newsn, uint64_t oldsn ) {
>>>>>>       if (newsn - oldsn <= WINDOW)
>>>>>>           // newsn >= oldsn
>>>>>>           return true;   
>>>>>>       } else
>>>>>>           // outside window or newsn < oldsn
>>>>>>           return false;  
>>>>>>       }
>>>>>>   }
>>>>>>
>>>>>>
>>>>>>
>>>>>> The above should even work is someone shovels NTP times into
>>>>>> sequence numbers with a blind typecasting.
>>>>>>
>>>>>> - Jouni
>>>>>>
>>>>>> On Dec 10, 2013, at 12:34 AM, Ben Campbell 
>>>>>> 
>>>>>>  wrote:
>>>>>>
>>>>>>
>>>>>>> On Dec 9, 2013, at 10:00 AM, Steve Donovan 
>>>>>>>  wrote:
>>>>>>>
>>>>>>>
>>>>>>>> Jouni,
>>>>>>>>
>>>>>>>> I propose that we keep the name OC-Sequence-Number but that we use the Time type for OC-Sequence-Number.  It is misleading and potentially confusing to call it OC-Time-Stamp.  
>>>>>>>>
>>>>>>>>
>>>>>>> I could live with that, although I would rather just define the expected properties of the sequence number, and leave the implementation up to the implementor. I assume your reasoning for not calling it a timestamp is that you do not want people to try to use it as a time base reference. If so, then we don't require any connection to a clock. We just need it to be monotonically increasing.
>>>>>>>
>>>>>>>
>>>>>>>> We might consider expanding on the format of the AVP to make it something like Session-ID, where it is a concatenation of the Diameter-ID of the generating node and a timestamp.  This might help the reacting node keep track of which sequence number it has received.
>>>>>>>>
>>>>>>>>
>>>>>>> Do we need a uniqueness across multiple nodes property? If so, why?
>>>>>>>
>>>>>>>
>>>>>>>> Steve
>>>>>>>>
>>>>>>>> On 12/9/13 5:37 AM, Jouni Korhonen wrote:
>>>>>>>>
>>>>>>>>> Folks
>>>>>>>>>
>>>>>>>>> Could we conclude on the sequence number vs. time stamp vs. something else?
>>>>>>>>> We got more important places to spend our energy than this ;)
>>>>>>>>>
>>>>>>>>> My proposal is the following (based on the original pre-00 design):
>>>>>>>>>
>>>>>>>>> o We change the OC-Sequence-Number to OC-Time-Stamp in all occurrences
>>>>>>>>> in the -01.
>>>>>>>>> o We use RFC6733 Time type for the OC-Time-Stamp. RFC6733 gives us
>>>>>>>>> already exact definition how to handle the AVP.
>>>>>>>>> o Define that the OC-Time-Stamp is the time of the creation of the 
>>>>>>>>> "original" AVP within whose context the time stamp is present.
>>>>>>>>> o The OC-Time-Stamp AVP uniqueness is still considered to be in scope
>>>>>>>>> of the communicating endpoints.
>>>>>>>>> o The time stamp can be used to quickly determine if the content of
>>>>>>>>> the encapsulating AVP context has changed (among other properties).
>>>>>>>>> This would be useful specifically in the future when the encapsulating
>>>>>>>>> grouped AVPs  grow in size and functionality.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> - Jouni
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> 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
>


--------------040807010507040107080108
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    See inline.

      

      Steve

    
    
On 12/12/13 5:36 AM, Jouni Korhonen
      wrote:

    

    

      
Steve,

On Dec 11, 2013, at 3:13 PM, Steve Donovan <srdonovan@usdonovans.com> wrote:



      

        
Jouni,

We need the sequence number to be strictly increasing.  I don't see the need for it to increase in uniform amounts.  Using time does fit these requirements.  I'm ok with using time as long as we don't call the AVP timestamp.

Ulrich does bring up an interesting use case, where a client is receiving realm reports for the same realm from different agents.  We need to define the clients behavior in this case.  


      

      
Any suggestions? I mean agents may have hugely different view of the
realm if they are acting on their own.

    

    I think it is ok to say that senders of Realm reports should attempt
    to send the same information.  I don't however, think this is
    sufficient.  There are likely to be lags in exchanging of
    information between agents sending the Realm reports.  

    

    As I said in another email, I think we need to define the behavior
    for a reacting node that receives realm reports from multiple
    sources.  This probably requires including the endpoint ID in the
    reports.

    

      



      

        
Presumably the client needs to be able to determine who generated the realm report.  This cannot be determine based on the content of the message or the connection on which the message arrived.  It seems like we might need "Report Generator Diameter ID" in the overload report specifically for Realm reports.  

Once the client is able to differentiate between realm reports sent by different agents (or servers) we need logic defining how the client deals with a new overload report.  


      

      
I need now to check one of the basic assumptions on DOIC now
so that we have the same understanding. I went back to the
endpoint text in Section 5.1. There, for example in Figures 
4 and 5 the DOIC association and the endpoint assumption does
does not work IMHO because we have no endpoint identity in the
OLR. In order the endpoint assumption to work (as I drew it on
the white board in Porto), it would require as many Diameter
level sessions as there are DOIC associations.

So.. has assumptions shifted in a meanwhile and I have just
not paid attention?

    

    SRD> I don't know if it has drifted or if people walked away with
    different understandings.  We are just working through behavior
    text, which is needed to fully understand the concept.  I do think
    we need endpoint ID in the report, as mentioned above.

    

      



      

        
I see a couple of options (others will probably see options I am missing):

- Use the last received realm report - This introduces the possibility of thrashing between two different reduction values and different durations.  Note that this approach does not require the source of the report to be included in the report.

- Only listen to one source of realm overload - The approach would be to remember who sent the first overload report from the realm and ignore realm overload reports from other sources.  This behavior would likely be constrained to a single occurrence of realm overload.  Meaning that the "memory" of the report source would only last as long as that overload event persists.  Once the overload event goes away, the report source would be forgotten and a new source could be used for the next occurrence.

On the surface, the second approach looks better to me.


      

      
Or add the identity of the OLR originator explicitly if it
cannot be determined implicitly (i.e. from the Diameter
message's Origin-Host/Realm).

    

    Yes, it might work to only require the end-point ID in realm
    reports.

    

      

Or assume the endpoint really is the endpoint in DOIC and
Diameter session sense.

    

    Please explain what you mean here.  I don't understand how making
    sessions and associations the same helps.

    

      

- Jouni



      

        
Steve

On 12/11/13 2:15 AM, Jouni wrote:


        

          
Ulrich,

I might be slow but.. Section 4.4 says

   control endpoints.  The sequence number is only required to be unique
   between two overload control endpoints and does not need to be

Unique between two endpoints..

Section 5.1 talks about endpoints:

   of an arbitrary Diameter network.  The overload control information
   is exchanged over on a "DOIC association" between two communication
   endpoints.  The endpoints, namely the "reacting node" and the
   "reporting node" do not need to be adjacent Diameter peer nodes, nor

So if your agents inject realm reports, they need to be endpoints to the
client. Similar to Figure 5. Therefore the sequence number spaces between
C-A1 and C-A2 are separate.

Now it is not clear to me, whether in your reasoning the C would see
the server identity (as the endpoint) when there is an active "DEP
agent" on the path. That would not clearly work and not be align with
the endpoint assumption.

Note that at some point of time we had (at least on a discussion level
in f2f meeting) report originator identity in the OLR. That would make
endpoint identification trivial. Now a "DEP agent" needs to act as a 
"server" for its clients in order to appear as an endpoint.

- Jouni

ps: still think the use of Time is simpler..


On Dec 11, 2013, at 9:43 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:




          

            
That's not predictable. It may be the same server in some cases, and different servers in other cases.

-----Original Message-----
From: ext Jouni [
mailto:jouni.nospam@gmail.com
] 
Sent: Wednesday, December 11, 2013 8:38 AM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: Ben Campbell; 
dime@ietf.org
 list; Steve Donovan
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3


Ulrich,

On Dec 11, 2013, at 9:21 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:




            

              
Jouni,

ad 1. "monotonically" does not express your intention. What we are looking for may be "stepwise with fixed step".

Ad 2. Is not necessarily a mistake that could result in out-of-sequence sequence numbers. When a client C sends a realm-type requests towards any server in the realm, an agent A1 that selects the server would send back the realm-type OLR with sequence number s1. The next realm-type request sent by C (that survived the throttling) may take a path that does not include A1 but A2. A2 then selects the server and sends back a sequence number s2. Nothing ensures that s1 and s2 are in sequence.



            

            
Would the server in both cases (via A1 and A2) be the same?

- Jouni





            

              
Ulrich


-----Original Message-----
From: ext Jouni Korhonen [
mailto:jouni.nospam@gmail.com
] 
Sent: Tuesday, December 10, 2013 10:31 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: Ben Campbell; 
dime@ietf.org
 list; Steve Donovan
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3

Ulrich,

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




              

                
Jouni,

1. I find the texts
a) "The sequence number ... does not need to be monotonically increasing"
and 



              

              
Means the delta from old-seqno to new-seqno can be any non-negative integer
(within the given limits) not something fixed step/delta (like +1). As long as
"new-seqno >= old-seqno" holds we are fine.




              

                
b) "...the new sequence number MUST be greater or equal than the old sequence number..."
contradicting.
Can you please clarify.



              

              
See above. (mind the overflow case)




              

                
2. The expected behaviour when receiving an out-of-sequence sequence number within OC-OLR is described in 4.3:
"The receiver SHOULD discard an OC-OLR AVP with a sequence number that is less than previously received one."
I don't find this very robust. Once a higher sequence number (received erroneously by mistake) is accepted you cannot (easily) recover.



              

              
I find it more robust in a sense that I should not care about stale old information.
However, since we are piggybacking (by popular demand) we have little room for seqno
re-sync negotiation.

What is the mistake you refer here? A misbehaving implementation? In that case, it 
deserves to get a manual intervention once figured out by admins checking alarms and
logs. If the mistake is due other things, like endpoints being out of sync, we currently
have no written down mechanism to survive that.




              

                
3. The expected behaviour when receiving an out-of-sequence sequence number within the OC-Supported-Features AVP is not described. What is the intention here?



              

              
No intention. Just a sloppy specification. You are right that something needs to be
done & clarified here. (again the semantics of Time would nice..)

I'll propose something. Others should too ;)

- Jouni




              

                
Ulrich

-----Original Message-----
From: DiME [
mailto:dime-bounces@ietf.org
] On Behalf Of ext Jouni Korhonen
Sent: Tuesday, December 10, 2013 8:28 AM
To: Ben Campbell; 
dime@ietf.org
 list; Steve Donovan
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3


Fine.. lets define then the sequence number semantics. Basic
unsigned integer math. The text proposal is the following:

4.4.  OC-Sequence-Number AVP

The OC-Sequence-Number AVP (AVP code TBD3) is type of Unsigned64.
Its usage in the context of the overload control is described in
Sections 4.1 and 4.3.

>From the functionality point of view, the OC-Sequence-Number AVP
MUST be used as a non-volatile increasing counter between two
overload control endpoints.  The sequence number is only required
to be unique between two overload control endpoints and does not
need to be monotonically increasing.

When comparing two sequence numbers, the new sequence number MUST
be greater or equal than the old sequence number within a window
that is half of the size of the maximum sequence number. This
allows a simple handling of the sequence number overflow using
unsigned integer arithmeticf:

  #define WINDOW 0x8000000000000000ULL

  bool verify_seqnum( uint64_t newsn, uint64_t oldsn ) {
      if (newsn - oldsn <= WINDOW)
          // newsn >= oldsn
          return true;   
      } else
          // outside window or newsn < oldsn
          return false;  
      }
  }



The above should even work is someone shovels NTP times into
sequence numbers with a blind typecasting.

- Jouni

On Dec 10, 2013, at 12:34 AM, Ben Campbell 
<ben@nostrum.com>
 wrote:




                

                  
On Dec 9, 2013, at 10:00 AM, Steve Donovan <srdonovan@usdonovans.com>
 wrote:




                  

                    
Jouni,

I propose that we keep the name OC-Sequence-Number but that we use the Time type for OC-Sequence-Number.  It is misleading and potentially confusing to call it OC-Time-Stamp.  




                  

                  
I could live with that, although I would rather just define the expected properties of the sequence number, and leave the implementation up to the implementor. I assume your reasoning for not calling it a timestamp is that you do not want people to try to use it as a time base reference. If so, then we don't require any connection to a clock. We just need it to be monotonically increasing.




                  

                    
We might consider expanding on the format of the AVP to make it something like Session-ID, where it is a concatenation of the Diameter-ID of the generating node and a timestamp.  This might help the reacting node keep track of which sequence number it has received.




                  

                  
Do we need a uniqueness across multiple nodes property? If so, why?




                  

                    
Steve

On 12/9/13 5:37 AM, Jouni Korhonen wrote:



                    

                      
Folks

Could we conclude on the sequence number vs. time stamp vs. something else?
We got more important places to spend our energy than this ;)

My proposal is the following (based on the original pre-00 design):

o We change the OC-Sequence-Number to OC-Time-Stamp in all occurrences
in the -01.
o We use RFC6733 Time type for the OC-Time-Stamp. RFC6733 gives us
already exact definition how to handle the AVP.
o Define that the OC-Time-Stamp is the time of the creation of the 
"original" AVP within whose context the time stamp is present.
o The OC-Time-Stamp AVP uniqueness is still considered to be in scope
of the communicating endpoints.
o The time stamp can be used to quickly determine if the content of
the encapsulating AVP context has changed (among other properties).
This would be useful specifically in the future when the encapsulating
grouped AVPs  grow in size and functionality.


- Jouni

_______________________________________________
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


              

            

          

          

        

        

      

      



    

    

  


--------------040807010507040107080108--

From srdonovan@usdonovans.com  Thu Dec 12 06:20:39 2013
Return-Path: 
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 75E9D1AE2E8 for ; Thu, 12 Dec 2013 06:20:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.12
X-Spam-Level: 
X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no
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 sXYlOdHWXaTP for ; Thu, 12 Dec 2013 06:20:34 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 7930E1AE2E0 for ; Thu, 12 Dec 2013 06:20:34 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:52347 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1Vr77q-0004fj-Os; Thu, 12 Dec 2013 06:20:28 -0800
Message-ID: <52A9C62A.6010207@usdonovans.com>
Date: Thu, 12 Dec 2013 08:20:26 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: "Nirav Salot (nsalot)" ,  Jouni Korhonen 
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DB1B@DEMUMBX014.nsn-intra.net>  <52A5E902.20605@usdonovans.com> <7475B713-1104-4791-96B1-CE97632A0D69@nostrum.com>  <5BCBA1FC2B7F0B4C9D935572D90006681519E476@DEMUMBX014.nsn-intra.net> <1CD20507-B0FE-4367-804A-B831734CF060@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E6DC@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D90006681519E712@DEMUMBX014.nsn-intra.net> <4A151D70-0291-4238-85B1-03BB54B361E6@gmail.com> <52A864FF.10705@usdonovans.com>  
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------010509070101020009020303"
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com
Cc: Ben Campbell , "dime@ietf.org list" 
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Dec 2013 14:20:39 -0000

This is a multi-part message in MIME format.
--------------010509070101020009020303
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Nirav,

See inline.

Steve

On 12/12/13 6:40 AM, Nirav Salot (nsalot) wrote:
> All,
>
> I do not understand this discussion regarding different agents of the same realm having different view of the realm and provide different overload report.
We can make the statement that all senders of realm reports should send
the same report.  This does not guarantee that it will always happen. 
If agents are sending the report, they are generally distributed
elements.  In very large networks, this distribution can span
continents.  There will be a lag in the "synchronization" of the realm
overload information.

My concern is that we have well defined behavior for when a reactor
receives conflicting realm reports.  We need to avoid thrashing between
different reduction levels, which could make the overload situation worse.
> Additionally, I also do not understand the proposal of adding identity of the agent generating "realm report" into the report.
Adding the endpoint identity is needed to allow the reacting node to
know that it is receiving two different views of Realm overload from two
different reporting end-points.
> What is the use of this identity at the reacting node when the report is realm report? Why should the reacting node care who generated the realm report?
One proposal for how we deal with the fact that different reports can
have different values is to have the reacting node treat the first
reporting node as the authority for reporting realm overload state for
that overload instance.  In this case, the reacting node would ignore
reports received from other reporting nodes. In order to ignore reports
from non authoritative endpoints requires the reacting node to know
which endpoints send which reports.
>
> Regards,
> Nirav.
>
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen
> Sent: Thursday, December 12, 2013 5:06 PM
> To: Steve Donovan
> Cc: Ben Campbell; dime@ietf.org list
> Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3
>
> Steve,
>
> On Dec 11, 2013, at 3:13 PM, Steve Donovan  wrote:
>
>> Jouni,
>>
>> We need the sequence number to be strictly increasing.  I don't see the need for it to increase in uniform amounts.  Using time does fit these requirements.  I'm ok with using time as long as we don't call the AVP timestamp.
>>
>> Ulrich does bring up an interesting use case, where a client is receiving realm reports for the same realm from different agents.  We need to define the clients behavior in this case.  
> Any suggestions? I mean agents may have hugely different view of the realm if they are acting on their own.
>
>> Presumably the client needs to be able to determine who generated the realm report.  This cannot be determine based on the content of the message or the connection on which the message arrived.  It seems like we might need "Report Generator Diameter ID" in the overload report specifically for Realm reports.  
>>
>> Once the client is able to differentiate between realm reports sent by different agents (or servers) we need logic defining how the client deals with a new overload report.  
> I need now to check one of the basic assumptions on DOIC now so that we have the same understanding. I went back to the endpoint text in Section 5.1. There, for example in Figures
> 4 and 5 the DOIC association and the endpoint assumption does does not work IMHO because we have no endpoint identity in the OLR. In order the endpoint assumption to work (as I drew it on the white board in Porto), it would require as many Diameter level sessions as there are DOIC associations.
>
> So.. has assumptions shifted in a meanwhile and I have just not paid attention?
>
>> I see a couple of options (others will probably see options I am missing):
>>
>> - Use the last received realm report - This introduces the possibility of thrashing between two different reduction values and different durations.  Note that this approach does not require the source of the report to be included in the report.
>>
>> - Only listen to one source of realm overload - The approach would be to remember who sent the first overload report from the realm and ignore realm overload reports from other sources.  This behavior would likely be constrained to a single occurrence of realm overload.  Meaning that the "memory" of the report source would only last as long as that overload event persists.  Once the overload event goes away, the report source would be forgotten and a new source could be used for the next occurrence.
>>
>> On the surface, the second approach looks better to me.
> Or add the identity of the OLR originator explicitly if it cannot be determined implicitly (i.e. from the Diameter message's Origin-Host/Realm).
>
> Or assume the endpoint really is the endpoint in DOIC and Diameter session sense.
>
> - Jouni
>
>> Steve
>>
>> On 12/11/13 2:15 AM, Jouni wrote:
>>> Ulrich,
>>>
>>> I might be slow but.. Section 4.4 says
>>>
>>>    control endpoints.  The sequence number is only required to be unique
>>>    between two overload control endpoints and does not need to be
>>>
>>> Unique between two endpoints..
>>>
>>> Section 5.1 talks about endpoints:
>>>
>>>    of an arbitrary Diameter network.  The overload control information
>>>    is exchanged over on a "DOIC association" between two communication
>>>    endpoints.  The endpoints, namely the "reacting node" and the
>>>    "reporting node" do not need to be adjacent Diameter peer nodes, 
>>> nor
>>>
>>> So if your agents inject realm reports, they need to be endpoints to 
>>> the client. Similar to Figure 5. Therefore the sequence number spaces 
>>> between
>>> C-A1 and C-A2 are separate.
>>>
>>> Now it is not clear to me, whether in your reasoning the C would see 
>>> the server identity (as the endpoint) when there is an active "DEP 
>>> agent" on the path. That would not clearly work and not be align with 
>>> the endpoint assumption.
>>>
>>> Note that at some point of time we had (at least on a discussion 
>>> level in f2f meeting) report originator identity in the OLR. That 
>>> would make endpoint identification trivial. Now a "DEP agent" needs 
>>> to act as a "server" for its clients in order to appear as an endpoint.
>>>
>>> - Jouni
>>>
>>> ps: still think the use of Time is simpler..
>>>
>>>
>>> On Dec 11, 2013, at 9:43 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>>>
>>>
>>>> That's not predictable. It may be the same server in some cases, and different servers in other cases.
>>>>
>>>> -----Original Message-----
>>>> From: ext Jouni [
>>>> mailto:jouni.nospam@gmail.com
>>>> ]
>>>> Sent: Wednesday, December 11, 2013 8:38 AM
>>>> To: Wiehe, Ulrich (NSN - DE/Munich)
>>>> Cc: Ben Campbell;
>>>> dime@ietf.org
>>>>  list; Steve Donovan
>>>> Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: 
>>>> comments to 4.3
>>>>
>>>>
>>>> Ulrich,
>>>>
>>>> On Dec 11, 2013, at 9:21 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>>>>
>>>>
>>>>> Jouni,
>>>>>
>>>>> ad 1. "monotonically" does not express your intention. What we are looking for may be "stepwise with fixed step".
>>>>>
>>>>> Ad 2. Is not necessarily a mistake that could result in out-of-sequence sequence numbers. When a client C sends a realm-type requests towards any server in the realm, an agent A1 that selects the server would send back the realm-type OLR with sequence number s1. The next realm-type request sent by C (that survived the throttling) may take a path that does not include A1 but A2. A2 then selects the server and sends back a sequence number s2. Nothing ensures that s1 and s2 are in sequence.
>>>>>
>>>> Would the server in both cases (via A1 and A2) be the same?
>>>>
>>>> - Jouni
>>>>
>>>>
>>>>
>>>>> Ulrich
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: ext Jouni Korhonen [
>>>>> mailto:jouni.nospam@gmail.com
>>>>> ]
>>>>> Sent: Tuesday, December 10, 2013 10:31 PM
>>>>> To: Wiehe, Ulrich (NSN - DE/Munich)
>>>>> Cc: Ben Campbell;
>>>>> dime@ietf.org
>>>>>  list; Steve Donovan
>>>>> Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: 
>>>>> comments to 4.3
>>>>>
>>>>> Ulrich,
>>>>>
>>>>> On Dec 10, 2013, at 4:31 PM, "Wiehe, Ulrich (NSN - DE/Munich)" 
>>>>> 
>>>>>  wrote:
>>>>>
>>>>>
>>>>>> Jouni,
>>>>>>
>>>>>> 1. I find the texts
>>>>>> a) "The sequence number ... does not need to be monotonically increasing"
>>>>>> and
>>>>>>
>>>>> Means the delta from old-seqno to new-seqno can be any non-negative 
>>>>> integer (within the given limits) not something fixed step/delta 
>>>>> (like +1). As long as "new-seqno >= old-seqno" holds we are fine.
>>>>>
>>>>>
>>>>>> b) "...the new sequence number MUST be greater or equal than the old sequence number..."
>>>>>> contradicting.
>>>>>> Can you please clarify.
>>>>>>
>>>>> See above. (mind the overflow case)
>>>>>
>>>>>
>>>>>> 2. The expected behaviour when receiving an out-of-sequence sequence number within OC-OLR is described in 4.3:
>>>>>> "The receiver SHOULD discard an OC-OLR AVP with a sequence number that is less than previously received one."
>>>>>> I don't find this very robust. Once a higher sequence number (received erroneously by mistake) is accepted you cannot (easily) recover.
>>>>>>
>>>>> I find it more robust in a sense that I should not care about stale old information.
>>>>> However, since we are piggybacking (by popular demand) we have 
>>>>> little room for seqno re-sync negotiation.
>>>>>
>>>>> What is the mistake you refer here? A misbehaving implementation? 
>>>>> In that case, it deserves to get a manual intervention once figured 
>>>>> out by admins checking alarms and logs. If the mistake is due other 
>>>>> things, like endpoints being out of sync, we currently have no written down mechanism to survive that.
>>>>>
>>>>>
>>>>>> 3. The expected behaviour when receiving an out-of-sequence sequence number within the OC-Supported-Features AVP is not described. What is the intention here?
>>>>>>
>>>>> No intention. Just a sloppy specification. You are right that 
>>>>> something needs to be done & clarified here. (again the semantics 
>>>>> of Time would nice..)
>>>>>
>>>>> I'll propose something. Others should too ;)
>>>>>
>>>>> - Jouni
>>>>>
>>>>>
>>>>>> Ulrich
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: DiME [
>>>>>> mailto:dime-bounces@ietf.org
>>>>>> ] On Behalf Of ext Jouni Korhonen
>>>>>> Sent: Tuesday, December 10, 2013 8:28 AM
>>>>>> To: Ben Campbell;
>>>>>> dime@ietf.org
>>>>>>  list; Steve Donovan
>>>>>> Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: 
>>>>>> OVLI: comments to 4.3
>>>>>>
>>>>>>
>>>>>> Fine.. lets define then the sequence number semantics. Basic 
>>>>>> unsigned integer math. The text proposal is the following:
>>>>>>
>>>>>> 4.4.  OC-Sequence-Number AVP
>>>>>>
>>>>>> The OC-Sequence-Number AVP (AVP code TBD3) is type of Unsigned64.
>>>>>> Its usage in the context of the overload control is described in 
>>>>>> Sections 4.1 and 4.3.
>>>>>>
>>>>>> From the functionality point of view, the OC-Sequence-Number AVP 
>>>>>> MUST be used as a non-volatile increasing counter between two 
>>>>>> overload control endpoints.  The sequence number is only required 
>>>>>> to be unique between two overload control endpoints and does not 
>>>>>> need to be monotonically increasing.
>>>>>>
>>>>>> When comparing two sequence numbers, the new sequence number MUST 
>>>>>> be greater or equal than the old sequence number within a window 
>>>>>> that is half of the size of the maximum sequence number. This 
>>>>>> allows a simple handling of the sequence number overflow using 
>>>>>> unsigned integer arithmeticf:
>>>>>>
>>>>>>   #define WINDOW 0x8000000000000000ULL
>>>>>>
>>>>>>   bool verify_seqnum( uint64_t newsn, uint64_t oldsn ) {
>>>>>>       if (newsn - oldsn <= WINDOW)
>>>>>>           // newsn >= oldsn
>>>>>>           return true;   
>>>>>>       } else
>>>>>>           // outside window or newsn < oldsn
>>>>>>           return false;  
>>>>>>       }
>>>>>>   }
>>>>>>
>>>>>>
>>>>>>
>>>>>> The above should even work is someone shovels NTP times into 
>>>>>> sequence numbers with a blind typecasting.
>>>>>>
>>>>>> - Jouni
>>>>>>
>>>>>> On Dec 10, 2013, at 12:34 AM, Ben Campbell 
>>>>>>  wrote:
>>>>>>
>>>>>>
>>>>>>> On Dec 9, 2013, at 10:00 AM, Steve Donovan 
>>>>>>>  wrote:
>>>>>>>
>>>>>>>
>>>>>>>> Jouni,
>>>>>>>>
>>>>>>>> I propose that we keep the name OC-Sequence-Number but that we use the Time type for OC-Sequence-Number.  It is misleading and potentially confusing to call it OC-Time-Stamp.  
>>>>>>>>
>>>>>>>>
>>>>>>> I could live with that, although I would rather just define the expected properties of the sequence number, and leave the implementation up to the implementor. I assume your reasoning for not calling it a timestamp is that you do not want people to try to use it as a time base reference. If so, then we don't require any connection to a clock. We just need it to be monotonically increasing.
>>>>>>>
>>>>>>>
>>>>>>>> We might consider expanding on the format of the AVP to make it something like Session-ID, where it is a concatenation of the Diameter-ID of the generating node and a timestamp.  This might help the reacting node keep track of which sequence number it has received.
>>>>>>>>
>>>>>>>>
>>>>>>> Do we need a uniqueness across multiple nodes property? If so, why?
>>>>>>>
>>>>>>>
>>>>>>>> Steve
>>>>>>>>
>>>>>>>> On 12/9/13 5:37 AM, Jouni Korhonen wrote:
>>>>>>>>
>>>>>>>>> Folks
>>>>>>>>>
>>>>>>>>> Could we conclude on the sequence number vs. time stamp vs. something else?
>>>>>>>>> We got more important places to spend our energy than this ;)
>>>>>>>>>
>>>>>>>>> My proposal is the following (based on the original pre-00 design):
>>>>>>>>>
>>>>>>>>> o We change the OC-Sequence-Number to OC-Time-Stamp in all occurrences
>>>>>>>>> in the -01.
>>>>>>>>> o We use RFC6733 Time type for the OC-Time-Stamp. RFC6733 gives us
>>>>>>>>> already exact definition how to handle the AVP.
>>>>>>>>> o Define that the OC-Time-Stamp is the time of the creation of the 
>>>>>>>>> "original" AVP within whose context the time stamp is present.
>>>>>>>>> o The OC-Time-Stamp AVP uniqueness is still considered to be in scope
>>>>>>>>> of the communicating endpoints.
>>>>>>>>> o The time stamp can be used to quickly determine if the content of
>>>>>>>>> the encapsulating AVP context has changed (among other properties).
>>>>>>>>> This would be useful specifically in the future when the encapsulating
>>>>>>>>> grouped AVPs  grow in size and functionality.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> - Jouni
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> 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
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>


--------------010509070101020009020303
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Nirav,

      

      See inline.

      

      Steve

      

    
    
On 12/12/13 6:40 AM, Nirav Salot
      (nsalot) wrote:

    

    

      
All,

I do not understand this discussion regarding different agents of the same realm having different view of the realm and provide different overload report.

    

    We can make the statement that all senders of realm reports should
    send the same report.  This does not guarantee that it will always
    happen.  If agents are sending the report, they are generally
    distributed elements.  In very large networks, this distribution can
    span continents.  There will be a lag in the "synchronization" of
    the realm overload information.

    

    My concern is that we have well defined behavior for when a reactor
    receives conflicting realm reports.  We need to avoid thrashing
    between different reduction levels, which could make the overload
    situation worse.

    

      
Additionally, I also do not understand the proposal of adding identity of the agent generating "realm report" into the report.

    

    Adding the endpoint identity is needed to allow the reacting node to
    know that it is receiving two different views of Realm overload from
    two different reporting end-points.

    

      
What is the use of this identity at the reacting node when the report is realm report? Why should the reacting node care who generated the realm report?

    

    One proposal for how we deal with the fact that different reports
    can have different values is to have the reacting node treat the
    first reporting node as the authority for reporting realm overload
    state for that overload instance.  In this case, the reacting node
    would ignore reports received from other reporting nodes. In order
    to ignore reports from non authoritative endpoints requires the
    reacting node to know which endpoints send which reports.

    

      

Regards,
Nirav.

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen
Sent: Thursday, December 12, 2013 5:06 PM
To: Steve Donovan
Cc: Ben Campbell; dime@ietf.org list
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3

Steve,

On Dec 11, 2013, at 3:13 PM, Steve Donovan <srdonovan@usdonovans.com> wrote:



      

        
Jouni,

We need the sequence number to be strictly increasing.  I don't see the need for it to increase in uniform amounts.  Using time does fit these requirements.  I'm ok with using time as long as we don't call the AVP timestamp.

Ulrich does bring up an interesting use case, where a client is receiving realm reports for the same realm from different agents.  We need to define the clients behavior in this case.  


      

      
Any suggestions? I mean agents may have hugely different view of the realm if they are acting on their own.



      

        
Presumably the client needs to be able to determine who generated the realm report.  This cannot be determine based on the content of the message or the connection on which the message arrived.  It seems like we might need "Report Generator Diameter ID" in the overload report specifically for Realm reports.  

Once the client is able to differentiate between realm reports sent by different agents (or servers) we need logic defining how the client deals with a new overload report.  


      

      
I need now to check one of the basic assumptions on DOIC now so that we have the same understanding. I went back to the endpoint text in Section 5.1. There, for example in Figures
4 and 5 the DOIC association and the endpoint assumption does does not work IMHO because we have no endpoint identity in the OLR. In order the endpoint assumption to work (as I drew it on the white board in Porto), it would require as many Diameter level sessions as there are DOIC associations.

So.. has assumptions shifted in a meanwhile and I have just not paid attention?



      

        
I see a couple of options (others will probably see options I am missing):

- Use the last received realm report - This introduces the possibility of thrashing between two different reduction values and different durations.  Note that this approach does not require the source of the report to be included in the report.

- Only listen to one source of realm overload - The approach would be to remember who sent the first overload report from the realm and ignore realm overload reports from other sources.  This behavior would likely be constrained to a single occurrence of realm overload.  Meaning that the "memory" of the report source would only last as long as that overload event persists.  Once the overload event goes away, the report source would be forgotten and a new source could be used for the next occurrence.

On the surface, the second approach looks better to me.


      

      
Or add the identity of the OLR originator explicitly if it cannot be determined implicitly (i.e. from the Diameter message's Origin-Host/Realm).

Or assume the endpoint really is the endpoint in DOIC and Diameter session sense.

- Jouni



      

        
Steve

On 12/11/13 2:15 AM, Jouni wrote:


        

          
Ulrich,

I might be slow but.. Section 4.4 says

   control endpoints.  The sequence number is only required to be unique
   between two overload control endpoints and does not need to be

Unique between two endpoints..

Section 5.1 talks about endpoints:

   of an arbitrary Diameter network.  The overload control information
   is exchanged over on a "DOIC association" between two communication
   endpoints.  The endpoints, namely the "reacting node" and the
   "reporting node" do not need to be adjacent Diameter peer nodes, 
nor

So if your agents inject realm reports, they need to be endpoints to 
the client. Similar to Figure 5. Therefore the sequence number spaces 
between
C-A1 and C-A2 are separate.

Now it is not clear to me, whether in your reasoning the C would see 
the server identity (as the endpoint) when there is an active "DEP 
agent" on the path. That would not clearly work and not be align with 
the endpoint assumption.

Note that at some point of time we had (at least on a discussion 
level in f2f meeting) report originator identity in the OLR. That 
would make endpoint identification trivial. Now a "DEP agent" needs 
to act as a "server" for its clients in order to appear as an endpoint.

- Jouni

ps: still think the use of Time is simpler..


On Dec 11, 2013, at 9:43 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:




          

            
That's not predictable. It may be the same server in some cases, and different servers in other cases.

-----Original Message-----
From: ext Jouni [
mailto:jouni.nospam@gmail.com
]
Sent: Wednesday, December 11, 2013 8:38 AM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: Ben Campbell;
dime@ietf.org
 list; Steve Donovan
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: 
comments to 4.3


Ulrich,

On Dec 11, 2013, at 9:21 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:




            

              
Jouni,

ad 1. "monotonically" does not express your intention. What we are looking for may be "stepwise with fixed step".

Ad 2. Is not necessarily a mistake that could result in out-of-sequence sequence numbers. When a client C sends a realm-type requests towards any server in the realm, an agent A1 that selects the server would send back the realm-type OLR with sequence number s1. The next realm-type request sent by C (that survived the throttling) may take a path that does not include A1 but A2. A2 then selects the server and sends back a sequence number s2. Nothing ensures that s1 and s2 are in sequence.



            

            
Would the server in both cases (via A1 and A2) be the same?

- Jouni





            

              
Ulrich


-----Original Message-----
From: ext Jouni Korhonen [
mailto:jouni.nospam@gmail.com
]
Sent: Tuesday, December 10, 2013 10:31 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: Ben Campbell;
dime@ietf.org
 list; Steve Donovan
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: 
comments to 4.3

Ulrich,

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




              

                
Jouni,

1. I find the texts
a) "The sequence number ... does not need to be monotonically increasing"
and



              

              
Means the delta from old-seqno to new-seqno can be any non-negative 
integer (within the given limits) not something fixed step/delta 
(like +1). As long as "new-seqno >= old-seqno" holds we are fine.




              

                
b) "...the new sequence number MUST be greater or equal than the old sequence number..."
contradicting.
Can you please clarify.



              

              
See above. (mind the overflow case)




              

                
2. The expected behaviour when receiving an out-of-sequence sequence number within OC-OLR is described in 4.3:
"The receiver SHOULD discard an OC-OLR AVP with a sequence number that is less than previously received one."
I don't find this very robust. Once a higher sequence number (received erroneously by mistake) is accepted you cannot (easily) recover.



              

              
I find it more robust in a sense that I should not care about stale old information.
However, since we are piggybacking (by popular demand) we have 
little room for seqno re-sync negotiation.

What is the mistake you refer here? A misbehaving implementation? 
In that case, it deserves to get a manual intervention once figured 
out by admins checking alarms and logs. If the mistake is due other 
things, like endpoints being out of sync, we currently have no written down mechanism to survive that.




              

                
3. The expected behaviour when receiving an out-of-sequence sequence number within the OC-Supported-Features AVP is not described. What is the intention here?



              

              
No intention. Just a sloppy specification. You are right that 
something needs to be done & clarified here. (again the semantics 
of Time would nice..)

I'll propose something. Others should too ;)

- Jouni




              

                
Ulrich

-----Original Message-----
From: DiME [
mailto:dime-bounces@ietf.org
] On Behalf Of ext Jouni Korhonen
Sent: Tuesday, December 10, 2013 8:28 AM
To: Ben Campbell;
dime@ietf.org
 list; Steve Donovan
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: 
OVLI: comments to 4.3


Fine.. lets define then the sequence number semantics. Basic 
unsigned integer math. The text proposal is the following:

4.4.  OC-Sequence-Number AVP

The OC-Sequence-Number AVP (AVP code TBD3) is type of Unsigned64.
Its usage in the context of the overload control is described in 
Sections 4.1 and 4.3.

>From the functionality point of view, the OC-Sequence-Number AVP 
MUST be used as a non-volatile increasing counter between two 
overload control endpoints.  The sequence number is only required 
to be unique between two overload control endpoints and does not 
need to be monotonically increasing.

When comparing two sequence numbers, the new sequence number MUST 
be greater or equal than the old sequence number within a window 
that is half of the size of the maximum sequence number. This 
allows a simple handling of the sequence number overflow using 
unsigned integer arithmeticf:

  #define WINDOW 0x8000000000000000ULL

  bool verify_seqnum( uint64_t newsn, uint64_t oldsn ) {
      if (newsn - oldsn <= WINDOW)
          // newsn >= oldsn
          return true;   
      } else
          // outside window or newsn < oldsn
          return false;  
      }
  }



The above should even work is someone shovels NTP times into 
sequence numbers with a blind typecasting.

- Jouni

On Dec 10, 2013, at 12:34 AM, Ben Campbell <ben@nostrum.com>
 wrote:




                

                  
On Dec 9, 2013, at 10:00 AM, Steve Donovan <srdonovan@usdonovans.com>
 wrote:




                  

                    
Jouni,

I propose that we keep the name OC-Sequence-Number but that we use the Time type for OC-Sequence-Number.  It is misleading and potentially confusing to call it OC-Time-Stamp.  




                  

                  
I could live with that, although I would rather just define the expected properties of the sequence number, and leave the implementation up to the implementor. I assume your reasoning for not calling it a timestamp is that you do not want people to try to use it as a time base reference. If so, then we don't require any connection to a clock. We just need it to be monotonically increasing.




                  

                    
We might consider expanding on the format of the AVP to make it something like Session-ID, where it is a concatenation of the Diameter-ID of the generating node and a timestamp.  This might help the reacting node keep track of which sequence number it has received.




                  

                  
Do we need a uniqueness across multiple nodes property? If so, why?




                  

                    
Steve

On 12/9/13 5:37 AM, Jouni Korhonen wrote:



                    

                      
Folks

Could we conclude on the sequence number vs. time stamp vs. something else?
We got more important places to spend our energy than this ;)

My proposal is the following (based on the original pre-00 design):

o We change the OC-Sequence-Number to OC-Time-Stamp in all occurrences
in the -01.
o We use RFC6733 Time type for the OC-Time-Stamp. RFC6733 gives us
already exact definition how to handle the AVP.
o Define that the OC-Time-Stamp is the time of the creation of the 
"original" AVP within whose context the time stamp is present.
o The OC-Time-Stamp AVP uniqueness is still considered to be in scope
of the communicating endpoints.
o The time stamp can be used to quickly determine if the content of
the encapsulating AVP context has changed (among other properties).
This would be useful specifically in the future when the encapsulating
grouped AVPs  grow in size and functionality.


- Jouni

_______________________________________________
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


              

            

          

          

        

        

      

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



    

    

  


--------------010509070101020009020303--

From ulrich.wiehe@nsn.com  Thu Dec 12 07:23:14 2013
Return-Path: 
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 5821C1AE301 for ; Thu, 12 Dec 2013 07:23:14 -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 orj_mBxmJSfg for ; Thu, 12 Dec 2013 07:23:05 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 7694E1A1F61 for ; Thu, 12 Dec 2013 07:23:04 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rBCFMu47025705 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 12 Dec 2013 16:22:56 +0100
Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rBCFMuFl011322 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Dec 2013 16:22:56 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.152]) by DEMUHTC004.nsn-intra.net ([10.159.42.35]) with mapi id 14.03.0123.003; Thu, 12 Dec 2013 16:22:55 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Steve Donovan , "dime@ietf.org" 
Thread-Topic: [Dime] OVLI: comments to 4.1
Thread-Index: Ac7xvTHHIECkLcDwSDuVAh2ACeOasAAprlMAAAaV6CAAlFJBAAADLijg///yiAD//+yxwIAAG3gA///jPWCAAV/bAP//0rCwAAujOgD//+gx4P//PIoA//3FKSD/+zWWgP/1DNgg/+nfowD/05n2AA==
Date: Thu, 12 Dec 2013 15:22:55 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519E9BE@DEMUMBX014.nsn-intra.net>
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DA3E@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681519DCE5@DEMUMBX014.nsn-intra.net> <09616DA2-D1ED-40EE-8E89-755DFCD81092@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E02B@DEMUMBX014.nsn-intra.net> <1A402C59-E390-4C95-8E30-97F1F9D3EF0F@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E05C@DEMUMBX014.nsn-intra.net> <790F1603-64D5-40E2-BC59-FD4C104EEF1B@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E0D9@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D90006681519E331@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D90006681519E3C4@DEMUMBX014.nsn-intra.net> <0CDBF4BB-4E38-41D6-A5E2-9218FFEFEA43@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E6EF@DEMUMBX014.nsn-intra.net> <52A869AD.6080305@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E89B@DEMUMBX014.nsn-intra.net> <52A9C040.40206@usdonovans.com>
In-Reply-To: <52A9C040.40206@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.100]
Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D90006681519E9BEDEMUMBX014nsnin_"
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: 40733
X-purgate-ID: 151667::1386861777-00000661-1D831E72/0-0/0-0
Subject: Re: [Dime] OVLI: comments to 4.1
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Dec 2013 15:23:14 -0000

--_000_5BCBA1FC2B7F0B4C9D935572D90006681519E9BEDEMUMBX014nsnin_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Steve,

you probably mean "...can't  be optional..." rather than "...can't be manda=
tory..."

If so, I understand your logic but this means that  reacting nodes are forc=
ed to  implement sequence numbers in OC-Supported-Features just because som=
e reporting nodes prefer to do things complicated rather than simple and I'=
m not convinced that this would be the way to go.

Ulrich


From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Thursday, December 12, 2013 2:55 PM
To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
Subject: Re: [Dime] OVLI: comments to 4.1

Ulrich,

No, the sequence number can't be mandatory.  It always needs to be sent to =
allow for end-points that what to use the logic I proposed.

An endpoint that receives the sequence number can choose to ignore it, but =
endpoints must always send sequence numbers.

Steve
On 12/12/13 3:30 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
Steve,

do you mean " keep sequence number in OC-Supported-Features as an optional =
AVP that may be ignored by the receiver and need notbe included by the send=
er"?

Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Wednesday, December 11, 2013 2:34 PM
To: dime@ietf.org
Subject: Re: [Dime] OVLI: comments to 4.1

Ulrich,

My email showed how a reporting node could avoid the work of recalculating =
capability information on a message by message basis using the sequence num=
ber.  This approach does require maintaining state.

As Ben pointed out, it is also possible to not follow my logic and do as yo=
u propose by ignoring the sequence number and going through the work of cal=
culating the response every time.

Which approach to take is clearly an implementation decision.  We should ke=
ep the sequence number to allow for the stateful approach for implementatio=
ns that are willing to take advantage of maintaining state to avoid work.

Steve
On 12/11/13 1:34 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:

Jouni,



I do not agree.



My statement was general: reporting node may be server or SFA; supported fe=
atures may be defined features (default algo) or future extensions.



Ulrich



-----Original Message-----

From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Sent: Tuesday, December 10, 2013 10:46 PM

To: Wiehe, Ulrich (NSN - DE/Munich)

Cc: dime@ietf.org

Subject: Re: [Dime] OVLI: comments to 4.1



Ulrich,



On Dec 10, 2013, at 2:18 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:







-----Original Message-----

From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Sent: Tuesday, December 10, 2013 12:32 PM

To: Wiehe, Ulrich (NSN - DE/Munich)

Cc: dime@ietf.org

Subject: Re: [Dime] OVLI: comments to 4.1





On Dec 10, 2013, at 12:41 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:



Hi Jouni,



my understanding from Steve's clarification was that the reporting node wou=
ld setup and maintain a database of "states", one per reacting node where a=
 state of a reacting node is identified by a sequence number and the databa=
se entry would contain the pre-calculated OLR.

Hard to see how this is done without consuming resources.



It is mostly static information. Still I do not see how

you would get away without any state.

[Wiehe, Ulrich (NSN - DE/Munich)] There is no need for the reporting node t=
o store and maintain information per reacting node because the reacting nod=
e actually tells within the request message all information the reporting n=
ode needs to know. The reporting node simply fetches the pre-calculated OLR=
 that matches the supported features of the reacting node as indicated in t=
he request and appends it to the answer.



This could be true for the default algorithm in this spec. However,

given the extension mechanism we have in place it is quite possible

that the assumption does not hold for new features.



Also, if I were to implement a server front end agent that would

definitely need state and still ought to comply the protocol spec.



- Jouni









Furthermore,

Why would the reacting node be interested in config changes of the reportin=
g node?

Isn't it so that the reacting node is only interested in OLR changes?



Sigh.. say the traffic abatement algorithm changes or new features

get added. Those have more impact than just OLR change.



- Jouni





Ulrich



-----Original Message-----

From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Sent: Tuesday, December 10, 2013 9:41 AM

To: Wiehe, Ulrich (NSN - DE/Munich)

Cc: dime@ietf.org

Subject: Re: [Dime] OVLI: comments to 4.1





On Dec 9, 2013, at 4:43 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:



But maintaining a specific state per reacting node is very resource consumi=
ng for the (overloaded) reporting node. It is simpler and more efficient to=
 base any processing logic on actual information received in the request ra=
ther than on information stored from previous communication.



The "state" in a reporting node is merely the current configuration

and a counter for sequence number. Hard to me see that as resource

consuming function.



And the earlier comment of mine is done from reacting node point

of view, since it is more interested in the possible config changes

in the reporting node (e.g. S6a is stateless application, configuration

can change at any time).



- Jouni







Ulrich



-----Original Message-----

From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Sent: Monday, December 09, 2013 2:25 PM

To: Wiehe, Ulrich (NSN - DE/Munich)

Cc: dime@ietf.org

Subject: Re: [Dime] OVLI: comments to 4.1





On Dec 9, 2013, at 3:13 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:



There is a fundamental difference:

OLRs need to be stored, Feature-Vectors not.



How come feature vector does not need to be stored? I do not

get that? I would set my implementation to a specific state

or mode based on the feature vector. When that changes I'd

like to know that. And then keep functioning based on that.



- Jouni



When receiving an OLR you may want to know whether its worth the effort to =
replace an already stored OLR with the received OLR.

When receiving a Feature-Vector you just act on it.



Ulrich



-----Original Message-----

From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Sent: Monday, December 09, 2013 1:55 PM

To: Wiehe, Ulrich (NSN - DE/Munich)

Cc: dime@ietf.org

Subject: Re: [Dime] OVLI: comments to 4.1





In the same vein as folks wanted send OLRs with the new or old information,

the feature vector should behave in a same way IMHO. That implies there are

situations when a reception of the feature vector does not change anything

in an endpoint current behavior.



- Jouni



On Dec 9, 2013, at 2:47 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:



Isn't it so that the Feature-Vector (if present) always contains something =
that an implementation needs to act upon?



Ulrich



-----Original Message-----

From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Sent: Monday, December 09, 2013 1:12 PM

To: Wiehe, Ulrich (NSN - DE/Munich)

Cc: dime@ietf.org

Subject: Re: [Dime] OVLI: comments to 4.1



Ulrich,



On Dec 6, 2013, at 3:03 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:



Hi Jouni,



thank you for your response.



With regard to 3)

I still fail to see the usecase for Sequence-Number or TimeStamp within OC-=
Feature-Vector. Please clarify.



Since we also allow extending the OC-Feature-Vector beyond recognition,

it has good chances become a rather complex grouped AVP. In that context

the Sequence-Number allows an easy and quick way to check if the feature

vector contains something that an implementation needs to act upon.



With regard to 4)

This was not obvious to me. (The obvious typo is the missing "of" between "=
one" and "the").



Ack. Fixed the missing 'of'.



- Jouni





Best regards

Ulrich





-----Original Message-----

From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Sent: Friday, December 06, 2013 11:17 AM

To: Wiehe, Ulrich (NSN - DE/Munich)

Cc: dime@ietf.org

Subject: Re: [Dime] OVLI: comments to 4.1





On Dec 5, 2013, at 3:23 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:



Dear all,



here are comments to clause 4.1:



1. The OC-Feature-Vector AVP is no longer a vector; the name of the AVP may=
 be misleading. Proposal is to rename it to "OC-Supported-Features AVP"



OK with me.



2. The OC-Feature AVP is a vector of features. Proposal is to rename it to =
"OC-Feature-Vector AVP"



OK with me.



3. The OC-Sequence-Number within OC-Feature-Vector only makes sense if the =
receiving reporting endpoint can determine the identity of the reacting end=
point (which is not necessarily the origin host (client),



My original proposal was to have seqnr as a timestamp. Some folks argued

it is no good and suggested seqnr. I still think time makes more sense than

seqnr.



it may be an agent and it may not always be the same agent), and if the rep=
orting endpoint is required to store the OC-Feature-Vector / reacting-endpo=
int-identity pair (which I think both is not required). The reporting endpo=
int can base its processing logic on the actually received OC-Feature-Vecto=
r value, no matter whether it is brand-new or old but stil valid. Proposal =
is to delete OC-Sequence-Number AVP from OC-Feature-Vector.



Do not agree removing it.



4. The text



The reporting node that sends the answer also includes the OC-

Feature-Vector AVP that describe the capabilities it supports.  The

set of capabilities advertised by the reporting node depends on local

policies.  At least one the announced capabilities MUST match

mutually.  If there is no single matching capability the reacting

node MUST act as if it does not implement DOIC and cease inserting

any DOIC related AVPs into any Diameter messages with this specific

reacting node.



is not clear.  Would the reporting node include the OC-Feature-Vector AVP i=
n the answer only if there is at least one matching capability?



Because then they have found a way to exchange something that both ends

know how to handle it.



Mandating the reacting node to cease for all time inserting OC-Feature-Vect=
or AVPs if it did not get back



There is an obvious typo. It should say:



policies.  At least one the announced capabilities MUST match

mutually.  If there is no single matching capability the reporting

node MUST act as if it does not implement DOIC and cease inserting

any DOIC related AVPs into any Diameter messages with this specific

reacting node.



- JOuni





at least one match is also not ok. The request might have been a realm-type=
 request (i.e. without Destination Host) and the reacting node cannot contr=
ol whether subsequent requests will take the same path to the same reportin=
g node.

Even if the request contains a destination host the reacting node cannot kn=
ow wether the reacting node's capabilities have been modified by the time a=
 subsequent request is sent.

Proposal is to keep only the first sentence and delete the rest.



Ulrich





_______________________________________________

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





--_000_5BCBA1FC2B7F0B4C9D935572D90006681519E9BEDEMUMBX014nsnin_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Steve,<=
/p>

 <=
/p>

you probab=
ly mean „…can’t  be optional…“ rather th=
an “…can’t be mandatory…”

 =
;


If so, I u=
nderstand your logic but this means that  reacting nodes are forced to=
  implement sequence numbers in OC-Supported-Features just because
 some reporting nodes prefer to do things complicated rather than simple an=
d I’m not convinced that this would be the way to go.


 =
;


Ulrich


 =
;


 =
;






From:=
 ext Steve Donovan [=
mailto:srdonovan@usdonovans.com]


Sent: Thursday, December 12, 2013 2:55 PM

To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org

Subject: Re: [Dime] OVLI: comments to 4.1






 


Ulrich,



No, the sequence number can't be mandatory.  It always needs to be sen=
t to allow for end-points that what to use the logic I proposed.



An endpoint that receives the sequence number can choose to ignore it, but =
endpoints must always send sequence numbers.



Steve




On 12/12/13 3:30 AM, Wiehe, Ulrich (NSN - DE/Munich)=
 wrote:






Steve,


 


do you mea=
n „ keep sequence number in OC-Supported-Features as an optional AVP =
that may be ignored by the receiver and need notbe included by the
 sender”?


 


Ulrich


 






From:=
 DiME [mailto:dime-bounces@ietf.org]
On Behalf Of ext Steve Donovan

Sent: Wednesday, December 11, 2013 2:34 PM

To: dime@ietf.org

Subject: Re: [Dime] OVLI: comments to 4.1






 


Ulrich,



My email showed how a reporting node could avoid the work of recalculating =
capability information on a message by message basis using the sequence num=
ber.  This approach does require maintaining state.



As Ben pointed out, it is also possible to not follow my logic and do as yo=
u propose by ignoring the sequence number and going through the work of cal=
culating the response every time. 




Which approach to take is clearly an implementation decision.  We shou=
ld keep the sequence number to allow for the stateful approach for implemen=
tations that are willing to take advantage of maintaining state to avoid wo=
rk.



Steve




On 12/11/13 1:34 AM, Wiehe, Ulrich (NSN - DE/Munich)=
 wrote:






Jouni,


 


I do not agree.


 


My statement was general: reporting node may be server or SFA; support=
ed features may be defined features (default algo) or future extensions.


 


Ulrich


 


-----Original Message-----


From: ext Jouni Korhonen [ma=
ilto:jouni.nospam@gmail.com] 


Sent: Tuesday, December 10, 2013 10:46 PM


To: Wiehe, Ulrich (NSN - DE/Munich)


Cc: dime@ietf.org

Subject: Re: [Dime] OVLI: comments to 4.1


 


Ulrich,


 


On Dec 10, 2013, at 2:18 PM, "Wiehe, Ulrich (NSN - DE/Munich)&quo=
t; <ulrich.wiehe@nsn.com>=
 wrote:


 




 


 


-----Original Message-----


From: ext Jouni Korhonen [ma=
ilto:jouni.nospam@gmail.com] 


Sent: Tuesday, December 10, 2013 12:32 PM


To: Wiehe, Ulrich (NSN - DE/Munich)


Cc: dime@ietf.org

Subject: Re: [Dime] OVLI: comments to 4.1


 


 


On Dec 10, 2013, at 12:41 PM, "Wiehe, Ulrich (NSN - DE/Munich)&qu=
ot; <ulrich.wiehe@nsn.com> wrote:


 




Hi Jouni,


 


my understanding from Steve's clarification was that the reporting nod=
e would setup and maintain a database of "states", one per reacti=
ng node where a state of a reacting node is identified by a sequence number=
 and the database entry would contain the pre-calculated OLR. 

Hard to see how this is done without consuming resources.



 


It is mostly static information. Still I do not see how

you would get away without any state.


[Wiehe, Ulrich (NSN - DE/Munich)] There is no need for the reporting n=
ode to store and maintain information per reacting node because the reactin=
g node actually tells within the request message all information the report=
ing node needs to know. The reporting node simply fetches the pre-calculate=
d OLR that matches the supported features of the reacting node as indicated=
 in the request and appends it to the answer.




 


This could be true for the default algorithm in this spec. However,


given the extension mechanism we have in place it is quite possible


that the assumption does not hold for new features.


 


Also, if I were to implement a server front end agent that would<=
/o:p>


definitely need state and still ought to comply the protocol spec.


 


- Jouni


 


 


 


 






Furthermore,


Why would the reacting node be interested in config changes of the rep=
orting node?


Isn't it so that the reacting node is only interested in OLR changes?<=
o:p>




 


Sigh.. say the traffic abatement algorithm changes or new features


get added. Those have more impact than just OLR change.

 


- Jouni


 




 


Ulrich


 


-----Original Message-----


From: ext Jouni Korhonen [ma=
ilto:jouni.nospam@gmail.com] 


Sent: Tuesday, December 10, 2013 9:41 AM


To: Wiehe, Ulrich (NSN - DE/Munich)


Cc: dime@ietf.org

Subject: Re: [Dime] OVLI: comments to 4.1


 


 


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


 




But maintaining a specific state per reacting node is very resource co=
nsuming for the (overloaded) reporting node. It is simpler and more efficie=
nt to base any processing logic on actual information received in the reque=
st rather than on information stored from previous communication.




 


The "state" in a reporting node is merely the current config=
uration


and a counter for sequence number. Hard to me see that as resource


consuming function.


 


And the earlier comment of mine is done from reacting node point<=
/o:p>


of view, since it is more interested in the possible config changes


in the reporting node (e.g. S6a is stateless application, configuratio=
n


can change at any time).


 


- Jouni


 


 




 


Ulrich


 


-----Original Message-----


From: ext Jouni Korhonen [ma=
ilto:jouni.nospam@gmail.com] 


Sent: Monday, December 09, 2013 2:25 PM


To: Wiehe, Ulrich (NSN - DE/Munich)


Cc: dime@ietf.org

Subject: Re: [Dime] OVLI: comments to 4.1


 


 


On Dec 9, 2013, at 3:13 PM, "Wiehe, Ulrich (NSN - DE/Munich)"=
; <ulrich.wiehe@nsn.com> =
wrote:


 




There is a fundamental difference:


OLRs need to be stored, Feature-Vectors not.




 


How come feature vector does not need to be stored? I do not


get that? I would set my implementation to a specific state=



or mode based on the feature vector. When that changes I'd<=
/pre>

like to know that. And then keep functioning based on that.=



 


- Jouni


 




When receiving an OLR you may want to know whether its worth the effor=
t to replace an already stored OLR with the received OLR.


When receiving a Feature-Vector you just act on it.


 


Ulrich 


 


-----Original Message-----


From: ext Jouni Korhonen [ma=
ilto:jouni.nospam@gmail.com] 


Sent: Monday, December 09, 2013 1:55 PM


To: Wiehe, Ulrich (NSN - DE/Munich)


Cc: dime@ietf.org

Subject: Re: [Dime] OVLI: comments to 4.1


 


 


In the same vein as folks wanted send OLRs with the new or old informa=
tion,


the feature vector should behave in a same way IMHO. That implies ther=
e are


situations when a reception of the feature vector does not change anyt=
hing


in an endpoint current behavior.


 


- Jouni


 


On Dec 9, 2013, at 2:47 PM, "Wiehe, Ulrich (NSN - DE/Munich)"=
; <ulrich.wiehe@nsn.com> =
wrote:


 




Isn't it so that the Feature-Vector (if present) always contains somet=
hing that an implementation needs to act upon?


 


Ulrich


 


-----Original Message-----


From: ext Jouni Korhonen [ma=
ilto:jouni.nospam@gmail.com] 


Sent: Monday, December 09, 2013 1:12 PM


To: Wiehe, Ulrich (NSN - DE/Munich)


Cc: dime@ietf.org

Subject: Re: [Dime] OVLI: comments to 4.1


 


Ulrich,


 


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


 




Hi Jouni,


 


thank you for your response.


 


With regard to 3) 


I still fail to see the usecase for Sequence-Number or TimeStamp withi=
n OC-Feature-Vector. Please clarify.




 


Since we also allow extending the OC-Feature-Vector beyond recognition=
, 


it has good chances become a rather complex grouped AVP. In that conte=
xt


the Sequence-Number allows an easy and quick way to check if the featu=
re


vector contains something that an implementation needs to act upon.


 




With regard to 4)


This was not obvious to me. (The obvious typo is the missing "of&=
quot; between "one" and "the").




 


Ack. Fixed the missing 'of'.


 


- Jouni


 




 


Best regards


Ulrich


 


 


-----Original Message-----


From: ext Jouni Korhonen [ma=
ilto:jouni.nospam@gmail.com] 


Sent: Friday, December 06, 2013 11:17 AM


To: Wiehe, Ulrich (NSN - DE/Munich)


Cc: dime@ietf.org

Subject: Re: [Dime] OVLI: comments to 4.1


 


 


On Dec 5, 2013, at 3:23 PM, "Wiehe, Ulrich (NSN - DE/Munich)"=
; <ulrich.wiehe@nsn.com> =
wrote:


 




Dear all,


 


here are comments to clause 4.1:


 


1. The OC-Feature-Vector AVP is no longer a vector; the name of the AV=
P may be misleading. Proposal is to rename it to "OC-Supported-Feature=
s AVP"




 


OK with me.


 




2. The OC-Feature AVP is a vector of features. Proposal is to rename i=
t to "OC-Feature-Vector AVP"




 


OK with me.


 




3. The OC-Sequence-Number within OC-Feature-Vector only makes sense if=
 the receiving reporting endpoint can determine the identity of the reactin=
g endpoint (which is not necessarily the origin host (client),



 


My original proposal was to have seqnr as a timestamp. Some folks argu=
ed


it is no good and suggested seqnr. I still think time makes more sense=
 than


seqnr.


 




it may be an agent and it may not always be the same agent), and if th=
e reporting endpoint is required to store the OC-Feature-Vector / reacting-=
endpoint-identity pair (which I think both is not required). The reporting =
endpoint can base its processing logic on the actually received OC-Feature-=
Vector value, no matter whether it is brand-new or old but stil valid. Prop=
osal is to delete OC-Sequence-Number AVP from OC-Feature-Vector.=





 


Do not agree removing it.


 




4. The text


 


The reporting node that sends the answer also includes the OC-


Feature-Vector AVP that describe the capabilities it supports.  T=
he


set of capabilities advertised by the reporting node depends on local<=
o:p>


policies.  At least one the announced capabilities MUST match


mutually.  If there is no single matching capability the reacting=



node MUST act as if it does not implement DOIC and cease inserting


any DOIC related AVPs into any Diameter messages with this specific


reacting node.


 


is not clear.  Would the reporting node include the OC-Feature-Ve=
ctor AVP in the answer only if there is at least one matching capability? <=
o:p>




 


Because then they have found a way to exchange something that both end=
s


know how to handle it.


 




Mandating the reacting node to cease for all time inserting OC-Feature=
-Vector AVPs if it did not get back 




 


There is an obvious typo. It should say:


 


policies.  At least one the announced capabilities MUST match


mutually.  If there is no single matching capability the reportin=
g


node MUST act as if it does not implement DOIC and cease inserting


any DOIC related AVPs into any Diameter messages with this specific


reacting node.


 


- JOuni


 


 




at least one match is also not ok. The request might have been a realm=
-type request (i.e. without Destination Host) and the reacting node cannot =
control whether subsequent requests will take the same path to the same rep=
orting node.


Even if the request contains a destination host the reacting node cann=
ot know wether the reacting node's capabilities have been modified by the t=
ime a subsequent request is sent. 


Proposal is to keep only the first sentence and delete the rest.<=
/o:p>


 


Ulrich


 


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime




 




 




 




 




 




 




 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 




 




 






--_000_5BCBA1FC2B7F0B4C9D935572D90006681519E9BEDEMUMBX014nsnin_--


From ulrich.wiehe@nsn.com  Thu Dec 12 07:33:01 2013
Return-Path: 
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 9B9B01AE324 for ; Thu, 12 Dec 2013 07:33:01 -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 Wm5eU2phyJ8n for ; Thu, 12 Dec 2013 07:32:56 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id A37B81AE319 for ; Thu, 12 Dec 2013 07:32:55 -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 rBCFWlQT002183 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 12 Dec 2013 16:32:47 +0100
Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rBCFWkR2007172 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Dec 2013 16:32:46 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.152]) by DEMUHTC003.nsn-intra.net ([10.159.42.34]) with mapi id 14.03.0123.003; Thu, 12 Dec 2013 16:32:46 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Steve Donovan , Ben Campbell 
Thread-Topic: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3
Thread-Index: AQHO9atFkoRa3B+doUWxxFMNrNdzoppNfy7wgAFzLACAAUbUgIAAT1uAgAAothA=
Date: Thu, 12 Dec 2013 15:32:45 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519E9DA@DEMUMBX014.nsn-intra.net>
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DB1B@DEMUMBX014.nsn-intra.net>  <52A5E902.20605@usdonovans.com> <7475B713-1104-4791-96B1-CE97632A0D69@nostrum.com> <52A71632.7040806@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E48F@DEMUMBX014.nsn-intra.net> <52A86C6E.4030602@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E888@DEMUMBX014.nsn-intra.net> <52A9C129.30501@usdonovans.com>
In-Reply-To: <52A9C129.30501@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.100]
Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D90006681519E9DADEMUMBX014nsnin_"
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: 32558
X-purgate-ID: 151667::1386862368-00001A6F-159DDCA1/0-0/0-0
Cc: "dime@ietf.org list" 
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Dec 2013 15:33:01 -0000

--_000_5BCBA1FC2B7F0B4C9D935572D90006681519E9DADEMUMBX014nsnin_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Steve,

Why would a reporting node that only supports OLR_DEFAULT_ALGO  and does no=
t support any other feature need to detect that a reacting node supports lo=
ts of new features in addition to OLR_DEFAULT_ALGO ? Even if it dectets sup=
port of new features by the reacting node, the reporting node would not beh=
ave any differently than before detecting this.

Ulrich

From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Thursday, December 12, 2013 2:59 PM
To: Wiehe, Ulrich (NSN - DE/Munich); Ben Campbell
Cc: dime@ietf.org list
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comment=
s to 4.3

Ulrich,

I don't understand your last statement.  How do new algorithms or features =
get introduced to a network if the reporting node does not detect that reac=
ting nodes start supporting new features.

As I've said in other messages, the sequence number does not force anyone t=
o keep a state database.  It allows it but does not require it.

Steve
On 12/12/13 3:24 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
Steve,

not sure if I correctly understand your second paragraph; please see inline=
.

Anyway I agree with your conclusion: Something is missing in the concept of=
 "sequence-number in OC-Supported-Features". We WOULD need the DOIC end-poi=
nt Diameter ID included in that AVP. I said WOULD because things are becomi=
ng more and more complex and complicated. This all is not worth the effort.=
  Let's remove sequence number from Supported-Features.

A Reporting node that does not support any extension (i.e. supports only OL=
R_DEFAULT_ALGO)  only needs to know whether there is a reacting node down s=
tream that supports OLR_DEFAULT_ALGO    in order to decide whether or not a=
 pre-calculated (default-algo-type) OLR must be returned or not. This can s=
imply be done by checking bit 0 of the received Feature-Vector.
The alternative

-          to setup and maintain a database of DOIC end-point ID / sequence=
-number pairs containing the pre-calculated (last-known-supported-feature-t=
ype) OLR , and

-          to check, when receiving a request, whether the included DOIC en=
d-point ID / sequence-number pair is present in the database and if so retu=
rn the corresponding OLR;
is over-overkill.

Also there is no need for the reporting node (which still only supports OLR=
_DEFAULT_ALGO ) to detect that the reacting nodes capabilities have been up=
dated e.g. from "support of   OLR_DEFAULT_ALGO" to "support of  OLR_DEFAULT=
_ALGO   and   OLR_SOMETHING_NEW "


Ulrich


From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Wednesday, December 11, 2013 2:45 PM
To: Wiehe, Ulrich (NSN - DE/Munich); Ben Campbell
Cc: dime@ietf.org list
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comment=
s to 4.3

Ulrich,

Is your question how sequence numbers work when there are DOIC supporting a=
gents?
[Wiehe, Ulrich (NSN - DE/Munich)] yes, when there are more than one DOIC su=
pporting agents that do DOIC on behalf of a (single) non-DOIC-supporting Cl=
ient.

The capabilities exchange is between two DOIC endpoints,
[Wiehe, Ulrich (NSN - DE/Munich)] I agree
so in the case you outline, the server would see capability information fro=
m each agent in the path
[Wiehe, Ulrich (NSN - DE/Munich)] the server would see capability informati=
on in a received request but does not know which downstream node included t=
he capability information. Not more than one node in a path will incude cap=
ability information.
.  The server should not see the sequence numbers from the clients.
[Wiehe, Ulrich (NSN - DE/Munich)] in the example there is only one client, =
and that does not support DOIC, so I don't understand "sequence numbers fro=
m the clients"


This does point out that we are likely missing something from the OC-Featur=
e-Vector AVP.  We likely need the DOIC end-point Diameter ID included in th=
at AVP.

Steve
On 12/10/13 8:43 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
Steve,

how does this work in scenarios where a non supporting client C sends some =
requests via the DOIC supporting agent A1 to the server S and other request=
s via a different DOIC supporting agent A2 to the same server S?

Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Tuesday, December 10, 2013 2:25 PM
To: Ben Campbell
Cc: dime@ietf.org list
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comment=
s to 4.3

inline
On 12/9/13 4:34 PM, Ben Campbell wrote:



On Dec 9, 2013, at 10:00 AM, Steve Donovan  wrote:



Jouni,



I propose that we keep the name OC-Sequence-Number but that we use the Time=
 type for OC-Sequence-Number.  It is misleading and potentially confusing t=
o call it OC-Time-Stamp.





I could live with that, although I would rather just define the expected pr=
operties of the sequence number, and leave the implementation up to the imp=
lementor. I assume your reasoning for not calling it a timestamp is that yo=
u do not want people to try to use it as a time base reference. If so, then=
 we don't require any connection to a clock. We just need it to be monotoni=
cally increasing.



We might consider expanding on the format of the AVP to make it something l=
ike Session-ID, where it is a concatenation of the Diameter-ID of the gener=
ating node and a timestamp.  This might help the reacting node keep track o=
f which sequence number it has received.





Do we need a uniqueness across multiple nodes property? If so, why?
Strictly speaking, no.  The thought was to make it similar to session-id an=
d potentially make it easier for the reacting node to keep differentiate se=
quence numbers from different reporting nodes.








Steve



On 12/9/13 5:37 AM, Jouni Korhonen wrote:

Folks



Could we conclude on the sequence number vs. time stamp vs. something else?

We got more important places to spend our energy than this ;)



My proposal is the following (based on the original pre-00 design):



o We change the OC-Sequence-Number to OC-Time-Stamp in all occurrences

  in the -01.

o We use RFC6733 Time type for the OC-Time-Stamp. RFC6733 gives us

  already exact definition how to handle the AVP.

o Define that the OC-Time-Stamp is the time of the creation of the

  "original" AVP within whose context the time stamp is present.

o The OC-Time-Stamp AVP uniqueness is still considered to be in scope

  of the communicating endpoints.

o The time stamp can be used to quickly determine if the content of

  the encapsulating AVP context has changed (among other properties).

  This would be useful specifically in the future when the encapsulating

  grouped AVPs  grow in size and functionality.





- Jouni



_______________________________________________

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








--_000_5BCBA1FC2B7F0B4C9D935572D90006681519E9DADEMUMBX014nsnin_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Steve,


 =
;


Why would =
a reporting node that only supports
OLR_DEFAULT_ALGO=
  and does not support any o=
ther feature need to detect that a reacting node supports lots of
 new features in addition to OLR_DEFAULT_ALGO ? E=
ven if it dectets support of new features by the reacting node,
 the reporting node would not behave any differently than before detecting =
this.


 =
;


Ulrich



 =
;






From:=
 ext Steve Donovan [=
mailto:srdonovan@usdonovans.com]


Sent: Thursday, December 12, 2013 2:59 PM

To: Wiehe, Ulrich (NSN - DE/Munich); Ben Campbell

Cc: dime@ietf.org list

Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: =
comments to 4.3






 


Ulrich,



I don't understand your last statement.  How do new algorithms or feat=
ures get introduced to a network if the reporting node does not detect that=
 reacting nodes start supporting new features.



As I've said in other messages, the sequence number does not force anyone t=
o keep a state database.  It allows it but does not require it.



Steve




On 12/12/13 3:24 AM, Wiehe, Ulrich (NSN - DE/Munich)=
 wrote:






Steve,<=
/p>

 <=
/p>

not sure i=
f I correctly understand your second paragraph; please see inline.


 


Anyway I a=
gree with your conclusion: Something is missing in the concept of “se=
quence-number in OC-Supported-Features”. We WOULD need the DOIC
 end-point Diameter ID included in that AVP. I said WOULD because things ar=
e becoming more and more complex and complicated. This all is not worth the=
 effort. 
Let’s remove sequence number from Supported-Features.


 


A Reportin=
g node that does not support any extension (i.e. supports only
OLR_DEFAULT_ALGO=
)  only needs to know whethe=
r there is a reacting node down stream that supports
OLR_DEFAULT_ALGO=
    in order to de=
cide whether or not a pre-calculated (default-algo-type) OLR must be return=
ed
 or not. This can simply be done by checking bit 0 of the received Feature-=
Vector.



The altern=
ative



-      =
   
to=
 setup and maintain a database of DOIC end-point ID / sequence-number pairs=
 containing the pre-calculated (last-known-supported-feature-type)
 OLR , and


-      =
   
to=
 check, when receiving a request, whether the included DOIC end-point ID / =
sequence-number pair is present in the database and if so
 return the corresponding OLR;


is over-ov=
erkill.


 


Also there=
 is no need for the reporting node (which still only supports
OLR_DEFAULT_ALGO=
 ) to detect that the reacting no=
des capabilities have been updated e.g. from “support of  
OLR_DEFAULT_ALGO=
“ to “support of &nbs=
p;OLR_DEFAULT_ALGO
  and  &nbs=
p;OLR_SOMETHING_NEW
 “


 


 


Ulrich


 


 






From:=
 ext Steve Donovan [=
mailto:srdonovan@usdonovans.com=
]


Sent: Wednesday, December 11, 2013 2:45 PM

To: Wiehe, Ulrich (NSN - DE/Munich); Ben Campbell

Cc: dime@ietf.org list

Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: =
comments to 4.3






 


Ulrich,



Is your question how sequence numbers work when there are DOIC supporting a=
gents?


[Wiehe, Ulrich (NSN - DE/Munich)] yes, when ther=
e are more than one DOIC supporting agents that do DOIC on behalf
 of a (single) non-DOIC-supporting Client.



The capabilities exchange is between two DOIC endpoints,<=
/p>

[Wiehe, Ulrich (NSN - DE/Munich)] I agree=



=
so in the case you outline, the server would see capability information fro=
m each agent in the path


[Wiehe, Ulrich (NSN - DE/Munich)] the server wou=
ld see capability information in a received request but does
 not know which downstream node included the capability information. Not mo=
re than one node in a path will incude capability information.


=
.  The server should not see the sequence numbers from the clie=
nts.


[Wiehe, Ulrich (NSN - DE/Munich)] in the example=
 there is only one client, and that does not support DOIC, so
 I don’t understand “sequence numbers from the clients”


=




This does point out that we are likely missing something from the OC-Featur=
e-Vector AVP. 
We likely need the DOIC end-point Diameter ID included in that AVP.<=
br>


Steve




On 12/10/13 8:43 AM, Wiehe, Ulrich (NSN - DE/Munich)=
 wrote:






Steve,


 


how does t=
his work in scenarios where a non supporting client C sends some requests v=
ia the DOIC supporting agent A1 to the server S and other
 requests via a different DOIC supporting agent A2 to the same server S?


 


Ulrich


 






From:=
 DiME [mailto:dime-bounces@ietf.org]
On Behalf Of ext Steve Donovan

Sent: Tuesday, December 10, 2013 2:25 PM

To: Ben Campbell

Cc: dime@ietf.org list

Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: =
comments to 4.3






 


inline




On 12/9/13 4:34 PM, Ben Campbell wrote:





 


On Dec 9, 2013, at 10:00 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:

 




Jouni,


 


I propose that we keep the name OC-Sequence-Number but that we use the=
 Time type for OC-Sequence-Number.  It is misleading and potentially c=
onfusing to call it OC-Time-Stamp.  


 




 


I could live with that, although I would rather just define the expect=
ed properties of the sequence number, and leave the implementation up to th=
e implementor. I assume your reasoning for not calling it a timestamp is th=
at you do not want people to try to use it as a time base reference. If so,=
 then we don't require any connection to a clock. We just need it to be mon=
otonically increasing.


 




We might consider expanding on the format of the AVP to make it someth=
ing like Session-ID, where it is a concatenation of the Diameter-ID of the =
generating node and a timestamp.  This might help the reacting node ke=
ep track of which sequence number it has received.


 




 


Do we need a uniqueness across multiple nodes property? If so, why?




Strictly speaking, no.  The thought was to make=
 it similar to session-id and potentially make it easier for the reacting n=
ode to keep differentiate sequence numbers from different reporting nodes.<=
br>









 


 




Steve


 


On 12/9/13 5:37 AM, Jouni Korhonen wrote:




Folks


 


Could we conclude on the sequence number vs. time stamp vs. something =
else?


We got more important places to spend our energy than this ;)


 


My proposal is the following (based on the original pre-00 design):


 


o We change the OC-Sequence-Number to OC-Time-Stamp in all occurrences=



  in the -01.


o We use RFC6733 Time type for the OC-Time-Stamp. RFC6733 gives us


  already exact definition how to handle the AVP.

o Define that the OC-Time-Stamp is the time of the creation of the 


  "original" AVP within whose context the time sta=
mp is present.


o The OC-Time-Stamp AVP uniqueness is still considered to be in scope<=
o:p>


  of the communicating endpoints.


o The time stamp can be used to quickly determine if the content of


  the encapsulating AVP context has changed (among other properti=
es).


  This would be useful specifically in the future when the encaps=
ulating


  grouped AVPs  grow in size and functionality.

 


 


- Jouni


 


_______________________________________________


DiME mailing list


 


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 


 


 




 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime




 


 


 




 




 






--_000_5BCBA1FC2B7F0B4C9D935572D90006681519E9DADEMUMBX014nsnin_--

From srdonovan@usdonovans.com  Thu Dec 12 07:33:50 2013
Return-Path: 
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 F40CB1AE329 for ; Thu, 12 Dec 2013 07:33:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.12
X-Spam-Level: 
X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no
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 y5ETvza6VXSR for ; Thu, 12 Dec 2013 07:33:44 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id EA3651AE324 for ; Thu, 12 Dec 2013 07:33:43 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:52505 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1Vr8GZ-000494-QU; Thu, 12 Dec 2013 07:33:36 -0800
Message-ID: <52A9D74B.8070404@usdonovans.com>
Date: Thu, 12 Dec 2013 09:33:31 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: "Wiehe, Ulrich (NSN - DE/Munich)" ,  "dime@ietf.org" 
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DA3E@DEMUMBX014.nsn-intra.net> <09616DA2-D1ED-40EE-8E89-755DFCD81092@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E02B@DEMUMBX014.nsn-intra.net> <1A402C59-E390-4C95-8E30-97F1F9D3EF0F@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E05C@DEMUMBX014.nsn-intra.net> <790F1603-64D5-40E2-BC59-FD4C104EEF1B@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E0D9@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D90006681519E331@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D90006681519E3C4@DEMUMBX014.nsn-intra.net> <0CDBF4BB-4E38-41D6-A5E2-9218FFEFEA43@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E6EF@DEMUMBX014.nsn-intra.net> <52A869AD.6080305@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E89B@DEMUMBX014.nsn-intra.net> <52A9C040.40206@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E9BE@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681519E9BE@DEMUMBX014.nsn-intra.net>
Content-Type: multipart/alternative; boundary="------------060408040501040501000705"
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com
Subject: Re: [Dime] OVLI: comments to 4.1
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Dec 2013 15:33:50 -0000

This is a multi-part message in MIME format.
--------------060408040501040501000705
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Ulrich,

Thanks for the correction -- obviously typed pre coffee this morning.

The tradeoff is requiring processing on every request versus maintaining
state to allow avoiding that processing on 99.99% of requests.

We should let individual implementers make the decision on which
approach they prefer.

Steve

On 12/12/13 9:22 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
> Steve,
>
>  
>
> you probably mean "...can't  be optional..." rather than "...can't be
> mandatory..."
>
>  
>
> If so, I understand your logic but this means that  reacting nodes are
> forced to  implement sequence numbers in OC-Supported-Features just
> because some reporting nodes prefer to do things complicated rather
> than simple and I'm not convinced that this would be the way to go.
>
>  
>
> Ulrich
>
>  
>
>  
>
> *From:*ext Steve Donovan [mailto:srdonovan@usdonovans.com]
> *Sent:* Thursday, December 12, 2013 2:55 PM
> *To:* Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
> *Subject:* Re: [Dime] OVLI: comments to 4.1
>
>  
>
> Ulrich,
>
> No, the sequence number can't be mandatory.  It always needs to be
> sent to allow for end-points that what to use the logic I proposed.
>
> An endpoint that receives the sequence number can choose to ignore it,
> but endpoints must always send sequence numbers.
>
> Steve
>
> On 12/12/13 3:30 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
>     Steve,
>
>      
>
>     do you mean " keep sequence number in OC-Supported-Features as an
>     optional AVP that may be ignored by the receiver and need notbe
>     included by the sender"?
>
>      
>
>     Ulrich
>
>      
>
>     *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *ext
>     Steve Donovan
>     *Sent:* Wednesday, December 11, 2013 2:34 PM
>     *To:* dime@ietf.org 
>     *Subject:* Re: [Dime] OVLI: comments to 4.1
>
>      
>
>     Ulrich,
>
>     My email showed how a reporting node could avoid the work of
>     recalculating capability information on a message by message basis
>     using the sequence number.  This approach does require maintaining
>     state.
>
>     As Ben pointed out, it is also possible to not follow my logic and
>     do as you propose by ignoring the sequence number and going
>     through the work of calculating the response every time. 
>
>     Which approach to take is clearly an implementation decision.  We
>     should keep the sequence number to allow for the stateful approach
>     for implementations that are willing to take advantage of
>     maintaining state to avoid work.
>
>     Steve
>
>     On 12/11/13 1:34 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
>         Jouni,
>
>          
>
>         I do not agree.
>
>          
>
>         My statement was general: reporting node may be server or SFA; supported features may be defined features (default algo) or future extensions.
>
>          
>
>         Ulrich
>
>          
>
>         -----Original Message-----
>
>         From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] 
>
>         Sent: Tuesday, December 10, 2013 10:46 PM
>
>         To: Wiehe, Ulrich (NSN - DE/Munich)
>
>         Cc: dime@ietf.org 
>
>         Subject: Re: [Dime] OVLI: comments to 4.1
>
>          
>
>         Ulrich,
>
>          
>
>         On Dec 10, 2013, at 2:18 PM, "Wiehe, Ulrich (NSN - DE/Munich)"   wrote:
>
>          
>
>              
>
>              
>
>             -----Original Message-----
>
>             From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] 
>
>             Sent: Tuesday, December 10, 2013 12:32 PM
>
>             To: Wiehe, Ulrich (NSN - DE/Munich)
>
>             Cc: dime@ietf.org 
>
>             Subject: Re: [Dime] OVLI: comments to 4.1
>
>              
>
>              
>
>             On Dec 10, 2013, at 12:41 PM, "Wiehe, Ulrich (NSN - DE/Munich)"   wrote:
>
>              
>
>                 Hi Jouni,
>
>                  
>
>                 my understanding from Steve's clarification was that the reporting node would setup and maintain a database of "states", one per reacting node where a state of a reacting node is identified by a sequence number and the database entry would contain the pre-calculated OLR. 
>
>                 Hard to see how this is done without consuming resources.
>
>              
>
>             It is mostly static information. Still I do not see how
>
>             you would get away without any state.
>
>             [Wiehe, Ulrich (NSN - DE/Munich)] There is no need for the reporting node to store and maintain information per reacting node because the reacting node actually tells within the request message all information the reporting node needs to know. The reporting node simply fetches the pre-calculated OLR that matches the supported features of the reacting node as indicated in the request and appends it to the answer.
>
>          
>
>         This could be true for the default algorithm in this spec. However,
>
>         given the extension mechanism we have in place it is quite possible
>
>         that the assumption does not hold for new features.
>
>          
>
>         Also, if I were to implement a server front end agent that would
>
>         definitely need state and still ought to comply the protocol spec.
>
>          
>
>         - Jouni
>
>          
>
>          
>
>          
>
>          
>
>                 Furthermore,
>
>                 Why would the reacting node be interested in config changes of the reporting node?
>
>                 Isn't it so that the reacting node is only interested in OLR changes?
>
>              
>
>             Sigh.. say the traffic abatement algorithm changes or new features
>
>             get added. Those have more impact than just OLR change.
>
>              
>
>             - Jouni
>
>              
>
>                  
>
>                 Ulrich
>
>                  
>
>                 -----Original Message-----
>
>                 From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] 
>
>                 Sent: Tuesday, December 10, 2013 9:41 AM
>
>                 To: Wiehe, Ulrich (NSN - DE/Munich)
>
>                 Cc: dime@ietf.org 
>
>                 Subject: Re: [Dime] OVLI: comments to 4.1
>
>                  
>
>                  
>
>                 On Dec 9, 2013, at 4:43 PM, "Wiehe, Ulrich (NSN - DE/Munich)"   wrote:
>
>                  
>
>                     But maintaining a specific state per reacting node is very resource consuming for the (overloaded) reporting node. It is simpler and more efficient to base any processing logic on actual information received in the request rather than on information stored from previous communication.
>
>                  
>
>                 The "state" in a reporting node is merely the current configuration
>
>                 and a counter for sequence number. Hard to me see that as resource
>
>                 consuming function.
>
>                  
>
>                 And the earlier comment of mine is done from reacting node point
>
>                 of view, since it is more interested in the possible config changes
>
>                 in the reporting node (e.g. S6a is stateless application, configuration
>
>                 can change at any time).
>
>                  
>
>                 - Jouni
>
>                  
>
>                  
>
>                      
>
>                     Ulrich
>
>                      
>
>                     -----Original Message-----
>
>                     From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] 
>
>                     Sent: Monday, December 09, 2013 2:25 PM
>
>                     To: Wiehe, Ulrich (NSN - DE/Munich)
>
>                     Cc: dime@ietf.org 
>
>                     Subject: Re: [Dime] OVLI: comments to 4.1
>
>                      
>
>                      
>
>                     On Dec 9, 2013, at 3:13 PM, "Wiehe, Ulrich (NSN - DE/Munich)"   wrote:
>
>                      
>
>                         There is a fundamental difference:
>
>                         OLRs need to be stored, Feature-Vectors not.
>
>                      
>
>                     How come feature vector does not need to be stored? I do not
>
>                     get that? I would set my implementation to a specific state
>
>                     or mode based on the feature vector. When that changes I'd
>
>                     like to know that. And then keep functioning based on that.
>
>                      
>
>                     - Jouni
>
>                      
>
>                         When receiving an OLR you may want to know whether its worth the effort to replace an already stored OLR with the received OLR.
>
>                         When receiving a Feature-Vector you just act on it.
>
>                          
>
>                         Ulrich 
>
>                          
>
>                         -----Original Message-----
>
>                         From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] 
>
>                         Sent: Monday, December 09, 2013 1:55 PM
>
>                         To: Wiehe, Ulrich (NSN - DE/Munich)
>
>                         Cc: dime@ietf.org 
>
>                         Subject: Re: [Dime] OVLI: comments to 4.1
>
>                          
>
>                          
>
>                         In the same vein as folks wanted send OLRs with the new or old information,
>
>                         the feature vector should behave in a same way IMHO. That implies there are
>
>                         situations when a reception of the feature vector does not change anything
>
>                         in an endpoint current behavior.
>
>                          
>
>                         - Jouni
>
>                          
>
>                         On Dec 9, 2013, at 2:47 PM, "Wiehe, Ulrich (NSN - DE/Munich)"   wrote:
>
>                          
>
>                             Isn't it so that the Feature-Vector (if present) always contains something that an implementation needs to act upon?
>
>                              
>
>                             Ulrich
>
>                              
>
>                             -----Original Message-----
>
>                             From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] 
>
>                             Sent: Monday, December 09, 2013 1:12 PM
>
>                             To: Wiehe, Ulrich (NSN - DE/Munich)
>
>                             Cc: dime@ietf.org 
>
>                             Subject: Re: [Dime] OVLI: comments to 4.1
>
>                              
>
>                             Ulrich,
>
>                              
>
>                             On Dec 6, 2013, at 3:03 PM, "Wiehe, Ulrich (NSN - DE/Munich)"   wrote:
>
>                              
>
>                                 Hi Jouni,
>
>                                  
>
>                                 thank you for your response.
>
>                                  
>
>                                 With regard to 3) 
>
>                                 I still fail to see the usecase for Sequence-Number or TimeStamp within OC-Feature-Vector. Please clarify.
>
>                              
>
>                             Since we also allow extending the OC-Feature-Vector beyond recognition, 
>
>                             it has good chances become a rather complex grouped AVP. In that context
>
>                             the Sequence-Number allows an easy and quick way to check if the feature
>
>                             vector contains something that an implementation needs to act upon.
>
>                              
>
>                                 With regard to 4)
>
>                                 This was not obvious to me. (The obvious typo is the missing "of" between "one" and "the").
>
>                              
>
>                             Ack. Fixed the missing 'of'.
>
>                              
>
>                             - Jouni
>
>                              
>
>                                  
>
>                                 Best regards
>
>                                 Ulrich
>
>                                  
>
>                                  
>
>                                 -----Original Message-----
>
>                                 From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] 
>
>                                 Sent: Friday, December 06, 2013 11:17 AM
>
>                                 To: Wiehe, Ulrich (NSN - DE/Munich)
>
>                                 Cc: dime@ietf.org 
>
>                                 Subject: Re: [Dime] OVLI: comments to 4.1
>
>                                  
>
>                                  
>
>                                 On Dec 5, 2013, at 3:23 PM, "Wiehe, Ulrich (NSN - DE/Munich)"   wrote:
>
>                                  
>
>                                     Dear all,
>
>                                      
>
>                                     here are comments to clause 4.1:
>
>                                      
>
>                                     1. The OC-Feature-Vector AVP is no longer a vector; the name of the AVP may be misleading. Proposal is to rename it to "OC-Supported-Features AVP"
>
>                                  
>
>                                 OK with me.
>
>                                  
>
>                                     2. The OC-Feature AVP is a vector of features. Proposal is to rename it to "OC-Feature-Vector AVP"
>
>                                  
>
>                                 OK with me.
>
>                                  
>
>                                     3. The OC-Sequence-Number within OC-Feature-Vector only makes sense if the receiving reporting endpoint can determine the identity of the reacting endpoint (which is not necessarily the origin host (client),
>
>                                  
>
>                                 My original proposal was to have seqnr as a timestamp. Some folks argued
>
>                                 it is no good and suggested seqnr. I still think time makes more sense than
>
>                                 seqnr.
>
>                                  
>
>                                     it may be an agent and it may not always be the same agent), and if the reporting endpoint is required to store the OC-Feature-Vector / reacting-endpoint-identity pair (which I think both is not required). The reporting endpoint can base its processing logic on the actually received OC-Feature-Vector value, no matter whether it is brand-new or old but stil valid. Proposal is to delete OC-Sequence-Number AVP from OC-Feature-Vector.
>
>                                  
>
>                                 Do not agree removing it.
>
>                                  
>
>                                     4. The text
>
>                                      
>
>                                     The reporting node that sends the answer also includes the OC-
>
>                                     Feature-Vector AVP that describe the capabilities it supports.  The
>
>                                     set of capabilities advertised by the reporting node depends on local
>
>                                     policies.  At least one the announced capabilities MUST match
>
>                                     mutually.  If there is no single matching capability the reacting
>
>                                     node MUST act as if it does not implement DOIC and cease inserting
>
>                                     any DOIC related AVPs into any Diameter messages with this specific
>
>                                     reacting node.
>
>                                      
>
>                                     is not clear.  Would the reporting node include the OC-Feature-Vector AVP in the answer only if there is at least one matching capability? 
>
>                                  
>
>                                 Because then they have found a way to exchange something that both ends
>
>                                 know how to handle it.
>
>                                  
>
>                                     Mandating the reacting node to cease for all time inserting OC-Feature-Vector AVPs if it did not get back 
>
>                                  
>
>                                 There is an obvious typo. It should say:
>
>                                  
>
>                                 policies.  At least one the announced capabilities MUST match
>
>                                 mutually.  If there is no single matching capability the reporting
>
>                                 node MUST act as if it does not implement DOIC and cease inserting
>
>                                 any DOIC related AVPs into any Diameter messages with this specific
>
>                                 reacting node.
>
>                                  
>
>                                 - JOuni
>
>                                  
>
>                                  
>
>                                     at least one match is also not ok. The request might have been a realm-type request (i.e. without Destination Host) and the reacting node cannot control whether subsequent requests will take the same path to the same reporting node.
>
>                                     Even if the request contains a destination host the reacting node cannot know wether the reacting node's capabilities have been modified by the time a subsequent request is sent. 
>
>                                     Proposal is to keep only the first sentence and delete the rest.
>
>                                      
>
>                                     Ulrich
>
>                                      
>
>                                      
>
>                                     _______________________________________________
>
>                                     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
>
>          
>
>      
>
>  
>


--------------060408040501040501000705
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Ulrich,

      

      Thanks for the correction -- obviously typed pre coffee this
      morning.

      

      The tradeoff is requiring processing on every request versus
      maintaining state to allow avoiding that processing on 99.99% of
      requests.

      

      We should let individual implementers make the decision on which
      approach they prefer.

      

      Steve

      

    
    
On 12/12/13 9:22 AM, Wiehe, Ulrich (NSN
      - DE/Munich) wrote:

    

    

      
      
      
      

        
Steve,

        
 

        
you probably mean „…can’t  be optional…“ rather
            than “…can’t be mandatory…”

        
 

        
If so, I understand your logic but this means
            that  reacting nodes are forced to  implement sequence
            numbers in OC-Supported-Features just because some reporting
            nodes prefer to do things complicated rather than simple and
            I’m not convinced that this would be the way to go.

        
 

        
Ulrich

        
 

        
 

        

          

            
From: ext Steve Donovan
                [mailto:srdonovan@usdonovans.com]
                

                Sent: Thursday, December 12, 2013 2:55 PM

                To: Wiehe, Ulrich (NSN - DE/Munich);
                dime@ietf.org

                Subject: Re: [Dime] OVLI: comments to 4.1

          

        

        
 

        
Ulrich,

          

          No, the sequence number can't be mandatory.  It always needs
          to be sent to allow for end-points that what to use the logic
          I proposed.

          

          An endpoint that receives the sequence number can choose to
          ignore it, but endpoints must always send sequence numbers.

          

          Steve

        

          
On 12/12/13 3:30 AM, Wiehe, Ulrich (NSN -
            DE/Munich) wrote:

        

        

          
Steve,

          
 

          
do you mean „ keep sequence number in
              OC-Supported-Features as an optional AVP that may be
              ignored by the receiver and need notbe included by the
              sender”?

          
 

          
Ulrich

          
 

          

            

              
From: DiME [mailto:dime-bounces@ietf.org]
                  On Behalf Of ext Steve Donovan

                  Sent: Wednesday, December 11, 2013 2:34 PM

                  To: dime@ietf.org

                  Subject: Re: [Dime] OVLI: comments to 4.1

            

          

          
 

          
Ulrich,

            

            My email showed how a reporting node could avoid the work of
            recalculating capability information on a message by message
            basis using the sequence number.  This approach does require
            maintaining state.

            

            As Ben pointed out, it is also possible to not follow my
            logic and do as you propose by ignoring the sequence number
            and going through the work of calculating the response every
            time. 
            

            

            Which approach to take is clearly an implementation
            decision.  We should keep the sequence number to allow for
            the stateful approach for implementations that are willing
            to take advantage of maintaining state to avoid work.

            

            Steve

          

            
On 12/11/13 1:34 AM, Wiehe, Ulrich (NSN
              - DE/Munich) wrote:

          

          

            
Jouni,

            
 

            
I do not agree.

            
 

            
My statement was general: reporting node may be server or SFA; supported features may be defined features (default algo) or future extensions.

            
 

            
Ulrich

            
 

            
-----Original Message-----

            
From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] 

            
Sent: Tuesday, December 10, 2013 10:46 PM

            
To: Wiehe, Ulrich (NSN - DE/Munich)

            
Cc: dime@ietf.org

            
Subject: Re: [Dime] OVLI: comments to 4.1

            
 

            
Ulrich,

            
 

            
On Dec 10, 2013, at 2:18 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> wrote:

            
 

            

              
 

              
 

              
-----Original Message-----

              
From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] 

              
Sent: Tuesday, December 10, 2013 12:32 PM

              
To: Wiehe, Ulrich (NSN - DE/Munich)

              
Cc: dime@ietf.org

              
Subject: Re: [Dime] OVLI: comments to 4.1

              
 

              
 

              
On Dec 10, 2013, at 12:41 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> wrote:

              
 

              

                
Hi Jouni,

                
 

                
my understanding from Steve's clarification was that the reporting node would setup and maintain a database of "states", one per reacting node where a state of a reacting node is identified by a sequence number and the database entry would contain the pre-calculated OLR. 

                
Hard to see how this is done without consuming resources.

              

              
 

              
It is mostly static information. Still I do not see how

              
you would get away without any state.

              
[Wiehe, Ulrich (NSN - DE/Munich)] There is no need for the reporting node to store and maintain information per reacting node because the reacting node actually tells within the request message all information the reporting node needs to know. The reporting node simply fetches the pre-calculated OLR that matches the supported features of the reacting node as indicated in the request and appends it to the answer.

            

            
 

            
This could be true for the default algorithm in this spec. However,

            
given the extension mechanism we have in place it is quite possible

            
that the assumption does not hold for new features.

            
 

            
Also, if I were to implement a server front end agent that would

            
definitely need state and still ought to comply the protocol spec.

            
 

            
- Jouni

            
 

            
 

            
 

            
 

            

              

                
Furthermore,

                
Why would the reacting node be interested in config changes of the reporting node?

                
Isn't it so that the reacting node is only interested in OLR changes?

              

              
 

              
Sigh.. say the traffic abatement algorithm changes or new features

              
get added. Those have more impact than just OLR change.

              
 

              
- Jouni

              
 

              

                
 

                
Ulrich

                
 

                
-----Original Message-----

                
From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] 

                
Sent: Tuesday, December 10, 2013 9:41 AM

                
To: Wiehe, Ulrich (NSN - DE/Munich)

                
Cc: dime@ietf.org

                
Subject: Re: [Dime] OVLI: comments to 4.1

                
 

                
 

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

                
 

                

                  
But maintaining a specific state per reacting node is very resource consuming for the (overloaded) reporting node. It is simpler and more efficient to base any processing logic on actual information received in the request rather than on information stored from previous communication.

                

                
 

                
The "state" in a reporting node is merely the current configuration

                
and a counter for sequence number. Hard to me see that as resource

                
consuming function.

                
 

                
And the earlier comment of mine is done from reacting node point

                
of view, since it is more interested in the possible config changes

                
in the reporting node (e.g. S6a is stateless application, configuration

                
can change at any time).

                
 

                
- Jouni

                
 

                
 

                

                  
 

                  
Ulrich

                  
 

                  
-----Original Message-----

                  
From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] 

                  
Sent: Monday, December 09, 2013 2:25 PM

                  
To: Wiehe, Ulrich (NSN - DE/Munich)

                  
Cc: dime@ietf.org

                  
Subject: Re: [Dime] OVLI: comments to 4.1

                  
 

                  
 

                  
On Dec 9, 2013, at 3:13 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> wrote:

                  
 

                  

                    
There is a fundamental difference:

                    
OLRs need to be stored, Feature-Vectors not.

                  

                  
 

                  
How come feature vector does not need to be stored? I do not

                  
get that? I would set my implementation to a specific state

                  
or mode based on the feature vector. When that changes I'd

                  
like to know that. And then keep functioning based on that.

                  
 

                  
- Jouni

                  
 

                  

                    
When receiving an OLR you may want to know whether its worth the effort to replace an already stored OLR with the received OLR.

                    
When receiving a Feature-Vector you just act on it.

                    
 

                    
Ulrich 

                    
 

                    
-----Original Message-----

                    
From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] 

                    
Sent: Monday, December 09, 2013 1:55 PM

                    
To: Wiehe, Ulrich (NSN - DE/Munich)

                    
Cc: dime@ietf.org

                    
Subject: Re: [Dime] OVLI: comments to 4.1

                    
 

                    
 

                    
In the same vein as folks wanted send OLRs with the new or old information,

                    
the feature vector should behave in a same way IMHO. That implies there are

                    
situations when a reception of the feature vector does not change anything

                    
in an endpoint current behavior.

                    
 

                    
- Jouni

                    
 

                    
On Dec 9, 2013, at 2:47 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> wrote:

                    
 

                    

                      
Isn't it so that the Feature-Vector (if present) always contains something that an implementation needs to act upon?

                      
 

                      
Ulrich

                      
 

                      
-----Original Message-----

                      
From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] 

                      
Sent: Monday, December 09, 2013 1:12 PM

                      
To: Wiehe, Ulrich (NSN - DE/Munich)

                      
Cc: dime@ietf.org

                      
Subject: Re: [Dime] OVLI: comments to 4.1

                      
 

                      
Ulrich,

                      
 

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

                      
 

                      

                        
Hi Jouni,

                        
 

                        
thank you for your response.

                        
 

                        
With regard to 3) 

                        
I still fail to see the usecase for Sequence-Number or TimeStamp within OC-Feature-Vector. Please clarify.

                      

                      
 

                      
Since we also allow extending the OC-Feature-Vector beyond recognition, 

                      
it has good chances become a rather complex grouped AVP. In that context

                      
the Sequence-Number allows an easy and quick way to check if the feature

                      
vector contains something that an implementation needs to act upon.

                      
 

                      

                        
With regard to 4)

                        
This was not obvious to me. (The obvious typo is the missing "of" between "one" and "the").

                      

                      
 

                      
Ack. Fixed the missing 'of'.

                      
 

                      
- Jouni

                      
 

                      

                        
 

                        
Best regards

                        
Ulrich

                        
 

                        
 

                        
-----Original Message-----

                        
From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] 

                        
Sent: Friday, December 06, 2013 11:17 AM

                        
To: Wiehe, Ulrich (NSN - DE/Munich)

                        
Cc: dime@ietf.org

                        
Subject: Re: [Dime] OVLI: comments to 4.1

                        
 

                        
 

                        
On Dec 5, 2013, at 3:23 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> wrote:

                        
 

                        

                          
Dear all,

                          
 

                          
here are comments to clause 4.1:

                          
 

                          
1. The OC-Feature-Vector AVP is no longer a vector; the name of the AVP may be misleading. Proposal is to rename it to "OC-Supported-Features AVP"

                        

                        
 

                        
OK with me.

                        
 

                        

                          
2. The OC-Feature AVP is a vector of features. Proposal is to rename it to "OC-Feature-Vector AVP"

                        

                        
 

                        
OK with me.

                        
 

                        

                          
3. The OC-Sequence-Number within OC-Feature-Vector only makes sense if the receiving reporting endpoint can determine the identity of the reacting endpoint (which is not necessarily the origin host (client),

                        

                        
 

                        
My original proposal was to have seqnr as a timestamp. Some folks argued

                        
it is no good and suggested seqnr. I still think time makes more sense than

                        
seqnr.

                        
 

                        

                          
it may be an agent and it may not always be the same agent), and if the reporting endpoint is required to store the OC-Feature-Vector / reacting-endpoint-identity pair (which I think both is not required). The reporting endpoint can base its processing logic on the actually received OC-Feature-Vector value, no matter whether it is brand-new or old but stil valid. Proposal is to delete OC-Sequence-Number AVP from OC-Feature-Vector.

                        

                        
 

                        
Do not agree removing it.

                        
 

                        

                          
4. The text

                          
 

                          
The reporting node that sends the answer also includes the OC-

                          
Feature-Vector AVP that describe the capabilities it supports.  The

                          
set of capabilities advertised by the reporting node depends on local

                          
policies.  At least one the announced capabilities MUST match

                          
mutually.  If there is no single matching capability the reacting

                          
node MUST act as if it does not implement DOIC and cease inserting

                          
any DOIC related AVPs into any Diameter messages with this specific

                          
reacting node.

                          
 

                          
is not clear.  Would the reporting node include the OC-Feature-Vector AVP in the answer only if there is at least one matching capability? 

                        

                        
 

                        
Because then they have found a way to exchange something that both ends

                        
know how to handle it.

                        
 

                        

                          
Mandating the reacting node to cease for all time inserting OC-Feature-Vector AVPs if it did not get back 

                        

                        
 

                        
There is an obvious typo. It should say:

                        
 

                        
policies.  At least one the announced capabilities MUST match

                        
mutually.  If there is no single matching capability the reporting

                        
node MUST act as if it does not implement DOIC and cease inserting

                        
any DOIC related AVPs into any Diameter messages with this specific

                        
reacting node.

                        
 

                        
- JOuni

                        
 

                        
 

                        

                          
at least one match is also not ok. The request might have been a realm-type request (i.e. without Destination Host) and the reacting node cannot control whether subsequent requests will take the same path to the same reporting node.

                          
Even if the request contains a destination host the reacting node cannot know wether the reacting node's capabilities have been modified by the time a subsequent request is sent. 

                          
Proposal is to keep only the first sentence and delete the rest.

                          
 

                          
Ulrich

                          
 

                          
 

                          
_______________________________________________

                          
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

            
 

          

          
 

        

        
 

      

    

    

  


--------------060408040501040501000705--

From ulrich.wiehe@nsn.com  Thu Dec 12 08:03:02 2013
Return-Path: 
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 896D41AE306 for ; Thu, 12 Dec 2013 08:03:02 -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 IS8x34ojFXp5 for ; Thu, 12 Dec 2013 08:02:55 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 0BCFC1AE22D for ; Thu, 12 Dec 2013 08:02:53 -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 rBCG2jwx019771 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 12 Dec 2013 17:02:45 +0100
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 rBCG2i05020221 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Dec 2013 17:02:45 +0100
Received: from DEMUHTC011.nsn-intra.net (10.159.42.42) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 12 Dec 2013 17:02:44 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.152]) by DEMUHTC011.nsn-intra.net ([10.159.42.42]) with mapi id 14.03.0123.003; Thu, 12 Dec 2013 17:02:44 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Steve Donovan , "dime@ietf.org" 
Thread-Topic: [Dime] OVLI: comments to 4.1
Thread-Index: Ac7xvTHHIECkLcDwSDuVAh2ACeOasAAprlMAAAaV6CAAlFJBAAADLijg///yiAD//+yxwIAAG3gA///jPWCAAV/bAP//0rCwAAujOgD//+gx4P//PIoA//3FKSD/+zWWgP/1DNgg/+nfowD/05n2AP+nPcSA/05pQsA=
Date: Thu, 12 Dec 2013 16:02:44 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519E9FE@DEMUMBX014.nsn-intra.net>
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DA3E@DEMUMBX014.nsn-intra.net> <09616DA2-D1ED-40EE-8E89-755DFCD81092@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E02B@DEMUMBX014.nsn-intra.net> <1A402C59-E390-4C95-8E30-97F1F9D3EF0F@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E05C@DEMUMBX014.nsn-intra.net> <790F1603-64D5-40E2-BC59-FD4C104EEF1B@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E0D9@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D90006681519E331@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D90006681519E3C4@DEMUMBX014.nsn-intra.net> <0CDBF4BB-4E38-41D6-A5E2-9218FFEFEA43@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E6EF@DEMUMBX014.nsn-intra.net> <52A869AD.6080305@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E89B@DEMUMBX014.nsn-intra.net> <52A9C040.40206@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E9BE@DEMUMBX014.nsn-intra.net> <52A9D74B.8070404@usdonovans.com>
In-Reply-To: <52A9D74B.8070404@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.100]
Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D90006681519E9FEDEMUMBX014nsnin_"
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: 46516
X-purgate-ID: 151667::1386864167-00001A6F-B432D858/0-0/0-0
Subject: Re: [Dime] OVLI: comments to 4.1
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Dec 2013 16:03:02 -0000

--_000_5BCBA1FC2B7F0B4C9D935572D90006681519E9FEDEMUMBX014nsnin_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Steve,
ok, but then its only fair to let individual implementers (of reacting node=
s) make the decision whether or not to spend the effort of include a sequen=
ce number in the OC-Supported-Features (i.e. make the sequence number optio=
nal).

Isn't the situation similar to the proposal to introduce Ongoing-Throttling=
-Information mandatorily in requests and let implementers of reporting node=
s decide whether they want to make use of this information?

Ulrich

See also inline


From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Thursday, December 12, 2013 4:34 PM
To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
Subject: Re: [Dime] OVLI: comments to 4.1

Ulrich,

Thanks for the correction -- obviously typed pre coffee this morning.

The tradeoff is requiring processing on every request versus maintaining st=
ate to allow avoiding that processing on 99.99% of requests.
[Wiehe, Ulrich (NSN - DE/Munich)] The tradeoff is between a) checking the S=
upported_Features in every request and know what to do, and b) checking the=
 sequence number in every request, looking up a database and then (in 99.99=
% of cases) know what to do.


We should let individual implementers make the decision on which approach t=
hey prefer.

Steve
On 12/12/13 9:22 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
Steve,

you probably mean "...can't  be optional..." rather than "...can't be manda=
tory..."

If so, I understand your logic but this means that  reacting nodes are forc=
ed to  implement sequence numbers in OC-Supported-Features just because som=
e reporting nodes prefer to do things complicated rather than simple and I'=
m not convinced that this would be the way to go.

Ulrich


From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Thursday, December 12, 2013 2:55 PM
To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
Subject: Re: [Dime] OVLI: comments to 4.1

Ulrich,

No, the sequence number can't be mandatory.  It always needs to be sent to =
allow for end-points that what to use the logic I proposed.

An endpoint that receives the sequence number can choose to ignore it, but =
endpoints must always send sequence numbers.

Steve
On 12/12/13 3:30 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
Steve,

do you mean " keep sequence number in OC-Supported-Features as an optional =
AVP that may be ignored by the receiver and need notbe included by the send=
er"?

Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Wednesday, December 11, 2013 2:34 PM
To: dime@ietf.org
Subject: Re: [Dime] OVLI: comments to 4.1

Ulrich,

My email showed how a reporting node could avoid the work of recalculating =
capability information on a message by message basis using the sequence num=
ber.  This approach does require maintaining state.

As Ben pointed out, it is also possible to not follow my logic and do as yo=
u propose by ignoring the sequence number and going through the work of cal=
culating the response every time.

Which approach to take is clearly an implementation decision.  We should ke=
ep the sequence number to allow for the stateful approach for implementatio=
ns that are willing to take advantage of maintaining state to avoid work.

Steve
On 12/11/13 1:34 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:

Jouni,



I do not agree.



My statement was general: reporting node may be server or SFA; supported fe=
atures may be defined features (default algo) or future extensions.



Ulrich



-----Original Message-----

From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Sent: Tuesday, December 10, 2013 10:46 PM

To: Wiehe, Ulrich (NSN - DE/Munich)

Cc: dime@ietf.org

Subject: Re: [Dime] OVLI: comments to 4.1



Ulrich,



On Dec 10, 2013, at 2:18 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:







-----Original Message-----

From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Sent: Tuesday, December 10, 2013 12:32 PM

To: Wiehe, Ulrich (NSN - DE/Munich)

Cc: dime@ietf.org

Subject: Re: [Dime] OVLI: comments to 4.1





On Dec 10, 2013, at 12:41 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:



Hi Jouni,



my understanding from Steve's clarification was that the reporting node wou=
ld setup and maintain a database of "states", one per reacting node where a=
 state of a reacting node is identified by a sequence number and the databa=
se entry would contain the pre-calculated OLR.

Hard to see how this is done without consuming resources.



It is mostly static information. Still I do not see how

you would get away without any state.

[Wiehe, Ulrich (NSN - DE/Munich)] There is no need for the reporting node t=
o store and maintain information per reacting node because the reacting nod=
e actually tells within the request message all information the reporting n=
ode needs to know. The reporting node simply fetches the pre-calculated OLR=
 that matches the supported features of the reacting node as indicated in t=
he request and appends it to the answer.



This could be true for the default algorithm in this spec. However,

given the extension mechanism we have in place it is quite possible

that the assumption does not hold for new features.



Also, if I were to implement a server front end agent that would

definitely need state and still ought to comply the protocol spec.



- Jouni









Furthermore,

Why would the reacting node be interested in config changes of the reportin=
g node?

Isn't it so that the reacting node is only interested in OLR changes?



Sigh.. say the traffic abatement algorithm changes or new features

get added. Those have more impact than just OLR change.



- Jouni





Ulrich



-----Original Message-----

From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Sent: Tuesday, December 10, 2013 9:41 AM

To: Wiehe, Ulrich (NSN - DE/Munich)

Cc: dime@ietf.org

Subject: Re: [Dime] OVLI: comments to 4.1





On Dec 9, 2013, at 4:43 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:



But maintaining a specific state per reacting node is very resource consumi=
ng for the (overloaded) reporting node. It is simpler and more efficient to=
 base any processing logic on actual information received in the request ra=
ther than on information stored from previous communication.



The "state" in a reporting node is merely the current configuration

and a counter for sequence number. Hard to me see that as resource

consuming function.



And the earlier comment of mine is done from reacting node point

of view, since it is more interested in the possible config changes

in the reporting node (e.g. S6a is stateless application, configuration

can change at any time).



- Jouni







Ulrich



-----Original Message-----

From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Sent: Monday, December 09, 2013 2:25 PM

To: Wiehe, Ulrich (NSN - DE/Munich)

Cc: dime@ietf.org

Subject: Re: [Dime] OVLI: comments to 4.1





On Dec 9, 2013, at 3:13 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:



There is a fundamental difference:

OLRs need to be stored, Feature-Vectors not.



How come feature vector does not need to be stored? I do not

get that? I would set my implementation to a specific state

or mode based on the feature vector. When that changes I'd

like to know that. And then keep functioning based on that.



- Jouni



When receiving an OLR you may want to know whether its worth the effort to =
replace an already stored OLR with the received OLR.

When receiving a Feature-Vector you just act on it.



Ulrich



-----Original Message-----

From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Sent: Monday, December 09, 2013 1:55 PM

To: Wiehe, Ulrich (NSN - DE/Munich)

Cc: dime@ietf.org

Subject: Re: [Dime] OVLI: comments to 4.1





In the same vein as folks wanted send OLRs with the new or old information,

the feature vector should behave in a same way IMHO. That implies there are

situations when a reception of the feature vector does not change anything

in an endpoint current behavior.



- Jouni



On Dec 9, 2013, at 2:47 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:



Isn't it so that the Feature-Vector (if present) always contains something =
that an implementation needs to act upon?



Ulrich



-----Original Message-----

From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Sent: Monday, December 09, 2013 1:12 PM

To: Wiehe, Ulrich (NSN - DE/Munich)

Cc: dime@ietf.org

Subject: Re: [Dime] OVLI: comments to 4.1



Ulrich,



On Dec 6, 2013, at 3:03 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:



Hi Jouni,



thank you for your response.



With regard to 3)

I still fail to see the usecase for Sequence-Number or TimeStamp within OC-=
Feature-Vector. Please clarify.



Since we also allow extending the OC-Feature-Vector beyond recognition,

it has good chances become a rather complex grouped AVP. In that context

the Sequence-Number allows an easy and quick way to check if the feature

vector contains something that an implementation needs to act upon.



With regard to 4)

This was not obvious to me. (The obvious typo is the missing "of" between "=
one" and "the").



Ack. Fixed the missing 'of'.



- Jouni





Best regards

Ulrich





-----Original Message-----

From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Sent: Friday, December 06, 2013 11:17 AM

To: Wiehe, Ulrich (NSN - DE/Munich)

Cc: dime@ietf.org

Subject: Re: [Dime] OVLI: comments to 4.1





On Dec 5, 2013, at 3:23 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:



Dear all,



here are comments to clause 4.1:



1. The OC-Feature-Vector AVP is no longer a vector; the name of the AVP may=
 be misleading. Proposal is to rename it to "OC-Supported-Features AVP"



OK with me.



2. The OC-Feature AVP is a vector of features. Proposal is to rename it to =
"OC-Feature-Vector AVP"



OK with me.



3. The OC-Sequence-Number within OC-Feature-Vector only makes sense if the =
receiving reporting endpoint can determine the identity of the reacting end=
point (which is not necessarily the origin host (client),



My original proposal was to have seqnr as a timestamp. Some folks argued

it is no good and suggested seqnr. I still think time makes more sense than

seqnr.



it may be an agent and it may not always be the same agent), and if the rep=
orting endpoint is required to store the OC-Feature-Vector / reacting-endpo=
int-identity pair (which I think both is not required). The reporting endpo=
int can base its processing logic on the actually received OC-Feature-Vecto=
r value, no matter whether it is brand-new or old but stil valid. Proposal =
is to delete OC-Sequence-Number AVP from OC-Feature-Vector.



Do not agree removing it.



4. The text



The reporting node that sends the answer also includes the OC-

Feature-Vector AVP that describe the capabilities it supports.  The

set of capabilities advertised by the reporting node depends on local

policies.  At least one the announced capabilities MUST match

mutually.  If there is no single matching capability the reacting

node MUST act as if it does not implement DOIC and cease inserting

any DOIC related AVPs into any Diameter messages with this specific

reacting node.



is not clear.  Would the reporting node include the OC-Feature-Vector AVP i=
n the answer only if there is at least one matching capability?



Because then they have found a way to exchange something that both ends

know how to handle it.



Mandating the reacting node to cease for all time inserting OC-Feature-Vect=
or AVPs if it did not get back



There is an obvious typo. It should say:



policies.  At least one the announced capabilities MUST match

mutually.  If there is no single matching capability the reporting

node MUST act as if it does not implement DOIC and cease inserting

any DOIC related AVPs into any Diameter messages with this specific

reacting node.



- JOuni





at least one match is also not ok. The request might have been a realm-type=
 request (i.e. without Destination Host) and the reacting node cannot contr=
ol whether subsequent requests will take the same path to the same reportin=
g node.

Even if the request contains a destination host the reacting node cannot kn=
ow wether the reacting node's capabilities have been modified by the time a=
 subsequent request is sent.

Proposal is to keep only the first sentence and delete the rest.



Ulrich





_______________________________________________

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






--_000_5BCBA1FC2B7F0B4C9D935572D90006681519E9FEDEMUMBX014nsnin_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Steve,


ok, but th=
en its only fair to let individual implementers (of reacting nodes) make th=
e decision whether or not to spend the effort of include a
 sequence number in the OC-Supported-Features (i.e. make the sequence numbe=
r optional). 



 =
;


Isn’=
t the situation similar to the proposal to introduce Ongoing-Throttling-Inf=
ormation mandatorily in requests and let implementers of reporting
 nodes decide whether they want to make use of this information?=



 =
;


Ulrich


 =
;


See also i=
nline


 =
;


 =
;






From:=
 ext Steve Donovan [=
mailto:srdonovan@usdonovans.com]


Sent: Thursday, December 12, 2013 4:34 PM

To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org

Subject: Re: [Dime] OVLI: comments to 4.1






 


Ulrich,



Thanks for the correction -- obviously typed pre coffee this morning.



The tradeoff is requiring processing on every request versus maintaining st=
ate to allow avoiding that processing on 99.99% of requests.


[Wiehe, Ulrich (NSN - DE/Munich)] The tradeoff i=
s between a) checking the Supported_Features in every request
 and know what to do, and b) checking the sequence number in every request,=
 looking up a database and then (in 99.99% of cases) know what to do.<=
/o:p>


=




We should let individual implementers make the decision on which approach t=
hey prefer.



Steve




On 12/12/13 9:22 AM, Wiehe, Ulrich (NSN - DE/Munich)=
 wrote:






Steve,<=
/p>

 <=
/p>

you probab=
ly mean „…can’t  be optional…“ rather th=
an “…can’t be mandatory…”

 


If so, I u=
nderstand your logic but this means that  reacting nodes are forced to=
  implement sequence numbers in OC-Supported-Features just because
 some reporting nodes prefer to do things complicated rather than simple an=
d I’m not convinced that this would be the way to go.


 


Ulrich


 


 






From:=
 ext Steve Donovan [=
mailto:srdonovan@usdonovans.com=
]


Sent: Thursday, December 12, 2013 2:55 PM

To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org

Subject: Re: [Dime] OVLI: comments to 4.1






 


Ulrich,



No, the sequence number can't be mandatory.  It always needs to be sen=
t to allow for end-points that what to use the logic I proposed.



An endpoint that receives the sequence number can choose to ignore it, but =
endpoints must always send sequence numbers.



Steve




On 12/12/13 3:30 AM, Wiehe, Ulrich (NSN - DE/Munich)=
 wrote:






Steve,


 


do you mea=
n „ keep sequence number in OC-Supported-Features as an optional AVP =
that may be ignored by the receiver and need notbe included by the
 sender”?


 


Ulrich


 






From:=
 DiME [mailto:dime-bounces@ietf.org]
On Behalf Of ext Steve Donovan

Sent: Wednesday, December 11, 2013 2:34 PM

To: dime@ietf.org

Subject: Re: [Dime] OVLI: comments to 4.1






 


Ulrich,



My email showed how a reporting node could avoid the work of recalculating =
capability information on a message by message basis using the sequence num=
ber.  This approach does require maintaining state.



As Ben pointed out, it is also possible to not follow my logic and do as yo=
u propose by ignoring the sequence number and going through the work of cal=
culating the response every time. 




Which approach to take is clearly an implementation decision.  We shou=
ld keep the sequence number to allow for the stateful approach for implemen=
tations that are willing to take advantage of maintaining state to avoid wo=
rk.



Steve




On 12/11/13 1:34 AM, Wiehe, Ulrich (NSN - DE/Munich)=
 wrote:






Jouni,


 


I do not agree.


 


My statement was general: reporting node may be server or SFA; support=
ed features may be defined features (default algo) or future extensions.


 


Ulrich


 


-----Original Message-----


From: ext Jouni Korhonen [ma=
ilto:jouni.nospam@gmail.com] 


Sent: Tuesday, December 10, 2013 10:46 PM


To: Wiehe, Ulrich (NSN - DE/Munich)


Cc: dime@ietf.org

Subject: Re: [Dime] OVLI: comments to 4.1


 


Ulrich,


 


On Dec 10, 2013, at 2:18 PM, "Wiehe, Ulrich (NSN - DE/Munich)&quo=
t; <ulrich.wiehe@nsn.com>=
 wrote:


 




 


 


-----Original Message-----


From: ext Jouni Korhonen [ma=
ilto:jouni.nospam@gmail.com] 


Sent: Tuesday, December 10, 2013 12:32 PM


To: Wiehe, Ulrich (NSN - DE/Munich)


Cc: dime@ietf.org

Subject: Re: [Dime] OVLI: comments to 4.1


 


 


On Dec 10, 2013, at 12:41 PM, "Wiehe, Ulrich (NSN - DE/Munich)&qu=
ot; <ulrich.wiehe@nsn.com> wrote:


 




Hi Jouni,


 


my understanding from Steve's clarification was that the reporting nod=
e would setup and maintain a database of "states", one per reacti=
ng node where a state of a reacting node is identified by a sequence number=
 and the database entry would contain the pre-calculated OLR. 

Hard to see how this is done without consuming resources.



 


It is mostly static information. Still I do not see how

you would get away without any state.


[Wiehe, Ulrich (NSN - DE/Munich)] There is no need for the reporting n=
ode to store and maintain information per reacting node because the reactin=
g node actually tells within the request message all information the report=
ing node needs to know. The reporting node simply fetches the pre-calculate=
d OLR that matches the supported features of the reacting node as indicated=
 in the request and appends it to the answer.




 


This could be true for the default algorithm in this spec. However,


given the extension mechanism we have in place it is quite possible


that the assumption does not hold for new features.


 


Also, if I were to implement a server front end agent that would<=
/o:p>


definitely need state and still ought to comply the protocol spec.


 


- Jouni


 


 


 


 






Furthermore,


Why would the reacting node be interested in config changes of the rep=
orting node?


Isn't it so that the reacting node is only interested in OLR changes?<=
o:p>




 


Sigh.. say the traffic abatement algorithm changes or new features


get added. Those have more impact than just OLR change.

 


- Jouni


 




 


Ulrich


 


-----Original Message-----


From: ext Jouni Korhonen [ma=
ilto:jouni.nospam@gmail.com] 


Sent: Tuesday, December 10, 2013 9:41 AM


To: Wiehe, Ulrich (NSN - DE/Munich)


Cc: dime@ietf.org

Subject: Re: [Dime] OVLI: comments to 4.1


 


 


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


 




But maintaining a specific state per reacting node is very resource co=
nsuming for the (overloaded) reporting node. It is simpler and more efficie=
nt to base any processing logic on actual information received in the reque=
st rather than on information stored from previous communication.




 


The "state" in a reporting node is merely the current config=
uration


and a counter for sequence number. Hard to me see that as resource


consuming function.


 


And the earlier comment of mine is done from reacting node point<=
/o:p>


of view, since it is more interested in the possible config changes


in the reporting node (e.g. S6a is stateless application, configuratio=
n


can change at any time).


 


- Jouni


 


 




 


Ulrich


 


-----Original Message-----


From: ext Jouni Korhonen [ma=
ilto:jouni.nospam@gmail.com] 


Sent: Monday, December 09, 2013 2:25 PM


To: Wiehe, Ulrich (NSN - DE/Munich)


Cc: dime@ietf.org

Subject: Re: [Dime] OVLI: comments to 4.1


 


 


On Dec 9, 2013, at 3:13 PM, "Wiehe, Ulrich (NSN - DE/Munich)"=
; <ulrich.wiehe@nsn.com> =
wrote:


 




There is a fundamental difference:


OLRs need to be stored, Feature-Vectors not.




 


How come feature vector does not need to be stored? I do not


get that? I would set my implementation to a specific state=



or mode based on the feature vector. When that changes I'd<=
/pre>

like to know that. And then keep functioning based on that.=



 


- Jouni


 




When receiving an OLR you may want to know whether its worth the effor=
t to replace an already stored OLR with the received OLR.


When receiving a Feature-Vector you just act on it.


 


Ulrich 


 


-----Original Message-----


From: ext Jouni Korhonen [ma=
ilto:jouni.nospam@gmail.com] 


Sent: Monday, December 09, 2013 1:55 PM


To: Wiehe, Ulrich (NSN - DE/Munich)


Cc: dime@ietf.org

Subject: Re: [Dime] OVLI: comments to 4.1


 


 


In the same vein as folks wanted send OLRs with the new or old informa=
tion,


the feature vector should behave in a same way IMHO. That implies ther=
e are


situations when a reception of the feature vector does not change anyt=
hing


in an endpoint current behavior.


 


- Jouni


 


On Dec 9, 2013, at 2:47 PM, "Wiehe, Ulrich (NSN - DE/Munich)"=
; <ulrich.wiehe@nsn.com> =
wrote:


 




Isn't it so that the Feature-Vector (if present) always contains somet=
hing that an implementation needs to act upon?


 


Ulrich


 


-----Original Message-----


From: ext Jouni Korhonen [ma=
ilto:jouni.nospam@gmail.com] 


Sent: Monday, December 09, 2013 1:12 PM


To: Wiehe, Ulrich (NSN - DE/Munich)


Cc: dime@ietf.org

Subject: Re: [Dime] OVLI: comments to 4.1


 


Ulrich,


 


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


 




Hi Jouni,


 


thank you for your response.


 


With regard to 3) 


I still fail to see the usecase for Sequence-Number or TimeStamp withi=
n OC-Feature-Vector. Please clarify.




 


Since we also allow extending the OC-Feature-Vector beyond recognition=
, 


it has good chances become a rather complex grouped AVP. In that conte=
xt


the Sequence-Number allows an easy and quick way to check if the featu=
re


vector contains something that an implementation needs to act upon.


 




With regard to 4)


This was not obvious to me. (The obvious typo is the missing "of&=
quot; between "one" and "the").




 


Ack. Fixed the missing 'of'.


 


- Jouni


 




 


Best regards


Ulrich


 


 


-----Original Message-----


From: ext Jouni Korhonen [ma=
ilto:jouni.nospam@gmail.com] 


Sent: Friday, December 06, 2013 11:17 AM


To: Wiehe, Ulrich (NSN - DE/Munich)


Cc: dime@ietf.org

Subject: Re: [Dime] OVLI: comments to 4.1


 


 


On Dec 5, 2013, at 3:23 PM, "Wiehe, Ulrich (NSN - DE/Munich)"=
; <ulrich.wiehe@nsn.com> =
wrote:


 




Dear all,


 


here are comments to clause 4.1:


 


1. The OC-Feature-Vector AVP is no longer a vector; the name of the AV=
P may be misleading. Proposal is to rename it to "OC-Supported-Feature=
s AVP"




 


OK with me.


 




2. The OC-Feature AVP is a vector of features. Proposal is to rename i=
t to "OC-Feature-Vector AVP"




 


OK with me.


 




3. The OC-Sequence-Number within OC-Feature-Vector only makes sense if=
 the receiving reporting endpoint can determine the identity of the reactin=
g endpoint (which is not necessarily the origin host (client),



 


My original proposal was to have seqnr as a timestamp. Some folks argu=
ed


it is no good and suggested seqnr. I still think time makes more sense=
 than


seqnr.


 




it may be an agent and it may not always be the same agent), and if th=
e reporting endpoint is required to store the OC-Feature-Vector / reacting-=
endpoint-identity pair (which I think both is not required). The reporting =
endpoint can base its processing logic on the actually received OC-Feature-=
Vector value, no matter whether it is brand-new or old but stil valid. Prop=
osal is to delete OC-Sequence-Number AVP from OC-Feature-Vector.=





 


Do not agree removing it.


 




4. The text


 


The reporting node that sends the answer also includes the OC-


Feature-Vector AVP that describe the capabilities it supports.  T=
he


set of capabilities advertised by the reporting node depends on local<=
o:p>


policies.  At least one the announced capabilities MUST match


mutually.  If there is no single matching capability the reacting=



node MUST act as if it does not implement DOIC and cease inserting


any DOIC related AVPs into any Diameter messages with this specific


reacting node.


 


is not clear.  Would the reporting node include the OC-Feature-Ve=
ctor AVP in the answer only if there is at least one matching capability? <=
o:p>




 


Because then they have found a way to exchange something that both end=
s


know how to handle it.


 




Mandating the reacting node to cease for all time inserting OC-Feature=
-Vector AVPs if it did not get back 




 


There is an obvious typo. It should say:


 


policies.  At least one the announced capabilities MUST match


mutually.  If there is no single matching capability the reportin=
g


node MUST act as if it does not implement DOIC and cease inserting


any DOIC related AVPs into any Diameter messages with this specific


reacting node.


 


- JOuni


 


 




at least one match is also not ok. The request might have been a realm=
-type request (i.e. without Destination Host) and the reacting node cannot =
control whether subsequent requests will take the same path to the same rep=
orting node.


Even if the request contains a destination host the reacting node cann=
ot know wether the reacting node's capabilities have been modified by the t=
ime a subsequent request is sent. 


Proposal is to keep only the first sentence and delete the rest.<=
/o:p>


 


Ulrich


 


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime




 




 




 




 




 




 




 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 




 




 




 






--_000_5BCBA1FC2B7F0B4C9D935572D90006681519E9FEDEMUMBX014nsnin_--


From ulrich.wiehe@nsn.com  Thu Dec 12 08:21:41 2013
Return-Path: 
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 7BDDF1ADFB7 for ; Thu, 12 Dec 2013 08:21:41 -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 48LDqI59R4OS for ; Thu, 12 Dec 2013 08:21:34 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 304AE1ADFE0 for ; Thu, 12 Dec 2013 08:21:33 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rBCGLQSl009667 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 12 Dec 2013 17:21:26 +0100
Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rBCGLPOF003074 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Dec 2013 17:21:26 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.152]) by DEMUHTC002.nsn-intra.net ([10.159.42.33]) with mapi id 14.03.0123.003; Thu, 12 Dec 2013 17:21:25 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Steve Donovan , "dime@ietf.org" 
Thread-Topic: [Dime] DOIC: Self-Contained OLRs
Thread-Index: AQHO67/t2PaAGa/GgUyaCwjRxXVUh5o5m/0AgAC8o/D///ghgIAAFu+wgBFDRACAABmHcIAA+40AgACAkLCAAUpWAIAAdj+AgAF3KaCAACIrAIAAN+/Q
Date: Thu, 12 Dec 2013 16:21:25 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519EA1B@DEMUMBX014.nsn-intra.net>
References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com>  <5BCBA1FC2B7F0B4C9D935572D90006681519BC90@DEMUMBX014.nsn-intra.net> <6390_1385631044_52970D44_6390_18593_1_6B7134B31289DC4FAF731D844122B36E30748E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BD19@DEMUMBX014.nsn-intra.net> <26C84DFD55BC3040A45BF70926E55F2587C1D028@SZXEMA512-MBX.china.huawei.com> <5BCBA1FC2B7F0B4C9D935572D90006681519DFC0@DEMUMBX014.nsn-intra.net> <26C84DFD55BC3040A45BF70926E55F2587C1D705@SZXEMA512-MBX.china.huawei.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E2DE@DEMUMBX014.nsn-intra.net> <26C84DFD55BC3040A45BF70926E55F2587C1DC24@SZXEMA512-MBX.china.huawei.com> <52A86839.4010103@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E931@DEMUMBX014.nsn-intra.net> <52A9BF98.6090805@usdonovans.com>
In-Reply-To: <52A9BF98.6090805@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.100]
Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D90006681519EA1BDEMUMBX014nsnin_"
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: 51028
X-purgate-ID: 151667::1386865286-00000661-BF5F9454/0-0/0-0
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Dec 2013 16:21:41 -0000

--_000_5BCBA1FC2B7F0B4C9D935572D90006681519EA1BDEMUMBX014nsnin_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Steve,

so you mean its allways case a) or allways case b) depending on local confi=
guration in the agent and not depending on message content.

Anyway, would you agree that in case a) the two DOIC associations may have =
independent different supported features?

Ulrich

From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Thursday, December 12, 2013 2:52 PM
To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
Subject: Re: [Dime] DOIC: Self-Contained OLRs

Ulrich,

My assumption is that and end-point is an end-point for all messages sent b=
etween the two end-points.

Steve
On 12/12/13 5:17 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
Steve,

Isn't it so that the agent may decide (e.g. based on the absence of Destina=
tion host in the received request and based of its ability/willingness to s=
elect the server)
either a) to take the role of an endpoint or b) to be transparent with rega=
rd to OC AVPs.
In case a) we end up with two DOIC associations, one between client and age=
nt, another one between agent and server. Different DOIC associations may h=
ave different advertised/negotiated features i.e. agent and server may use =
window algorithm, but client and agent use loss algorithm. Therefore the ho=
st-type window OLR must not be sent unchanged to the client.
In case b) being transparent includes not inserting realm-type AVPs.

We end up with receiving not more than one OLR at the client.

Ulrich




From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Wednesday, December 11, 2013 2:27 PM
To: dime@ietf.org
Subject: Re: [Dime] DOIC: Self-Contained OLRs

Susan,

The use case for an agent that sits between a DOIC client and a DOIC server=
 is Realm overload, which the agent might be responsible for reporting.  Th=
is will particularly be the case when there are multiple servers sitting be=
hind the agent.  This might be considered a server farm, as you indicate, b=
ut we don't have a good definition of server farm, so I'm being explicit.

In this case, the agent must handle to types of occurrences.

1) Server overload - In this case the agent will receive a node overload re=
port from the server.  The agent should (I'm not sure if we have defined th=
is behavior in the draft yet) send the report unchanged to the client.  The=
 agent will also most likely use the contents of the report to determine th=
e realm overload state.

2) Realm overload - In this case the agent will insert an overload report i=
nto the appropriate answer messages.

Is this consistent with your thinking?

Regards,

Steve
On 12/11/13 12:24 AM, Shishufeng (Susan) wrote:

Hi Ulrich,



I'm not sure if you are taking the overload of agent into account for which=
 we decided to not consider for the time being. If not, I couldn't understa=
nd why an agent which does not serve for a server farm needs to be a DOIC e=
ndpoint between the client and server if both of them support overload cont=
rol. My understanding is that if there is the need for an agent to take a r=
ole of a DOIC endpoint between a specific server and client, it would alway=
s do that, otherwise, it just transfer the overload information of the serv=
er to the client.



Best Regards,

Susan



-----Original Message-----

From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]

Sent: Tuesday, December 10, 2013 6:15 PM

To: Shishufeng (Susan); ext lionel.morand@orange.com; ext Jouni Korhonen; Ben Campbell

Cc: dime@ietf.org list

Subject: RE: [Dime] DOIC: Self-Contained OLRs



Hi Susan,



if the agent does not take the role of a DOIC endpont then the feature nego=
tiation/adverisement is between client and server and one host type OLR is =
sent from server to client. For the agent this is all transparent and there=
 is no need for the agent to support any DOIC feature.

However, if the agent takes the role of an DOIC endpoint then the feature n=
egotiation/advertisement is between client and agent and a separate feature=
 negotiation/advertisement is between agent and server. An OLR sent from se=
rver to agent is in-context with the supported features of server and agent=
 but possibly not in-context with supported features of client and agent an=
d therefore must not be (blindly) sent to the client. And in fact there is =
also no need to do that. For subsequent requests that contain the desinatio=
n host of the server, the agent will not take the role of a DOIC endpoint.



Best regards

Ulrich



-----Original Message-----

From: ext Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]

Sent: Tuesday, December 10, 2013 4:02 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



Hi Ulrich,



Thanks for your clarification. I understood the scenario, while from my poi=
nt of view, if the agent that selects the HSS is not configured to serve as=
 a load balancer for the HSS, the agent should not change any supported/neg=
otiated features between C and S, that would be the normal case. If the age=
nt serve as a load balancer for the HSS, the subsequent request from C towa=
rds the S would always go via the agent, in this case whatever the associat=
ions between C and A, between A and S are the same or not, it doesn't matte=
r. With an E2E solution as we agreed, I don't see the problem with it.



Best Regards,

Susan



-----Original Message-----

From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]

Sent: Monday, December 09, 2013 7:43 PM

To: Shishufeng (Susan); ext lionel.morand@orange.com; ext Jouni Korhonen; Ben Campbell

Cc: dime@ietf.org list

Subject: RE: [Dime] DOIC: Self-Contained OLRs



Hi Susan,



let me come back to your S6a example.



The MME (C) sends a request without Destination-Host towards the HPLMN (rea=
lm). There must be an agent (A) in the HPLMN (realm) that selects the HSS (=
S).

We would have two distinct DOIC associations: one between C and A, another =
between A and S (see figure 5 in clause 5.1). The two DOIC associations may=
 have different supported/negotiated features. An OLR sent from S to A base=
d on supported/negotiated features valid for the DOIC association between A=
 and S is at least problematic (out-of context) when sent from A to C.



When the MME (C) sends a subsequent request with Destination-Host towards t=
he HSS (S), there is no agent that selects the HSS (as the HSS is already s=
elected). For this session there is only one DOIC association between C and=
 S (see figure 3 in clause 5.1) and OLRs sent from S to C are not problemat=
ic.



Best regards

Ulrich





-----Original Message-----

From: ext Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]

Sent: Monday, December 09, 2013 11:30 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



Hi Ulrich,



I have different views. In any case, I think the host-type OLR should not b=
e ignored by the clients. On the contrary, the realm-type OLR can be though=
t as optimization, which may not even be needed at all for all cases, espec=
ially in 3GPP. Here is an example of S6a, in the case the first attach requ=
est comes from the UE to the MME, the MME can only derive the realm informa=
tion, and sends a request without Destination-Host towards the HPLMN. Since=
 the subscriber corresponding to the UE belongs to a specific HSS, and the =
HSS may provide its overload report to the MME, and the MME is able to know=
 how to react regarding the requests towards the HSS, which would be the no=
rmal case. Whether Realm report will be provided by the HSS or the agent se=
rving the HSS is kind of optimization which may help the MME to know how to=
 react on the requests towards the realm, not specific to the HSS.



Best Regards,

Susan



-----Original Message-----

From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]

Sent: Thursday, November 28, 2013 6:30 PM

To: ext lionel.morand@orange.com; ext Joun=
i Korhonen; Ben Campbell

Cc: dime@ietf.org list

Subject: 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 act=
ual OLR created by the reporting end point and which OLR is an additional O=
LR created by another node.



We have two cases:

a) The request sent by the client (reacting end point) contains no Destinat=
ion Host. The agent (reporting node) (after forwarding the request to the s=
elected server and receiving the answer) returns a realm-type OLR as the ac=
tual 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 Destinat=
ion 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 stat=
us. It could be provided an agent inserting this info in answers received f=
rom a server behind but also from a server that would know this info by som=
e internal magic.

But in any case, if we assume that the client will received a successful an=
swer from the server for an initial request with only Dest-Realm AVP, it sh=
ould be possible to have both report types in the answer: one for the serve=
r itself, one for the realm for new request sent to the realm with only Des=
t-Realm AVP.



Lionel



-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN -=
 DE/Munich) Envoy=E9 : jeudi 28 novembre 2013 10:26 =C0 : ext Jouni Korhone=
n; 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 a=
ligned with the "endpoint principle". If the ReportType is "realm" this ind=
icates 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  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 endpoin=
ts, the more it makes sense to me to keep the ReportType in the OC-OLR. Eve=
n if the baseline does not have agent overload etc, the ReportType fits wel=
l to the "endpoint principle" we have in the draft. It indeed gives more to=
ols to make a host vs. realm base decision on the reacting node and is plai=
n 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 Diamet=
er request that corresponds to the answer containing the OLR. My reasons fo=
r 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 i=
dentified by Origin-Realm, and so on. This means that the "meaning" of an O=
LR 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 answe=
r to another, it's meaning may change completely.



I think this approach is a mistake. I would greatly prefer that we explicit=
ly 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 variou=
s other AVPs to find all the information it needs. For example, I think a c=
ommon software design for overload control processing to be separated from =
application processing. The consumer cannot simply hand the OLR to that mod=
ule and expect things to work. The OC module must not only parse the OLR, b=
ut parse any other AVPs that are relevant. As OLR contents get extended (as=
sumedly following the same strategy as the base spec), the number of "conte=
xt" avps that must be interpreted can grow large. This approach is error pr=
one, and will likely encourage brittle, hard-to-maintain code. Self-contain=
ed OLRs would keep all the information related to overload in one place. ma=
king for simpler implementations.



2) It's more complex for the reporting node to send implicit values than ex=
plicit values. The sender cannot simply set the context to match the OLR--a=
ll those other AVPs have application or protocol layer meanings. Once a rep=
orting node realizes that it is overloade, it has to wait for the right ans=
wer that contains the right context before it can send the OLR. This is par=
ticularly 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 sig=
nificantly. 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 so=
me 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 overlo=
ad reports were self-contained, one could just reuse the report format we s=
pecify here. But if the meaning of an OLR depends on the way it's transport=
ed, this won't work. We would have to create a new or significantly modifie=
d OLR format if we found a need to transport OLRs in different ways. Self-c=
ontained OLRs would allow much greater flexibility.



So, in summary, I think that self-contained OLRs would lead to simpler impl=
ementations, less brittle deployments, and more flexibility for future evol=
ution 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 confiden=
tielles 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. Le=
s messages electroniques etant susceptibles d'alteration, Orange decline to=
ute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged inf=
ormation 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 dele=
te 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





--_000_5BCBA1FC2B7F0B4C9D935572D90006681519EA1BDEMUMBX014nsnin_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Steve,<=
/p>

 <=
/p>

so you mea=
n its allways case a) or allways case b) depending on local configuration i=
n the agent and not depending on message content.


 =
;


Anyway, wo=
uld you agree that in case a) the two DOIC associations may have independen=
t different supported features?


 =
;


Ulrich


 =
;






From:=
 ext Steve Donovan [=
mailto:srdonovan@usdonovans.com]


Sent: Thursday, December 12, 2013 2:52 PM

To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org

Subject: Re: [Dime] DOIC: Self-Contained OLRs






 


Ulrich,



My assumption is that and end-point is an end-point for all messages sent b=
etween the two end-points.



Steve




On 12/12/13 5:17 AM, Wiehe, Ulrich (NSN - DE/Munich)=
 wrote:






Steve,<=
/p>

 <=
/p>

Isn’=
t it so that the agent may decide (e.g. based on the absence of Destination=
 host in the received request and based of its ability/willingness
 to select the server)


either a) =
to take the role of an endpoint or b) to be transparent with regard to OC A=
VPs.


In case a)=
 we end up with two DOIC associations, one between client and agent, anothe=
r one between agent and server. Different DOIC associations
 may have different advertised/negotiated features i.e. agent and server ma=
y use window algorithm, but client and agent use loss algorithm. Therefore =
the host-type window OLR must not be sent unchanged to the client.


In case b)=
 being transparent includes not inserting realm-type AVPs.


 


We end up =
with receiving not more than one OLR at the client.


 


Ulrich


 


 


 


 






From:=
 DiME [mailto:dime-bounces@ietf.org]
On Behalf Of ext Steve Donovan

Sent: Wednesday, December 11, 2013 2:27 PM

To: dime@ietf.org

Subject: Re: [Dime] DOIC: Self-Contained OLRs






 


Susan,



The use case for an agent that sits between a DOIC client and a DOIC server=
 is Realm overload, which the agent might be responsible for reporting.&nbs=
p; This will particularly be the case when there are multiple servers sitti=
ng behind the agent.  This might be considered
 a server farm, as you indicate, but we don't have a good definition of ser=
ver farm, so I'm being explicit.



In this case, the agent must handle to types of occurrences.  



1) Server overload - In this case the agent will receive a node overload re=
port from the server.  The agent should (I'm not sure if we have defin=
ed this behavior in the draft yet) send the report unchanged to the client.=
  The agent will also most likely use
 the contents of the report to determine the realm overload state.



2) Realm overload - In this case the agent will insert an overload report i=
nto the appropriate answer messages.



Is this consistent with your thinking?



Regards,



Steve




On 12/11/13 12:24 AM, Shishufeng (Susan) wrote:=







Hi Ulrich,


 


I'm not sure if you are taking the overload of agent into account for =
which we decided to not consider for the time being. If not, I couldn't und=
erstand why an agent which does not serve for a server farm needs to be a D=
OIC endpoint between the client and server if both of them support overload=
 control. My understanding is that if there is the need for an agent to tak=
e a role of a DOIC endpoint between a specific server and client, it would =
always do that, otherwise, it just transfer the overload information of the=
 server to the client.


 


Best Regards,


Susan


 


-----Original Message-----


From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] 


Sent: Tuesday, December 10, 2013 6:15 PM


To: Shishufeng (Susan); ext lionel.morand@orange.com; ext Jouni Korhonen; Ben Campbell=



Cc: dime@ietf.org list=



Subject: RE: [Dime] DOIC: Self-Contained OLRs


 


Hi Susan,


 


if the agent does not take the role of a DOIC endpont then the feature=
 negotiation/adverisement is between client and server and one host type OL=
R is sent from server to client. For the agent this is all transparent and =
there is no need for the agent to support any DOIC feature.

However, if the agent takes the role of an DOIC endpoint then the feat=
ure negotiation/advertisement is between client and agent and a separate fe=
ature negotiation/advertisement is between agent and server. An OLR sent fr=
om server to agent is in-context with the supported features of server and =
agent but possibly not in-context with supported features of client and age=
nt and therefore must not be (blindly) sent to the client. And in fact ther=
e is also no need to do that. For subsequent requests that contain the desi=
nation host of the server, the agent will not take the role of a DOIC endpo=
int.


 


Best regards


Ulrich


 


-----Original Message-----


From: ext Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]


Sent: Tuesday, December 10, 2013 4:02 AM


To: Wiehe, Ulrich (NSN - DE/Munich); ext lionel.morand@orange.com; ext Jouni Korhonen; Ben Campbe=
ll


Cc: dime@ietf.org list=



Subject: RE: [Dime] DOIC: Self-Contained OLRs


 


Hi Ulrich,


 


Thanks for your clarification. I understood the scenario, while from m=
y point of view, if the agent that selects the HSS is not configured to ser=
ve as a load balancer for the HSS, the agent should not change any supporte=
d/negotiated features between C and S, that would be the normal case. If th=
e agent serve as a load balancer for the HSS, the subsequent request from C=
 towards the S would always go via the agent, in this case whatever the ass=
ociations between C and A, between A and S are the same or not, it doesn't =
matter. With an E2E solution as we agreed, I don't see the problem with it.=



 


Best Regards,


Susan


 


-----Original Message-----


From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]


Sent: Monday, December 09, 2013 7:43 PM


To: Shishufeng (Susan); ext lionel.morand@orange.com; ext Jouni Korhonen; Ben Campbell=



Cc: dime@ietf.org list=



Subject: RE: [Dime] DOIC: Self-Contained OLRs


 


Hi Susan,


 


let me come back to your S6a example.


 


The MME (C) sends a request without Destination-Host towards the HPLMN=
 (realm). There must be an agent (A) in the HPLMN (realm) that selects the =
HSS (S). 


We would have two distinct DOIC associations: one between C and A, ano=
ther between A and S (see figure 5 in clause 5.1). The two DOIC association=
s may have different supported/negotiated features. An OLR sent from S to A=
 based on supported/negotiated features valid for the DOIC association betw=
een A and S is at least problematic (out-of context) when sent from A to C.=



 


When the MME (C) sends a subsequent request with Destination-Host towa=
rds the HSS (S), there is no agent that selects the HSS (as the HSS is alre=
ady selected). For this session there is only one DOIC association between =
C and S (see figure 3 in clause 5.1) and OLRs sent from S to C are not prob=
lematic.


 


Best regards


Ulrich


 


 


-----Original Message-----


From: ext Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]


Sent: Monday, December 09, 2013 11:30 AM


To: Wiehe, Ulrich (NSN - DE/Munich); ext lionel.morand@orange.com; ext Jouni Korhonen; Ben Campbe=
ll


Cc: dime@ietf.org list=



Subject: RE: [Dime] DOIC: Self-Contained OLRs


 


Hi Ulrich,


 


I have different views. In any case, I think the host-type OLR should =
not be ignored by the clients. On the contrary, the realm-type OLR can be t=
hought as optimization, which may not even be needed at all for all cases, =
especially in 3GPP. Here is an example of S6a, in the case the first attach=
 request comes from the UE to the MME, the MME can only derive the realm in=
formation, and sends a request without Destination-Host towards the HPLMN. =
Since the subscriber corresponding to the UE belongs to a specific HSS, and=
 the HSS may provide its overload report to the MME, and the MME is able to=
 know how to react regarding the requests towards the HSS, which would be t=
he normal case. Whether Realm report will be provided by the HSS or the age=
nt serving the HSS is kind of optimization which may help the MME to know h=
ow to react on the requests towards the realm, not specific to the HSS.


 


Best Regards,


Susan


 


-----Original Message-----


From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]


Sent: Thursday, November 28, 2013 6:30 PM


To: ext lionel.morand@oran=
ge.com; ext Jouni Korhonen; Ben Campbell


Cc: dime@ietf.org list=



Subject: 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 th=
e actual OLR created by the reporting end point and which OLR is an additio=
nal OLR created by another node.


 


We have two cases:


a) The request sent by the client (reacting end point) contains no Des=
tination Host. The agent (reporting node) (after forwarding the request to =
the selected server and receiving the answer) returns a realm-type OLR as t=
he actual reporting-node-created OLR and optionally in addition a host-type=
 OLR as learned from the selected server.  The client may ignore the a=
dditional OLR.


b) The request sent by the client (reacting endpoint) contains the Des=
tination Host. The Server (reporting node) returns a host-type OLR as the a=
ctual reporting-node-created OLR in the answer. The agent may optionally in=
sert a realm-type OLR as additional OLR to the answer. The client may ignor=
e the additional OLR.


 


Ulrich


 


 


 


-----Original Message-----


From: ext lionel.morand@or=
ange.com [mailto:lionel.mor=
and@orange.com]


Sent: Thursday, November 28, 2013 10:31 AM


To: Wiehe, Ulrich (NSN - DE/Munich); ext Jouni Korhonen; Ben Campbell<=
o:p>


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 recei=
ved from a server behind but also from a server that would know this info b=
y some internal magic.


But in any case, if we assume that the client will received a successf=
ul 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 onl=
y Dest-Realm AVP.


 


Lionel


 


-----Message d'origine-----


De : DiME [mailto:dime-b=
ounces@ietf.org] De la part de Wiehe, Ulrich (NSN - DE/Munich) Envoy=E9=
 : jeudi 28 novembre 2013 10:26 =C0 : ext Jouni Korhonen; Ben Cam=
pbell Cc : dime@ietf.org list Obj=
et : 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 &=
quot;realm" this indicates to the reacting end point that the reportin=
g 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 repor=
ting end point is a server. How can the reporting end point be both agent a=
nd server?


 


Ulrich


 


-----Original Message-----


From: DiME [mailto:dime-bounc=
es@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 <=
/o:p>


ReportType AVP in an OLR, rather than




 


The more I spent time thinking/writing the actual procedures on the en=
dpoints, 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 fit=
s well to the "endpoint principle" we have in the draft. It indee=
d gives more tools to make a host vs. realm base decision on the reacting n=
ode 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 D=
iameter request that corresponds to the answer containing the OLR. My reaso=
ns 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 applica=
tion identified by the Application-Id field of the enclosing answer, the re=
alm identified by Origin-Realm, and so on. This means that the "meanin=
g" of an OLR cannot be determined from the OLR contents alone; OLRs on=
ly 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 exp=
licitly include such values in the OLR itself, for multiple reasons:


 


1) It's more complex to interpret implicit, contextual values than exp=
licit values. The consumer cannot simply look at the OLR; it must look in v=
arious other AVPs to find all the information it needs. For example, I thin=
k a common software design for overload control processing to be separated =
from application processing. The consumer cannot simply hand the OLR to tha=
t module and expect things to work. The OC module must not only parse the O=
LR, but parse any other AVPs that are relevant. As OLR contents get extende=
d (assumedly following the same strategy as the base spec), the number of &=
quot;context" avps that must be interpreted can grow large. This appro=
ach is error prone, and will likely encourage brittle, hard-to-maintain cod=
e. Self-contained OLRs would keep all the information related to overload i=
n one place. making for simpler implementations.


 


2) It's more complex for the reporting node to send implicit values th=
an explicit values. The sender cannot simply set the context to match the O=
LR--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 righ=
t answer that contains the right context before it can send the OLR. This i=
s particularly troublesome for agents, since they will typically have to in=
sert OLRs into answers created by other nodes. 


 


If the reporting node screws this up, the meaning of the OLR may chang=
e significantly. So again, implicit meaning gives us error prone implementa=
tions. 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.<=
o:p>


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 <=
o:p>


are distinct from those sent by a server, see Steve's agent overload <=
o:p>


draft, or my dh/dr example.)


 


OTOH, explicit values will work for all cases where we need to associa=
te some arbitrary value with an OLR.


 


4) Implicit values seriously constrain the future evolution of Diamete=
r OC standards. For example, lets say we find a good reason to allow OLRs t=
o be sent out of band, or be sent in a dedicated Diameter application. If o=
verload 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 tran=
sported, this won't work. We would have to create a new or significantly mo=
dified OLR format if we found a need to transport OLRs in different ways. S=
elf-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.iet=
f.org/mailman/listinfo/dime




 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 


______________________________________________________________________=
___________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploite=
s ou copies sans autorisation. Si vous avez recu ce message par erreur, veu=
illez le signaler a l'expediteur et le detruire ainsi que les pieces jointe=
s. Les messages electroniques etant susceptibles d'alteration, Orange decli=
ne toute responsabilite si ce message a ete altere, deforme ou falsifie. Me=
rci.


 


This message and its attachments may contain confidential or privilege=
d 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.iet=
f.org/mailman/listinfo/dime


 




 




 






--_000_5BCBA1FC2B7F0B4C9D935572D90006681519EA1BDEMUMBX014nsnin_--

From nsalot@cisco.com  Thu Dec 12 08:26:18 2013
Return-Path: 
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 7C32F1AE35B for ; Thu, 12 Dec 2013 08:26:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.501
X-Spam-Level: 
X-Spam-Status: No, score=-9.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.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 Gu0Mr01joUh5 for ; Thu, 12 Dec 2013 08:26:10 -0800 (PST)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id AE54E1AE358 for ; Thu, 12 Dec 2013 08:26:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=49934; q=dns/txt; s=iport; t=1386865564; x=1388075164; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=LLnJvVtkMqfvan5/nINHdFxXACBwLtg3q6AcWb0aLkg=; b=SYeeRHegewpxYY7Ju5igNBTDQMraE0joKxn7h4bKTJisCNMji+oibVXd YnopRLFhoVB9IwALLl9B1sLZf64/kxIdssZG0Ti7Bktb/STTttYPg148F WCQ8nnbpyC59Mlwm+eYNkKW5FCpx+r7wtpHcMyYFPs7UDRgmPntFUHGZb g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AksFAGniqVKtJXG8/2dsb2JhbABQCYJGRDhVuFuBHBZ0giUBAQEEAQEBFxNBCwwEAgEIDgMEAQELFgEGByEGCxQJCAIEAQ0FCIdoAxENu1ANhxITBI0AgTkqLQQGAQaDG4ETBJQygXiORYU6gymCKg
X-IronPort-AV: E=Sophos;i="4.93,879,1378857600"; d="scan'208,217";a="6322408"
Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by alln-iport-6.cisco.com with ESMTP; 12 Dec 2013 16:26:02 +0000
Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id rBCGQ1bS025151 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Dec 2013 16:26:02 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.227]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0123.003; Thu, 12 Dec 2013 10:26:01 -0600
From: "Nirav Salot (nsalot)" 
To: Steve Donovan , Jouni Korhonen 
Thread-Topic: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3
Thread-Index: AQHO90VQs8ahl6t/j0WtaMBOVpqI85pQvUrg
Date: Thu, 12 Dec 2013 16:26:01 +0000
Message-ID: 
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DB1B@DEMUMBX014.nsn-intra.net>  <52A5E902.20605@usdonovans.com> <7475B713-1104-4791-96B1-CE97632A0D69@nostrum.com>  <5BCBA1FC2B7F0B4C9D935572D90006681519E476@DEMUMBX014.nsn-intra.net> <1CD20507-B0FE-4367-804A-B831734CF060@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E6DC@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D90006681519E712@DEMUMBX014.nsn-intra.net> <4A151D70-0291-4238-85B1-03BB54B361E6@gmail.com> <52A864FF.10705@usdonovans.com>   <52A9C62A.6010207@usdonovans.com>
In-Reply-To: <52A9C62A.6010207@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.65.48.72]
Content-Type: multipart/alternative; boundary="_000_A9CA33BB78081F478946E4F34BF9AAA014D31B3Cxmbrcdx10ciscoc_"
MIME-Version: 1.0
Cc: Ben Campbell , "dime@ietf.org list" 
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Dec 2013 16:26:18 -0000

--_000_A9CA33BB78081F478946E4F34BF9AAA014D31B3Cxmbrcdx10ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Steve,

So as I understand it is not a common case for different agent to provide d=
ifferent view of the same realm and this may have happen during a small win=
dow when synchronization has not taken place between the geographically dis=
tributed agents.
Right?

If so, I can understand the following part of your proposal.
One proposal for how we deal with the fact that different reports can have =
different values is to have the reacting node treat the first reporting nod=
e as the authority for reporting realm overload state for that overload ins=
tance.

i.e. I can understand to define some behavior for the reacting node to hand=
le the case (which is anyway rare case) when two agents provide different r=
ealm-report for the same report.
The behavior could be simply to consider only the last report when two agen=
ts have sent two different reports of the same realm. (And this will also w=
ork when the same agent has sent two different realm-reports, purposefully =
- e.g. due to the change in the realm overload).
But this still does not require adding of agent's identity in the overload-=
report.

Regards,
Nirav.

From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Thursday, December 12, 2013 7:50 PM
To: Nirav Salot (nsalot); Jouni Korhonen
Cc: Ben Campbell; dime@ietf.org list
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comment=
s to 4.3

Nirav,

See inline.

Steve
On 12/12/13 6:40 AM, Nirav Salot (nsalot) wrote:

All,



I do not understand this discussion regarding different agents of the same =
realm having different view of the realm and provide different overload rep=
ort.
We can make the statement that all senders of realm reports should send the=
 same report.  This does not guarantee that it will always happen.  If agen=
ts are sending the report, they are generally distributed elements.  In ver=
y large networks, this distribution can span continents.  There will be a l=
ag in the "synchronization" of the realm overload information.

My concern is that we have well defined behavior for when a reactor receive=
s conflicting realm reports.  We need to avoid thrashing between different =
reduction levels, which could make the overload situation worse.




Additionally, I also do not understand the proposal of adding identity of t=
he agent generating "realm report" into the report.
Adding the endpoint identity is needed to allow the reacting node to know t=
hat it is receiving two different views of Realm overload from two differen=
t reporting end-points.




What is the use of this identity at the reacting node when the report is re=
alm report? Why should the reacting node care who generated the realm repor=
t?
One proposal for how we deal with the fact that different reports can have =
different values is to have the reacting node treat the first reporting nod=
e as the authority for reporting realm overload state for that overload ins=
tance.  In this case, the reacting node would ignore reports received from =
other reporting nodes. In order to ignore reports from non authoritative en=
dpoints requires the reacting node to know which endpoints send which repor=
ts.






Regards,

Nirav.



-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen

Sent: Thursday, December 12, 2013 5:06 PM

To: Steve Donovan

Cc: Ben Campbell; dime@ietf.org list

Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comment=
s to 4.3



Steve,



On Dec 11, 2013, at 3:13 PM, Steve Donovan  wrote:



Jouni,



We need the sequence number to be strictly increasing.  I don't see the nee=
d for it to increase in uniform amounts.  Using time does fit these require=
ments.  I'm ok with using time as long as we don't call the AVP timestamp.



Ulrich does bring up an interesting use case, where a client is receiving r=
ealm reports for the same realm from different agents.  We need to define t=
he clients behavior in this case.



Any suggestions? I mean agents may have hugely different view of the realm =
if they are acting on their own.



Presumably the client needs to be able to determine who generated the realm=
 report.  This cannot be determine based on the content of the message or t=
he connection on which the message arrived.  It seems like we might need "R=
eport Generator Diameter ID" in the overload report specifically for Realm =
reports.



Once the client is able to differentiate between realm reports sent by diff=
erent agents (or servers) we need logic defining how the client deals with =
a new overload report.



I need now to check one of the basic assumptions on DOIC now so that we hav=
e the same understanding. I went back to the endpoint text in Section 5.1. =
There, for example in Figures

4 and 5 the DOIC association and the endpoint assumption does does not work=
 IMHO because we have no endpoint identity in the OLR. In order the endpoin=
t assumption to work (as I drew it on the white board in Porto), it would r=
equire as many Diameter level sessions as there are DOIC associations.



So.. has assumptions shifted in a meanwhile and I have just not paid attent=
ion?



I see a couple of options (others will probably see options I am missing):



- Use the last received realm report - This introduces the possibility of t=
hrashing between two different reduction values and different durations.  N=
ote that this approach does not require the source of the report to be incl=
uded in the report.



- Only listen to one source of realm overload - The approach would be to re=
member who sent the first overload report from the realm and ignore realm o=
verload reports from other sources.  This behavior would likely be constrai=
ned to a single occurrence of realm overload.  Meaning that the "memory" of=
 the report source would only last as long as that overload event persists.=
  Once the overload event goes away, the report source would be forgotten a=
nd a new source could be used for the next occurrence.



On the surface, the second approach looks better to me.



Or add the identity of the OLR originator explicitly if it cannot be determ=
ined implicitly (i.e. from the Diameter message's Origin-Host/Realm).



Or assume the endpoint really is the endpoint in DOIC and Diameter session =
sense.



- Jouni





Steve



On 12/11/13 2:15 AM, Jouni wrote:

Ulrich,



I might be slow but.. Section 4.4 says



   control endpoints.  The sequence number is only required to be unique

   between two overload control endpoints and does not need to be



Unique between two endpoints..



Section 5.1 talks about endpoints:



   of an arbitrary Diameter network.  The overload control information

   is exchanged over on a "DOIC association" between two communication

   endpoints.  The endpoints, namely the "reacting node" and the

   "reporting node" do not need to be adjacent Diameter peer nodes,

nor



So if your agents inject realm reports, they need to be endpoints to

the client. Similar to Figure 5. Therefore the sequence number spaces

between

C-A1 and C-A2 are separate.



Now it is not clear to me, whether in your reasoning the C would see

the server identity (as the endpoint) when there is an active "DEP

agent" on the path. That would not clearly work and not be align with

the endpoint assumption.



Note that at some point of time we had (at least on a discussion

level in f2f meeting) report originator identity in the OLR. That

would make endpoint identification trivial. Now a "DEP agent" needs

to act as a "server" for its clients in order to appear as an endpoint.



- Jouni



ps: still think the use of Time is simpler..





On Dec 11, 2013, at 9:43 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:





That's not predictable. It may be the same server in some cases, and differ=
ent servers in other cases.



-----Original Message-----

From: ext Jouni [

mailto:jouni.nospam@gmail.com

]

Sent: Wednesday, December 11, 2013 8:38 AM

To: Wiehe, Ulrich (NSN - DE/Munich)

Cc: Ben Campbell;

dime@ietf.org

 list; Steve Donovan

Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI:

comments to 4.3





Ulrich,



On Dec 11, 2013, at 9:21 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:





Jouni,



ad 1. "monotonically" does not express your intention. What we are looking =
for may be "stepwise with fixed step".



Ad 2. Is not necessarily a mistake that could result in out-of-sequence seq=
uence numbers. When a client C sends a realm-type requests towards any serv=
er in the realm, an agent A1 that selects the server would send back the re=
alm-type OLR with sequence number s1. The next realm-type request sent by C=
 (that survived the throttling) may take a path that does not include A1 bu=
t A2. A2 then selects the server and sends back a sequence number s2. Nothi=
ng ensures that s1 and s2 are in sequence.



Would the server in both cases (via A1 and A2) be the same?



- Jouni







Ulrich





-----Original Message-----

From: ext Jouni Korhonen [

mailto:jouni.nospam@gmail.com

]

Sent: Tuesday, December 10, 2013 10:31 PM

To: Wiehe, Ulrich (NSN - DE/Munich)

Cc: Ben Campbell;

dime@ietf.org

 list; Steve Donovan

Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI:

comments to 4.3



Ulrich,



On Dec 10, 2013, at 4:31 PM, "Wiehe, Ulrich (NSN - DE/Munich)"



 wrote:





Jouni,



1. I find the texts

a) "The sequence number ... does not need to be monotonically increasing"

and



Means the delta from old-seqno to new-seqno can be any non-negative

integer (within the given limits) not something fixed step/delta

(like +1). As long as "new-seqno >=3D old-seqno" holds we are fine.





b) "...the new sequence number MUST be greater or equal than the old sequen=
ce number..."

contradicting.

Can you please clarify.



See above. (mind the overflow case)





2. The expected behaviour when receiving an out-of-sequence sequence number=
 within OC-OLR is described in 4.3:

"The receiver SHOULD discard an OC-OLR AVP with a sequence number that is l=
ess than previously received one."

I don't find this very robust. Once a higher sequence number (received erro=
neously by mistake) is accepted you cannot (easily) recover.



I find it more robust in a sense that I should not care about stale old inf=
ormation.

However, since we are piggybacking (by popular demand) we have

little room for seqno re-sync negotiation.



What is the mistake you refer here? A misbehaving implementation?

In that case, it deserves to get a manual intervention once figured

out by admins checking alarms and logs. If the mistake is due other

things, like endpoints being out of sync, we currently have no written down=
 mechanism to survive that.





3. The expected behaviour when receiving an out-of-sequence sequence number=
 within the OC-Supported-Features AVP is not described. What is the intenti=
on here?



No intention. Just a sloppy specification. You are right that

something needs to be done & clarified here. (again the semantics

of Time would nice..)



I'll propose something. Others should too ;)



- Jouni





Ulrich



-----Original Message-----

From: DiME [

mailto:dime-bounces@ietf.org

] On Behalf Of ext Jouni Korhonen

Sent: Tuesday, December 10, 2013 8:28 AM

To: Ben Campbell;

dime@ietf.org

 list; Steve Donovan

Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re:

OVLI: comments to 4.3





Fine.. lets define then the sequence number semantics. Basic

unsigned integer math. The text proposal is the following:



4.4.  OC-Sequence-Number AVP



The OC-Sequence-Number AVP (AVP code TBD3) is type of Unsigned64.

Its usage in the context of the overload control is described in

Sections 4.1 and 4.3.



>From the functionality point of view, the OC-Sequence-Number AVP

MUST be used as a non-volatile increasing counter between two

overload control endpoints.  The sequence number is only required

to be unique between two overload control endpoints and does not

need to be monotonically increasing.



When comparing two sequence numbers, the new sequence number MUST

be greater or equal than the old sequence number within a window

that is half of the size of the maximum sequence number. This

allows a simple handling of the sequence number overflow using

unsigned integer arithmeticf:



  #define WINDOW 0x8000000000000000ULL



  bool verify_seqnum( uint64_t newsn, uint64_t oldsn ) {

      if (newsn - oldsn <=3D WINDOW)

          // newsn >=3D oldsn

          return true;

      } else

          // outside window or newsn < oldsn

          return false;

      }

  }







The above should even work is someone shovels NTP times into

sequence numbers with a blind typecasting.



- Jouni



On Dec 10, 2013, at 12:34 AM, Ben Campbell 

 wrote:





On Dec 9, 2013, at 10:00 AM, Steve Donovan 

 wrote:





Jouni,



I propose that we keep the name OC-Sequence-Number but that we use the Time=
 type for OC-Sequence-Number.  It is misleading and potentially confusing t=
o call it OC-Time-Stamp.





I could live with that, although I would rather just define the expected pr=
operties of the sequence number, and leave the implementation up to the imp=
lementor. I assume your reasoning for not calling it a timestamp is that yo=
u do not want people to try to use it as a time base reference. If so, then=
 we don't require any connection to a clock. We just need it to be monotoni=
cally increasing.





We might consider expanding on the format of the AVP to make it something l=
ike Session-ID, where it is a concatenation of the Diameter-ID of the gener=
ating node and a timestamp.  This might help the reacting node keep track o=
f which sequence number it has received.





Do we need a uniqueness across multiple nodes property? If so, why?





Steve



On 12/9/13 5:37 AM, Jouni Korhonen wrote:



Folks



Could we conclude on the sequence number vs. time stamp vs. something else?

We got more important places to spend our energy than this ;)



My proposal is the following (based on the original pre-00 design):



o We change the OC-Sequence-Number to OC-Time-Stamp in all occurrences

in the -01.

o We use RFC6733 Time type for the OC-Time-Stamp. RFC6733 gives us

already exact definition how to handle the AVP.

o Define that the OC-Time-Stamp is the time of the creation of the

"original" AVP within whose context the time stamp is present.

o The OC-Time-Stamp AVP uniqueness is still considered to be in scope

of the communicating endpoints.

o The time stamp can be used to quickly determine if the content of

the encapsulating AVP context has changed (among other properties).

This would be useful specifically in the future when the encapsulating

grouped AVPs  grow in size and functionality.





- Jouni



_______________________________________________

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







_______________________________________________

DiME mailing list

DiME@ietf.org

https://www.ietf.org/mailman/listinfo/dime




--_000_A9CA33BB78081F478946E4F34BF9AAA014D31B3Cxmbrcdx10ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Steve,<=
/p>

 <=
/p>

So as I understand it is =
not a common case for different agent to provide different view of the same=
 realm and this may have happen during a small window when
 synchronization has not taken place between the geographically distributed=
 agents.


Right?<=
/p>

 <=
/p>

If so, I can understand t=
he following part of your proposal.


One proposal for how we deal with the fact that diff=
erent reports can have different values is to have the reacting node treat =
the first reporting node as the authority for reporting realm overload stat=
e for that overload instance.<=
/p>

 <=
/p>

i.e. I can understand to =
define some behavior for the reacting node to handle the case (which is any=
way rare case) when two agents provide different realm-report
 for the same report.


The behavior could be sim=
ply to consider only the last report when two agents have sent two differen=
t reports of the same realm. (And this will also work when
 the same agent has sent two different realm-reports, purposefully – =
e.g. due to the change in the realm overload).


But this still does not r=
equire adding of agent's identity in the overload-report.=



 <=
/p>

Regards,


Nirav.<=
/p>

 <=
/p>





From: Steve Donovan [mailto:srdonovan@usdonovans.com]


Sent: Thursday, December 12, 2013 7:50 PM

To: Nirav Salot (nsalot); Jouni Korhonen

Cc: Ben Campbell; dime@ietf.org list

Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: =
comments to 4.3






 


Nirav,



See inline.



Steve




On 12/12/13 6:40 AM, Nirav Salot (nsalot) wrote:






All,


 


I do not understand this discussion regarding different agents of the =
same realm having different view of the realm and provide different overloa=
d report.




We can make the statement that all senders of realm =
reports should send the same report.  This does not guarantee that it =
will always happen.  If agents are sending the report, they are genera=
lly distributed elements.  In very large networks,
 this distribution can span continents.  There will be a lag in the &q=
uot;synchronization" of the realm overload information.



My concern is that we have well defined behavior for when a reactor receive=
s conflicting realm reports.  We need to avoid thrashing between diffe=
rent reduction levels, which could make the overload situation worse.






 


Additionally, I also do not understand the proposal of adding identity=
 of the agent generating "realm report" into the report.


Adding the endpoint identity is needed to allow the =
reacting node to know that it is receiving two different views of Realm ove=
rload from two different reporting end-points.






 


What is the use of this identity at the reacting node when the report =
is realm report? Why should the reacting node care who generated the realm =
report?


One proposal for how we deal with the fact that diff=
erent reports can have different values is to have the reacting node treat =
the first reporting node as the authority for reporting realm overload stat=
e for that overload instance.  In
 this case, the reacting node would ignore reports received from other repo=
rting nodes. In order to ignore reports from non authoritative endpoints re=
quires the reacting node to know which endpoints send which reports.






 


 


Regards,


Nirav.


 


-----Original Message-----


From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of Jouni Korhonen


Sent: Thursday, December 12, 2013 5:06 PM


To: Steve Donovan


Cc: Ben Campbell; dime@ietf.org l=
ist


Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: co=
mments to 4.3


 


Steve,


 


On Dec 11, 2013, at 3:13 PM, Steve Donovan <srdonovan@usdonovans.com> wrote:

 




Jouni,


 


We need the sequence number to be strictly increasing.  I don't s=
ee the need for it to increase in uniform amounts.  Using time does fi=
t these requirements.  I'm ok with using time as long as we don't call=
 the AVP timestamp.


 


Ulrich does bring up an interesting use case, where a client is receiv=
ing realm reports for the same realm from different agents.  We need t=
o define the clients behavior in this case.  




 


Any suggestions? I mean agents may have hugely different view of the r=
ealm if they are acting on their own.


 




Presumably the client needs to be able to determine who generated the =
realm report.  This cannot be determine based on the content of the me=
ssage or the connection on which the message arrived.  It seems like w=
e might need "Report Generator Diameter ID" in the overload repor=
t specifically for Realm reports.  


 


Once the client is able to differentiate between realm reports sent by=
 different agents (or servers) we need logic defining how the client deals =
with a new overload report.  




 


I need now to check one of the basic assumptions on DOIC now so that w=
e have the same understanding. I went back to the endpoint text in Section =
5.1. There, for example in Figures


4 and 5 the DOIC association and the endpoint assumption does does not=
 work IMHO because we have no endpoint identity in the OLR. In order the en=
dpoint assumption to work (as I drew it on the white board in Porto), it wo=
uld require as many Diameter level sessions as there are DOIC associations.=



 


So.. has assumptions shifted in a meanwhile and I have just not paid a=
ttention?


 




I see a couple of options (others will probably see options I am missi=
ng):


 


- Use the last received realm report - This introduces the possibility=
 of thrashing between two different reduction values and different duration=
s.  Note that this approach does not require the source of the report =
to be included in the report.


 


- Only listen to one source of realm overload - The approach would be =
to remember who sent the first overload report from the realm and ignore re=
alm overload reports from other sources.  This behavior would likely b=
e constrained to a single occurrence of realm overload.  Meaning that =
the "memory" of the report source would only last as long as that=
 overload event persists.  Once the overload event goes away, the repo=
rt source would be forgotten and a new source could be used for the next oc=
currence.


 


On the surface, the second approach looks better to me.



 


Or add the identity of the OLR originator explicitly if it cannot be d=
etermined implicitly (i.e. from the Diameter message's Origin-Host/Realm).<=
o:p>


 


Or assume the endpoint really is the endpoint in DOIC and Diameter ses=
sion sense.


 


- Jouni


 




 


Steve


 


On 12/11/13 2:15 AM, Jouni wrote:




Ulrich,


 


I might be slow but.. Section 4.4 says


 


   control endpoints.  The sequence number is only requ=
ired to be unique


   between two overload control endpoints and does not need =
to be


 


Unique between two endpoints..


 


Section 5.1 talks about endpoints:


 


   of an arbitrary Diameter network.  The overload cont=
rol information


   is exchanged over on a "DOIC association" betwe=
en two communication


   endpoints.  The endpoints, namely the "reacting=
 node" and the


   "reporting node" do not need to be adjacent Dia=
meter peer nodes, 


nor


 


So if your agents inject realm reports, they need to be endpoints to <=
o:p>


the client. Similar to Figure 5. Therefore the sequence number spaces =



between


C-A1 and C-A2 are separate.


 


Now it is not clear to me, whether in your reasoning the C would see <=
o:p>


the server identity (as the endpoint) when there is an active "DE=
P 


agent" on the path. That would not clearly work and not be align =
with 


the endpoint assumption.


 


Note that at some point of time we had (at least on a discussion =



level in f2f meeting) report originator identity in the OLR. That 


would make endpoint identification trivial. Now a "DEP agent"=
; needs 


to act as a "server" for its clients in order to appear as a=
n endpoint.


 


- Jouni


 


ps: still think the use of Time is simpler..


 


 


On Dec 11, 2013, at 9:43 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:


 


 




That's not predictable. It may be the same server in some cases, and d=
ifferent servers in other cases.


 


-----Original Message-----


From: ext Jouni [


mailto:jouni.nospam@gmail.co=
m


]


Sent: Wednesday, December 11, 2013 8:38 AM


To: Wiehe, Ulrich (NSN - DE/Munich)


Cc: Ben Campbell;


dime@ietf.org


 list; Steve Donovan


Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: 


comments to 4.3


 


 


Ulrich,


 


On Dec 11, 2013, at 9:21 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:


 


 




Jouni,


 


ad 1. "monotonically" does not express your intention. What =
we are looking for may be "stepwise with fixed step".<=
/pre>

 


Ad 2. Is not necessarily a mistake that could result in out-of-sequenc=
e sequence numbers. When a client C sends a realm-type requests towards any=
 server in the realm, an agent A1 that selects the server would send back t=
he realm-type OLR with sequence number s1. The next realm-type request sent=
 by C (that survived the throttling) may take a path that does not include =
A1 but A2. A2 then selects the server and sends back a sequence number s2. =
Nothing ensures that s1 and s2 are in sequence.


 




Would the server in both cases (via A1 and A2) be the same?=



 


- Jouni


 


 


 




Ulrich


 


 


-----Original Message-----


From: ext Jouni Korhonen [


mailto:jouni.nospam@gmail.co=
m


]


Sent: Tuesday, December 10, 2013 10:31 PM


To: Wiehe, Ulrich (NSN - DE/Munich)


Cc: Ben Campbell;


dime@ietf.org


 list; Steve Donovan


Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: 


comments to 4.3


 


Ulrich,


 


On Dec 10, 2013, at 4:31 PM, "Wiehe, Ulrich (NSN - DE/Munich)&quo=
t; 


<ulrich.wiehe@nsn.com>


 wrote:


 


 




Jouni,


 


1. I find the texts


a) "The sequence number ... does not need to be monotonically inc=
reasing"


and


 




Means the delta from old-seqno to new-seqno can be any non-negative 


integer (within the given limits) not something fixed step/delta =



(like +1). As long as "new-seqno >=3D old-seqno" hold=
s we are fine.


 


 




b) "...the new sequence number MUST be greater or equal than the =
old sequence number..."


contradicting.


Can you please clarify.


 




See above. (mind the overflow case)


 


 




2. The expected behaviour when receiving an out-of-sequence sequence n=
umber within OC-OLR is described in 4.3:


"The receiver SHOULD discard an OC-OLR AVP with a sequence number=
 that is less than previously received one."


I don't find this very robust. Once a higher sequence number (received=
 erroneously by mistake) is accepted you cannot (easily) recover.


 




I find it more robust in a sense that I should not care about stale ol=
d information.


However, since we are piggybacking (by popular demand) we have 


little room for seqno re-sync negotiation.


 


What is the mistake you refer here? A misbehaving implementation? 


In that case, it deserves to get a manual intervention once figured 


out by admins checking alarms and logs. If the mistake is due other 


things, like endpoints being out of sync, we currently have no written=
 down mechanism to survive that.


 


 




3. The expected behaviour when receiving an out-of-sequence sequence n=
umber within the OC-Supported-Features AVP is not described. What is the in=
tention here?


 




No intention. Just a sloppy specification. You are right that 


something needs to be done & clarified here. (again the semantics =



of Time would nice..)


 


I'll propose something. Others should too ;)


 


- Jouni


 


 




Ulrich


 


-----Original Message-----


From: DiME [


mailto:dime-bounces@ietf.org<=
/a>


] On Behalf Of ext Jouni Korhonen


Sent: Tuesday, December 10, 2013 8:28 AM


To: Ben Campbell;


dime@ietf.org


 list; Steve Donovan


Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: 


OVLI: comments to 4.3


 


 


Fine.. lets define then the sequence number semantics. Basic 


unsigned integer math. The text proposal is the following:<=
/pre>

 


4.4.  OC-Sequence-Number AVP


 


The OC-Sequence-Number AVP (AVP code TBD3) is type of Unsigned64.=



Its usage in the context of the overload control is described in =



Sections 4.1 and 4.3.


 


From the functionality point of view, the OC-Sequence-Number AVP =



MUST be used as a non-volatile increasing counter between two 


overload control endpoints.  The sequence number is only required=
 


to be unique between two overload control endpoints and does not =



need to be monotonically increasing.


 


When comparing two sequence numbers, the new sequence number MUST 


be greater or equal than the old sequence number within a window =



that is half of the size of the maximum sequence number. This 


allows a simple handling of the sequence number overflow using 


unsigned integer arithmeticf:


 


  #define WINDOW 0x8000000000000000ULL


 


  bool verify_seqnum( uint64_t newsn, uint64_t oldsn ) {


      if (newsn - oldsn <=3D WINDOW)<=
/o:p>


          // newsn >=
=3D oldsn


          return true;&nb=
sp;  


      } else


          // outside wind=
ow or newsn < oldsn


          return false;&n=
bsp; 


      }


  }


 


 


 


The above should even work is someone shovels NTP times into 


sequence numbers with a blind typecasting.


 


- Jouni


 


On Dec 10, 2013, at 12:34 AM, Ben Campbell <ben@nostrum.com>


 wrote:


 


 




On Dec 9, 2013, at 10:00 AM, Steve Donovan <srdonovan@usdonovans.com>


 wrote:


 


 




Jouni,


 


I propose that we keep the name OC-Sequence-Number but that we use the=
 Time type for OC-Sequence-Number.  It is misleading and potentially c=
onfusing to call it OC-Time-Stamp.  


 


 




I could live with that, although I would rather just define the expect=
ed properties of the sequence number, and leave the implementation up to th=
e implementor. I assume your reasoning for not calling it a timestamp is th=
at you do not want people to try to use it as a time base reference. If so,=
 then we don't require any connection to a clock. We just need it to be mon=
otonically increasing.


 


 




We might consider expanding on the format of the AVP to make it someth=
ing like Session-ID, where it is a concatenation of the Diameter-ID of the =
generating node and a timestamp.  This might help the reacting node ke=
ep track of which sequence number it has received.


 


 




Do we need a uniqueness across multiple nodes property? If so, why?


 


 




Steve


 


On 12/9/13 5:37 AM, Jouni Korhonen wrote:


 




Folks


 


Could we conclude on the sequence number vs. time stamp vs. something =
else?


We got more important places to spend our energy than this ;)


 


My proposal is the following (based on the original pre-00 design):


 


o We change the OC-Sequence-Number to OC-Time-Stamp in all occurrences=



in the -01.


o We use RFC6733 Time type for the OC-Time-Stamp. RFC6733 gives us


already exact definition how to handle the AVP.


o Define that the OC-Time-Stamp is the time of the creation of the 


"original" AVP within whose context the time stamp is presen=
t.


o The OC-Time-Stamp AVP uniqueness is still considered to be in scope<=
o:p>


of the communicating endpoints.


o The time stamp can be used to quickly determine if the content of


the encapsulating AVP context has changed (among other properties).


This would be useful specifically in the future when the encapsulating=



grouped AVPs  grow in size and functionality.


 


 


- Jouni


 


_______________________________________________


DiME mailing list


 


 


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 


 


 


 


 




_______________________________________________


DiME mailing list


 


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime




_______________________________________________


DiME mailing list


 


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime




_______________________________________________


DiME mailing list


 


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime








 




 




 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 


 






--_000_A9CA33BB78081F478946E4F34BF9AAA014D31B3Cxmbrcdx10ciscoc_--


From nsalot@cisco.com  Thu Dec 12 08:37:10 2013
Return-Path: 
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 CB6F01ADF9A for ; Thu, 12 Dec 2013 08:37:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.501
X-Spam-Level: 
X-Spam-Status: No, score=-9.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.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 wcccKKkkaO4c for ; Thu, 12 Dec 2013 08:37:02 -0800 (PST)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id 4ADB01AE350 for ; Thu, 12 Dec 2013 08:37:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=55936; q=dns/txt; s=iport; t=1386866215; x=1388075815; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=l31+G2RD1UBLtMw0MhhAPjGXNDpzjCW2X0U6IhQ6cO8=; b=SBYUkI0FBgtnAnfBeieDY5QhrNPZn/y9Pos5J4P1xU2t9tPqBn8p/bP8 9xOpuInezrMU/tlDLpsynbgo7A4ByrW8Y4EnmFUwHuf6C5RMFBAO6cKYp 0AlcPDZkO3Jo6etqiiM2W7tQOG0Z1Jr2xjrPKVeT4Xzd8jAkD30r00pjz 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AksFAPTkqVKtJV2a/2dsb2JhbABZgkZEOFW4W4EcFnSCJQEBAQQBAQEXE0EbAgEIDgMEAQELFgEGByEGCxQJCAIEARIIEgEEh1EDEQ27Pw2HEhMEjQCBMTItCgEGgxuBEwSJC4sngXiORYU6gymCKg
X-IronPort-AV: E=Sophos;i="4.93,879,1378857600"; d="scan'208,217";a="6324954"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-6.cisco.com with ESMTP; 12 Dec 2013 16:36:53 +0000
Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rBCGarv0008027 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Dec 2013 16:36:53 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.227]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Thu, 12 Dec 2013 10:36:53 -0600
From: "Nirav Salot (nsalot)" 
To: Steve Donovan , "dime@ietf.org" 
Thread-Topic: [Dime] DOIC: Self-Contained OLRs
Thread-Index: AQHO67/s/vGpiVuf2UayvwQoJbzwfZo5m/0AgACzUoCAAAFygIAAE14AgAF8EACAACKcAIAANGaAgATJUgCAAAuAAIACAWkAgAAGHYCAAXsigIAALuKAgAAb/4CAAHc6gIAAOZAAgAAO+4CAAAVNAIAABNCAgAAF6QCAAAecAIAF/9gAgAAFIoCAANV2gIAARHaAgAHlZ9CAAEm9gIAAWSGggAACrFCAAAAqoIAAeyEAgADOAYCAAGoDgP//yK3w
Date: Thu, 12 Dec 2013 16:36:52 +0000
Message-ID: 
References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com>  <52A088D0.2020406@usdonovans.com>  <52A091CE.2000104@usdonovans.com> <13081_1386256433_52A09831_13081_8197_1_6B7134B31289DC4FAF! 731D84412 2B36E32B6EB@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B9209739738@ESESSMB101.ericsson.se>  <8FD63E2D-5203-4DA4-A6DA-C4CA181C9CFB@nostrum.com> <26C84DFD55BC3040A45BF70926E55F2587C1D786@SZXEMA512-MBX.china.huawei.com>  <52A86663.30500@usdonovans.com>  <087A34937E64E74E848732CFF8354B920973A82A@ESESSMB101.ericsson.se> <52A8B862.5040207@usdonovans.com> <087A34937E64E74E848732CFF8354B920973AAF5@ESESSMB101.ericsson.se> <52A9BE1F.7020201@usdonovans.com>
In-Reply-To: <52A9BE1F.7020201@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.65.48.72]
Content-Type: multipart/alternative; boundary="_000_A9CA33BB78081F478946E4F34BF9AAA014D31B94xmbrcdx10ciscoc_"
MIME-Version: 1.0
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Dec 2013 16:37:11 -0000

--_000_A9CA33BB78081F478946E4F34BF9AAA014D31B94xmbrcdx10ciscoc_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Steve,

Why do you always talk about "the application which the Diameter node does =
not understand?"
What if the reacting node supports two applications and in the message for =
application-X it receives the overload-report for application-Y?
Do you propose to ignore this report as well?

As already indicated earlier, by many of us, handling of application-Y's da=
ta in the application-X's message is not how the Diameter applications are =
designed today. And hence this type of proposal requires architectural supp=
ort for handling it. And there lies the complexity.
This main drawback was highlighted earlier as well but was conveniently ign=
ored while preparing the pros and cons list for the self-contained OLR.

Regards,
Nirav.

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: Thursday, December 12, 2013 7:16 PM
To: dime@ietf.org
Subject: Re: [Dime] DOIC: Self-Contained OLRs

Maria Cruz,

Can you explain the complexity behind the cross-application procedure.  The=
 work required is to ignore any application that the Diameter node does not=
 understand.  I don't see this as very complex.

Steve
On 12/12/13 1:26 AM, Maria Cruz Bartolome wrote:
Yes, I agree consistency is not any longer a problem, since now your intent=
ion is that _any_ (and multiple) application data could be conveyed within =
the same message.
But as mentioned a few times, I consider this not necessary since OLR is se=
nt in every answer.
A part from that, as mentioned by Lionel, this implies a cross-application =
procedure at both endpoints, that increases complexity and it is not requir=
ed for our work (RFC7068)

Cheers
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: mi=E9rcoles, 11 de diciembre de 2013 20:09
To: dime@ietf.org
Subject: Re: [Dime] DOIC: Self-Contained OLRs

Maria Cruz,

I don't agree with the assertion that self-contained OLRs results in the po=
tential for data inconsistency.  If a reactor receives an overload report f=
or an application that is not supported by the reactor then the reactor can=
 and should ignore that OLR.

The concept of self-contained overload reports would explicitly allow for t=
he contents of the overload report to be different than the message that is=
 carrying the OLR.  As with application-ids, if the reactor doesn't send me=
ssages to a reported host or realm then the reactor ignores that part of th=
e overload report.  As such, there is no need to check the implicit data wh=
en receiving a self-contained OLR.

Steve
On 12/11/13 12:25 PM, Maria Cruz Bartolome wrote:

Hello (and something else now :), fast key combination, I won't be able to =
repeat,  was the responsible)



As mentioned before, something else on cons side for self-contained:



A part from that,  one concern with "self-contained OLRs" is that some data=
 is duplicated. Duplication should be avoided, since then we need to assure=
 consistency, and error handing in case implicit and explicit data values a=
re different for any reason... what means that it may always be required to=
 check both implicit and explicit data.



Also, I think this is a pure implementation proposal. Regardless how the da=
ta is transported it could be packed in a "self-contained OLRs" within the =
diameter application, if for any implementation this is preferred.

Best regards
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE=
S (JEAN-JACQUES)
Sent: mi=E9rcoles, 11 de diciembre de 2013 19:02
To: dime@ietf.org
Subject: Re: [Dime] DOIC: Self-Contained OLRs

Hi Steve

I am sorry, Steve,  I do not see the difference between the Draft Roach sco=
pe approach and the self contained OLRs.

With the scope approach in Draft Roach : there is an overload metric AVP  (=
eg containing a % of traffic reduction) coupled with one or several Overlao=
d-Infoscope AVPs, an overlaod infoscope identifying an application or a des=
tination host or... . These Overlaod-Infoscope AVPs can be combined  with a=
lso  the possibility of  multi instances to have a list of applications, a =
list of destination hosts etc  to which the overload metric would apply.

With self contained OLR as you have described them, un OLR will also contai=
n an OC-Reduction-Percentage  AVP coupled with one or several others AVPs (=
the self containment approach) to indicate which application(s), destinatio=
ns host (s) etc the   OC-Reduction-Percentage  AVP applies.

Where is the difference?

So the drawbacks identified for the scope approach also apply with the self=
 contained approach

Best regards

JJacques



De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9 : mercredi 11 d=E9cembre 2013 14:20
=C0 : dime@ietf.org
Objet : Re: [Dime] DOIC: Self-Contained OLRs

JJacques,

While the self contained overload report concept may be similar to the scop=
es concept in the Roach draft, they are not the same.  As such, I don't agr=
ee with your assertion that the previous rejection of the Roach draft requi=
res us to reject self contained overload reports as currently being discuss=
ed.

Steve
On 12/11/13 2:27 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:
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 multip=
ly the number of AVPs in the OLRs (AVPs identifying Application, destinatio=
n 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 sel=
f 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 rec=
reate  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 si=
mple way to proceed, which drove to the current draft content. This decisio=
n is a strong argument that still prevails  for the current baseline descri=
bed in the current draft.

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

As also said, when news requirements will appear (eg session group or APN e=
xamples)  the baseline is extensible to support these new requirements .  I=
 prefer this way of progressive extensions , rather than to create a self c=
ontained 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=E9 : mardi 10 d=E9cembre 2013 04:58
=C0 : 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 righ=
t 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 opti=
mization 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 overloa=
d.

-          The last three pros are mainly for the case of overload of agent=
, if I understood them correctly. Overload of agent is still a controversia=
l scenario, we may need more discussion in the future. But anyway, with def=
inition 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-co=
ntained OLR.

Best Regards,
Susan

From: Ben Campbell [mailto:ben@nostrum.com]
Sent: Tuesday, December 10, 2013 7:53 AM
To: 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 wh=
at we do for a later (or final) version.

So far, I've seen 4 people opposed to self-contained OLRs (Lionel, Nirav, M=
aria, 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 lo=
ok 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 firs=
t group explain what they think the pros of implicit OLRs might be beyond t=
hose 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 application=
s at once, instead of having to signal each one separately.
  *   Allows an easy solution to our "loss" algorithm corner case of not be=
ing able to signal the end of a 100% overload condition
  *   Makes it easier to solve the agent overload problem, without requirin=
g 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 transac=
tion 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 trans=
action context and the report type. [I don't understand why this is valuabl=
e, 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 supporte=
d 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 > wrote:

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

- Jouni



_______________________________________________

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


--_000_A9CA33BB78081F478946E4F34BF9AAA014D31B94xmbrcdx10ciscoc_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Steve,<=
/p>

 <=
/p>

Why do you always talk ab=
out "the application which the Diameter node does not understand?"=
;


What if the reacting node=
 supports two applications and in the message for application-X it receives=
 the overload-report for application-Y?


Do you propose to ignore =
this report as well?


 <=
/p>

As already indicated earl=
ier, by many of us, handling of application-Y's data in the application-X's=
 message is not how the Diameter applications are designed
 today. And hence this type of proposal requires architectural support for =
handling it. And there lies the complexity.


This main drawback was hi=
ghlighted earlier as well but was conveniently ignored while preparing the =
pros and cons list for the self-contained OLR.


 <=
/p>

Regards,


Nirav.<=
/p>

 <=
/p>





From: DiME [mailto:dime-bounces@ietf.org]
On Behalf Of Steve Donovan

Sent: Thursday, December 12, 2013 7:16 PM

To: dime@ietf.org

Subject: Re: [Dime] DOIC: Self-Contained OLRs






 


Maria Cruz,



Can you explain the complexity behind the cross-application procedure. =
; The work required is to ignore any application that the Diameter node doe=
s not understand.  I don't see this as very complex.



Steve




On 12/12/13 1:26 AM, Maria Cruz Bartolome wrote:






Yes, I agree consistency =
is not any longer a problem, since now your intention is that _any_ =
(and multiple) application data could be conveyed within
 the same message.


But as mentioned a few ti=
mes, I consider this not necessary since OLR is sent in every answer.



A part from that, as ment=
ioned by Lionel, this implies a cross-application procedure at both endpoin=
ts, that increases complexity and it is not required for
 our work (RFC7068)


 <=
/p>

Cheers<=
/p>

/MCruz<=
/p>

 <=
/p>





From: DiME [ma=
ilto:dime-bounces@ietf.org]
On Behalf Of Steve Donovan

Sent: mi=E9rcoles, 11 de diciembre de 2013 20:09

To: dime@ietf.org

Subject: Re: [Dime] DOIC: Self-Contained OLRs






 


Maria Cruz,



I don't agree with the assertion that self-contained OLRs results in the po=
tential for data inconsistency.  If a reactor receives an overload rep=
ort for an application that is not supported by the reactor then the reacto=
r can and should ignore that OLR. 




The concept of self-contained overload reports would explicitly allow for t=
he contents of the overload report to be different than the message that is=
 carrying the OLR.  As with application-ids, if the reactor doesn't se=
nd messages to a reported host or realm
 then the reactor ignores that part of the overload report.  As such, =
there is no need to check the implicit data when receiving a self-contained=
 OLR.



Steve




On 12/11/13 12:25 PM, Maria Cruz Bartolome wrote:






Hello (and something else now 
J, fast key combination, I won’t be able to repeat,  was =
the responsible)


 


As mentioned before, something else on cons side =
for self-contained:


 


A part from that, =
; one concern with "self-contained OLRs" is that some data is dup=
licated. Duplication should be avoided, since then we need to assure consis=
tency, and error handing in case implicit and explicit
 data values are different for any reason... what means that it may always =
be required to check both implicit and explicit data.


 


Also, I think this is =
a pure implementation proposal. Regardless how the data is transported it c=
ould be packed in a "self-contained OLRs" within the diameter app=
lication, if for any implementation this is preferred.


 <=
/p>

Best regards<=
/o:p>


/MCruz<=
/p>

 <=
/p>





From: DiME [ma=
ilto:dime-bounces@ietf.org]
On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)

Sent: mi=E9rcoles, 11 de diciembre de 2013 19:02

To: dime@ietf.org

Subject: Re: [Dime] DOIC: Self-Contained OLRs






 


Hi Steve


 <=
/p>

I am sorry, Steve,  =
I do not see the difference between the Draft Roach scope approach and the =
self contained OLRs.


 <=
/p>

With the scope approach i=
n Draft Roach : there is an overload metric AVP  (eg containing a % of=
 traffic reduction) coupled with one or several Overlaod-Infoscope
 AVPs, an overlaod infoscope identifying an application or a destination ho=
st or… . These Overlaod-Infoscope AVPs can be combined  with als=
o  the possibility of  multi instances to have a list of applicat=
ions, a list of destination hosts etc  to which the overload
 metric would apply.


 <=
/p>

With self contained OLR a=
s you have described them, un OLR will also contain an OC-Reduction-Percent=
age
 AVP coupled with one or several oth=
ers AVPs (the self containment approach) to indicate which application(s), =
destinations host (s) etc the   OC-Reduction-Percentage
 AVP applies.



 <=
/p>

Where is the difference?<=
/span>


 <=
/p>

So the drawbacks identifi=
ed for the scope approach also apply with the self contained approach



 <=
/p>

Best regards<=
/o:p>


 <=
/p>

JJacques



 <=
/p>

 <=
/p>

 <=
/p>





De =
: DiME [mailto:dime-bounces@ietf.org]
De la part de Steve Donovan

Envoy=E9 : mercredi 11 d=E9cembre 2013 14:20

=C0 : dime@ietf.org

Objet : Re: [Dime] DOIC: Self-Contained OLRs<=
/p>





 


JJacques,



While the self contained overload report concept may be similar to the scop=
es concept in the Roach draft, they are not the same.  As such, I don'=
t agree with your assertion that the previous rejection of the Roach draft =
requires us to reject self contained
 overload reports as currently being discussed.



Steve




On 12/11/13 2:27 AM, TROTTIN, JEAN-JACQUES (JEAN-JAC=
QUES) wrote:






Hi Ben and all



 <=
/p>

I remind my mail of 05/12=
, where the self contained OLRs approach is quite similar to the self conta=
ined 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 i=
n draft Roach).  


This also result in a pig=
gybacking  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 ho=
p, the self contained  OLRs are opened to be reprocessed in order to r=
ecreate  new self contained OLR(s)  to various destinations.



I remind that, now 6 mont=
hs ago:


This is why I remain in f=
avor of the baseline  described in the current  draft, as as I ha=
ve always and regularly  expressed for  a while.


 <=
/p>

As also said, when news r=
equirements will appear (eg session group or APN examples)  the baseli=
ne is extensible to support these new requirements .  I prefer
 this way of progressive extensions , rather than to create a self containe=
d OLR  with an  immediate and not needed complexity   &=
nbsp;


 <=
/p>

Best regards<=
/o:p>


 <=
/p>

JJacques


 <=
/p>

 <=
/p>





De : DiME [mailto:d=
ime-bounces@ietf.org]
De la part de Shishufeng (Susan)

Envoy=E9 : mardi 10 d=E9cembre 2013 04:58

=C0 : Ben Campbell; dime@ietf.=
org list

Objet : Re: [Dime] DOIC: Self-Contained OLRs<=
/p>





 


Hi Ben,=



 <=
/p>

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



 <=
/p>

Quick thinking on the pro=
s you listed for self-contained OLR.


 <=
/p>


-       &nb=
sp; 
The first two pro=
s can be seen as optimization, on which we are still arguing if these optim=
ization are worth doing or not, since such optimization
 brings extra cost.



-       &nb=
sp; 
The third one is =
not a key issue, which could be addressed with several ways as discussed. A=
s a last resort, the overloaded server may send something
 in a request towards the client to inform the end of the overload.<=
o:p>



-       &nb=
sp; 
The last three pr=
os are mainly for the case of overload of agent, if I understood them corre=
ctly. 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.


 <=
/p>

Best Regards,=



Susan

 <=
/p>





From: Ben Camp=
bell [mailto:ben@nostrum.com]


Sent: Tuesday, December 10, 2013 7:53 AM

To: dime@ietf.org list

Subject: Re: [Dime] DOIC: Self-Contained OLRs






 




I am willing to call the discussion concluded for th=
e 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 conse=
nsus. 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 explai=
n 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 no=
t already weighed into this.






 






Self-Contained O=
LRS:






 






Pros:






    

  • 
Allows an easy, generic solution to Maria's "all-application" sco=
ped overload use case.
  • 
Allows an overloaded node to signal overload for multiple applications at o=
nce, instead of having to signal each one separately.
  • 
Allows an easy solution to our "loss" algorithm corner case of no=
t being able to signal the end of a 100% overload condition
    • =

  • 
Makes it easier to solve the agent overload problem, without requiring inco=
nsistent behavior.
  • 
Allows out-of-band transmission of OLRs without a new format
  • 
Makes it easier to do things like adding a dedicated application for overlo=
ad, 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 i=
n 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" s=
cope.
  • 
An overloaded node needs to send a separate report for every supported appl=
ication.
  • 
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.
  •  
    







 






 




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




OK. Lets call this thread concluded then. I keep the old OC-OLR  seman=
tics

regarding its information context then unmodified.



- Jouni


 


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime



 













_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime



 











_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime



 





--_000_A9CA33BB78081F478946E4F34BF9AAA014D31B94xmbrcdx10ciscoc_--

From maria.cruz.bartolome@ericsson.com  Thu Dec 12 08:38:27 2013
Return-Path: 
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 D4D9E1AE35D for ; Thu, 12 Dec 2013 08:38:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 lOWXB4eOddSK for ; Thu, 12 Dec 2013 08:38:25 -0800 (PST)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id EC80B1AE35B for ; Thu, 12 Dec 2013 08:38:24 -0800 (PST)
X-AuditID: c1b4fb38-b7f2c8e000006d25-e9-52a9e67adde6
Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 04.6A.27941.A76E9A25; Thu, 12 Dec 2013 17:38:18 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.197]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.02.0347.000; Thu, 12 Dec 2013 17:38:17 +0100
From: Maria Cruz Bartolome 
To: Jouni Korhonen 
Thread-Topic: [Dime] OVLI: OC-Validity-Duration
Thread-Index: Ac73DRNgVjMdaw2ATnC3EBEvo4YB4gAABXsAABLFinA=
Date: Thu, 12 Dec 2013 16:38:16 +0000
Message-ID: <087A34937E64E74E848732CFF8354B920973AF29@ESESSMB101.ericsson.se>
References: <087A34937E64E74E848732CFF8354B920973AB4B@ESESSMB101.ericsson.se> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.148]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUyM+JvrW7Vs5VBBrefC1vM7V3BZrF/XQOT A5PHzll32T2WLPnJFMAUxWWTkpqTWZZapG+XwJVx79FT9oINvBWnTro0MD7k6mLk5JAQMJE4 uukLK4QtJnHh3nq2LkYuDiGBI4wS7Q82MYEkhASWMEp0bkkDsdkE7CQunX4BFOfgEBHQlli+ QQwkzCygLDF7xwN2kLCwgJ7E7UP6IGERAX2JTRMusEBUW0ksWe4NEmYRUJV4uOES2HBeAV+J Pws/MENsbWCU+D3pIxtIglPAVqJzz12wIkag076fWsMEsUpc4taT+UwQJwtILNlznhnCFpV4 +fgf1CtKEo1LnrBC1OtILNj9iQ3C1pZYtvA1M8RiQYmTM5+wTGAUm4Vk7CwkLbOQtMxC0rKA kWUVI0dxanFSbrqRwSZGYHwc3PLbYgfj5b82hxilOViUxHk/vnUOEhJITyxJzU5NLUgtii8q zUktPsTIxMEp1cCYaaxZd8Aq5v13X8b1K6epHDb+u6xfZWpd+oL5zuI+sf71frJhNgd1pxt/ WBe9cH5lv7Prg6VvlZf33Di9a/nZfw/60z0W6d39wH9KVFMjMtszY9nLzzkx7XyqPjqC3hMP qMw6xVA88epSy0P5537/VPeo2ndOZ/MsGZNz5x9Mlb7NyL/JVDxXiaU4I9FQi7moOBEAt7Ur 6l0CAAA=
Cc: "dime@ietf.org" 
Subject: Re: [Dime] OVLI: OC-Validity-Duration
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Dec 2013 16:38:28 -0000

Jouni,

I think the best way to manage "something unpredictable" is not to provide =
an estimation (on an unpredictable event) from the server.
If you really think that scheduled cleanups are helpful, this could always =
be considered in the client, with a default value, that does not need to be=
 sent from the reporting node.

Regards
/MCrzu

-----Original Message-----
From: Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
Sent: jueves, 12 de diciembre de 2013 9:39
To: Maria Cruz Bartolome
Cc: dime@ietf.org
Subject: Re: [Dime] OVLI: OC-Validity-Duration

Hi,

I kind of like scheduled cleanups.. just to make sure there is no
stuff left hanging around when something unpredictable happens in
the network system.

Again, I would say this is a wrong place to "optimize".


- Jouni

On Dec 12, 2013, at 9:53 AM, Maria Cruz Bartolome  wrote:

> Dear all,
> =20
> I would like to reconsider the real need for the OC-Validity-Duration AVP=
 to be included into overload report.
> Overload mechanism is being design with a principle in mind: as soon as r=
eporting node determines a reacting node overload behavior should change, r=
eporting node sends a fresh overload report to this reacting node.
> Therefore, latest overload report received will be always applicable unti=
l a new report is received, and then I do not see the value, but just compl=
exity, of including a Duration in the report.
> =20
> Let me know your views.
> Best regards
> /MCruz
> =20
> =20
> =20
> =20
> =20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From amit5.arora@aricent.com  Thu Dec 12 21:25:09 2013
Return-Path: 
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 EF5551AE655 for ; Thu, 12 Dec 2013 21:25:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.003
X-Spam-Level: 
X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 NFzCZ30hSlFX for ; Thu, 12 Dec 2013 21:25:07 -0800 (PST)
Received: from jaguar.aricent.com (jaguar.aricent.com [180.151.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id 2B2B71AE657 for ; Thu, 12 Dec 2013 21:25:04 -0800 (PST)
Received: from jaguar.aricent.com (localhost [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id C011E36B61 for ; Fri, 13 Dec 2013 10:54:37 +0530 (IST)
Received: from GUREXHT02.ASIAN.AD.ARICENT.COM (gurexht02.asian.ad.aricent.com [10.203.171.138]) by jaguar.aricent.com (Postfix) with ESMTP id A9E8836B59 for ; Fri, 13 Dec 2013 10:54:37 +0530 (IST)
Received: from GUREXMB01.asian.ad.aricent.com ([10.203.171.132]) by GUREXHT02.ASIAN.AD.ARICENT.COM ([10.203.171.138]) with mapi; Fri, 13 Dec 2013 10:54:37 +0530
From: Amit Arora 
To: "DiME@ietf.org" 
Date: Fri, 13 Dec 2013 10:54:35 +0530
Thread-Topic: please unsubscribe  me 
Thread-Index: Ac73w5xKyT3Jn1izSiq2s+z+PBCPbA==
Message-ID: <5B83EDB274279747A5D70F7A9E7EC4364A31729FC4@GUREXMB01.ASIAN.AD.ARICENT.COM>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_5B83EDB274279747A5D70F7A9E7EC4364A31729FC4GUREXMB01ASIA_"
MIME-Version: 1.0
X-TM-AS-MML: No
Subject: [Dime] please unsubscribe  me
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Dec 2013 05:25:09 -0000

--_000_5B83EDB274279747A5D70F7A9E7EC4364A31729FC4GUREXMB01ASIA_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable






=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D
Please refer to http://www.aricent.com/legal/email_disclaimer.html
for important disclosures regarding this electronic communication.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D

--_000_5B83EDB274279747A5D70F7A9E7EC4364A31729FC4GUREXMB01ASIA_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











 











=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D

Please refer to http://www.aricent.com/legal/email_disclaimer.html

for important disclosures regarding this electronic communication.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D





--_000_5B83EDB274279747A5D70F7A9E7EC4364A31729FC4GUREXMB01ASIA_--


From ulrich.wiehe@nsn.com  Fri Dec 13 01:06:16 2013
Return-Path: 
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 3E4D51A1F3E for ; Fri, 13 Dec 2013 01:06:16 -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 A3FL3HCjgmJd for ; Fri, 13 Dec 2013 01:06:09 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id D546E1AD7C0 for ; Fri, 13 Dec 2013 01:06:06 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rBD95wiq014933 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 13 Dec 2013 10:05:58 +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 rBD95vNr017956 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 13 Dec 2013 10:05:58 +0100
Received: from DEMUHTC014.nsn-intra.net (10.159.42.45) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 13 Dec 2013 10:05:57 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.152]) by DEMUHTC014.nsn-intra.net ([10.159.42.45]) with mapi id 14.03.0123.003; Fri, 13 Dec 2013 10:05:57 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Steve Donovan , Jouni 
Thread-Topic: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3
Thread-Index: AQHO9e8qVWG779dz9k2pnHnmYU487ZpOiY/wgAABi4CAABHrIP//+MaAgABTK4CAAuoD4A==
Date: Fri, 13 Dec 2013 09:05:57 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519EA91@DEMUMBX014.nsn-intra.net>
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DB1B@DEMUMBX014.nsn-intra.net>  <52A5E902.20605@usdonovans.com> <7475B713-1104-4791-96B1-CE97632A0D69@nostrum.com>  <5BCBA1FC2B7F0B4C9D935572D90006681519E476@DEMUMBX014.nsn-intra.net> <1CD20507-B0FE-4367-804A-B831734CF060@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E6DC@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D90006681519E712@DEMUMBX014.nsn-intra.net> <4A151D70-0291-4238-85B1-03BB54B361E6@gmail.com> <52A864FF.10705@usdonovans.com>
In-Reply-To: <52A864FF.10705@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.107]
Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D90006681519EA91DEMUMBX014nsnin_"
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: 39531
X-purgate-ID: 151667::1386925558-00000661-1F273047/0-0/0-0
Cc: Ben Campbell , "dime@ietf.org list" 
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Dec 2013 09:06:16 -0000

--_000_5BCBA1FC2B7F0B4C9D935572D90006681519EA91DEMUMBX014nsnin_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Steve,

     I see a couple of options (others will probably see options I am missi=
ng):


another approach is to let the reacting node indicate Ongoing-Throttling-In=
formation in requests. Based on that agents will not return out of sync OLR=
s.
e.g. client C sends 1st realm type request which is routed via agent A1. A1=
 returns OLR requesting 10% reduction with sequence number s. C sends a 2nd=
 realm type request (which survived the 10% throttling and indicates so in =
the request) which is routed via agent A2. Since it is assumed that A2 woul=
d also require  a 10% reduction and A2 detects that C is already doing a 10=
% reduction, there is no need for A2 to return an OLR which potentially wou=
ld have an out-of-sync sequence number.
We could also allow the agents to accept a limited deviation in the percent=
age, i.e. if A2 would want a reduction of 9% it still could accept the 2nd =
request and not return an OLR.

Ulrich




From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Wednesday, December 11, 2013 2:14 PM
To: Jouni; Wiehe, Ulrich (NSN - DE/Munich)
Cc: Ben Campbell; dime@ietf.org list
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comment=
s to 4.3

Jouni,

We need the sequence number to be strictly increasing.  I don't see the nee=
d for it to increase in uniform amounts.  Using time does fit these require=
ments.  I'm ok with using time as long as we don't call the AVP timestamp.

Ulrich does bring up an interesting use case, where a client is receiving r=
ealm reports for the same realm from different agents.  We need to define t=
he clients behavior in this case.

Presumably the client needs to be able to determine who generated the realm=
 report.  This cannot be determine based on the content of the message or t=
he connection on which the message arrived.  It seems like we might need "R=
eport Generator Diameter ID" in the overload report specifically for Realm =
reports.

Once the client is able to differentiate between realm reports sent by diff=
erent agents (or servers) we need logic defining how the client deals with =
a new overload report.

I see a couple of options (others will probably see options I am missing):

- Use the last received realm report - This introduces the possibility of t=
hrashing between two different reduction values and different durations.  N=
ote that this approach does not require the source of the report to be incl=
uded in the report.

- Only listen to one source of realm overload - The approach would be to re=
member who sent the first overload report from the realm and ignore realm o=
verload reports from other sources.  This behavior would likely be constrai=
ned to a single occurrence of realm overload.  Meaning that the "memory" of=
 the report source would only last as long as that overload event persists.=
  Once the overload event goes away, the report source would be forgotten a=
nd a new source could be used for the next occurrence.

On the surface, the second approach looks better to me.

Steve
On 12/11/13 2:15 AM, Jouni wrote:

Ulrich,



I might be slow but.. Section 4.4 says



   control endpoints.  The sequence number is only required to be unique

   between two overload control endpoints and does not need to be



Unique between two endpoints..



Section 5.1 talks about endpoints:



   of an arbitrary Diameter network.  The overload control information

   is exchanged over on a "DOIC association" between two communication

   endpoints.  The endpoints, namely the "reacting node" and the

   "reporting node" do not need to be adjacent Diameter peer nodes, nor



So if your agents inject realm reports, they need to be endpoints to the

client. Similar to Figure 5. Therefore the sequence number spaces between

C-A1 and C-A2 are separate.



Now it is not clear to me, whether in your reasoning the C would see

the server identity (as the endpoint) when there is an active "DEP

agent" on the path. That would not clearly work and not be align with

the endpoint assumption.



Note that at some point of time we had (at least on a discussion level

in f2f meeting) report originator identity in the OLR. That would make

endpoint identification trivial. Now a "DEP agent" needs to act as a

"server" for its clients in order to appear as an endpoint.



- Jouni



ps: still think the use of Time is simpler..





On Dec 11, 2013, at 9:43 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:



That's not predictable. It may be the same server in some cases, and differ=
ent servers in other cases.



-----Original Message-----

From: ext Jouni [mailto:jouni.nospam@gmail.com]

Sent: Wednesday, December 11, 2013 8:38 AM

To: Wiehe, Ulrich (NSN - DE/Munich)

Cc: Ben Campbell; dime@ietf.org list; Steve Donovan

Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comment=
s to 4.3





Ulrich,



On Dec 11, 2013, at 9:21 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:



Jouni,



ad 1. "monotonically" does not express your intention. What we are looking =
for may be "stepwise with fixed step".



Ad 2. Is not necessarily a mistake that could result in out-of-sequence seq=
uence numbers. When a client C sends a realm-type requests towards any serv=
er in the realm, an agent A1 that selects the server would send back the re=
alm-type OLR with sequence number s1. The next realm-type request sent by C=
 (that survived the throttling) may take a path that does not include A1 bu=
t A2. A2 then selects the server and sends back a sequence number s2. Nothi=
ng ensures that s1 and s2 are in sequence.



Would the server in both cases (via A1 and A2) be the same?



- Jouni







Ulrich





-----Original Message-----

From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Sent: Tuesday, December 10, 2013 10:31 PM

To: Wiehe, Ulrich (NSN - DE/Munich)

Cc: Ben Campbell; dime@ietf.org list; Steve Donovan

Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comment=
s to 4.3



Ulrich,



On Dec 10, 2013, at 4:31 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:



Jouni,



1. I find the texts

a) "The sequence number ... does not need to be monotonically increasing"

and



Means the delta from old-seqno to new-seqno can be any non-negative integer

(within the given limits) not something fixed step/delta (like +1). As long=
 as

"new-seqno >=3D old-seqno" holds we are fine.



b) "...the new sequence number MUST be greater or equal than the old sequen=
ce number..."

contradicting.

Can you please clarify.



See above. (mind the overflow case)



2. The expected behaviour when receiving an out-of-sequence sequence number=
 within OC-OLR is described in 4.3:

"The receiver SHOULD discard an OC-OLR AVP with a sequence number that is l=
ess than previously received one."

I don't find this very robust. Once a higher sequence number (received erro=
neously by mistake) is accepted you cannot (easily) recover.



I find it more robust in a sense that I should not care about stale old inf=
ormation.

However, since we are piggybacking (by popular demand) we have little room =
for seqno

re-sync negotiation.



What is the mistake you refer here? A misbehaving implementation? In that c=
ase, it

deserves to get a manual intervention once figured out by admins checking a=
larms and

logs. If the mistake is due other things, like endpoints being out of sync,=
 we currently

have no written down mechanism to survive that.



3. The expected behaviour when receiving an out-of-sequence sequence number=
 within the OC-Supported-Features AVP is not described. What is the intenti=
on here?



No intention. Just a sloppy specification. You are right that something nee=
ds to be

done & clarified here. (again the semantics of Time would nice..)



I'll propose something. Others should too ;)



- Jouni





Ulrich



-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Jouni Korhonen

Sent: Tuesday, December 10, 2013 8:28 AM

To: Ben Campbell; dime@ietf.org list; Steve Donovan

Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comment=
s to 4.3





Fine.. lets define then the sequence number semantics. Basic

unsigned integer math. The text proposal is the following:



4.4.  OC-Sequence-Number AVP



The OC-Sequence-Number AVP (AVP code TBD3) is type of Unsigned64.

Its usage in the context of the overload control is described in

Sections 4.1 and 4.3.



>From the functionality point of view, the OC-Sequence-Number AVP

MUST be used as a non-volatile increasing counter between two

overload control endpoints.  The sequence number is only required

to be unique between two overload control endpoints and does not

need to be monotonically increasing.



When comparing two sequence numbers, the new sequence number MUST

be greater or equal than the old sequence number within a window

that is half of the size of the maximum sequence number. This

allows a simple handling of the sequence number overflow using

unsigned integer arithmeticf:



  #define WINDOW 0x8000000000000000ULL



  bool verify_seqnum( uint64_t newsn, uint64_t oldsn ) {

      if (newsn - oldsn <=3D WINDOW)

          // newsn >=3D oldsn

          return true;

      } else

          // outside window or newsn < oldsn

          return false;

      }

  }







The above should even work is someone shovels NTP times into

sequence numbers with a blind typecasting.



- Jouni



On Dec 10, 2013, at 12:34 AM, Ben Campbell  wrote:





On Dec 9, 2013, at 10:00 AM, Steve Donovan  wrote:



Jouni,



I propose that we keep the name OC-Sequence-Number but that we use the Time=
 type for OC-Sequence-Number.  It is misleading and potentially confusing t=
o call it OC-Time-Stamp.





I could live with that, although I would rather just define the expected pr=
operties of the sequence number, and leave the implementation up to the imp=
lementor. I assume your reasoning for not calling it a timestamp is that yo=
u do not want people to try to use it as a time base reference. If so, then=
 we don't require any connection to a clock. We just need it to be monotoni=
cally increasing.



We might consider expanding on the format of the AVP to make it something l=
ike Session-ID, where it is a concatenation of the Diameter-ID of the gener=
ating node and a timestamp.  This might help the reacting node keep track o=
f which sequence number it has received.





Do we need a uniqueness across multiple nodes property? If so, why?



Steve



On 12/9/13 5:37 AM, Jouni Korhonen wrote:

Folks



Could we conclude on the sequence number vs. time stamp vs. something else?

We got more important places to spend our energy than this ;)



My proposal is the following (based on the original pre-00 design):



o We change the OC-Sequence-Number to OC-Time-Stamp in all occurrences

in the -01.

o We use RFC6733 Time type for the OC-Time-Stamp. RFC6733 gives us

already exact definition how to handle the AVP.

o Define that the OC-Time-Stamp is the time of the creation of the

"original" AVP within whose context the time stamp is present.

o The OC-Time-Stamp AVP uniqueness is still considered to be in scope

of the communicating endpoints.

o The time stamp can be used to quickly determine if the content of

the encapsulating AVP context has changed (among other properties).

This would be useful specifically in the future when the encapsulating

grouped AVPs  grow in size and functionality.





- Jouni



_______________________________________________

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










--_000_5BCBA1FC2B7F0B4C9D935572D90006681519EA91DEMUMBX014nsnin_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Steve,<=
/p>

 <=
/p>

     I see =
a couple of options (others will probably see options I am missing):






 =
;


another ap=
proach is to let the reacting node indicate Ongoing-Throttling-Information =
in requests. Based on that agents will not return out of sync
 OLRs.


e.g. clien=
t C sends 1st realm type request which is routed via agent A1. A=
1 returns OLR requesting 10% reduction with sequence number
 s. C sends a 2nd realm type request (which survived the 10% thr=
ottling and indicates so in the request) which is routed via agent A2. Sinc=
e it is assumed that A2 would also require  a 10% reduction and A2 det=
ects that C is already doing a 10% reduction,
 there is no need for A2 to return an OLR which potentially would have an o=
ut-of-sync sequence number.


We could a=
lso allow the agents to accept a limited deviation in the percentage, i.e. =
if A2 would want a reduction of 9% it still could accept the
 2nd request and not return an OLR.


 =
;


Ulrich


 =
;


 =
;


 =
;


 =
;






From:=
 ext Steve Donovan [=
mailto:srdonovan@usdonovans.com]


Sent: Wednesday, December 11, 2013 2:14 PM

To: Jouni; Wiehe, Ulrich (NSN - DE/Munich)

Cc: Ben Campbell; dime@ietf.org list

Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: =
comments to 4.3






 


Jouni,



We need the sequence number to be strictly increasing.  I don't see th=
e need for it to increase in uniform amounts.  Using time does fit the=
se requirements.  I'm ok with using time as long as we don't call the =
AVP timestamp.



Ulrich does bring up an interesting use case, where a client is receiving r=
ealm reports for the same realm from different agents.  We need to def=
ine the clients behavior in this case. 




Presumably the client needs to be able to determine who generated the realm=
 report.  This cannot be determine based on the content of the message=
 or the connection on which the message arrived.  It seems like we mig=
ht need "Report Generator Diameter ID" in
 the overload report specifically for Realm reports.  



Once the client is able to differentiate between realm reports sent by diff=
erent agents (or servers) we need logic defining how the client deals with =
a new overload report. 




I see a couple of options (others will probably see options I am missing):<=
br>


- Use the last received realm report - This introduces the possibility of t=
hrashing between two different reduction values and different durations.&nb=
sp; Note that this approach does not require the source of the report to be=
 included in the report.



- Only listen to one source of realm overload - The approach would be to re=
member who sent the first overload report from the realm and ignore realm o=
verload reports from other sources.  This behavior would likely be con=
strained to a single occurrence of realm
 overload.  Meaning that the "memory" of the report source w=
ould only last as long as that overload event persists.  Once the over=
load event goes away, the report source would be forgotten and a new source=
 could be used for the next occurrence.



On the surface, the second approach looks better to me.



Steve




On 12/11/13 2:15 AM, Jouni wrote:






Ulrich,


 


I might be slow but.. Section 4.4 says


 


   control endpoints.  The sequence number is only requ=
ired to be unique


   between two overload control endpoints and does not need =
to be


 


Unique between two endpoints..


 


Section 5.1 talks about endpoints:


 


   of an arbitrary Diameter network.  The overload cont=
rol information


   is exchanged over on a "DOIC association" betwe=
en two communication


   endpoints.  The endpoints, namely the "reacting=
 node" and the


   "reporting node" do not need to be adjacent Dia=
meter peer nodes, nor


 


So if your agents inject realm reports, they need to be endpoints to t=
he


client. Similar to Figure 5. Therefore the sequence number spaces betw=
een


C-A1 and C-A2 are separate.


 


Now it is not clear to me, whether in your reasoning the C would see


the server identity (as the endpoint) when there is an active "DE=
P


agent" on the path. That would not clearly work and not be align =
with


the endpoint assumption.


 


Note that at some point of time we had (at least on a discussion level=



in f2f meeting) report originator identity in the OLR. That would make=



endpoint identification trivial. Now a "DEP agent" needs to =
act as a 


"server" for its clients in order to appear as an endpoint.<=
o:p>


 


- Jouni


 


ps: still think the use of Time is simpler..


 


 


On Dec 11, 2013, at 9:43 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:


 




That's not predictable. It may be the same server in some cases, and d=
ifferent servers in other cases.


 


-----Original Message-----


From: ext Jouni [mailto:joun=
i.nospam@gmail.com] 


Sent: Wednesday, December 11, 2013 8:38 AM


To: Wiehe, Ulrich (NSN - DE/Munich)


Cc: Ben Campbell; dime@ietf.org l=
ist; Steve Donovan


Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: co=
mments to 4.3


 


 


Ulrich,


 


On Dec 11, 2013, at 9:21 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:


 




Jouni,


 


ad 1. "monotonically" does not express your intention. What =
we are looking for may be "stepwise with fixed step".<=
/pre>

 


Ad 2. Is not necessarily a mistake that could result in out-of-sequenc=
e sequence numbers. When a client C sends a realm-type requests towards any=
 server in the realm, an agent A1 that selects the server would send back t=
he realm-type OLR with sequence number s1. The next realm-type request sent=
 by C (that survived the throttling) may take a path that does not include =
A1 but A2. A2 then selects the server and sends back a sequence number s2. =
Nothing ensures that s1 and s2 are in sequence.




 


Would the server in both cases (via A1 and A2) be the same?=



 


- Jouni


 


 




 


Ulrich


 


 


-----Original Message-----


From: ext Jouni Korhonen [ma=
ilto:jouni.nospam@gmail.com] 


Sent: Tuesday, December 10, 2013 10:31 PM


To: Wiehe, Ulrich (NSN - DE/Munich)


Cc: Ben Campbell; dime@ietf.org l=
ist; Steve Donovan


Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: co=
mments to 4.3


 


Ulrich,


 


On Dec 10, 2013, at 4:31 PM, "Wiehe, Ulrich (NSN - DE/Munich)&quo=
t; <ulrich.wiehe@nsn.com>=
 wrote:


 




Jouni,


 


1. I find the texts


a) "The sequence number ... does not need to be monotonically inc=
reasing"


and 




 


Means the delta from old-seqno to new-seqno can be any non-negative in=
teger


(within the given limits) not something fixed step/delta (like +1)=
. As long as


"new-seqno >=3D old-seqno" holds we are fine.<=
/pre>

 




b) "...the new sequence number MUST be greater or equal than the =
old sequence number..."


contradicting.


Can you please clarify.




 


See above. (mind the overflow case)


 




2. The expected behaviour when receiving an out-of-sequence sequence n=
umber within OC-OLR is described in 4.3:


"The receiver SHOULD discard an OC-OLR AVP with a sequence number=
 that is less than previously received one."


I don't find this very robust. Once a higher sequence number (received=
 erroneously by mistake) is accepted you cannot (easily) recover.




 


I find it more robust in a sense that I should not care about stale ol=
d information.


However, since we are piggybacking (by popular demand) we have little =
room for seqno


re-sync negotiation.


 


What is the mistake you refer here? A misbehaving implementation? In t=
hat case, it 


deserves to get a manual intervention once figured out by admins check=
ing alarms and


logs. If the mistake is due other things, like endpoints being out of =
sync, we currently


have no written down mechanism to survive that.


 




3. The expected behaviour when receiving an out-of-sequence sequence n=
umber within the OC-Supported-Features AVP is not described. What is the in=
tention here?




 


No intention. Just a sloppy specification. You are right that somethin=
g needs to be


done & clarified here. (again the semantics of Time would nice..)<=
o:p>


 


I'll propose something. Others should too ;)


 


- Jouni


 




 


Ulrich


 


-----Original Message-----


From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of ext Jouni Korhonen


Sent: Tuesday, December 10, 2013 8:28 AM


To: Ben Campbell; dime@ietf.org l=
ist; Steve Donovan


Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: co=
mments to 4.3


 


 


Fine.. lets define then the sequence number semantics. Basic


unsigned integer math. The text proposal is the following:<=
/pre>

 


4.4.  OC-Sequence-Number AVP


 


The OC-Sequence-Number AVP (AVP code TBD3) is type of Unsigned64.=



Its usage in the context of the overload control is described in<=
/o:p>


Sections 4.1 and 4.3.


 


From the functionality point of view, the OC-Sequence-Number AVP<=
/o:p>


MUST be used as a non-volatile increasing counter between two


overload control endpoints.  The sequence number is only required=



to be unique between two overload control endpoints and does not<=
/o:p>


need to be monotonically increasing.


 


When comparing two sequence numbers, the new sequence number MUST=



be greater or equal than the old sequence number within a window<=
/o:p>


that is half of the size of the maximum sequence number. This


allows a simple handling of the sequence number overflow using


unsigned integer arithmeticf:


 


  #define WINDOW 0x8000000000000000ULL


 


  bool verify_seqnum( uint64_t newsn, uint64_t oldsn ) {


      if (newsn - oldsn <=3D WINDOW)<=
/o:p>


          // newsn >=
=3D oldsn


          return true;&nb=
sp;  


      } else


          // outside wind=
ow or newsn < oldsn


          return false;&n=
bsp; 


      }


  }


 


 


 


The above should even work is someone shovels NTP times into


sequence numbers with a blind typecasting.


 


- Jouni


 


On Dec 10, 2013, at 12:34 AM, Ben Campbell <ben@nostrum.com> wrote:


 




 


On Dec 9, 2013, at 10:00 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:

 




Jouni,


 


I propose that we keep the name OC-Sequence-Number but that we use the=
 Time type for OC-Sequence-Number.  It is misleading and potentially c=
onfusing to call it OC-Time-Stamp.  


 




 


I could live with that, although I would rather just define the expect=
ed properties of the sequence number, and leave the implementation up to th=
e implementor. I assume your reasoning for not calling it a timestamp is th=
at you do not want people to try to use it as a time base reference. If so,=
 then we don't require any connection to a clock. We just need it to be mon=
otonically increasing.


 




We might consider expanding on the format of the AVP to make it someth=
ing like Session-ID, where it is a concatenation of the Diameter-ID of the =
generating node and a timestamp.  This might help the reacting node ke=
ep track of which sequence number it has received.


 




 


Do we need a uniqueness across multiple nodes property? If so, why?


 




Steve


 


On 12/9/13 5:37 AM, Jouni Korhonen wrote:




Folks


 


Could we conclude on the sequence number vs. time stamp vs. something =
else?


We got more important places to spend our energy than this ;)


 


My proposal is the following (based on the original pre-00 design):


 


o We change the OC-Sequence-Number to OC-Time-Stamp in all occurrences=



in the -01.


o We use RFC6733 Time type for the OC-Time-Stamp. RFC6733 gives us


already exact definition how to handle the AVP.


o Define that the OC-Time-Stamp is the time of the creation of the 


"original" AVP within whose context the time stamp is presen=
t.


o The OC-Time-Stamp AVP uniqueness is still considered to be in scope<=
o:p>


of the communicating endpoints.


o The time stamp can be used to quickly determine if the content of


the encapsulating AVP context has changed (among other properties).


This would be useful specifically in the future when the encapsulating=



grouped AVPs  grow in size and functionality.


 


 


- Jouni


 


_______________________________________________


DiME mailing list


 


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 


 


 




 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime




 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime




 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime




 




 




 


 




 






--_000_5BCBA1FC2B7F0B4C9D935572D90006681519EA91DEMUMBX014nsnin_--


From maria.cruz.bartolome@ericsson.com  Fri Dec 13 01:28:23 2013
Return-Path: 
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 8DE1A1AE01F for ; Fri, 13 Dec 2013 01:28:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.24
X-Spam-Level: 
X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no
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 psCFElcmfLM3 for ; Fri, 13 Dec 2013 01:28:20 -0800 (PST)
Received: from sesbmg21.mgmt.ericsson.se (sesbmg21.ericsson.net [193.180.251.49]) by ietfa.amsl.com (Postfix) with ESMTP id BB1521A802A for ; Fri, 13 Dec 2013 01:28:19 -0800 (PST)
X-AuditID: c1b4fb31-b7fa78e0000005dd-bf-52aad32c1f12
Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg21.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 57.7E.01501.C23DAA25; Fri, 13 Dec 2013 10:28:12 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.197]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.02.0347.000; Fri, 13 Dec 2013 10:28:09 +0100
From: Maria Cruz Bartolome 
To: "dime@ietf.org" 
Thread-Topic: [Dime] OVLI: comments to 4.6
Thread-Index: Ac7yfC5RbFsL+gV9TT6AJTwE2XmtwwANV4kAAAOr9wAAG9aeQAB3FIIAAAup3DD//0H8gP/58ajA
Date: Fri, 13 Dec 2013 09:28:08 +0000
Message-ID: <087A34937E64E74E848732CFF8354B920973B124@ESESSMB101.ericsson.se>
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DCBC@DEMUMBX014.nsn-intra.net> <6950EE6B-689E-47A1-88AA-1A67C47BC82E@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519DD4D@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D90006681519E00D@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D90006681519E086@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681519E086@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.148]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrOLMWRmVeSWpSXmKPExsUyM+Jvra7O5VVBBpOXaFnM7V3B5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujL37lrIXrImv2HCyk62BcY1vFyMnh4SAicSJ+ecZIWwxiQv3 1rOB2EICJxglPh6z6GLkArKXMEr8/naFHSTBJmAncen0C6YuRg4OEQFlidO/HEDCwgKaEi8f HWIFsUUEtCRuzv7DClESJXHjjiJImEVAVaL74k0mEJtXwFfi+qvjbBDjbzFL7Ju+C6yXUyBA 4vL17WBFjED3fD+1BsxmFhCXuPVkPhPEnQISS/acZ4awRSVePv7HCmErSTQuecIKUa8jsWD3 JzYIW1ti2cLXzBCLBSVOznzCMoFRdBaSsbOQtMxC0jILScsCRpZVjJLFqcVJuelGhnq56bkl eqlFmcnFxfl5esWpmxiBkXFwy2/DHYwTr9kfYpTmYFES52WY3hkkJJCeWJKanZpakFoUX1Sa k1p8iJGJg1OqgXFKibXZHn/b6GkuUZft9qtGLf7IrKJr9+7r77PBqanV3+bFH75YPuX3q45/ CybfKjuXx9hXoyci/MSNbYmj/7yjfxtr3AWWf/9g9LLlcwfLjaTniW3vCl9tc+P5Kuxz++LN r3/2mPTf3Lz0jkLbfXeHJWscwlWPhH+yf//XJuzHVD3/lEUvuQKUWIozEg21mIuKEwHOVRWF WgIAAA==
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Dec 2013 09:28:23 -0000

Hello Ulrich, all,

I agree with Nirav, I think in the base IETF draft we need to keep what is =
required for the use cases identified so far, (as long as ReportType is ext=
ensible).

Therefore I think that DESTINATION_HOST_MATCH and DESTINATION_REALM_MATCH a=
re enough in the draft.

Going a bit more in detail into your mail, I will comment on why rest of va=
lues are not required:=20

>   APPLICATION_ID_MATCH (0x0000000000000001)
Agreement for the baseline is to infer this always from the Diameter encaps=
ulating message. Therefore, this is always done, no reason to add a ReportT=
ype for this.
>=20
>   DESTINATION_HOST_PRESENT (0x0000000000000002)
What we need to know if whether overload-report shall apply for either HOST=
_MATCH or REALM_MATCH.=20
This value is included into HOST_MATCH, then I do not see a reason to have =
it as an independent value.

>   DESTINATION_HOST_MATCH (0x0000000000000004)
Fine, I think this is required

>   DESTINATION_HOST_ABSENT (0x0000000000000008)
This value is included into REALM_MATCH. Any reason to have it as an indepe=
ndent value?=20

>   DESTINATION_REALM_MATCH (0x0000000000000010)
Fine, I think this is required

About decision on whether it should be Unsigned or Enumerated, not sure whi=
ch one could be best, I then to agree with Jouni that both could be valid a=
s long as we need to define new values on application documentation, explai=
ning expected behavior.

Best regards
/MCruz

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN -=
 DE/Munich)
Sent: lunes, 09 de diciembre de 2013 14:38
To: ext Nirav Salot (nsalot); ext Jouni
Cc: dime@ietf.org
Subject: Re: [Dime] OVLI: comments to 4.6

Hi Nirav,

in the end its a matter of taste, and I definitly prefer the Unsigned64 app=
roach.

Please note: The Enumerated approach also has a value (0 Reserved) without =
use case. And there is confusing text e.g. "...should apply to requests tha=
t the reacting node knows will reach the overloaded node."=20
How would the reacting node know that a request will actually reach the ove=
rloaded node? And even if it knows this, wouldn't the overload treatment ap=
ply only to those requests that match the application-id from the answer?

Best regards
Ulrich


-----Original Message-----
From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com]=20
Sent: Monday, December 09, 2013 1:56 PM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Jouni
Cc: dime@ietf.org
Subject: RE: [Dime] OVLI: comments to 4.6

Ulrich,

Defining a bit "APPLICATION_ID_MATCH" and not having a use case when this b=
it is set to "0" (at least in the context of the current draft) is confusin=
g to me. Same is the case with some other bits you have proposed.

In summary, I do not see any issue with the current ReportType.=20
For the extensibility, we have to deal with it anyway when we have correspo=
nding use case in 3GPP or in IETF. In my view, defining the ReportType with=
 some assumption of its extensibility is confusing since those use cases ar=
e not discussed here yet.

Regards,
Nirav.

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20
Sent: Monday, December 09, 2013 5:55 PM
To: Nirav Salot (nsalot); ext Jouni
Cc: dime@ietf.org
Subject: RE: [Dime] OVLI: comments to 4.6

Hi Nirav,
can you please point out what actually is confusing. I would have thougth t=
hat my proposal is more clear and precise as it exactly identifies when a g=
iven request matches the OLR (i.e. must undergo the throttling).

With regard to complexity there is no difference between checking the two a=
llowed enumeration values 1 and 2 (current version) or the two allowed Unsi=
gned64 values (0x0000000000000007) and (0x0000000000000019) (my proposal).

The main benefit I see with my proposal is the extensibility e.g.
One new value of   ORIGIN_HOST_MATCH (0x0000000000000020) for Overload Miti=
gation Differentiation per client rather than
Two new values of "host report with origin-host match" and realm-report wit=
h origin-host match".

Best regards
Ulrich



-----Original Message-----
From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com]=20
Sent: Saturday, December 07, 2013 10:44 AM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Jouni
Cc: dime@ietf.org
Subject: RE: [Dime] OVLI: comments to 4.6

Hi Ulrich,

Instead of re-packing, I see your proposal as confusing or adding more impl=
ementation complexity to the exiting simple proposal of having just two Rep=
ort-Type.
e.g. with your proposal, now the nodes have to validate if the combination =
of Report-Type flag is correct/allowed or not and perform the error handlin=
g if there is any discrepancy.=20

Besides, I do not see the need for some obvious Report-Type e.g. "APPLICATI=
ON_ID_MATCH" since it is always present and/or implicit.
Same is the case with "DESTINATION_HOST_PRESENT" and "DESTINATION_HOST_MATC=
H". What is the use case for destination-host present but not match? In oth=
er words, the reacting node should use this type of report towards which no=
de/realm?

I guess this time you need to convince me (at least) as why you think so ma=
ny different Report-Types are needed and what is the issue with existing de=
finition of Report-Type.

Regards,
Nirav.

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN -=
 DE/Munich)
Sent: Friday, December 06, 2013 7:48 PM
To: ext Jouni
Cc: dime@ietf.org
Subject: Re: [Dime] OVLI: comments to 4.6

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.

Best regards
Ulrich

-----Original Message-----
From: ext Jouni [mailto:jouni.nospam@gmail.com]=20
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,
> =20
> here are comments to clause 4.6:
> =20
> 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 pr=
oblems. =20

I do not see how changing the type to unsigned would help with the extensib=
ility 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 semantic=
s to
something like what we have on OC-Feature AVP. How the receiver of the repo=
rt 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 receiv=
er has
no other choice than drop the OLR, since it cannot be sure how to handle th=
e 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 ma=
ps
   to a report type (that has been defined after the publication of this=20
   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 le=
t the reacting node know to which (future) request commands the overload tr=
eatment should apply:
>=20
> 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=20
> c) The request command's Destination-Host matches the Origin-Host of the =
OC-Report-Type AVP's encapsulating answer command
>=20
> For a realm report-type the overload treatment should apply to all reques=
t commands for which
> a)  and
> d) The request command's Destination-Host is absent and=20
> e) The request command's Destination Realm matches the Origin-Realm of th=
e OC-Report-Type AVP's encapsulating answer command.
>=20
> The proposal now is to assign individual bits of the Unsinged64 type to a=
), b), c), d), and e):
>=20
> Proposed text:
>   4.6 OC-Report-Type AVP
>=20
>   The OC-Report-Type AVP (AVP code TBD5) is type of Unsigned64 and contai=
ns a 64 bit flags field of a request
>   command's characteristics.
>=20
>   The following characteristics are defined in this document:
>=20
>   APPLICATION_ID_MATCH (0x0000000000000001)
>=20
>   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 Appli=
cation-Id of the OC-Report-Type AVP's
>   encapsulating answer command.
>=20
>   DESTINATION_HOST_PRESENT (0x0000000000000002)
>=20
>   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.
>=20
>   DESTINATION_HOST_MATCH (0x0000000000000004)
>=20
>   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.
>=20
>   DESTINATION_HOST_ABSENT (0x0000000000000008)
>=20
>   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.
>=20
>   DESTINATION_REALM_MATCH (0x0000000000000010)
>=20
>   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.
>=20
>   Combinations other than=20
>   1) APPLICATION_ID_MATCH and DESTINATION_HOST_PRESENT and DESTINATION_HO=
ST_MATCH
>   and
>   2) APPLICATION_ID_MATCH and DESTINATION_HOST_ABSENT and DESTINATION_REA=
LM_MATCH
>   require a mutually agreed extension.
>=20
>=20
>=20
>=20
> One extension required by 3GPP applications is the Overload Mitigation Di=
fferentiation per client (see 3GPP TR 29.809 clause 6.4.7. To address this,=
 a new value would be needed e.g.
>=20
>   ORIGIN_HOST_MATCH (0x0000000000000020)
>=20
>   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 Dest=
ination-Host of the OC-Report-Type AVP's
>   encapsulating answer command.
>=20
> With this extension the following additional combinations would be allowe=
d:
> 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
>=20
> Another potential extension is Diameter Agent Overload. To address this, =
a new value would be needed e.g.
>=20
>   NEXT_HOP_MATCH (0x0000000000000040)
>=20
>   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.
>=20
>=20
> Best regards
> Ulrich
>=20
>=20
> _______________________________________________
> 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

From jouni.nospam@gmail.com  Fri Dec 13 02:54:08 2013
Return-Path: 
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 4DD691AE11A for ; Fri, 13 Dec 2013 02:54:08 -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 JPBm4nrxqMEp for ; Fri, 13 Dec 2013 02:54:04 -0800 (PST)
Received: from mail-bk0-x233.google.com (mail-bk0-x233.google.com [IPv6:2a00:1450:4008:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id F32561AE118 for ; Fri, 13 Dec 2013 02:54:03 -0800 (PST)
Received: by mail-bk0-f51.google.com with SMTP id 6so1316057bkj.38 for ; Fri, 13 Dec 2013 02:53:57 -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=e7x42zN2t20vULGmJJH1hrwHEqcUejR5Ry42gfDqqKU=; b=OQkaPDKJ2Hc4Gys/XXsXiTep99bpQA9T8qcTqC6x0Hq1nRc/IIfWuXKq9iEB35UUFD oA+cJADkKq4e8jx+s/7eDHLd1r4/ZcqBcdfYfPAmW52Sjf+XvgGWI5pKSI+PlOovVBS5 TqOVH9D33fPIglowQBBwYe7BAhEt/MA8s1U5a5bqUGqMu25znqdKqu6m6wZVe5oEpZFI uzL/vUjV5tHTRrGdZ8qEdeFOBmMilYA9tEuoZNkD4svoVDqjBdJn784dLTSCrErlPHR2 BNXsbv3hW/PJ6KX7Hi3cotvBBCHkt4+bidoAnWtBoLKuzNDn3n1XUOW/cEUQz1c8eZAr 9kvg==
X-Received: by 10.205.5.194 with SMTP id oh2mr32898bkb.114.1386932037052; Fri, 13 Dec 2013 02:53:57 -0800 (PST)
Received: from ?IPv6:2001:6e8:480:60:a0e8:8f75:1f5a:7e15? ([2001:6e8:480:60:a0e8:8f75:1f5a:7e15]) by mx.google.com with ESMTPSA id a4sm1668261bko.11.2013.12.13.02.53.52 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 13 Dec 2013 02:53:53 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jouni Korhonen 
In-Reply-To: <087A34937E64E74E848732CFF8354B920973B124@ESESSMB101.ericsson.se>
Date: Fri, 13 Dec 2013 12:53:54 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <56726CC6-823B-4F4E-B898-2034D1EE8A85@gmail.com>
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DCBC@DEMUMBX014.nsn-intra.net> <6950EE6B-689E-47A1-88AA-1A67C47BC82E@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519DD4D@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D90006681519E00D@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D90006681519E086@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B920973B124@ESESSMB101.ericsson.se>
To: Maria Cruz Bartolome 
X-Mailer: Apple Mail (2.1510)
Cc: "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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Dec 2013 10:54:08 -0000

On Dec 13, 2013, at 11:28 AM, Maria Cruz Bartolome =
 wrote:

> Hello Ulrich, all,
>=20
> I agree with Nirav, I think in the base IETF draft we need to keep =
what is required for the use cases identified so far, (as long as =
ReportType is extensible).
>=20
> Therefore I think that DESTINATION_HOST_MATCH and =
DESTINATION_REALM_MATCH are enough in the draft.

Ok.



> Going a bit more in detail into your mail, I will comment on why rest =
of values are not required:=20
>=20
>>  APPLICATION_ID_MATCH (0x0000000000000001)
> Agreement for the baseline is to infer this always from the Diameter =
encapsulating message. Therefore, this is always done, no reason to add =
a ReportType for this.
>>=20
>>  DESTINATION_HOST_PRESENT (0x0000000000000002)
> What we need to know if whether overload-report shall apply for either =
HOST_MATCH or REALM_MATCH.=20
> This value is included into HOST_MATCH, then I do not see a reason to =
have it as an independent value.
>=20
>>  DESTINATION_HOST_MATCH (0x0000000000000004)
> Fine, I think this is required
>=20
>>  DESTINATION_HOST_ABSENT (0x0000000000000008)
> This value is included into REALM_MATCH. Any reason to have it as an =
independent value?=20
>=20
>>  DESTINATION_REALM_MATCH (0x0000000000000010)
> Fine, I think this is required
>=20
> About decision on whether it should be Unsigned or Enumerated, not =
sure which one could be best, I then to agree with Jouni that both could =
be valid as long as we need to define new values on application =
documentation, explaining expected behavior.

Ok. My preference is still enumerated, mainly because it prevents
designing do_everything_and_a_bit_more OLRs. A report type and a=20
matching OLR for a single purpose.

- Jouni


>=20
> Best regards
> /MCruz
>=20
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich =
(NSN - DE/Munich)
> Sent: lunes, 09 de diciembre de 2013 14:38
> To: ext Nirav Salot (nsalot); ext Jouni
> Cc: dime@ietf.org
> Subject: Re: [Dime] OVLI: comments to 4.6
>=20
> Hi Nirav,
>=20
> in the end its a matter of taste, and I definitly prefer the =
Unsigned64 approach.
>=20
> Please note: The Enumerated approach also has a value (0 Reserved) =
without use case. And there is confusing text e.g. "...should apply to =
requests that the reacting node knows will reach the overloaded node."=20=

> How would the reacting node know that a request will actually reach =
the overloaded node? And even if it knows this, wouldn't the overload =
treatment apply only to those requests that match the application-id =
from the answer?
>=20
> Best regards
> Ulrich
>=20
>=20
> -----Original Message-----
> From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com]=20
> Sent: Monday, December 09, 2013 1:56 PM
> To: Wiehe, Ulrich (NSN - DE/Munich); ext Jouni
> Cc: dime@ietf.org
> Subject: RE: [Dime] OVLI: comments to 4.6
>=20
> Ulrich,
>=20
> Defining a bit "APPLICATION_ID_MATCH" and not having a use case when =
this bit is set to "0" (at least in the context of the current draft) is =
confusing to me. Same is the case with some other bits you have =
proposed.
>=20
> In summary, I do not see any issue with the current ReportType.=20
> For the extensibility, we have to deal with it anyway when we have =
corresponding use case in 3GPP or in IETF. In my view, defining the =
ReportType with some assumption of its extensibility is confusing since =
those use cases are not discussed here yet.
>=20
> Regards,
> Nirav.
>=20
> -----Original Message-----
> From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20
> Sent: Monday, December 09, 2013 5:55 PM
> To: Nirav Salot (nsalot); ext Jouni
> Cc: dime@ietf.org
> Subject: RE: [Dime] OVLI: comments to 4.6
>=20
> Hi Nirav,
> can you please point out what actually is confusing. I would have =
thougth that my proposal is more clear and precise as it exactly =
identifies when a given request matches the OLR (i.e. must undergo the =
throttling).
>=20
> With regard to complexity there is no difference between checking the =
two allowed enumeration values 1 and 2 (current version) or the two =
allowed Unsigned64 values (0x0000000000000007) and (0x0000000000000019) =
(my proposal).
>=20
> The main benefit I see with my proposal is the extensibility e.g.
> One new value of   ORIGIN_HOST_MATCH (0x0000000000000020) for Overload =
Mitigation Differentiation per client rather than
> Two new values of "host report with origin-host match" and =
realm-report with origin-host match".
>=20
> Best regards
> Ulrich
>=20
>=20
>=20
> -----Original Message-----
> From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com]=20
> Sent: Saturday, December 07, 2013 10:44 AM
> To: Wiehe, Ulrich (NSN - DE/Munich); ext Jouni
> Cc: dime@ietf.org
> Subject: RE: [Dime] OVLI: comments to 4.6
>=20
> Hi Ulrich,
>=20
> Instead of re-packing, I see your proposal as confusing or adding more =
implementation complexity to the exiting simple proposal of having just =
two Report-Type.
> e.g. with your proposal, now the nodes have to validate if the =
combination of Report-Type flag is correct/allowed or not and perform =
the error handling if there is any discrepancy.=20
>=20
> Besides, I do not see the need for some obvious Report-Type e.g. =
"APPLICATION_ID_MATCH" since it is always present and/or implicit.
> Same is the case with "DESTINATION_HOST_PRESENT" and =
"DESTINATION_HOST_MATCH". What is the use case for destination-host =
present but not match? In other words, the reacting node should use this =
type of report towards which node/realm?
>=20
> I guess this time you need to convince me (at least) as why you think =
so many different Report-Types are needed and what is the issue with =
existing definition of Report-Type.
>=20
> Regards,
> Nirav.
>=20
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich =
(NSN - DE/Munich)
> Sent: Friday, December 06, 2013 7:48 PM
> To: ext Jouni
> Cc: dime@ietf.org
> Subject: Re: [Dime] OVLI: comments to 4.6
>=20
> Hi Jouni,
>=20
> 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.
>=20
> Best regards
> Ulrich
>=20
> -----Original Message-----
> From: ext Jouni [mailto:jouni.nospam@gmail.com]=20
> 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
>=20
>=20
> On Dec 6, 2013, at 2:10 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>=20
>> Dear all,
>>=20
>> here are comments to clause 4.6:
>>=20
>> 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. =20
>=20
> 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.
>=20
> 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=20
>   spec)
>=20
> Other than those, IMHO, are just repackaging the issue into different =
form.
>=20
>=20
> - Jouni
>=20
>> 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:
>>=20
>> 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=20
>> c) The request command's Destination-Host matches the Origin-Host of =
the OC-Report-Type AVP's encapsulating answer command
>>=20
>> For a realm report-type the overload treatment should apply to all =
request commands for which
>> a)  and
>> d) The request command's Destination-Host is absent and=20
>> e) The request command's Destination Realm matches the Origin-Realm =
of the OC-Report-Type AVP's encapsulating answer command.
>>=20
>> The proposal now is to assign individual bits of the Unsinged64 type =
to a), b), c), d), and e):
>>=20
>> Proposed text:
>>  4.6 OC-Report-Type AVP
>>=20
>>  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.
>>=20
>>  The following characteristics are defined in this document:
>>=20
>>  APPLICATION_ID_MATCH (0x0000000000000001)
>>=20
>>  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.
>>=20
>>  DESTINATION_HOST_PRESENT (0x0000000000000002)
>>=20
>>  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.
>>=20
>>  DESTINATION_HOST_MATCH (0x0000000000000004)
>>=20
>>  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.
>>=20
>>  DESTINATION_HOST_ABSENT (0x0000000000000008)
>>=20
>>  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.
>>=20
>>  DESTINATION_REALM_MATCH (0x0000000000000010)
>>=20
>>  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.
>>=20
>>  Combinations other than=20
>>  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.
>>=20
>>=20
>>=20
>>=20
>> 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.
>>=20
>>  ORIGIN_HOST_MATCH (0x0000000000000020)
>>=20
>>  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.
>>=20
>> 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
>>=20
>> Another potential extension is Diameter Agent Overload. To address =
this, a new value would be needed e.g.
>>=20
>>  NEXT_HOP_MATCH (0x0000000000000040)
>>=20
>>  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.
>>=20
>>=20
>> Best regards
>> Ulrich
>>=20
>>=20
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>=20
> _______________________________________________
> 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


From ulrich.wiehe@nsn.com  Fri Dec 13 03:45:12 2013
Return-Path: 
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 0EA881AE1F9 for ; Fri, 13 Dec 2013 03:45:12 -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 m9IFimEx0c6C for ; Fri, 13 Dec 2013 03:45:07 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id DC4E61AE1F8 for ; Fri, 13 Dec 2013 03:45:06 -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 rBDBivwu010506 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 13 Dec 2013 12:44:57 +0100
Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rBDBivtP028297 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 13 Dec 2013 12:44:57 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.152]) by DEMUHTC004.nsn-intra.net ([10.159.42.35]) with mapi id 14.03.0123.003; Fri, 13 Dec 2013 12:44:57 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Jouni Korhonen , Maria Cruz Bartolome 
Thread-Topic: [Dime] OVLI: comments to 4.6
Thread-Index: Ac7yfC5RbFsL+gV9TT6AJTwE2Xmtw///9WMA///VCNCAAY5MAP/8pa7QgAa0jQD//+gXwADE42MAAAL+0AD//+ZFcA==
Date: Fri, 13 Dec 2013 11:44:57 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519EB25@DEMUMBX014.nsn-intra.net>
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DCBC@DEMUMBX014.nsn-intra.net> <6950EE6B-689E-47A1-88AA-1A67C47BC82E@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519DD4D@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D90006681519E00D@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D90006681519E086@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B920973B124@ESESSMB101.ericsson.se> <56726CC6-823B-4F4E-B898-2034D1EE8A85@gmail.com>
In-Reply-To: <56726CC6-823B-4F4E-B898-2034D1EE8A85@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.107]
Content-Type: text/plain; charset="us-ascii"
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: 13761
X-purgate-ID: 151667::1386935098-00001A6F-918B5F4B/0-0/0-0
Cc: "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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Dec 2013 11:45:12 -0000

Would it be acceptable to define enumeration values for Host Report to be 7=
 and for Realm Report to be 25 and add some informative text that explains =
the intention?

Although its ok to signal only one of two values, the reporting node must d=
o three of five checks.

Ulrich  =20

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Jouni Korhonen
Sent: Friday, December 13, 2013 11:54 AM
To: Maria Cruz Bartolome
Cc: dime@ietf.org
Subject: Re: [Dime] OVLI: comments to 4.6


On Dec 13, 2013, at 11:28 AM, Maria Cruz Bartolome  wrote:

> Hello Ulrich, all,
>=20
> I agree with Nirav, I think in the base IETF draft we need to keep what i=
s required for the use cases identified so far, (as long as ReportType is e=
xtensible).
>=20
> Therefore I think that DESTINATION_HOST_MATCH and DESTINATION_REALM_MATCH=
 are enough in the draft.

Ok.



> Going a bit more in detail into your mail, I will comment on why rest of =
values are not required:=20
>=20
>>  APPLICATION_ID_MATCH (0x0000000000000001)
> Agreement for the baseline is to infer this always from the Diameter enca=
psulating message. Therefore, this is always done, no reason to add a Repor=
tType for this.
>>=20
>>  DESTINATION_HOST_PRESENT (0x0000000000000002)
> What we need to know if whether overload-report shall apply for either HO=
ST_MATCH or REALM_MATCH.=20
> This value is included into HOST_MATCH, then I do not see a reason to hav=
e it as an independent value.
>=20
>>  DESTINATION_HOST_MATCH (0x0000000000000004)
> Fine, I think this is required
>=20
>>  DESTINATION_HOST_ABSENT (0x0000000000000008)
> This value is included into REALM_MATCH. Any reason to have it as an inde=
pendent value?=20
>=20
>>  DESTINATION_REALM_MATCH (0x0000000000000010)
> Fine, I think this is required
>=20
> About decision on whether it should be Unsigned or Enumerated, not sure w=
hich one could be best, I then to agree with Jouni that both could be valid=
 as long as we need to define new values on application documentation, expl=
aining expected behavior.

Ok. My preference is still enumerated, mainly because it prevents
designing do_everything_and_a_bit_more OLRs. A report type and a=20
matching OLR for a single purpose.

- Jouni


>=20
> Best regards
> /MCruz
>=20
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN=
 - DE/Munich)
> Sent: lunes, 09 de diciembre de 2013 14:38
> To: ext Nirav Salot (nsalot); ext Jouni
> Cc: dime@ietf.org
> Subject: Re: [Dime] OVLI: comments to 4.6
>=20
> Hi Nirav,
>=20
> in the end its a matter of taste, and I definitly prefer the Unsigned64 a=
pproach.
>=20
> Please note: The Enumerated approach also has a value (0 Reserved) withou=
t use case. And there is confusing text e.g. "...should apply to requests t=
hat the reacting node knows will reach the overloaded node."=20
> How would the reacting node know that a request will actually reach the o=
verloaded node? And even if it knows this, wouldn't the overload treatment =
apply only to those requests that match the application-id from the answer?
>=20
> Best regards
> Ulrich
>=20
>=20
> -----Original Message-----
> From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com]=20
> Sent: Monday, December 09, 2013 1:56 PM
> To: Wiehe, Ulrich (NSN - DE/Munich); ext Jouni
> Cc: dime@ietf.org
> Subject: RE: [Dime] OVLI: comments to 4.6
>=20
> Ulrich,
>=20
> Defining a bit "APPLICATION_ID_MATCH" and not having a use case when this=
 bit is set to "0" (at least in the context of the current draft) is confus=
ing to me. Same is the case with some other bits you have proposed.
>=20
> In summary, I do not see any issue with the current ReportType.=20
> For the extensibility, we have to deal with it anyway when we have corres=
ponding use case in 3GPP or in IETF. In my view, defining the ReportType wi=
th some assumption of its extensibility is confusing since those use cases =
are not discussed here yet.
>=20
> Regards,
> Nirav.
>=20
> -----Original Message-----
> From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20
> Sent: Monday, December 09, 2013 5:55 PM
> To: Nirav Salot (nsalot); ext Jouni
> Cc: dime@ietf.org
> Subject: RE: [Dime] OVLI: comments to 4.6
>=20
> Hi Nirav,
> can you please point out what actually is confusing. I would have thougth=
 that my proposal is more clear and precise as it exactly identifies when a=
 given request matches the OLR (i.e. must undergo the throttling).
>=20
> With regard to complexity there is no difference between checking the two=
 allowed enumeration values 1 and 2 (current version) or the two allowed Un=
signed64 values (0x0000000000000007) and (0x0000000000000019) (my proposal)=
.
>=20
> The main benefit I see with my proposal is the extensibility e.g.
> One new value of   ORIGIN_HOST_MATCH (0x0000000000000020) for Overload Mi=
tigation Differentiation per client rather than
> Two new values of "host report with origin-host match" and realm-report w=
ith origin-host match".
>=20
> Best regards
> Ulrich
>=20
>=20
>=20
> -----Original Message-----
> From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com]=20
> Sent: Saturday, December 07, 2013 10:44 AM
> To: Wiehe, Ulrich (NSN - DE/Munich); ext Jouni
> Cc: dime@ietf.org
> Subject: RE: [Dime] OVLI: comments to 4.6
>=20
> Hi Ulrich,
>=20
> Instead of re-packing, I see your proposal as confusing or adding more im=
plementation complexity to the exiting simple proposal of having just two R=
eport-Type.
> e.g. with your proposal, now the nodes have to validate if the combinatio=
n of Report-Type flag is correct/allowed or not and perform the error handl=
ing if there is any discrepancy.=20
>=20
> Besides, I do not see the need for some obvious Report-Type e.g. "APPLICA=
TION_ID_MATCH" since it is always present and/or implicit.
> Same is the case with "DESTINATION_HOST_PRESENT" and "DESTINATION_HOST_MA=
TCH". What is the use case for destination-host present but not match? In o=
ther words, the reacting node should use this type of report towards which =
node/realm?
>=20
> I guess this time you need to convince me (at least) as why you think so =
many different Report-Types are needed and what is the issue with existing =
definition of Report-Type.
>=20
> Regards,
> Nirav.
>=20
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN=
 - DE/Munich)
> Sent: Friday, December 06, 2013 7:48 PM
> To: ext Jouni
> Cc: dime@ietf.org
> Subject: Re: [Dime] OVLI: comments to 4.6
>=20
> Hi Jouni,
>=20
> 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.
>=20
> Best regards
> Ulrich
>=20
> -----Original Message-----
> From: ext Jouni [mailto:jouni.nospam@gmail.com]=20
> 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
>=20
>=20
> On Dec 6, 2013, at 2:10 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>=20
>> Dear all,
>>=20
>> here are comments to clause 4.6:
>>=20
>> It has already been proposed to change the type of the OC-Report-Type AV=
P from Enumerated to Unsinged64 in order to avoid potential extensibility p=
roblems. =20
>=20
> I do not see how changing the type to unsigned would help with the extens=
ibility on
> an assumption we create an IANA maintained registry for it. Unsigned64 wi=
ll have
> exactly the same issues as enumerated unless we define report type semant=
ics to
> something like what we have on OC-Feature AVP. How the receiver of the re=
port type
> reacts when it sees a flag bit that is does not understand? If the conten=
t and
> handling  of the OC-OLR somehow depends on the unknown flag bit, the rece=
iver has
> no other choice than drop the OLR, since it cannot be sure how to handle =
the report
> as a whole.
>=20
> 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=20
>   spec)
>=20
> Other than those, IMHO, are just repackaging the issue into different for=
m.
>=20
>=20
> - Jouni
>=20
>> In addition to that, I think that the purpose of the Report-Type is to l=
et the reacting node know to which (future) request commands the overload t=
reatment should apply:
>>=20
>> For a host report-type the overload treatment should apply to all reques=
t commands for which
>> a) The request command's Application-ID matches the Application-Id of th=
e OC-Report-Type AVP's encapsulating answer command and
>> b) The request command's Destination-Host is present and=20
>> c) The request command's Destination-Host matches the Origin-Host of the=
 OC-Report-Type AVP's encapsulating answer command
>>=20
>> For a realm report-type the overload treatment should apply to all reque=
st commands for which
>> a)  and
>> d) The request command's Destination-Host is absent and=20
>> e) The request command's Destination Realm matches the Origin-Realm of t=
he OC-Report-Type AVP's encapsulating answer command.
>>=20
>> The proposal now is to assign individual bits of the Unsinged64 type to =
a), b), c), d), and e):
>>=20
>> Proposed text:
>>  4.6 OC-Report-Type AVP
>>=20
>>  The OC-Report-Type AVP (AVP code TBD5) is type of Unsigned64 and contai=
ns a 64 bit flags field of a request
>>  command's characteristics.
>>=20
>>  The following characteristics are defined in this document:
>>=20
>>  APPLICATION_ID_MATCH (0x0000000000000001)
>>=20
>>  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 Appli=
cation-Id of the OC-Report-Type AVP's
>>  encapsulating answer command.
>>=20
>>  DESTINATION_HOST_PRESENT (0x0000000000000002)
>>=20
>>  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.
>>=20
>>  DESTINATION_HOST_MATCH (0x0000000000000004)
>>=20
>>  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.
>>=20
>>  DESTINATION_HOST_ABSENT (0x0000000000000008)
>>=20
>>  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.
>>=20
>>  DESTINATION_REALM_MATCH (0x0000000000000010)
>>=20
>>  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.
>>=20
>>  Combinations other than=20
>>  1) APPLICATION_ID_MATCH and DESTINATION_HOST_PRESENT and DESTINATION_HO=
ST_MATCH
>>  and
>>  2) APPLICATION_ID_MATCH and DESTINATION_HOST_ABSENT and DESTINATION_REA=
LM_MATCH
>>  require a mutually agreed extension.
>>=20
>>=20
>>=20
>>=20
>> One extension required by 3GPP applications is the Overload Mitigation D=
ifferentiation per client (see 3GPP TR 29.809 clause 6.4.7. To address this=
, a new value would be needed e.g.
>>=20
>>  ORIGIN_HOST_MATCH (0x0000000000000020)
>>=20
>>  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 Dest=
ination-Host of the OC-Report-Type AVP's
>>  encapsulating answer command.
>>=20
>> With this extension the following additional combinations would be allow=
ed:
>> 3) APPLICATION_ID_MATCH and DESTINATION_HOST_PRESENT and DESTINATION_HOS=
T_MATCH and ORIGIN_HOST_MATCH
>> and
>> 4) APPLICATION_ID_MATCH and DESTINATION_HOST_ABSENT and DESTINATION_REAL=
M_MATCH and ORIGIN_HOST_MATCH
>>=20
>> Another potential extension is Diameter Agent Overload. To address this,=
 a new value would be needed e.g.
>>=20
>>  NEXT_HOP_MATCH (0x0000000000000040)
>>=20
>>  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.
>>=20
>>=20
>> Best regards
>> Ulrich
>>=20
>>=20
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>=20
> _______________________________________________
> 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

From ulrich.wiehe@nsn.com  Fri Dec 13 04:13:22 2013
Return-Path: 
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 D18CE1A1F5E for ; Fri, 13 Dec 2013 04:13:22 -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 kB5pIwGlLfzH for ; Fri, 13 Dec 2013 04:13:20 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 1B0931A1F7D for ; Fri, 13 Dec 2013 04:13:19 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rBDCDAxR013946 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 13 Dec 2013 13:13:10 +0100
Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rBDCCiea004105 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 13 Dec 2013 13:13:10 +0100
Received: from DEMUHTC011.nsn-intra.net (10.159.42.42) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 13 Dec 2013 13:12:59 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.152]) by DEMUHTC011.nsn-intra.net ([10.159.42.42]) with mapi id 14.03.0123.003; Fri, 13 Dec 2013 13:12:59 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Jouni Korhonen 
Thread-Topic: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3
Thread-Index: AQHO9ykNu8kXrTctjEKAa/22QPkdEZpSBLYQ
Date: Fri, 13 Dec 2013 12:12:58 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519EB40@DEMUMBX014.nsn-intra.net>
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DB1B@DEMUMBX014.nsn-intra.net>  <52A5E902.20605@usdonovans.com> <7475B713-1104-4791-96B1-CE97632A0D69@nostrum.com>  <5BCBA1FC2B7F0B4C9D935572D90006681519E476@DEMUMBX014.nsn-intra.net> <1CD20507-B0FE-4367-804A-B831734CF060@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E6DC@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D90006681519E712@DEMUMBX014.nsn-intra.net> <4A151D70-0291-4238-85B1-03BB54B361E6@gmail.com> <52A864FF.10705@usdonovans.com> <23887553-5068-477A-AE34-3DC5E3D5AC76@gmail.com> <087A34937E64E74E848732CFF8354B920973A7D7@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D90006681519E8D9@DEMUMBX014.nsn-intra.net> <4A51393B-7AC4-4185-BA29-93801F6811D0@gmail.com>
In-Reply-To: <4A51393B-7AC4-4185-BA29-93801F6811D0@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.107]
Content-Type: text/plain; charset="us-ascii"
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: 3899
X-purgate-ID: 151667::1386936791-00000661-BAE4F37E/0-0/0-0
Cc: Ben Campbell , "dime@ietf.org list" 
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI:	comments to 4.3
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Dec 2013 12:13:23 -0000

Jouni,

again, I don't find this acceptable.=20

See inline.

Ulrich

-----Original Message-----
From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
Sent: Thursday, December 12, 2013 11:58 AM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: ext Maria Cruz Bartolome; Steve Donovan; Ben Campbell; dime@ietf.org li=
st
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comment=
s to 4.3


Ulrich,

On Dec 12, 2013, at 12:29 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:

> Jouni,
>=20
> I dont find it acceptable to say "well, the concept of real-type OLRs has=
 unresolved issues; implementatios are expected to resolve those."

If you need synchronisation for one thing.. then you achieve it
somehow. Just like in you example how you would keep realm reports
in sync between agents? It is equivalent issue unless you are fine
with conflicting reports..
[Wiehe, Ulrich (NSN - DE/Munich)] I'm not fine with conflicting reports, bu=
t the current solution for DOIC will result in conflicting reports in some =
deployments. I propose to update the solution so that it solves the identif=
ied problems for these deployments.

It is not necessarily our job to define how some things at the=20
deployment level are achieved. We already made rather rough=20
assumptions how front ends and such work.
[Wiehe, Ulrich (NSN - DE/Munich)] It is our job to make DOIC a success. It =
will not be a success when it cannot be used in certain deployments.


> Also, there may be deployments where agent A1 has connections to Servers =
S1 and S2 but not S3, A2 has connections to S1 and S3 but not S2, A3 has co=
nnections to S1 and S3 but not S2.

So? How would that change the situation? The realm status should=20
be the same for all reports representing the same realm.

> Note there are still other open issue of realm type concept e.g. like par=
titioned servers.
>=20
>=20
> MCruz,
> I'm afraid TimeStamp does not help. Even if the agents are 100% time sync=
hronized it is not guaranteed that all agents will go into the (same) overl=
oad state exactly at the same time. Also: with the deployment scenario outl=
ined above different agents  may be in different overload states.

So now you are saying that it would be acceptable that multiple
sources (agents) from the same realm tell different truth about
the realm state to the reacting node? I would find that somewhat=20
unacceptable assumption.
[Wiehe, Ulrich (NSN - DE/Munich)] I don't say that this is acceptable; I sa=
y that this may be the result in the current solution and we need to enhanc=
e the solution to cover those cases.

- Jouni



>=20
> Ulrich
>=20
>=20
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Bar=
tolome
> Sent: Wednesday, December 11, 2013 6:22 PM
> To: Jouni Korhonen; Steve Donovan
> Cc: Ben Campbell; dime@ietf.org list
> Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comme=
nts to 4.3
>=20
> Dear all,
>=20
>> [Steve] Ulrich does bring up an interesting use case, where a client is =
receiving realm reports for the same realm from different agents.  We need =
to define the clients behavior in this case. =20
>=20
> [Jouni] Could we simply say that in this case the agents (or who ever ins=
erts the realm report) MUST share the same view of the realm overload condi=
tion? Obviously how it is achieved would be implementation specific. I reca=
ll we have surfaced this topic earlier..
>=20
> [MCruz] But... isn't simpler to use time instead of sequence? It would so=
lve this case as long as any number of agents serving same realm are time s=
ynchronized. =20
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From jouni.nospam@gmail.com  Fri Dec 13 05:33:18 2013
Return-Path: 
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 293DD1AE26F for ; Fri, 13 Dec 2013 05:33:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.889
X-Spam-Level: 
X-Spam-Status: No, score=-0.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no
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 IalWpjKuGdPd for ; Fri, 13 Dec 2013 05:33:14 -0800 (PST)
Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 56C081AC863 for ; Fri, 13 Dec 2013 05:33:14 -0800 (PST)
Received: by mail-la0-f48.google.com with SMTP id n7so1360319lam.7 for ; Fri, 13 Dec 2013 05:33:07 -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=MrJl8uv/d1F5VE3ajCb9h4pkMAXO2jjWf0sQUjjW1tU=; b=tN6ZmZRm35oHpebMK/RgSvtykT7XCTtuljxkBCnIBajJWi6QJmvm6QXQmWCiyNA3d5 1yDjAaaK3/zLG0bqaVigAW4lvtQbGqzKFU0JTv2QY1CJPas1vMj6usDlGigwIF9bma07 JqbG+QW6Trot84ZVZ3tD5ZKuf8MnMmhnzEutmeqMDeTmjrvZN0a6n6ak9laydwKtx/EU rgvHsNJoeSLNxi+NE7R5AKv2nfF4lFN39mtK3s/NvuTfCuvR/A0wvS1lK6ykgbMYia7P IqzRDxRKF7FZff1OAOrIWpYZ5S929r2nW75hQmkEvH4u3zVElBhmkBnkkN2YDWUQsf1R V8Sg==
X-Received: by 10.152.3.70 with SMTP id a6mr25767laa.63.1386941587119; Fri, 13 Dec 2013 05:33:07 -0800 (PST)
Received: from wireless-86-50-132-140.open.aalto.fi (wireless-86-50-132-140.open.aalto.fi. [86.50.132.140]) by mx.google.com with ESMTPSA id e10sm4289205laa.6.2013.12.13.05.33.06 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 13 Dec 2013 05:33:06 -0800 (PST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jouni Korhonen 
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681519E9FE@DEMUMBX014.nsn-intra.net>
Date: Fri, 13 Dec 2013 15:33:05 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <36AA0D1A-C1A8-4C3D-B47A-67606862E3F6@gmail.com>
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DA3E@DEMUMBX014.nsn-intra.net> <09616DA2-D1ED-40EE-8E89-755DFCD81092@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E02B@DEMUMBX014.nsn-intra.net> <1A402C59-E390-4C95-8E30-97F1F9D3EF0F@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E05C@DEMUMBX014.nsn-intra.net> <790F1603-64D5-40E2-BC59-FD4C104EEF1B@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E0D9@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D90006681519E331@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D90006681519E3C4@DEMUMBX014.nsn-intra.net> <0CDBF4BB-4E38-41D6-A5E2-9218FFEFEA43@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E6EF@DEMUMBX014.nsn-intra.net> <52A869AD.6080305@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E89B@DEMUMBX014.nsn-intra.net> <52A9C040.40206@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E9BE@DEMUMBX014.nsn-intra.net> <52A9D74B.8070 404@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E9FE@DEMUMBX014.nsn-intra.net>
To: "Wiehe, Ulrich (NSN - DE/Munich)" 
X-Mailer: Apple Mail (2.1510)
Cc: "dime@ietf.org" 
Subject: Re: [Dime] OVLI: comments to 4.1
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Dec 2013 13:33:18 -0000

On Dec 12, 2013, at 6:02 PM, "Wiehe, Ulrich (NSN - DE/Munich)" =
 wrote:

> Steve,
> ok, but then its only fair to let individual implementers (of reacting =
nodes) make the decision whether or not to spend the effort of include a =
sequence number in the OC-Supported-Features (i.e. make the sequence =
number optional).=20

Having a mandatory to send but optional to process AVP would fit here.
That would not be optional in a Diameter CCF point of view but text
saying on the receiver side "MAY process seqno.." or "SHOULD process
seqno..". Just avoiding MUST should do.

- JOuni



> =20
> Isn=92t the situation similar to the proposal to introduce =
Ongoing-Throttling-Information mandatorily in requests and let =
implementers of reporting nodes decide whether they want to make use of =
this information?
> =20
> Ulrich
> =20
> See also inline
> =20
> =20
> From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]=20
> Sent: Thursday, December 12, 2013 4:34 PM
> To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
> Subject: Re: [Dime] OVLI: comments to 4.1
> =20
> Ulrich,
>=20
> Thanks for the correction -- obviously typed pre coffee this morning.
>=20
> The tradeoff is requiring processing on every request versus =
maintaining state to allow avoiding that processing on 99.99% of =
requests.
>=20
> [Wiehe, Ulrich (NSN - DE/Munich)] The tradeoff is between a) checking =
the Supported_Features in every request and know what to do, and b) =
checking the sequence number in every request, looking up a database and =
then (in 99.99% of cases) know what to do.
>=20
>=20
>=20
> We should let individual implementers make the decision on which =
approach they prefer.
>=20
> Steve
>=20
> On 12/12/13 9:22 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> Steve,
> =20
> you probably mean =84=85can=92t  be optional=85=93 rather than =93=85can=
=92t be mandatory=85=94
> =20
> If so, I understand your logic but this means that  reacting nodes are =
forced to  implement sequence numbers in OC-Supported-Features just =
because some reporting nodes prefer to do things complicated rather than =
simple and I=92m not convinced that this would be the way to go.
> =20
> Ulrich
> =20
> =20
> From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]=20
> Sent: Thursday, December 12, 2013 2:55 PM
> To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
> Subject: Re: [Dime] OVLI: comments to 4.1
> =20
> Ulrich,
>=20
> No, the sequence number can't be mandatory.  It always needs to be =
sent to allow for end-points that what to use the logic I proposed.
>=20
> An endpoint that receives the sequence number can choose to ignore it, =
but endpoints must always send sequence numbers.
>=20
> Steve
>=20
> On 12/12/13 3:30 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> Steve,
> =20
> do you mean =84 keep sequence number in OC-Supported-Features as an =
optional AVP that may be ignored by the receiver and need notbe included =
by the sender=94?
> =20
> Ulrich
> =20
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve =
Donovan
> Sent: Wednesday, December 11, 2013 2:34 PM
> To: dime@ietf.org
> Subject: Re: [Dime] OVLI: comments to 4.1
> =20
> Ulrich,
>=20
> My email showed how a reporting node could avoid the work of =
recalculating capability information on a message by message basis using =
the sequence number.  This approach does require maintaining state.
>=20
> As Ben pointed out, it is also possible to not follow my logic and do =
as you propose by ignoring the sequence number and going through the =
work of calculating the response every time. =20
>=20
> Which approach to take is clearly an implementation decision.  We =
should keep the sequence number to allow for the stateful approach for =
implementations that are willing to take advantage of maintaining state =
to avoid work.
>=20
> Steve
>=20
> On 12/11/13 1:34 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> Jouni,
> =20
> I do not agree.
> =20
> My statement was general: reporting node may be server or SFA; =
supported features may be defined features (default algo) or future =
extensions.
> =20
> Ulrich
> =20
> -----Original Message-----
> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
> Sent: Tuesday, December 10, 2013 10:46 PM
> To: Wiehe, Ulrich (NSN - DE/Munich)
> Cc: dime@ietf.org
> Subject: Re: [Dime] OVLI: comments to 4.1
> =20
> Ulrich,
> =20
> On Dec 10, 2013, at 2:18 PM, "Wiehe, Ulrich (NSN - DE/Munich)" =
 wrote:
> =20
> =20
> =20
> -----Original Message-----
> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
> Sent: Tuesday, December 10, 2013 12:32 PM
> To: Wiehe, Ulrich (NSN - DE/Munich)
> Cc: dime@ietf.org
> Subject: Re: [Dime] OVLI: comments to 4.1
> =20
> =20
> On Dec 10, 2013, at 12:41 PM, "Wiehe, Ulrich (NSN - DE/Munich)" =
 wrote:
> =20
> Hi Jouni,
> =20
> my understanding from Steve's clarification was that the reporting =
node would setup and maintain a database of "states", one per reacting =
node where a state of a reacting node is identified by a sequence number =
and the database entry would contain the pre-calculated OLR.=20
> Hard to see how this is done without consuming resources.
> =20
> It is mostly static information. Still I do not see how
> you would get away without any state.
> [Wiehe, Ulrich (NSN - DE/Munich)] There is no need for the reporting =
node to store and maintain information per reacting node because the =
reacting node actually tells within the request message all information =
the reporting node needs to know. The reporting node simply fetches the =
pre-calculated OLR that matches the supported features of the reacting =
node as indicated in the request and appends it to the answer.
> =20
> This could be true for the default algorithm in this spec. However,
> given the extension mechanism we have in place it is quite possible
> that the assumption does not hold for new features.
> =20
> Also, if I were to implement a server front end agent that would
> definitely need state and still ought to comply the protocol spec.
> =20
> - Jouni
> =20
> =20
> =20
> =20
> Furthermore,
> Why would the reacting node be interested in config changes of the =
reporting node?
> Isn't it so that the reacting node is only interested in OLR changes?
> =20
> Sigh.. say the traffic abatement algorithm changes or new features
> get added. Those have more impact than just OLR change.
> =20
> - Jouni
> =20
> =20
> Ulrich
> =20
> -----Original Message-----
> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
> Sent: Tuesday, December 10, 2013 9:41 AM
> To: Wiehe, Ulrich (NSN - DE/Munich)
> Cc: dime@ietf.org
> Subject: Re: [Dime] OVLI: comments to 4.1
> =20
> =20
> On Dec 9, 2013, at 4:43 PM, "Wiehe, Ulrich (NSN - DE/Munich)" =
 wrote:
> =20
> But maintaining a specific state per reacting node is very resource =
consuming for the (overloaded) reporting node. It is simpler and more =
efficient to base any processing logic on actual information received in =
the request rather than on information stored from previous =
communication.
> =20
> The "state" in a reporting node is merely the current configuration
> and a counter for sequence number. Hard to me see that as resource
> consuming function.
> =20
> And the earlier comment of mine is done from reacting node point
> of view, since it is more interested in the possible config changes
> in the reporting node (e.g. S6a is stateless application, =
configuration
> can change at any time).
> =20
> - Jouni
> =20
> =20
> =20
> Ulrich
> =20
> -----Original Message-----
> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
> Sent: Monday, December 09, 2013 2:25 PM
> To: Wiehe, Ulrich (NSN - DE/Munich)
> Cc: dime@ietf.org
> Subject: Re: [Dime] OVLI: comments to 4.1
> =20
> =20
> On Dec 9, 2013, at 3:13 PM, "Wiehe, Ulrich (NSN - DE/Munich)" =
 wrote:
> =20
> There is a fundamental difference:
> OLRs need to be stored, Feature-Vectors not.
> =20
> How come feature vector does not need to be stored? I do not
> get that? I would set my implementation to a specific state
> or mode based on the feature vector. When that changes I'd
> like to know that. And then keep functioning based on that.
> =20
> - Jouni
> =20
> When receiving an OLR you may want to know whether its worth the =
effort to replace an already stored OLR with the received OLR.
> When receiving a Feature-Vector you just act on it.
> =20
> Ulrich=20
> =20
> -----Original Message-----
> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
> Sent: Monday, December 09, 2013 1:55 PM
> To: Wiehe, Ulrich (NSN - DE/Munich)
> Cc: dime@ietf.org
> Subject: Re: [Dime] OVLI: comments to 4.1
> =20
> =20
> In the same vein as folks wanted send OLRs with the new or old =
information,
> the feature vector should behave in a same way IMHO. That implies =
there are
> situations when a reception of the feature vector does not change =
anything
> in an endpoint current behavior.
> =20
> - Jouni
> =20
> On Dec 9, 2013, at 2:47 PM, "Wiehe, Ulrich (NSN - DE/Munich)" =
 wrote:
> =20
> Isn't it so that the Feature-Vector (if present) always contains =
something that an implementation needs to act upon?
> =20
> Ulrich
> =20
> -----Original Message-----
> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
> Sent: Monday, December 09, 2013 1:12 PM
> To: Wiehe, Ulrich (NSN - DE/Munich)
> Cc: dime@ietf.org
> Subject: Re: [Dime] OVLI: comments to 4.1
> =20
> Ulrich,
> =20
> On Dec 6, 2013, at 3:03 PM, "Wiehe, Ulrich (NSN - DE/Munich)" =
 wrote:
> =20
> Hi Jouni,
> =20
> thank you for your response.
> =20
> With regard to 3)=20
> I still fail to see the usecase for Sequence-Number or TimeStamp =
within OC-Feature-Vector. Please clarify.
> =20
> Since we also allow extending the OC-Feature-Vector beyond =
recognition,=20
> it has good chances become a rather complex grouped AVP. In that =
context
> the Sequence-Number allows an easy and quick way to check if the =
feature
> vector contains something that an implementation needs to act upon.
> =20
> With regard to 4)
> This was not obvious to me. (The obvious typo is the missing "of" =
between "one" and "the").
> =20
> Ack. Fixed the missing 'of'.
> =20
> - Jouni
> =20
> =20
> Best regards
> Ulrich
> =20
> =20
> -----Original Message-----
> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
> Sent: Friday, December 06, 2013 11:17 AM
> To: Wiehe, Ulrich (NSN - DE/Munich)
> Cc: dime@ietf.org
> Subject: Re: [Dime] OVLI: comments to 4.1
> =20
> =20
> On Dec 5, 2013, at 3:23 PM, "Wiehe, Ulrich (NSN - DE/Munich)" =
 wrote:
> =20
> Dear all,
> =20
> here are comments to clause 4.1:
> =20
> 1. The OC-Feature-Vector AVP is no longer a vector; the name of the =
AVP may be misleading. Proposal is to rename it to =
"OC-Supported-Features AVP"
> =20
> OK with me.
> =20
> 2. The OC-Feature AVP is a vector of features. Proposal is to rename =
it to "OC-Feature-Vector AVP"
> =20
> OK with me.
> =20
> 3. The OC-Sequence-Number within OC-Feature-Vector only makes sense if =
the receiving reporting endpoint can determine the identity of the =
reacting endpoint (which is not necessarily the origin host (client),
> =20
> My original proposal was to have seqnr as a timestamp. Some folks =
argued
> it is no good and suggested seqnr. I still think time makes more sense =
than
> seqnr.
> =20
> it may be an agent and it may not always be the same agent), and if =
the reporting endpoint is required to store the OC-Feature-Vector / =
reacting-endpoint-identity pair (which I think both is not required). =
The reporting endpoint can base its processing logic on the actually =
received OC-Feature-Vector value, no matter whether it is brand-new or =
old but stil valid. Proposal is to delete OC-Sequence-Number AVP from =
OC-Feature-Vector.
> =20
> Do not agree removing it.
> =20
> 4. The text
> =20
> The reporting node that sends the answer also includes the OC-
> Feature-Vector AVP that describe the capabilities it supports.  The
> set of capabilities advertised by the reporting node depends on local
> policies.  At least one the announced capabilities MUST match
> mutually.  If there is no single matching capability the reacting
> node MUST act as if it does not implement DOIC and cease inserting
> any DOIC related AVPs into any Diameter messages with this specific
> reacting node.
> =20
> is not clear.  Would the reporting node include the OC-Feature-Vector =
AVP in the answer only if there is at least one matching capability?=20
> =20
> Because then they have found a way to exchange something that both =
ends
> know how to handle it.
> =20
> Mandating the reacting node to cease for all time inserting =
OC-Feature-Vector AVPs if it did not get back=20
> =20
> There is an obvious typo. It should say:
> =20
> policies.  At least one the announced capabilities MUST match
> mutually.  If there is no single matching capability the reporting
> node MUST act as if it does not implement DOIC and cease inserting
> any DOIC related AVPs into any Diameter messages with this specific
> reacting node.
> =20
> - JOuni
> =20
> =20
> at least one match is also not ok. The request might have been a =
realm-type request (i.e. without Destination Host) and the reacting node =
cannot control whether subsequent requests will take the same path to =
the same reporting node.
> Even if the request contains a destination host the reacting node =
cannot know wether the reacting node's capabilities have been modified =
by the time a subsequent request is sent.=20
> Proposal is to keep only the first sentence and delete the rest.
> =20
> Ulrich
> =20
> =20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
> =20
> =20
> =20
> =20
> =20
> =20
> =20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
> =20
> =20
> =20
> =20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From jean-jacques.trottin@alcatel-lucent.com  Fri Dec 13 05:45:07 2013
Return-Path: 
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 CCBC41ADA5D for ; Fri, 13 Dec 2013 05:45:07 -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 XIBBmMGj3-_s for ; Fri, 13 Dec 2013 05:45:01 -0800 (PST)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 94A2B1AC4C1 for ; Fri, 13 Dec 2013 05:45:01 -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 rBDDiouM023896 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 13 Dec 2013 07:44:52 -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 rBDDiodJ029359 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 13 Dec 2013 14:44:50 +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; Fri, 13 Dec 2013 14:44:50 +0100
From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
To: "dime@ietf.org" 
Thread-Topic: OC-Supported Feature AVP
Thread-Index: Ac74CX1Hcx+hHoLfTg+cADFSVxx9GA==
Date: Fri, 13 Dec 2013 13:44:49 +0000
Message-ID: 
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.39]
Content-Type: multipart/alternative; boundary="_000_E194C2E18676714DACA9C3A2516265D201CB53EAFR712WXCHMBA12z_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
Subject: [Dime] OC-Supported Feature AVP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Dec 2013 13:45:08 -0000

--_000_E194C2E18676714DACA9C3A2516265D201CB53EAFR712WXCHMBA12z_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Dear all

When analysing the discussion of the sequence number in the OC-Supported-Fe=
atures AVP , it has driven me to some other considerations regarding this  =
feature negotiation that I hereafter present:  it is a bit long but it rais=
es  a certain number of questions   and then we have to draw some conclusio=
n  and adapt the text  of the draft if needed


A)     Behaviours for sending the  OC-Supported-Features AVP

Currently there is only one default algorithm. So the use of  OC-Supported-=
Features AVP containing the OC-Feature-Vector is  only to indicate the supp=
ort of DOIC with the default algorithm, given that en entity not supporting=
 DOIC will never sends the OC-Supported-Features AVP.



This AVP in the future  will allow to add new feature/capabilities .


This AVP is needed initially to advertise the mutual  capabilities between =
reacting and reporting node  and  when changes occur in the  supported  fea=
tures (eg in general to add a new feature, but may be also to remove  one).=
 A sequence number was introduced to manage these changes, but this introdu=
ction is still under discussion (cf Ulrich's mails questioning this point)



Then there is the question about when the OC-Supported-Features AVP is sent=
.  The current draft  has related statements in 3.2 and 4.1  :

The several hereafter possible  behaviors are compliant for me with 3.2 and=
 4.1  statements (are you sharing this reading?), we have to see if the dra=
ft allows all of them or if additional rules must be  fulfilled:



a)      The reacting node sends the OC-Supported-Features AVP in each reque=
st and the reporting node sends back its own OC-Supported-Features AVP in e=
ach answer.

b)      The reacting nodes initially sends its  OC-Supported-Features AVP, =
but does not repeat it any more , until a change in the features to be adve=
rtised  happens or after a node restart

c)       Something intermediate, so when there is a change as in b)  plus  =
a periodic advertisement of the supported features although unchanged




About a):

Steve,  and I agree,   indicated that the features are quite stable over ti=
me, and modifications will appear when a new feature is deployed (OAM case)=
; I think  it is also needed at restart. So there are very few events over =
the year where the advertisement is actually needed (have you others in min=
d?) . Now my questioning:   why to permanently do such an exchange in each =
request/answer?  I observe that this behavior  is used in 3GPP where suppor=
ted features are advertised in each request/answer, so we can apply  the sa=
me principle, but I nevertheless raise the question.



About the sequence number:

o   the receiving node has to open the sequence number AVP and checks if it=
 has changed, given the value will change only a few times a year.  A besid=
es  question,  which value the seq number takes after a restart

o   if we do not use the sequence number, the  receiving node has to open t=
he OC-feature-Vector AVP and see if it has changed, so I do not see much di=
fference with the above

o   the sequence number has the property  to be equal  or to increase in or=
der to detect an eventual  change of the order of the messages and avoid to=
 come back to a previous value of the feature-vector. But further messages =
will all be with the new feature-vector, so the right result. I am not sure=
 that the seq number bring a value for the transient period when the suppor=
ted feature is  modified. So question: can we suppress the seq number in th=
is a) behaviour?
In this a ) behaviour, if the OC-Supported-Features AVP is no more present =
in a message (and in later messages) ,  it would  be interpreted  that DOIC=
 is no more supported . ( so different from the b) or c) case)


About b): this is the other extreme use case compared to a).

Here in practice all the messages will not contain an  OC-Supported-Feature=
s AVP (except in the  rare cases of a change or after a restart), So the ab=
sence of this AVP in a message  does not mean that DOIC is not supported. C=
apability negotiation  happens once and remain valid until a change. At res=
tart or when a change  a reacting node sends an OC-Supported-Features AVP i=
n a request, and wait for an OC-Supported-Features AVP   in the answer; if =
nothing, it means the reporting node is not supporting DOIC. If the answer =
is lost the reacting node may repeat the request or use another one with it=
s OC Supported-feature AVP.



If the change occurs in the reporting node, it cannot wait for a request co=
ming from the reacting node with an OC Supported-feature AVP,  (as it will =
 never come if no change at the reacting node side), so the reporting node =
should advertise the  OC Supported-feature AVP in answers (although the cor=
responding request do not contain this AVP).  I think this behavior is curr=
ently allowed by the draft text, do you agree?.   To secure a bit more, the=
 reacting node may then  send a request with its own OC Supported-feature A=
VP, acting as an acknowledgement to the reporting node. The reporting node =
may repeat if needed  or to be more secure.

There may be some corner cases to investigate more, but I currently stop he=
re.



In this use case, I do not see a need  for a sequence number .


Do you think such an approach is applicable? it will save many checks compa=
red to a).


About c): it is the same principle as in b) but with some periodic  "refres=
h" that may make the a) approach  still more secure. But not sure  it is ac=
tually needed.



So do you think the draft should  allow these different  behaviors  or only=
 mandate one?

Then do you think we need a sequence number for the OC-Supported-Features A=
VP?





B)      Another point also related to the OC-Supported-Features AVP and OC-=
Feature-Vector:


For example a node can use the default mechanism  and in addition support e=
xtensions (eg the APN or the session group examples). I would think extensi=
ons should be advertized by the reacting node , otherwise the server does n=
ot know if it can use an extension or not, and  a server should avoid  to s=
end OLRs that the client will not understand .
 So here we may have  a set of extensions compatible with the default mecha=
nism

The other example is "exclusive" or not compatible features, for example Tr=
affic reduction %control  and rate control. I do not consider  a reporting =
node  will  use both with a reacting node. A reacting node , even if it sup=
ports both does not want to mix  throttling based on % traffic and throttli=
ng on rate control with the same reporting node. But the current  text does=
 not say anything about which feature is selected .
I remember that in our initial discussions, the reacting node was advertisi=
ng its features / capabilities and the reporting node was selecting the one=
s it wants to use. Should not we come back to this rule? or do you consider=
 that when we will introduce new features , we will introduce statements  t=
o indicate rules on their presence in OC-Feature-Vector. Personnaly, I thin=
k  the advertisement  followed  by selection  was a good approach. Views on=
 this?

I have  described this B part  here, as it may have some interaction with t=
he  A part.

Best regards

JJacques










--_000_E194C2E18676714DACA9C3A2516265D201CB53EAFR712WXCHMBA12z_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Dear all 


 


When analysing the discussion of the sequence number=
 in the OC-Supported-Features AVP , it has driven me to some other consider=
ations regarding this  feature negotiation that I hereafter present: &=
nbsp;it is a bit long but it raises  a certain
 number of questions   and then we have to draw some conclusion&n=
bsp; and adapt the text  of the draft if needed



 



A)    
Behaviours for sending the  OC-Supported-Featu=
res AVP


Currently there is =
only one default algorithm. So the use of  OC-Supported-Features AVP c=
ontaining the OC-Feature-Vector is  only to indicate the support of DO=
IC with the default algorithm, given that en entity
 not supporting DOIC will never sends the OC-Supported-Features AVP. <=
/o:p>


 

This AVP in the fut=
ure  will allow to add new feature/capabilities .



 


This AVP is needed =
initially to advertise the mutual  capabilities between reacting and r=
eporting node  and  when changes occur in the  supported &nb=
sp;features (eg in general to add a new feature, but may be also
 to remove  one). A sequence number was introduced to manage these cha=
nges, but this introduction is still under discussion (cf Ulrich’s ma=
ils questioning this point)



 

Then there is the q=
uestion about when the OC-Supported-Features AVP is sent.  The current=
 draft  has related statements in 3.2 and 4.1  :



The several hereaft=
er possible  behaviors are compliant for me with 3.2 and 4.1  sta=
tements (are you sharing this reading?), we have to see if the draft allows=
 all of them or
if additional rules must be  fulfilled:


 


a)     
The reacting node sends the OC-Supported-Features A=
VP in each request and the reporting node sends back its own OC-Supported-F=
eatures AVP in each answer.




b)     
The reacting nodes initially sends its  OC-Sup=
ported-Features AVP, but does not repeat it any more , until a change in th=
e features to be advertised  happens or after a node restart



c)      
Something intermediate, so when there is a change a=
s in b)  plus  a periodic advertisement of the supported features=
 although unchanged


 


 

About a):


Steve,  and I =
agree,   indicated that the features are quite stable over time, =
and modifications will appear when a new feature is deployed (OAM case); I =
think  it is also needed at restart. So there are very
 few events over the year where the advertisement is actually needed (have =
you others in mind?) . Now my questioning:   why to permanently d=
o such an exchange in each request/answer?  I observe that this behavi=
or  is used in 3GPP where supported features are
 advertised in each request/answer, so we can apply  the same principl=
e, but I nevertheless raise the question.


 

About the sequence =
number:



o  
the receiving node has to open the sequence =
number AVP and checks if it has changed, given the value will change only a=
 few times a year.  A besides  question,  which value the se=
q number takes after a restart




o  
if we do not use the sequence number, the &n=
bsp;receiving node has to open the OC-feature-Vector AVP and see if it has =
changed, so I do not see much difference with the above




o  
the sequence number has the property  t=
o be equal  or to increase in order to detect an eventual  change=
 of the order of the messages and avoid to come back to a previous value of=
 the feature-vector. But further messages will
 all be with the new feature-vector, so the right result. I am not sure tha=
t the seq number bring a value for the transient period when the supported =
feature is  modified. So question: can we suppress the seq number in t=
his a) behaviour?


In this a ) behaviour, =
if the OC-Supported-Features AVP is no more present in a message (and in la=
ter messages) ,  it would  be interpreted  that DOIC is no m=
ore supported . ( so different from the b) or c) case)



   


About b): th=
is is the other extreme use case compared to a).



Here in practice al=
l the messages will not contain an  OC-Supported-Features AVP (except =
in the  rare cases of a change or after a restart), So the absence of =
this AVP in a message  does not mean that DOIC
 is not supported. Capability negotiation  happens once and remain val=
id until a change. At restart or when a change  a reacting node sends =
an OC-Supported-Features AVP in a request, and wait for an OC-Supported-Fea=
tures AVP   in the answer; if nothing, it
 means the reporting node is not supporting DOIC. If the answer is lost the=
 reacting node may repeat the request or use another one with its OC Suppor=
ted-feature AVP.



 

If the change occur=
s in the reporting node, it cannot wait for a request coming from the react=
ing node with an OC Supported-feature AVP,  (as it will  never co=
me if no change at the reacting node side), so
 the reporting node should advertise the  OC Supported-feature AVP in =
answers (although the corresponding request do not contain this AVP).  =
;I think this behavior is currently allowed by the draft text, do you agree=
?.   To secure a bit more, the reacting node
 may then  send a request with its own OC Supported-feature AVP, actin=
g as an acknowledgement to the reporting node. The reporting node may repea=
t if needed  or to be more secure.


There may be some c=
orner cases to investigate more, but I currently stop here.  


 

In this use case, I=
 do not see a need  for a sequence number .



     


Do you think such a=
n approach is applicable? it will save many checks compared to a).


 


About c): it=
 is the same principle as in b) but with some periodic  “refresh=
” that may make the a) approach  still more secure. But not sure=
  it is actually needed.


 

So do you think the=
 draft should  allow these different  behaviors  or only man=
date one?


Then do you think w=
e need a sequence number for the OC-Supported-Features AVP?


 

 


B)     
Another point also related to the OC-Supported-Feat=
ures AVP and OC-Feature-Vector:


 


For example a node can use the default mechanism &nb=
sp;and in addition support extensions (eg the APN or the session group exam=
ples). I would think extensions should be advertized by the reacting node ,=
 otherwise the server does not know if
 it can use an extension or not, and  a server should avoid  to s=
end OLRs that the client will not understand .    



 So here we may have  a set of extensions =
compatible with the default mechanism


 


The other example is “exclusive” or not =
compatible features, for example Traffic reduction %control  and rate =
control. I do not consider  a reporting node  will  use both=
 with a reacting node. A reacting node , even if it supports both
 does not want to mix  throttling based on % traffic and throttling on=
 rate control with the same reporting node. But the current  text does=
 not say anything about which feature is selected .



I remember that in our initial discussions, the reac=
ting node was advertising its features / capabilities and the reporting nod=
e was selecting the ones it wants to use. Should not we come back to this r=
ule? or do you consider that when
 we will introduce new features , we will introduce statements  to ind=
icate rules on their presence in OC-Feature-Vector. Personnaly, I think &nb=
sp;the advertisement  followed  by selection  was a good app=
roach. Views on this?



 


I have  described this B part  here, as it=
 may have some interaction with the  A part.


 


Best regards


 


JJacques 


 


 


 


     


 






--_000_E194C2E18676714DACA9C3A2516265D201CB53EAFR712WXCHMBA12z_--

From ulrich.wiehe@nsn.com  Mon Dec 16 02:23:09 2013
Return-Path: 
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 0A6821AE11D for ; Mon, 16 Dec 2013 02:23:09 -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 U9vGfrGCi1kf for ; Mon, 16 Dec 2013 02:23:04 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 080061AE0DD for ; Mon, 16 Dec 2013 02:23:03 -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 rBGAMxqK010602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 16 Dec 2013 11:23:00 +0100
Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rBGAMxTJ016176 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 16 Dec 2013 11:22:59 +0100
Received: from DEMUHTC013.nsn-intra.net (10.159.42.44) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 16 Dec 2013 11:22:58 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.217]) by DEMUHTC013.nsn-intra.net ([10.159.42.44]) with mapi id 14.03.0123.003; Mon, 16 Dec 2013 11:22:58 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Jouni Korhonen 
Thread-Topic: [Dime] OVLI: comments to 4.1
Thread-Index: Ac7xvTHHIECkLcDwSDuVAh2ACeOasAAprlMAAAaV6CAAlFJBAAADLijg///yiAD//+yxwIAAG3gA///jPWCAAV/bAP//0rCwAAujOgD//+gx4P//PIoA//3FKSD/+zWWgP/1DNgg/+nfowD/05n2AP+nPcSA/05pQsD+m3QbgP0yVdhw
Date: Mon, 16 Dec 2013 10:22:58 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151A5D34@DEMUMBX014.nsn-intra.net>
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DA3E@DEMUMBX014.nsn-intra.net> <09616DA2-D1ED-40EE-8E89-755DFCD81092@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E02B@DEMUMBX014.nsn-intra.net> <1A402C59-E390-4C95-8E30-97F1F9D3EF0F@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E05C@DEMUMBX014.nsn-intra.net> <790F1603-64D5-40E2-BC59-FD4C104EEF1B@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E0D9@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D90006681519E331@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D90006681519E3C4@DEMUMBX014.nsn-intra.net> <0CDBF4BB-4E38-41D6-A5E2-9218FFEFEA43@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E6EF@DEMUMBX014.nsn-intra.net> <52A869AD.6080305@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E89B@DEMUMBX014.nsn-intra.net> <52A9C040.40206@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E9BE@DEMUMBX014.nsn-intra.net> <52A9D74B.8070404@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E9FE@DEMUMBX014.nsn-intra.net> <36AA0D1A-C1A8-4C3D-B47A-67606862E3F6@gmail.com>
In-Reply-To: <36AA0D1A-C1A8-4C3D-B47A-67606862E3F6@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.109]
Content-Type: text/plain; charset="us-ascii"
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: 14912
X-purgate-ID: 151667::1387189381-00001A6F-A4EC10D3/0-0/0-0
Cc: "dime@ietf.org" 
Subject: Re: [Dime] OVLI: comments to 4.1
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Dec 2013 10:23:09 -0000

Then let's do the same way with Ongoing-Throttling-Information.

-----Original Message-----
From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
Sent: Friday, December 13, 2013 2:33 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: ext Steve Donovan; dime@ietf.org
Subject: Re: [Dime] OVLI: comments to 4.1


On Dec 12, 2013, at 6:02 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:

> Steve,
> ok, but then its only fair to let individual implementers (of reacting no=
des) make the decision whether or not to spend the effort of include a sequ=
ence number in the OC-Supported-Features (i.e. make the sequence number opt=
ional).=20

Having a mandatory to send but optional to process AVP would fit here.
That would not be optional in a Diameter CCF point of view but text
saying on the receiver side "MAY process seqno.." or "SHOULD process
seqno..". Just avoiding MUST should do.

- JOuni



> =20
> Isn't the situation similar to the proposal to introduce Ongoing-Throttli=
ng-Information mandatorily in requests and let implementers of reporting no=
des decide whether they want to make use of this information?
> =20
> Ulrich
> =20
> See also inline
> =20
> =20
> From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]=20
> Sent: Thursday, December 12, 2013 4:34 PM
> To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
> Subject: Re: [Dime] OVLI: comments to 4.1
> =20
> Ulrich,
>=20
> Thanks for the correction -- obviously typed pre coffee this morning.
>=20
> The tradeoff is requiring processing on every request versus maintaining =
state to allow avoiding that processing on 99.99% of requests.
>=20
> [Wiehe, Ulrich (NSN - DE/Munich)] The tradeoff is between a) checking the=
 Supported_Features in every request and know what to do, and b) checking t=
he sequence number in every request, looking up a database and then (in 99.=
99% of cases) know what to do.
>=20
>=20
>=20
> We should let individual implementers make the decision on which approach=
 they prefer.
>=20
> Steve
>=20
> On 12/12/13 9:22 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> Steve,
> =20
> you probably mean "...can't  be optional..." rather than "...can't be man=
datory..."
> =20
> If so, I understand your logic but this means that  reacting nodes are fo=
rced to  implement sequence numbers in OC-Supported-Features just because s=
ome reporting nodes prefer to do things complicated rather than simple and =
I'm not convinced that this would be the way to go.
> =20
> Ulrich
> =20
> =20
> From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]=20
> Sent: Thursday, December 12, 2013 2:55 PM
> To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
> Subject: Re: [Dime] OVLI: comments to 4.1
> =20
> Ulrich,
>=20
> No, the sequence number can't be mandatory.  It always needs to be sent t=
o allow for end-points that what to use the logic I proposed.
>=20
> An endpoint that receives the sequence number can choose to ignore it, bu=
t endpoints must always send sequence numbers.
>=20
> Steve
>=20
> On 12/12/13 3:30 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> Steve,
> =20
> do you mean " keep sequence number in OC-Supported-Features as an optiona=
l AVP that may be ignored by the receiver and need notbe included by the se=
nder"?
> =20
> Ulrich
> =20
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
> Sent: Wednesday, December 11, 2013 2:34 PM
> To: dime@ietf.org
> Subject: Re: [Dime] OVLI: comments to 4.1
> =20
> Ulrich,
>=20
> My email showed how a reporting node could avoid the work of recalculatin=
g capability information on a message by message basis using the sequence n=
umber.  This approach does require maintaining state.
>=20
> As Ben pointed out, it is also possible to not follow my logic and do as =
you propose by ignoring the sequence number and going through the work of c=
alculating the response every time. =20
>=20
> Which approach to take is clearly an implementation decision.  We should =
keep the sequence number to allow for the stateful approach for implementat=
ions that are willing to take advantage of maintaining state to avoid work.
>=20
> Steve
>=20
> On 12/11/13 1:34 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> Jouni,
> =20
> I do not agree.
> =20
> My statement was general: reporting node may be server or SFA; supported =
features may be defined features (default algo) or future extensions.
> =20
> Ulrich
> =20
> -----Original Message-----
> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
> Sent: Tuesday, December 10, 2013 10:46 PM
> To: Wiehe, Ulrich (NSN - DE/Munich)
> Cc: dime@ietf.org
> Subject: Re: [Dime] OVLI: comments to 4.1
> =20
> Ulrich,
> =20
> On Dec 10, 2013, at 2:18 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:
> =20
> =20
> =20
> -----Original Message-----
> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
> Sent: Tuesday, December 10, 2013 12:32 PM
> To: Wiehe, Ulrich (NSN - DE/Munich)
> Cc: dime@ietf.org
> Subject: Re: [Dime] OVLI: comments to 4.1
> =20
> =20
> On Dec 10, 2013, at 12:41 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:
> =20
> Hi Jouni,
> =20
> my understanding from Steve's clarification was that the reporting node w=
ould setup and maintain a database of "states", one per reacting node where=
 a state of a reacting node is identified by a sequence number and the data=
base entry would contain the pre-calculated OLR.=20
> Hard to see how this is done without consuming resources.
> =20
> It is mostly static information. Still I do not see how
> you would get away without any state.
> [Wiehe, Ulrich (NSN - DE/Munich)] There is no need for the reporting node=
 to store and maintain information per reacting node because the reacting n=
ode actually tells within the request message all information the reporting=
 node needs to know. The reporting node simply fetches the pre-calculated O=
LR that matches the supported features of the reacting node as indicated in=
 the request and appends it to the answer.
> =20
> This could be true for the default algorithm in this spec. However,
> given the extension mechanism we have in place it is quite possible
> that the assumption does not hold for new features.
> =20
> Also, if I were to implement a server front end agent that would
> definitely need state and still ought to comply the protocol spec.
> =20
> - Jouni
> =20
> =20
> =20
> =20
> Furthermore,
> Why would the reacting node be interested in config changes of the report=
ing node?
> Isn't it so that the reacting node is only interested in OLR changes?
> =20
> Sigh.. say the traffic abatement algorithm changes or new features
> get added. Those have more impact than just OLR change.
> =20
> - Jouni
> =20
> =20
> Ulrich
> =20
> -----Original Message-----
> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
> Sent: Tuesday, December 10, 2013 9:41 AM
> To: Wiehe, Ulrich (NSN - DE/Munich)
> Cc: dime@ietf.org
> Subject: Re: [Dime] OVLI: comments to 4.1
> =20
> =20
> On Dec 9, 2013, at 4:43 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:
> =20
> But maintaining a specific state per reacting node is very resource consu=
ming for the (overloaded) reporting node. It is simpler and more efficient =
to base any processing logic on actual information received in the request =
rather than on information stored from previous communication.
> =20
> The "state" in a reporting node is merely the current configuration
> and a counter for sequence number. Hard to me see that as resource
> consuming function.
> =20
> And the earlier comment of mine is done from reacting node point
> of view, since it is more interested in the possible config changes
> in the reporting node (e.g. S6a is stateless application, configuration
> can change at any time).
> =20
> - Jouni
> =20
> =20
> =20
> Ulrich
> =20
> -----Original Message-----
> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
> Sent: Monday, December 09, 2013 2:25 PM
> To: Wiehe, Ulrich (NSN - DE/Munich)
> Cc: dime@ietf.org
> Subject: Re: [Dime] OVLI: comments to 4.1
> =20
> =20
> On Dec 9, 2013, at 3:13 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:
> =20
> There is a fundamental difference:
> OLRs need to be stored, Feature-Vectors not.
> =20
> How come feature vector does not need to be stored? I do not
> get that? I would set my implementation to a specific state
> or mode based on the feature vector. When that changes I'd
> like to know that. And then keep functioning based on that.
> =20
> - Jouni
> =20
> When receiving an OLR you may want to know whether its worth the effort t=
o replace an already stored OLR with the received OLR.
> When receiving a Feature-Vector you just act on it.
> =20
> Ulrich=20
> =20
> -----Original Message-----
> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
> Sent: Monday, December 09, 2013 1:55 PM
> To: Wiehe, Ulrich (NSN - DE/Munich)
> Cc: dime@ietf.org
> Subject: Re: [Dime] OVLI: comments to 4.1
> =20
> =20
> In the same vein as folks wanted send OLRs with the new or old informatio=
n,
> the feature vector should behave in a same way IMHO. That implies there a=
re
> situations when a reception of the feature vector does not change anythin=
g
> in an endpoint current behavior.
> =20
> - Jouni
> =20
> On Dec 9, 2013, at 2:47 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:
> =20
> Isn't it so that the Feature-Vector (if present) always contains somethin=
g that an implementation needs to act upon?
> =20
> Ulrich
> =20
> -----Original Message-----
> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
> Sent: Monday, December 09, 2013 1:12 PM
> To: Wiehe, Ulrich (NSN - DE/Munich)
> Cc: dime@ietf.org
> Subject: Re: [Dime] OVLI: comments to 4.1
> =20
> Ulrich,
> =20
> On Dec 6, 2013, at 3:03 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:
> =20
> Hi Jouni,
> =20
> thank you for your response.
> =20
> With regard to 3)=20
> I still fail to see the usecase for Sequence-Number or TimeStamp within O=
C-Feature-Vector. Please clarify.
> =20
> Since we also allow extending the OC-Feature-Vector beyond recognition,=20
> it has good chances become a rather complex grouped AVP. In that context
> the Sequence-Number allows an easy and quick way to check if the feature
> vector contains something that an implementation needs to act upon.
> =20
> With regard to 4)
> This was not obvious to me. (The obvious typo is the missing "of" between=
 "one" and "the").
> =20
> Ack. Fixed the missing 'of'.
> =20
> - Jouni
> =20
> =20
> Best regards
> Ulrich
> =20
> =20
> -----Original Message-----
> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
> Sent: Friday, December 06, 2013 11:17 AM
> To: Wiehe, Ulrich (NSN - DE/Munich)
> Cc: dime@ietf.org
> Subject: Re: [Dime] OVLI: comments to 4.1
> =20
> =20
> On Dec 5, 2013, at 3:23 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:
> =20
> Dear all,
> =20
> here are comments to clause 4.1:
> =20
> 1. The OC-Feature-Vector AVP is no longer a vector; the name of the AVP m=
ay be misleading. Proposal is to rename it to "OC-Supported-Features AVP"
> =20
> OK with me.
> =20
> 2. The OC-Feature AVP is a vector of features. Proposal is to rename it t=
o "OC-Feature-Vector AVP"
> =20
> OK with me.
> =20
> 3. The OC-Sequence-Number within OC-Feature-Vector only makes sense if th=
e receiving reporting endpoint can determine the identity of the reacting e=
ndpoint (which is not necessarily the origin host (client),
> =20
> My original proposal was to have seqnr as a timestamp. Some folks argued
> it is no good and suggested seqnr. I still think time makes more sense th=
an
> seqnr.
> =20
> it may be an agent and it may not always be the same agent), and if the r=
eporting endpoint is required to store the OC-Feature-Vector / reacting-end=
point-identity pair (which I think both is not required). The reporting end=
point can base its processing logic on the actually received OC-Feature-Vec=
tor value, no matter whether it is brand-new or old but stil valid. Proposa=
l is to delete OC-Sequence-Number AVP from OC-Feature-Vector.
> =20
> Do not agree removing it.
> =20
> 4. The text
> =20
> The reporting node that sends the answer also includes the OC-
> Feature-Vector AVP that describe the capabilities it supports.  The
> set of capabilities advertised by the reporting node depends on local
> policies.  At least one the announced capabilities MUST match
> mutually.  If there is no single matching capability the reacting
> node MUST act as if it does not implement DOIC and cease inserting
> any DOIC related AVPs into any Diameter messages with this specific
> reacting node.
> =20
> is not clear.  Would the reporting node include the OC-Feature-Vector AVP=
 in the answer only if there is at least one matching capability?=20
> =20
> Because then they have found a way to exchange something that both ends
> know how to handle it.
> =20
> Mandating the reacting node to cease for all time inserting OC-Feature-Ve=
ctor AVPs if it did not get back=20
> =20
> There is an obvious typo. It should say:
> =20
> policies.  At least one the announced capabilities MUST match
> mutually.  If there is no single matching capability the reporting
> node MUST act as if it does not implement DOIC and cease inserting
> any DOIC related AVPs into any Diameter messages with this specific
> reacting node.
> =20
> - JOuni
> =20
> =20
> at least one match is also not ok. The request might have been a realm-ty=
pe request (i.e. without Destination Host) and the reacting node cannot con=
trol whether subsequent requests will take the same path to the same report=
ing node.
> Even if the request contains a destination host the reacting node cannot =
know wether the reacting node's capabilities have been modified by the time=
 a subsequent request is sent.=20
> Proposal is to keep only the first sentence and delete the rest.
> =20
> Ulrich
> =20
> =20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
> =20
> =20
> =20
> =20
> =20
> =20
> =20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
> =20
> =20
> =20
> =20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From srdonovan@usdonovans.com  Mon Dec 16 04:16:59 2013
Return-Path: 
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 DB92F1AE2F9 for ; Mon, 16 Dec 2013 04:16:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.58
X-Spam-Level: *
X-Spam-Status: No, score=1.58 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no
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 jN7K5-B_7hC0 for ; Mon, 16 Dec 2013 04:16:52 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id D935D1AE2F7 for ; Mon, 16 Dec 2013 04:16:49 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:61897 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1VsX6F-0004pr-Up; Mon, 16 Dec 2013 04:16:48 -0800
Message-ID: <52AEEF27.50208@usdonovans.com>
Date: Mon, 16 Dec 2013 06:16:39 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: "Nirav Salot (nsalot)" ,  Jouni Korhonen 
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DB1B@DEMUMBX014.nsn-intra.net>  <52A5E902.20605@usdonovans.com> <7475B713-1104-4791-96B1-CE97632A0D69@nostrum.com>  <5BCBA1FC2B7F0B4C9D935572D90006681519E476@DEMUMBX014.nsn-intra.net> <1CD20507-B0FE-4367-804A-B831734CF060@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E6DC@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D90006681519E712@DEMUMBX014.nsn-intra.net> <4A151D70-0291-4238-85B1-03BB54B361E6@gmail.com> <52A864FF.10705@usdonovans.com>   <52A9C62A.6010207@usdonovans.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------090508020502050908070007"
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com
Cc: Ben Campbell , "dime@ietf.org list" 
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Dec 2013 12:16:59 -0000

This is a multi-part message in MIME format.
--------------090508020502050908070007
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Nirav,

The issue with considering only the last report is that it introduces
the potential for thrashing between different values.  This could make
the overload event even worse.

I agree that this should be a rare case.  I still think, however, that
we need to have defined behavior.

One other argument for including the sender of the overload report in
the report itself is security.  The ability of a bad actor to insert a
malicious overload report can be a very effective DOS attack.  I know we
have said we aren't addressing security yet but this seems pretty short
sighted.  Being able to establish that the identity of the sender of an
overload report will be an important part of the security solution.  We
should take this step in that direction.

Steve

On 12/12/13 10:26 AM, Nirav Salot (nsalot) wrote:
>
> Steve,
>
>  
>
> So as I understand it is not a common case for different agent to
> provide different view of the same realm and this may have happen
> during a small window when synchronization has not taken place between
> the geographically distributed agents.
>
> Right?
>
>  
>
> If so, I can understand the following part of your proposal.
>
> One proposal for how we deal with the fact that different reports can
> have different values is to have the reacting node treat the first
> reporting node as the authority for reporting realm overload state for
> that overload instance.
>
>  
>
> i.e. I can understand to define some behavior for the reacting node to
> handle the case (which is anyway rare case) when two agents provide
> different realm-report for the same report.
>
> The behavior could be simply to consider only the last report when two
> agents have sent two different reports of the same realm. (And this
> will also work when the same agent has sent two different
> realm-reports, purposefully -- e.g. due to the change in the realm
> overload).
>
> But this still does not require adding of agent's identity in the
> overload-report.
>
>  
>
> Regards,
>
> Nirav.
>
>  
>
> *From:*Steve Donovan [mailto:srdonovan@usdonovans.com]
> *Sent:* Thursday, December 12, 2013 7:50 PM
> *To:* Nirav Salot (nsalot); Jouni Korhonen
> *Cc:* Ben Campbell; dime@ietf.org list
> *Subject:* Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI:
> comments to 4.3
>
>  
>
> Nirav,
>
> See inline.
>
> Steve
>
> On 12/12/13 6:40 AM, Nirav Salot (nsalot) wrote:
>
>     All,
>
>      
>
>     I do not understand this discussion regarding different agents of the same realm having different view of the realm and provide different overload report.
>
> We can make the statement that all senders of realm reports should
> send the same report.  This does not guarantee that it will always
> happen.  If agents are sending the report, they are generally
> distributed elements.  In very large networks, this distribution can
> span continents.  There will be a lag in the "synchronization" of the
> realm overload information.
>
> My concern is that we have well defined behavior for when a reactor
> receives conflicting realm reports.  We need to avoid thrashing
> between different reduction levels, which could make the overload
> situation worse.
>
>  
> Additionally, I also do not understand the proposal of adding identity of the agent generating "realm report" into the report.
>
> Adding the endpoint identity is needed to allow the reacting node to
> know that it is receiving two different views of Realm overload from
> two different reporting end-points.
>
>  
> What is the use of this identity at the reacting node when the report is realm report? Why should the reacting node care who generated the realm report?
>
> One proposal for how we deal with the fact that different reports can
> have different values is to have the reacting node treat the first
> reporting node as the authority for reporting realm overload state for
> that overload instance.  In this case, the reacting node would ignore
> reports received from other reporting nodes. In order to ignore
> reports from non authoritative endpoints requires the reacting node to
> know which endpoints send which reports.
>
>  
>  
> Regards,
> Nirav.
>  
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen
> Sent: Thursday, December 12, 2013 5:06 PM
> To: Steve Donovan
> Cc: Ben Campbell; dime@ietf.org  list
> Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3
>  
> Steve,
>  
> On Dec 11, 2013, at 3:13 PM, Steve Donovan   wrote:
>  
>
>     Jouni,
>
>      
>
>     We need the sequence number to be strictly increasing.  I don't see the need for it to increase in uniform amounts.  Using time does fit these requirements.  I'm ok with using time as long as we don't call the AVP timestamp.
>
>      
>
>     Ulrich does bring up an interesting use case, where a client is receiving realm reports for the same realm from different agents.  We need to define the clients behavior in this case.  
>
>  
> Any suggestions? I mean agents may have hugely different view of the realm if they are acting on their own.
>  
>
>     Presumably the client needs to be able to determine who generated the realm report.  This cannot be determine based on the content of the message or the connection on which the message arrived.  It seems like we might need "Report Generator Diameter ID" in the overload report specifically for Realm reports.  
>
>      
>
>     Once the client is able to differentiate between realm reports sent by different agents (or servers) we need logic defining how the client deals with a new overload report.  
>
>  
> I need now to check one of the basic assumptions on DOIC now so that we have the same understanding. I went back to the endpoint text in Section 5.1. There, for example in Figures
> 4 and 5 the DOIC association and the endpoint assumption does does not work IMHO because we have no endpoint identity in the OLR. In order the endpoint assumption to work (as I drew it on the white board in Porto), it would require as many Diameter level sessions as there are DOIC associations.
>  
> So.. has assumptions shifted in a meanwhile and I have just not paid attention?
>  
>
>     I see a couple of options (others will probably see options I am missing):
>
>      
>
>     - Use the last received realm report - This introduces the possibility of thrashing between two different reduction values and different durations.  Note that this approach does not require the source of the report to be included in the report.
>
>      
>
>     - Only listen to one source of realm overload - The approach would be to remember who sent the first overload report from the realm and ignore realm overload reports from other sources.  This behavior would likely be constrained to a single occurrence of realm overload.  Meaning that the "memory" of the report source would only last as long as that overload event persists.  Once the overload event goes away, the report source would be forgotten and a new source could be used for the next occurrence.
>
>      
>
>     On the surface, the second approach looks better to me.
>
>  
> Or add the identity of the OLR originator explicitly if it cannot be determined implicitly (i.e. from the Diameter message's Origin-Host/Realm).
>  
> Or assume the endpoint really is the endpoint in DOIC and Diameter session sense.
>  
> - Jouni
>  
>
>      
>
>     Steve
>
>      
>
>     On 12/11/13 2:15 AM, Jouni wrote:
>
>         Ulrich,
>
>          
>
>         I might be slow but.. Section 4.4 says
>
>          
>
>            control endpoints.  The sequence number is only required to be unique
>
>            between two overload control endpoints and does not need to be
>
>          
>
>         Unique between two endpoints..
>
>          
>
>         Section 5.1 talks about endpoints:
>
>          
>
>            of an arbitrary Diameter network.  The overload control information
>
>            is exchanged over on a "DOIC association" between two communication
>
>            endpoints.  The endpoints, namely the "reacting node" and the
>
>            "reporting node" do not need to be adjacent Diameter peer nodes, 
>
>         nor
>
>          
>
>         So if your agents inject realm reports, they need to be endpoints to 
>
>         the client. Similar to Figure 5. Therefore the sequence number spaces 
>
>         between
>
>         C-A1 and C-A2 are separate.
>
>          
>
>         Now it is not clear to me, whether in your reasoning the C would see 
>
>         the server identity (as the endpoint) when there is an active "DEP 
>
>         agent" on the path. That would not clearly work and not be align with 
>
>         the endpoint assumption.
>
>          
>
>         Note that at some point of time we had (at least on a discussion 
>
>         level in f2f meeting) report originator identity in the OLR. That 
>
>         would make endpoint identification trivial. Now a "DEP agent" needs 
>
>         to act as a "server" for its clients in order to appear as an endpoint.
>
>          
>
>         - Jouni
>
>          
>
>         ps: still think the use of Time is simpler..
>
>          
>
>          
>
>         On Dec 11, 2013, at 9:43 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
>          
>
>          
>
>             That's not predictable. It may be the same server in some cases, and different servers in other cases.
>
>              
>
>             -----Original Message-----
>
>             From: ext Jouni [
>
>             mailto:jouni.nospam@gmail.com
>
>             ]
>
>             Sent: Wednesday, December 11, 2013 8:38 AM
>
>             To: Wiehe, Ulrich (NSN - DE/Munich)
>
>             Cc: Ben Campbell;
>
>             dime@ietf.org 
>
>              list; Steve Donovan
>
>             Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: 
>
>             comments to 4.3
>
>              
>
>              
>
>             Ulrich,
>
>              
>
>             On Dec 11, 2013, at 9:21 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
>              
>
>              
>
>                 Jouni,
>
>                  
>
>                 ad 1. "monotonically" does not express your intention. What we are looking for may be "stepwise with fixed step".
>
>                  
>
>                 Ad 2. Is not necessarily a mistake that could result in out-of-sequence sequence numbers. When a client C sends a realm-type requests towards any server in the realm, an agent A1 that selects the server would send back the realm-type OLR with sequence number s1. The next realm-type request sent by C (that survived the throttling) may take a path that does not include A1 but A2. A2 then selects the server and sends back a sequence number s2. Nothing ensures that s1 and s2 are in sequence.
>
>                  
>
>             Would the server in both cases (via A1 and A2) be the same?
>
>              
>
>             - Jouni
>
>              
>
>              
>
>              
>
>                 Ulrich
>
>                  
>
>                  
>
>                 -----Original Message-----
>
>                 From: ext Jouni Korhonen [
>
>                 mailto:jouni.nospam@gmail.com
>
>                 ]
>
>                 Sent: Tuesday, December 10, 2013 10:31 PM
>
>                 To: Wiehe, Ulrich (NSN - DE/Munich)
>
>                 Cc: Ben Campbell;
>
>                 dime@ietf.org 
>
>                  list; Steve Donovan
>
>                 Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: 
>
>                 comments to 4.3
>
>                  
>
>                 Ulrich,
>
>                  
>
>                 On Dec 10, 2013, at 4:31 PM, "Wiehe, Ulrich (NSN - DE/Munich)" 
>
>                  
>
>                  wrote:
>
>                  
>
>                  
>
>                     Jouni,
>
>                      
>
>                     1. I find the texts
>
>                     a) "The sequence number ... does not need to be monotonically increasing"
>
>                     and
>
>                      
>
>                 Means the delta from old-seqno to new-seqno can be any non-negative 
>
>                 integer (within the given limits) not something fixed step/delta 
>
>                 (like +1). As long as "new-seqno >= old-seqno" holds we are fine.
>
>                  
>
>                  
>
>                     b) "...the new sequence number MUST be greater or equal than the old sequence number..."
>
>                     contradicting.
>
>                     Can you please clarify.
>
>                      
>
>                 See above. (mind the overflow case)
>
>                  
>
>                  
>
>                     2. The expected behaviour when receiving an out-of-sequence sequence number within OC-OLR is described in 4.3:
>
>                     "The receiver SHOULD discard an OC-OLR AVP with a sequence number that is less than previously received one."
>
>                     I don't find this very robust. Once a higher sequence number (received erroneously by mistake) is accepted you cannot (easily) recover.
>
>                      
>
>                 I find it more robust in a sense that I should not care about stale old information.
>
>                 However, since we are piggybacking (by popular demand) we have 
>
>                 little room for seqno re-sync negotiation.
>
>                  
>
>                 What is the mistake you refer here? A misbehaving implementation? 
>
>                 In that case, it deserves to get a manual intervention once figured 
>
>                 out by admins checking alarms and logs. If the mistake is due other 
>
>                 things, like endpoints being out of sync, we currently have no written down mechanism to survive that.
>
>                  
>
>                  
>
>                     3. The expected behaviour when receiving an out-of-sequence sequence number within the OC-Supported-Features AVP is not described. What is the intention here?
>
>                      
>
>                 No intention. Just a sloppy specification. You are right that 
>
>                 something needs to be done & clarified here. (again the semantics 
>
>                 of Time would nice..)
>
>                  
>
>                 I'll propose something. Others should too ;)
>
>                  
>
>                 - Jouni
>
>                  
>
>                  
>
>                     Ulrich
>
>                      
>
>                     -----Original Message-----
>
>                     From: DiME [
>
>                     mailto:dime-bounces@ietf.org
>
>                     ] On Behalf Of ext Jouni Korhonen
>
>                     Sent: Tuesday, December 10, 2013 8:28 AM
>
>                     To: Ben Campbell;
>
>                     dime@ietf.org 
>
>                      list; Steve Donovan
>
>                     Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: 
>
>                     OVLI: comments to 4.3
>
>                      
>
>                      
>
>                     Fine.. lets define then the sequence number semantics. Basic 
>
>                     unsigned integer math. The text proposal is the following:
>
>                      
>
>                     4.4.  OC-Sequence-Number AVP
>
>                      
>
>                     The OC-Sequence-Number AVP (AVP code TBD3) is type of Unsigned64.
>
>                     Its usage in the context of the overload control is described in 
>
>                     Sections 4.1 and 4.3.
>
>                      
>
>                     From the functionality point of view, the OC-Sequence-Number AVP 
>
>                     MUST be used as a non-volatile increasing counter between two 
>
>                     overload control endpoints.  The sequence number is only required 
>
>                     to be unique between two overload control endpoints and does not 
>
>                     need to be monotonically increasing.
>
>                      
>
>                     When comparing two sequence numbers, the new sequence number MUST 
>
>                     be greater or equal than the old sequence number within a window 
>
>                     that is half of the size of the maximum sequence number. This 
>
>                     allows a simple handling of the sequence number overflow using 
>
>                     unsigned integer arithmeticf:
>
>                      
>
>                       #define WINDOW 0x8000000000000000ULL
>
>                      
>
>                       bool verify_seqnum( uint64_t newsn, uint64_t oldsn ) {
>
>                           if (newsn - oldsn <= WINDOW)
>
>                               // newsn >= oldsn
>
>                               return true;   
>
>                           } else
>
>                               // outside window or newsn < oldsn
>
>                               return false;  
>
>                           }
>
>                       }
>
>                      
>
>                      
>
>                      
>
>                     The above should even work is someone shovels NTP times into 
>
>                     sequence numbers with a blind typecasting.
>
>                      
>
>                     - Jouni
>
>                      
>
>                     On Dec 10, 2013, at 12:34 AM, Ben Campbell  
>
>                      wrote:
>
>                      
>
>                      
>
>                         On Dec 9, 2013, at 10:00 AM, Steve Donovan  
>
>                          wrote:
>
>                          
>
>                          
>
>                             Jouni,
>
>                              
>
>                             I propose that we keep the name OC-Sequence-Number but that we use the Time type for OC-Sequence-Number.  It is misleading and potentially confusing to call it OC-Time-Stamp.  
>
>                              
>
>                              
>
>                         I could live with that, although I would rather just define the expected properties of the sequence number, and leave the implementation up to the implementor. I assume your reasoning for not calling it a timestamp is that you do not want people to try to use it as a time base reference. If so, then we don't require any connection to a clock. We just need it to be monotonically increasing.
>
>                          
>
>                          
>
>                             We might consider expanding on the format of the AVP to make it something like Session-ID, where it is a concatenation of the Diameter-ID of the generating node and a timestamp.  This might help the reacting node keep track of which sequence number it has received.
>
>                              
>
>                              
>
>                         Do we need a uniqueness across multiple nodes property? If so, why?
>
>                          
>
>                          
>
>                             Steve
>
>                              
>
>                             On 12/9/13 5:37 AM, Jouni Korhonen wrote:
>
>                              
>
>                                 Folks
>
>                                  
>
>                                 Could we conclude on the sequence number vs. time stamp vs. something else?
>
>                                 We got more important places to spend our energy than this ;)
>
>                                  
>
>                                 My proposal is the following (based on the original pre-00 design):
>
>                                  
>
>                                 o We change the OC-Sequence-Number to OC-Time-Stamp in all occurrences
>
>                                 in the -01.
>
>                                 o We use RFC6733 Time type for the OC-Time-Stamp. RFC6733 gives us
>
>                                 already exact definition how to handle the AVP.
>
>                                 o Define that the OC-Time-Stamp is the time of the creation of the 
>
>                                 "original" AVP within whose context the time stamp is present.
>
>                                 o The OC-Time-Stamp AVP uniqueness is still considered to be in scope
>
>                                 of the communicating endpoints.
>
>                                 o The time stamp can be used to quickly determine if the content of
>
>                                 the encapsulating AVP context has changed (among other properties).
>
>                                 This would be useful specifically in the future when the encapsulating
>
>                                 grouped AVPs  grow in size and functionality.
>
>                                  
>
>                                  
>
>                                 - Jouni
>
>                                  
>
>                                 _______________________________________________
>
>                                 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
>
>          
>
>      
>
>  
> _______________________________________________
> DiME mailing list
> DiME@ietf.org 
> https://www.ietf.org/mailman/listinfo/dime
>  
>
>  
>


--------------090508020502050908070007
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Nirav,

      

      The issue with considering only the last report is that it
      introduces the potential for thrashing between different values. 
      This could make the overload event even worse.

      

      I agree that this should be a rare case.  I still think, however,
      that we need to have defined behavior.

      

      One other argument for including the sender of the overload report
      in the report itself is security.  The ability of a bad actor to
      insert a malicious overload report can be a very effective DOS
      attack.  I know we have said we aren't addressing security yet but
      this seems pretty short sighted.  Being able to establish that the
      identity of the sender of an overload report will be an important
      part of the security solution.  We should take this step in that
      direction.

      

      Steve

      

    
    
On 12/12/13 10:26 AM, Nirav Salot
      (nsalot) wrote:

    

    

      
      
      
      

        
Steve,

        
 

        
So
            as I understand it is not a common case for different agent
            to provide different view of the same realm and this may
            have happen during a small window when synchronization has
            not taken place between the geographically distributed
            agents.

        
Right?

        
 

        
If
            so, I can understand the following part of your proposal.

        
One proposal for how we deal with the fact
          that different reports can have different values is to have
          the reacting node treat the first reporting node as the
          authority for reporting realm overload state for that overload
          instance.

        
 

        
i.e.
            I can understand to define some behavior for the reacting
            node to handle the case (which is anyway rare case) when two
            agents provide different realm-report for the same report.

        
The
            behavior could be simply to consider only the last report
            when two agents have sent two different reports of the same
            realm. (And this will also work when the same agent has sent
            two different realm-reports, purposefully – e.g. due to the
            change in the realm overload).

        
But
            this still does not require adding of agent's identity in
            the overload-report.

        
 

        
Regards,

        
Nirav.

        
 

        

          

            
From:
                Steve Donovan [mailto:srdonovan@usdonovans.com]
                

                Sent: Thursday, December 12, 2013 7:50 PM

                To: Nirav Salot (nsalot); Jouni Korhonen

                Cc: Ben Campbell; dime@ietf.org list

                Subject: Re: [Dime] Conclusion for Sequence
                Numbers - was Re: OVLI: comments to 4.3

          

        

        
 

        
Nirav,

          

          See inline.

          

          Steve

        

          
On 12/12/13 6:40 AM, Nirav Salot (nsalot)
            wrote:

        

        

          
All,

          
 

          
I do not understand this discussion regarding different agents of the same realm having different view of the realm and provide different overload report.

        

        
We can make the statement that all senders
          of realm reports should send the same report.  This does not
          guarantee that it will always happen.  If agents are sending
          the report, they are generally distributed elements.  In very
          large networks, this distribution can span continents.  There
          will be a lag in the "synchronization" of the realm overload
          information.

          

          My concern is that we have well defined behavior for when a
          reactor receives conflicting realm reports.  We need to avoid
          thrashing between different reduction levels, which could make
          the overload situation worse.

          

          

        
 

        
Additionally, I also do not understand the proposal of adding identity of the agent generating "realm report" into the report.

        
Adding the endpoint identity is needed to
          allow the reacting node to know that it is receiving two
          different views of Realm overload from two different reporting
          end-points.

          

          

        
 

        
What is the use of this identity at the reacting node when the report is realm report? Why should the reacting node care who generated the realm report?

        
One proposal for how we deal with the fact
          that different reports can have different values is to have
          the reacting node treat the first reporting node as the
          authority for reporting realm overload state for that overload
          instance.  In this case, the reacting node would ignore
          reports received from other reporting nodes. In order to
          ignore reports from non authoritative endpoints requires the
          reacting node to know which endpoints send which reports.

          

          

        
 

        
 

        
Regards,

        
Nirav.

        
 

        
-----Original Message-----

        
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen

        
Sent: Thursday, December 12, 2013 5:06 PM

        
To: Steve Donovan

        
Cc: Ben Campbell; dime@ietf.org list

        
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3

        
 

        
Steve,

        
 

        
On Dec 11, 2013, at 3:13 PM, Steve Donovan <srdonovan@usdonovans.com> wrote:

        
 

        

          
Jouni,

          
 

          
We need the sequence number to be strictly increasing.  I don't see the need for it to increase in uniform amounts.  Using time does fit these requirements.  I'm ok with using time as long as we don't call the AVP timestamp.

          
 

          
Ulrich does bring up an interesting use case, where a client is receiving realm reports for the same realm from different agents.  We need to define the clients behavior in this case.  

        

        
 

        
Any suggestions? I mean agents may have hugely different view of the realm if they are acting on their own.

        
 

        

          
Presumably the client needs to be able to determine who generated the realm report.  This cannot be determine based on the content of the message or the connection on which the message arrived.  It seems like we might need "Report Generator Diameter ID" in the overload report specifically for Realm reports.  

          
 

          
Once the client is able to differentiate between realm reports sent by different agents (or servers) we need logic defining how the client deals with a new overload report.  

        

        
 

        
I need now to check one of the basic assumptions on DOIC now so that we have the same understanding. I went back to the endpoint text in Section 5.1. There, for example in Figures

        
4 and 5 the DOIC association and the endpoint assumption does does not work IMHO because we have no endpoint identity in the OLR. In order the endpoint assumption to work (as I drew it on the white board in Porto), it would require as many Diameter level sessions as there are DOIC associations.

        
 

        
So.. has assumptions shifted in a meanwhile and I have just not paid attention?

        
 

        

          
I see a couple of options (others will probably see options I am missing):

          
 

          
- Use the last received realm report - This introduces the possibility of thrashing between two different reduction values and different durations.  Note that this approach does not require the source of the report to be included in the report.

          
 

          
- Only listen to one source of realm overload - The approach would be to remember who sent the first overload report from the realm and ignore realm overload reports from other sources.  This behavior would likely be constrained to a single occurrence of realm overload.  Meaning that the "memory" of the report source would only last as long as that overload event persists.  Once the overload event goes away, the report source would be forgotten and a new source could be used for the next occurrence.

          
 

          
On the surface, the second approach looks better to me.

        

        
 

        
Or add the identity of the OLR originator explicitly if it cannot be determined implicitly (i.e. from the Diameter message's Origin-Host/Realm).

        
 

        
Or assume the endpoint really is the endpoint in DOIC and Diameter session sense.

        
 

        
- Jouni

        
 

        

          
 

          
Steve

          
 

          
On 12/11/13 2:15 AM, Jouni wrote:

          

            
Ulrich,

            
 

            
I might be slow but.. Section 4.4 says

            
 

            
   control endpoints.  The sequence number is only required to be unique

            
   between two overload control endpoints and does not need to be

            
 

            
Unique between two endpoints..

            
 

            
Section 5.1 talks about endpoints:

            
 

            
   of an arbitrary Diameter network.  The overload control information

            
   is exchanged over on a "DOIC association" between two communication

            
   endpoints.  The endpoints, namely the "reacting node" and the

            
   "reporting node" do not need to be adjacent Diameter peer nodes, 

            
nor

            
 

            
So if your agents inject realm reports, they need to be endpoints to 

            
the client. Similar to Figure 5. Therefore the sequence number spaces 

            
between

            
C-A1 and C-A2 are separate.

            
 

            
Now it is not clear to me, whether in your reasoning the C would see 

            
the server identity (as the endpoint) when there is an active "DEP 

            
agent" on the path. That would not clearly work and not be align with 

            
the endpoint assumption.

            
 

            
Note that at some point of time we had (at least on a discussion 

            
level in f2f meeting) report originator identity in the OLR. That 

            
would make endpoint identification trivial. Now a "DEP agent" needs 

            
to act as a "server" for its clients in order to appear as an endpoint.

            
 

            
- Jouni

            
 

            
ps: still think the use of Time is simpler..

            
 

            
 

            
On Dec 11, 2013, at 9:43 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:

            
 

            
 

            

              
That's not predictable. It may be the same server in some cases, and different servers in other cases.

              
 

              
-----Original Message-----

              
From: ext Jouni [

              
mailto:jouni.nospam@gmail.com

              
]

              
Sent: Wednesday, December 11, 2013 8:38 AM

              
To: Wiehe, Ulrich (NSN - DE/Munich)

              
Cc: Ben Campbell;

              
dime@ietf.org

              
 list; Steve Donovan

              
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: 

              
comments to 4.3

              
 

              
 

              
Ulrich,

              
 

              
On Dec 11, 2013, at 9:21 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:

              
 

              
 

              

                
Jouni,

                
 

                
ad 1. "monotonically" does not express your intention. What we are looking for may be "stepwise with fixed step".

                
 

                
Ad 2. Is not necessarily a mistake that could result in out-of-sequence sequence numbers. When a client C sends a realm-type requests towards any server in the realm, an agent A1 that selects the server would send back the realm-type OLR with sequence number s1. The next realm-type request sent by C (that survived the throttling) may take a path that does not include A1 but A2. A2 then selects the server and sends back a sequence number s2. Nothing ensures that s1 and s2 are in sequence.

                
 

              

              
Would the server in both cases (via A1 and A2) be the same?

              
 

              
- Jouni

              
 

              
 

              
 

              

                
Ulrich

                
 

                
 

                
-----Original Message-----

                
From: ext Jouni Korhonen [

                
mailto:jouni.nospam@gmail.com

                
]

                
Sent: Tuesday, December 10, 2013 10:31 PM

                
To: Wiehe, Ulrich (NSN - DE/Munich)

                
Cc: Ben Campbell;

                
dime@ietf.org

                
 list; Steve Donovan

                
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: 

                
comments to 4.3

                
 

                
Ulrich,

                
 

                
On Dec 10, 2013, at 4:31 PM, "Wiehe, Ulrich (NSN - DE/Munich)" 

                
<ulrich.wiehe@nsn.com>

                
 wrote:

                
 

                
 

                

                  
Jouni,

                  
 

                  
1. I find the texts

                  
a) "The sequence number ... does not need to be monotonically increasing"

                  
and

                  
 

                

                
Means the delta from old-seqno to new-seqno can be any non-negative 

                
integer (within the given limits) not something fixed step/delta 

                
(like +1). As long as "new-seqno >= old-seqno" holds we are fine.

                
 

                
 

                

                  
b) "...the new sequence number MUST be greater or equal than the old sequence number..."

                  
contradicting.

                  
Can you please clarify.

                  
 

                

                
See above. (mind the overflow case)

                
 

                
 

                

                  
2. The expected behaviour when receiving an out-of-sequence sequence number within OC-OLR is described in 4.3:

                  
"The receiver SHOULD discard an OC-OLR AVP with a sequence number that is less than previously received one."

                  
I don't find this very robust. Once a higher sequence number (received erroneously by mistake) is accepted you cannot (easily) recover.

                  
 

                

                
I find it more robust in a sense that I should not care about stale old information.

                
However, since we are piggybacking (by popular demand) we have 

                
little room for seqno re-sync negotiation.

                
 

                
What is the mistake you refer here? A misbehaving implementation? 

                
In that case, it deserves to get a manual intervention once figured 

                
out by admins checking alarms and logs. If the mistake is due other 

                
things, like endpoints being out of sync, we currently have no written down mechanism to survive that.

                
 

                
 

                

                  
3. The expected behaviour when receiving an out-of-sequence sequence number within the OC-Supported-Features AVP is not described. What is the intention here?

                  
 

                

                
No intention. Just a sloppy specification. You are right that 

                
something needs to be done & clarified here. (again the semantics 

                
of Time would nice..)

                
 

                
I'll propose something. Others should too ;)

                
 

                
- Jouni

                
 

                
 

                

                  
Ulrich

                  
 

                  
-----Original Message-----

                  
From: DiME [

                  
mailto:dime-bounces@ietf.org

                  
] On Behalf Of ext Jouni Korhonen

                  
Sent: Tuesday, December 10, 2013 8:28 AM

                  
To: Ben Campbell;

                  
dime@ietf.org

                  
 list; Steve Donovan

                  
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: 

                  
OVLI: comments to 4.3

                  
 

                  
 

                  
Fine.. lets define then the sequence number semantics. Basic 

                  
unsigned integer math. The text proposal is the following:

                  
 

                  
4.4.  OC-Sequence-Number AVP

                  
 

                  
The OC-Sequence-Number AVP (AVP code TBD3) is type of Unsigned64.

                  
Its usage in the context of the overload control is described in 

                  
Sections 4.1 and 4.3.

                  
 

                  
From the functionality point of view, the OC-Sequence-Number AVP 

                  
MUST be used as a non-volatile increasing counter between two 

                  
overload control endpoints.  The sequence number is only required 

                  
to be unique between two overload control endpoints and does not 

                  
need to be monotonically increasing.

                  
 

                  
When comparing two sequence numbers, the new sequence number MUST 

                  
be greater or equal than the old sequence number within a window 

                  
that is half of the size of the maximum sequence number. This 

                  
allows a simple handling of the sequence number overflow using 

                  
unsigned integer arithmeticf:

                  
 

                  
  #define WINDOW 0x8000000000000000ULL

                  
 

                  
  bool verify_seqnum( uint64_t newsn, uint64_t oldsn ) {

                  
      if (newsn - oldsn <= WINDOW)

                  
          // newsn >= oldsn

                  
          return true;   

                  
      } else

                  
          // outside window or newsn < oldsn

                  
          return false;  

                  
      }

                  
  }

                  
 

                  
 

                  
 

                  
The above should even work is someone shovels NTP times into 

                  
sequence numbers with a blind typecasting.

                  
 

                  
- Jouni

                  
 

                  
On Dec 10, 2013, at 12:34 AM, Ben Campbell <ben@nostrum.com>

                  
 wrote:

                  
 

                  
 

                  

                    
On Dec 9, 2013, at 10:00 AM, Steve Donovan <srdonovan@usdonovans.com>

                    
 wrote:

                    
 

                    
 

                    

                      
Jouni,

                      
 

                      
I propose that we keep the name OC-Sequence-Number but that we use the Time type for OC-Sequence-Number.  It is misleading and potentially confusing to call it OC-Time-Stamp.  

                      
 

                      
 

                    

                    
I could live with that, although I would rather just define the expected properties of the sequence number, and leave the implementation up to the implementor. I assume your reasoning for not calling it a timestamp is that you do not want people to try to use it as a time base reference. If so, then we don't require any connection to a clock. We just need it to be monotonically increasing.

                    
 

                    
 

                    

                      
We might consider expanding on the format of the AVP to make it something like Session-ID, where it is a concatenation of the Diameter-ID of the generating node and a timestamp.  This might help the reacting node keep track of which sequence number it has received.

                      
 

                      
 

                    

                    
Do we need a uniqueness across multiple nodes property? If so, why?

                    
 

                    
 

                    

                      
Steve

                      
 

                      
On 12/9/13 5:37 AM, Jouni Korhonen wrote:

                      
 

                      

                        
Folks

                        
 

                        
Could we conclude on the sequence number vs. time stamp vs. something else?

                        
We got more important places to spend our energy than this ;)

                        
 

                        
My proposal is the following (based on the original pre-00 design):

                        
 

                        
o We change the OC-Sequence-Number to OC-Time-Stamp in all occurrences

                        
in the -01.

                        
o We use RFC6733 Time type for the OC-Time-Stamp. RFC6733 gives us

                        
already exact definition how to handle the AVP.

                        
o Define that the OC-Time-Stamp is the time of the creation of the 

                        
"original" AVP within whose context the time stamp is present.

                        
o The OC-Time-Stamp AVP uniqueness is still considered to be in scope

                        
of the communicating endpoints.

                        
o The time stamp can be used to quickly determine if the content of

                        
the encapsulating AVP context has changed (among other properties).

                        
This would be useful specifically in the future when the encapsulating

                        
grouped AVPs  grow in size and functionality.

                        
 

                        
 

                        
- Jouni

                        
 

                        
_______________________________________________

                        
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

                

              

            

            
 

          

          
 

        

        
 

        
_______________________________________________

        
DiME mailing list

        
DiME@ietf.org

        
https://www.ietf.org/mailman/listinfo/dime

        
 

        
 

      

    

    

  


--------------090508020502050908070007--

From jouni.nospam@gmail.com  Mon Dec 16 04:49:46 2013
Return-Path: 
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 1ED0C1AE306 for ; Mon, 16 Dec 2013 04:49:46 -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 bDyVxlKh80r6 for ; Mon, 16 Dec 2013 04:49:41 -0800 (PST)
Received: from mail-bk0-x232.google.com (mail-bk0-x232.google.com [IPv6:2a00:1450:4008:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 9F4DA1AE2FC for ; Mon, 16 Dec 2013 04:49:40 -0800 (PST)
Received: by mail-bk0-f50.google.com with SMTP id e11so2270344bkh.23 for ; Mon, 16 Dec 2013 04:49:39 -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=JB4urTBXNQ7MlWTJcDBjHo5sJvorkEwwgDWXUXiVN1U=; b=mycFHgH8UhsvBhipFVJjquTBUxPzdpjgn9w76bV6py+oGQFRPIOANFBS/D3lApxciV fHq9hBVFVbUIC4ZvjNKYzednkNvQTjeKDAn3IOvWJv7bLMCdqabV1akjlR4Kp8p4kOZ3 0YsCI5YwwsrpLAPoU4QRaU3L6rRh+Qm3aeejVGIu3HX/B0Kun/dgUPeceWG0u/5kwYIi 8dt6KulhiDkY/5TZFkjsXoHw9XMIRLBN2kni0pdaCh38lbwNVpuSw8Nm9l8R/ulso4w+ ooG7FxYMw8F0ERdmHldELDZtKlRqOpiBHB2Oe8fe8D+Ej1Bhh7/FwXtLgLCOPN0Fl28u EeKQ==
X-Received: by 10.204.164.145 with SMTP id e17mr343594bky.136.1387198179326; Mon, 16 Dec 2013 04:49:39 -0800 (PST)
Received: from ?IPv6:2001:6e8:480:60:64c0:5aab:1f68:f80c? ([2001:6e8:480:60:64c0:5aab:1f68:f80c]) by mx.google.com with ESMTPSA id dg4sm10489666bkc.10.2013.12.16.04.49.35 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 16 Dec 2013 04:49:35 -0800 (PST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jouni Korhonen 
In-Reply-To: 
Date: Mon, 16 Dec 2013 14:49:33 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
To: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
X-Mailer: Apple Mail (2.1510)
Cc: "dime@ietf.org" 
Subject: Re: [Dime] OC-Supported Feature AVP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Dec 2013 12:49:46 -0000

Hi,

On Dec 13, 2013, at 3:44 PM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" =
 wrote:

> Dear all
> =20
> When analysing the discussion of the sequence number in the =
OC-Supported-Features AVP , it has driven me to some other =
considerations regarding this  feature negotiation that I hereafter =
present:  it is a bit long but it raises  a certain number of questions  =
 and then we have to draw some conclusion  and adapt the text  of the =
draft if needed
> =20
> A)     Behaviours for sending the  OC-Supported-Features AVP
> Currently there is only one default algorithm. So the use of  =
OC-Supported-Features AVP containing the OC-Feature-Vector is  only to =
indicate the support of DOIC with the default algorithm, given that en =
entity not supporting DOIC will never sends the OC-Supported-Features =
AVP.
> =20
> This AVP in the future  will allow to add new feature/capabilities .
> =20
> This AVP is needed initially to advertise the mutual  capabilities =
between reacting and reporting node  and  when changes occur in the  =
supported  features (eg in general to add a new feature, but may be also =
to remove  one). A sequence number was introduced to manage these =
changes, but this introduction is still under discussion (cf Ulrich=92s =
mails questioning this point)
> =20
> Then there is the question about when the OC-Supported-Features AVP is =
sent.  The current draft  has related statements in 3.2 and 4.1  :
> The several hereafter possible  behaviors are compliant for me with =
3.2 and 4.1  statements (are you sharing this reading?), we have to see =
if the draft allows all of them or if additional rules must be  =
fulfilled:
> =20
> a)      The reacting node sends the OC-Supported-Features AVP in each =
request and the reporting node sends back its own OC-Supported-Features =
AVP in each answer.
> b)      The reacting nodes initially sends its  OC-Supported-Features =
AVP, but does not repeat it any more , until a change in the features to =
be advertised  happens or after a node restart
> c)       Something intermediate, so when there is a change as in b)  =
plus  a periodic advertisement of the supported features although =
unchanged

I would be strongly supporting a) type of behaviour specifically for =
Diameter applications that do not maintain state. b) or c) could work =
for applications that have a state on Diameter level.

>=20
> About a):
> Steve,  and I agree,   indicated that the features are quite stable =
over time, and modifications will appear when a new feature is deployed =
(OAM case); I think  it is also needed at restart. So there are very few =
events over the year where the advertisement is actually needed (have =
you others in mind?) . Now my questioning:   why to permanently do such =
an exchange in each request/answer?  I observe that this behavior  is =
used in 3GPP where supported features are advertised in each =
request/answer, so we can apply  the same principle, but I nevertheless =
raise the question.

Because for applications that do not maintain state you typically need =
to send everything to express your intentions properly. As said earlier =
for certain types of applications you can drop AVPs once your intentions =
regarding behaviour have been made clear.

>=20
> About the sequence number:
> o   the receiving node has to open the sequence number AVP and checks =
if it has changed, given the value will change only a few times a year.  =
A besides  question,  which value the seq number takes after a restart
> o   if we do not use the sequence number, the  receiving node has to =
open the OC-feature-Vector AVP and see if it has changed, so I do not =
see much difference with the above
> o   the sequence number has the property  to be equal  or to increase =
in order to detect an eventual  change of the order of the messages and =
avoid to come back to a previous value of the feature-vector. But =
further messages will all be with the new feature-vector, so the right =
result. I am not sure that the seq number bring a value for the =
transient period when the supported feature is  modified. So question: =
can we suppress the seq number in this a) behaviour?

IMHO the above is good reasoning/analysis why not use seqnum in =
OC-Supported-Features. My counter argument has been (and still is) =
whether we could have a situation where the OC-Feature-Vector remain =
unchanged but some additional AVPs related to the supported features =
would change? At the moment I do not have a valid use case in mind, =
specifically outside 3GPP context, but could those arise? In that case =
just looking into OC-Feature-Vector would not tell the difference but =
you would need to parse the whole OC-Supported-Features.

> In this a ) behaviour, if the OC-Supported-Features AVP is no more =
present in a message (and in later messages) ,  it would  be interpreted =
 that DOIC is no more supported . ( so different from the b) or c) case)
>   =20
> About b): this is the other extreme use case compared to a).
> Here in practice all the messages will not contain an  =
OC-Supported-Features AVP (except in the  rare cases of a change or =
after a restart), So the absence of this AVP in a message  does not mean =
that DOIC is not supported. Capability negotiation  happens once and =
remain valid until a change. At restart or when a change  a reacting =
node sends an OC-Supported-Features AVP in a request, and wait for an =
OC-Supported-Features AVP   in the answer; if nothing, it means the =
reporting node is not supporting DOIC. If the answer is lost the =
reacting node may repeat the request or use another one with its OC =
Supported-feature AVP.
> =20
> If the change occurs in the reporting node, it cannot wait for a =
request coming from the reacting node with an OC Supported-feature AVP,  =
(as it will  never come if no change at the reacting node side), so the =
reporting node should advertise the  OC Supported-feature AVP in answers =
(although the corresponding request do not contain this AVP).  I think =
this behavior is currently allowed by the draft text, do you agree?.   =
To secure a bit more, the reacting node may then  send a request with =
its own OC Supported-feature AVP, acting as an acknowledgement to the =
reporting node. The reporting node may repeat if needed  or to be more =
secure.
> There may be some corner cases to investigate more, but I currently =
stop here. =20
> =20
> In this use case, I do not see a need  for a sequence number .
>     =20
> Do you think such an approach is applicable? it will save many checks =
compared to a).
> =20
> About c): it is the same principle as in b) but with some periodic  =
=93refresh=94 that may make the a) approach  still more secure. But not =
sure  it is actually needed.
> =20
> So do you think the draft should  allow these different  behaviors  or =
only mandate one?
> Then do you think we need a sequence number for the =
OC-Supported-Features AVP?
> =20
> =20
> B)      Another point also related to the OC-Supported-Features AVP =
and OC-Feature-Vector:
> =20
> For example a node can use the default mechanism  and in addition =
support extensions (eg the APN or the session group examples). I would =
think extensions should be advertized by the reacting node , otherwise =
the server does not know if it can use an extension or not, and  a =
server should avoid  to send OLRs that the client will not understand .  =
 =20
>  So here we may have  a set of extensions compatible with the default =
mechanism
> =20
> The other example is =93exclusive=94 or not compatible features, for =
example Traffic reduction %control  and rate control. I do not consider  =
a reporting node  will  use both with a reacting node. A reacting node , =
even if it supports both does not want to mix  throttling based on % =
traffic and throttling on rate control with the same reporting node. But =
the current  text does not say anything about which feature is selected =
.
> I remember that in our initial discussions, the reacting node was =
advertising its features / capabilities and the reporting node was =
selecting the ones it wants to use. Should not we come back to this =
rule? or

I would love to come back to this rule where the reporting node picks up =
one common feature. Now the text just mandates that at least one feature =
must be common on both side (and be advertised by both). This does not =
preclude reporting node implementations to do the "select one common =
feature" though. They can advertise back only the one selected but they =
do not have to.. they can add more information on will. IMHO this =
complicates implementations. For example if both ends have three common =
(and advertised) features, the reacting node must be prepared to receive =
OLRs on any of those for the same reporting node in parallel (why would =
the reporting node do so, no idea, but it could based on the spec).

> do you consider that when we will introduce new features , we will =
introduce statements  to indicate rules on their presence in =
OC-Feature-Vector. Personnaly, I think  the advertisement  followed  by =
selection  was a good approach. Views on this?

Agree.

- Jouni

> =20
> I have  described this B part  here, as it may have some interaction =
with the  A part.
> =20
> Best regards
> =20
> JJacques
> =20
> =20
> =20
>     =20
> =20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From srdonovan@usdonovans.com  Mon Dec 16 04:59:55 2013
Return-Path: 
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 8F4511AE308 for ; Mon, 16 Dec 2013 04:59:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.12
X-Spam-Level: 
X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no
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 kabcJWseIJMB for ; Mon, 16 Dec 2013 04:59:52 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 29F791ADF9F for ; Mon, 16 Dec 2013 04:59:52 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:61939 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1VsXm1-0007Wv-GW for dime@ietf.org; Mon, 16 Dec 2013 04:59:51 -0800
Message-ID: <52AEF944.6030108@usdonovans.com>
Date: Mon, 16 Dec 2013 06:59:48 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: dime@ietf.org
References: 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------020608050401070706000604"
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com
Subject: Re: [Dime] OC-Supported Feature AVP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Dec 2013 12:59:55 -0000

This is a multi-part message in MIME format.
--------------020608050401070706000604
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

JJacques,

See my responses inline.

Regards,

Steve

On 12/13/13 7:44 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:
>
> Dear all
>
>  
>
> When analysing the discussion of the sequence number in the
> OC-Supported-Features AVP , it has driven me to some other
> considerations regarding this  feature negotiation that I hereafter
> present:  it is a bit long but it raises  a certain number of
> questions   and then we have to draw some conclusion  and adapt the
> text  of the draft if needed
>
>  
>
> A)     Behaviours for sending the  OC-Supported-Features AVP
>
> Currently there is only one default algorithm. So the use of
>  OC-Supported-Features AVP containing the OC-Feature-Vector is  only
> to indicate the support of DOIC with the default algorithm, given that
> en entity not supporting DOIC will never sends the
> OC-Supported-Features AVP.
>
SRD> OC-Supported-Features is also there for extensibility.  Once we
have rate defined then your statement no longer holds.
>
>  
>
> This AVP in the future  will allow to add new feature/capabilities .
>
>  
>
> This AVP is needed initially to advertise the mutual  capabilities
> between reacting and reporting node  and  when changes occur in the
>  supported  features (eg in general to add a new feature, but may be
> also to remove  one). A sequence number was introduced to manage these
> changes, but this introduction is still under discussion (cf Ulrich's
> mails questioning this point)
>
>  
>
> Then there is the question about when the OC-Supported-Features AVP is
> sent.  The current draft  has related statements in 3.2 and 4.1  :
>
> The several hereafter possible  behaviors are compliant for me with
> 3.2 and 4.1  statements (are you sharing this reading?), we have to
> see if the draft allows all of them or _if additional rules must be 
> fulfilled_:
>
>  
>
> a)      The reacting node sends the OC-Supported-Features AVP in each
> request and the reporting node sends back its own
> OC-Supported-Features AVP in each answer.
>
> b)      The reacting nodes initially sends its  OC-Supported-Features
> AVP, but does not repeat it any more , until a change in the features
> to be advertised  happens or after a node restart
>
> c)       Something intermediate, so when there is a change as in b)
>  plus  a periodic advertisement of the supported features although
> unchanged
>
SRD> I agree that a) does not need to be a MUST.  The requirement is
that the reacting node knows that all reporting nodes have received the
overload capabilities advertisement.  This is difficult in the presence
of agents when using piggybacking. 
>
>  
>
>  
>
> _About a):_
>
> Steve,  and I agree,   indicated that the features are quite stable
> over time, and modifications will appear when a new feature is
> deployed (OAM case); I think  it is also needed at restart.
>
SRD> Whether it needs a restart of a node is an implementation decision. 
>
> So there are very few events over the year where the advertisement is
> actually needed (have you others in mind?) .
>
SRD> There are two needs -- initial advertisment and change of capabilities.
>
> Now my questioning:   why to permanently do such an exchange in each
> request/answer?  I observe that this behavior  is used in 3GPP where
> supported features are advertised in each request/answer, so we can
> apply  the same principle, but I nevertheless raise the question.
>
SRD> I don't know the thought behind 3GPP feature advertisement.  My
reason for thinking it is needed every time is to address Diameter
networks with agents. 
>
>  
>
> About the sequence number:
>
> o   the receiving node has to open the sequence number AVP and checks
> if it has changed, given the value will change only a few times a
> year.  A besides  question,  which value the seq number takes after a
> restart
>
SRD> This needs to be specified.  If we have a time component of the
value then we can be sure that the value will have increased after
restart.  Having a new sequence number with the same report, as would
happen in this case, would not break anything.
>
> o   if we do not use the sequence number, the  receiving node has to
> open the OC-feature-Vector AVP and see if it has changed, so I do not
> see much difference with the above
>
SRD> If the OC-Feature-Vector is the only thing being advertised then
this might be true.  We have already talked about other parameters being
included as part of the advertisement.  This means that the
advertisement could become arbitrarily complex and parsing it every time
when it will change very infrequently will add real cost to the
reporting nodes.
>
> o   the sequence number has the property  to be equal  or to increase
> in order to detect an eventual  change of the order of the messages
> and avoid to come back to a previous value of the feature-vector. But
> further messages will all be with the new feature-vector, so the right
> result. I am not sure that the seq number bring a value for the
> transient period when the supported feature is  modified. So question:
> can we suppress the seq number in this a) behaviour?
>
SRD> No, for the reasons discussed.
>
> In this a ) behaviour, if the OC-Supported-Features AVP is no more
> present in a message (and in later messages) ,  it would  be
> interpreted  that DOIC is no more supported . ( so different from the
> b) or c) case)
>
>    
>
> _About b):_ this is the other extreme use case compared to a).
>
> Here in practice all the messages will not contain an
>  OC-Supported-Features AVP (except in the  rare cases of a change or
> after a restart), So the absence of this AVP in a message  does not
> mean that DOIC is not supported. Capability negotiation  happens once
> and remain valid until a change. At restart or when a change  a
> reacting node sends an OC-Supported-Features AVP in a request, and
> wait for an OC-Supported-Features AVP   in the answer; if nothing, it
> means the reporting node is not supporting DOIC. If the answer is lost
> the reacting node may repeat the request or use another one with its
> OC Supported-feature AVP.
>
SRD> How does a client (reacting node) know that all servers (reporting
nodes) have received the advertisement?
>
>  
>
> If the change occurs in the reporting node, it cannot wait for a
> request coming from the reacting node with an OC Supported-feature
> AVP,  (as it will  never come if no change at the reacting node side),
> so the reporting node should advertise the  OC Supported-feature AVP
> in answers (although the corresponding request do not contain this
> AVP).  I think this behavior is currently allowed by the draft text,
> do you agree?.   To secure a bit more, the reacting node may then
>  send a request with its own OC Supported-feature AVP, acting as an
> acknowledgement to the reporting node. The reporting node may repeat
> if needed  or to be more secure.
>
> There may be some corner cases to investigate more, but I currently
> stop here. 
>
SRD> This seems pretty complex.  Why not just assume a)?
>
>  
>
> In this use case, I do not see a need  for a sequence number .
>
SRD> The need for a sequence number does go away if we can insure a
single handshake between each reacting and reporting node.  We don't
have a mechanism insure this using the piggyback approach.
>
>      
>
> Do you think such an approach is applicable? it will save many checks
> compared to a).
>
>  
>
> _About c):_ it is the same principle as in b) but with some periodic
>  "refresh" that may make the a) approach  still more secure. But not
> sure  it is actually needed.
>
>  
>
> So do you think the draft should  allow these different  behaviors  or
> only mandate one?
>
> Then do you think we need a sequence number for the
> OC-Supported-Features AVP?
>
SRD> As stated above, I think the requirement is that the reacting nodes
MUST have a capability exchange with all reporting nodes.  To achieve
this the reacting node SHOULD send advertisements in all requests. 
>
>  
>
>  
>
> B)      Another point also related to the OC-Supported-Features AVP
> and OC-Feature-Vector:
>
>  
>
> For example a node can use the default mechanism  and in addition
> support extensions (eg the APN or the session group examples). I would
> think extensions should be advertized by the reacting node , otherwise
> the server does not know if it can use an extension or not, and  a
> server should avoid  to send OLRs that the client will not understand
> .    
>
>  So here we may have  a set of extensions compatible with the default
> mechanism
>
>  
>
> The other example is "exclusive" or not compatible features, for
> example Traffic reduction %control  and rate control. I do not
> consider  a reporting node  will  use both with a reacting node. A
> reacting node , even if it supports both does not want to mix
>  throttling based on % traffic and throttling on rate control with the
> same reporting node. But the current  text does not say anything about
> which feature is selected .
>
> I remember that in our initial discussions, the reacting node was
> advertising its features / capabilities and the reporting node was
> selecting the ones it wants to use. Should not we come back to this
> rule? or do you consider that when we will introduce new features , we
> will introduce statements  to indicate rules on their presence in
> OC-Feature-Vector. Personnaly, I think  the advertisement  followed
>  by selection  was a good approach. Views on this?
>
SRD> I think the interactions between features should be addressed in
the extension documents.
>
>  
>
> I have  described this B part  here, as it may have some interaction
> with the  A part.
>
>  
>
> Best regards
>
>  
>
> JJacques
>
>  
>
>  
>
>  
>
>      
>
>  
>
>
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


--------------020608050401070706000604
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    JJacques,

      

      See my responses inline.

      

      Regards,

      

      Steve

      

    
    
On 12/13/13 7:44 AM, TROTTIN,
      JEAN-JACQUES (JEAN-JACQUES) wrote:

    

    

      
      
      
      

        
Dear all 

        
 

        
When analysing the discussion of the
          sequence number in the OC-Supported-Features AVP , it has
          driven me to some other considerations regarding this  feature
          negotiation that I hereafter present:  it is a bit long but it
          raises  a certain number of questions   and then we have to
          draw some conclusion  and adapt the text  of the draft if
          needed
          

        
 

        

          A)    
            Behaviours for sending the
           OC-Supported-Features AVP

        
Currently
          there is only one default algorithm. So the use of
           OC-Supported-Features AVP containing the OC-Feature-Vector is
           only to indicate the support of DOIC with the default
          algorithm, given that en entity not supporting DOIC will never
          sends the OC-Supported-Features AVP. 

      

    

    SRD> OC-Supported-Features is also there for extensibility.  Once
    we have rate defined then your statement no longer holds.

    

      

        

        
 

        
This AVP in
          the future  will allow to add new feature/capabilities .
          

        
 

        
This AVP is
          needed initially to advertise the mutual  capabilities between
          reacting and reporting node  and  when changes occur in the
           supported  features (eg in general to add a new feature, but
          may be also to remove  one). A sequence number was introduced
          to manage these changes, but this introduction is still under
          discussion (cf Ulrich’s mails questioning this point)
          

        
 

        
Then there
          is the question about when the OC-Supported-Features AVP is
          sent.  The current draft  has related statements in 3.2 and
          4.1  :
          

        
The several
          hereafter possible  behaviors are compliant for me with 3.2
          and 4.1  statements (are you sharing this reading?), we have
          to see if the draft allows all of them or
          if additional rules must be  fulfilled:

        
 

        

          a)     
            The reacting node sends the
          OC-Supported-Features AVP in each request and the reporting
          node sends back its own OC-Supported-Features AVP in each
          answer.
          

        

          b)     
            The reacting nodes initially
          sends its  OC-Supported-Features AVP, but does not repeat it
          any more , until a change in the features to be advertised
           happens or after a node restart

        

          c)      
            Something intermediate, so when
          there is a change as in b)  plus  a periodic advertisement of
          the supported features although unchanged

      

    

    SRD> I agree that a) does not need to be a MUST.  The requirement
    is that the reacting node knows that all reporting nodes have
    received the overload capabilities advertisement.  This is difficult
    in the presence of agents when using piggybacking.  

    

      

        

        
 

        
 

        
About a):

        
Steve,  and
          I agree,   indicated that the features are quite stable over
          time, and modifications will appear when a new feature is
          deployed (OAM case); I think  it is also needed at restart. 

      

    

    SRD> Whether it needs a restart of a node is an implementation
    decision.  

    

      

        
So there are
          very few events over the year where the advertisement is
          actually needed (have you others in mind?) . 

      

    

    SRD> There are two needs -- initial advertisment and change of
    capabilities.

    

      

        
Now my
          questioning:   why to permanently do such an exchange in each
          request/answer?  I observe that this behavior  is used in 3GPP
          where supported features are advertised in each
          request/answer, so we can apply  the same principle, but I
          nevertheless raise the question.

      

    

    SRD> I don't know the thought behind 3GPP feature advertisement. 
    My reason for thinking it is needed every time is to address
    Diameter networks with agents.  

    

      

        

        
 

        
About the
          sequence number:

        

          o  
              the receiving node has
          to open the sequence number AVP and checks if it has changed,
          given the value will change only a few times a year.  A
          besides  question,  which value the seq number takes after a
          restart
        

      

    

    SRD> This needs to be specified.  If we have a time component of
    the value then we can be sure that the value will have increased
    after restart.  Having a new sequence number with the same report,
    as would happen in this case, would not break anything.

    

      

        

        

          o  
              if we do not use the
          sequence number, the  receiving node has to open the
          OC-feature-Vector AVP and see if it has changed, so I do not
          see much difference with the above
        

      

    

    SRD> If the OC-Feature-Vector is the only thing being advertised
    then this might be true.  We have already talked about other
    parameters being included as part of the advertisement.  This means
    that the advertisement could become arbitrarily complex and parsing
    it every time when it will change very infrequently will add real
    cost to the reporting nodes.

    

      

        

        

          o  
              the sequence number has
          the property  to be equal  or to increase in order to detect
          an eventual  change of the order of the messages and avoid to
          come back to a previous value of the feature-vector. But
          further messages will all be with the new feature-vector, so
          the right result. I am not sure that the seq number bring a
          value for the transient period when the supported feature is
           modified. So question: can we suppress the seq number in this
          a) behaviour?

      

    

    SRD> No, for the reasons discussed.

    

      

        

        
In this a )
          behaviour, if the OC-Supported-Features AVP is no more present
          in a message (and in later messages) ,  it would  be
          interpreted  that DOIC is no more supported . ( so different
          from the b) or c) case)
          

        
   

        
About b):
          this is the other extreme use case compared to a).
          

        
Here in
          practice all the messages will not contain an
           OC-Supported-Features AVP (except in the  rare cases of a
          change or after a restart), So the absence of this AVP in a
          message  does not mean that DOIC is not supported. Capability
          negotiation  happens once and remain valid until a change. At
          restart or when a change  a reacting node sends an
          OC-Supported-Features AVP in a request, and wait for an
          OC-Supported-Features AVP   in the answer; if nothing, it
          means the reporting node is not supporting DOIC. If the answer
          is lost the reacting node may repeat the request or use
          another one with its OC Supported-feature AVP.
        

      

    

    SRD> How does a client (reacting node) know that all servers
    (reporting nodes) have received the advertisement?

    

      

        

        
 

        
If the
          change occurs in the reporting node, it cannot wait for a
          request coming from the reacting node with an OC
          Supported-feature AVP,  (as it will  never come if no change
          at the reacting node side), so the reporting node should
          advertise the  OC Supported-feature AVP in answers (although
          the corresponding request do not contain this AVP).  I think
          this behavior is currently allowed by the draft text, do you
          agree?.   To secure a bit more, the reacting node may then
           send a request with its own OC Supported-feature AVP, acting
          as an acknowledgement to the reporting node. The reporting
          node may repeat if needed  or to be more secure.

        
There may be
          some corner cases to investigate more, but I currently stop
          here.  

        

      

    

    SRD> This seems pretty complex.  Why not just assume a)?

    

      

        

        
 

        
In this use
          case, I do not see a need  for a sequence number .
        

      

    

    SRD> The need for a sequence number does go away if we can insure
    a single handshake between each reacting and reporting node.  We
    don't have a mechanism insure this using the piggyback approach.

    

      

        

        
     

        
Do you think
          such an approach is applicable? it will save many checks
          compared to a).

        
 

        
About c):
          it is the same principle as in b) but with some periodic
           “refresh” that may make the a) approach  still more secure.
          But not sure  it is actually needed.

        
 

        
So do you
          think the draft should  allow these different  behaviors  or
          only mandate one?

        
Then do you
          think we need a sequence number for the OC-Supported-Features
          AVP?

      

    

    SRD> As stated above, I think the requirement is that the
    reacting nodes MUST have a capability exchange with all reporting
    nodes.  To achieve this the reacting node SHOULD send advertisements
    in all requests.  

    

      

        

        
 

        
 

        

          B)     
            Another point also related to
          the OC-Supported-Features AVP and OC-Feature-Vector:

        
 

        
For example a node can use the default
          mechanism  and in addition support extensions (eg the APN or
          the session group examples). I would think extensions should
          be advertized by the reacting node , otherwise the server does
          not know if it can use an extension or not, and  a server
          should avoid  to send OLRs that the client will not understand
          .    
          

        
 So here we may have  a set of extensions
          compatible with the default mechanism

        
 

        
The other example is “exclusive” or not
          compatible features, for example Traffic reduction %control 
          and rate control. I do not consider  a reporting node  will
           use both with a reacting node. A reacting node , even if it
          supports both does not want to mix  throttling based on %
          traffic and throttling on rate control with the same reporting
          node. But the current  text does not say anything about which
          feature is selected .
          

        
I remember that in our initial discussions,
          the reacting node was advertising its features / capabilities
          and the reporting node was selecting the ones it wants to use.
          Should not we come back to this rule? or do you consider that
          when we will introduce new features , we will introduce
          statements  to indicate rules on their presence in
          OC-Feature-Vector. Personnaly, I think  the advertisement
           followed  by selection  was a good approach. Views on this?
          

      

    

    SRD> I think the interactions between features should be
    addressed in the extension documents.

    

      

        
 

        
I have  described this B part  here, as it
          may have some interaction with the  A part.

        
 

        
Best regards

        
 

        
JJacques 

        
 

        
 

        
 

        
     

        
 

      

      

      

      

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


    

    

  


--------------020608050401070706000604--

From srdonovan@usdonovans.com  Mon Dec 16 05:23:49 2013
Return-Path: 
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 792801AE319 for ; Mon, 16 Dec 2013 05:23:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.12
X-Spam-Level: 
X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no
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 hzl177R-gE5r for ; Mon, 16 Dec 2013 05:23:43 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 866101AE317 for ; Mon, 16 Dec 2013 05:23:43 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:61962 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1VsY92-0007hy-6D; Mon, 16 Dec 2013 05:23:42 -0800
Message-ID: <52AEFED7.5060908@usdonovans.com>
Date: Mon, 16 Dec 2013 07:23:35 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: "Nirav Salot (nsalot)" , "dime@ietf.org" 
References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com>  <52A091CE.2000104@usdonovans.com> <13081_1386256433_52A09831_13081_8197_1_6B7134B31289DC4FAF! 731D84412 2B36E32B6EB@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B9209739738@ESESSMB101.ericsson.se>  <8FD63E2D-5203-4DA4-A6DA-C4CA181C9CFB@nostrum.com> <26C84DFD55BC3040A45BF70926E55F2587C1D786@SZXEMA512-MBX.china.huawei.com>  <52A86663.30500@usdonovans.com>  <087A34937E64E74E848732CFF8354B920973A82A@ESESSMB101.ericsson.se> <52A8B862.5040207@usdonovans.com> <087A34937E64E74E848732CFF8354B920973AAF5@ESESSMB101.ericsson.se> <52A9BE1F.7020201@usdonovans.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------010100060809010508040704"
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Dec 2013 13:23:49 -0000

This is a multi-part message in MIME format.
--------------010100060809010508040704
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

Nirav,

See my response inline.

Regards,

Steve

On 12/12/13 10:36 AM, Nirav Salot (nsalot) wrote:
>
> Steve,
>
>  
>
> Why do you always talk about "the application which the Diameter node
> does not understand?"
>
> What if the reacting node supports two applications and in the message
> for application-X it receives the overload-report for application-Y?
>
> Do you propose to ignore this report as well?
>
SRD> The logic behind self contained reports would be that the reactor 
use the reports that it makes sense for the reactor to use.  I think
your question is what should a reactor do if it supports application-X
and application-Y, sends a request for application-X and receives a
reply with an overload report for application-Y in the answer to that
request. The behavior I would suggest is that the reactor should (not
must) honor the overload report for requests sent to application-Y.  If
this is particularly difficult for the reactor to achieve then it can
wait to receive an overload for application-Y in answers to requests
sent on application-Y.
>
>  
>
> As already indicated earlier, by many of us, handling of
> application-Y's data in the application-X's message is not how the
> Diameter applications are designed today. And hence this type of
> proposal requires architectural support for handling it. And there
> lies the complexity.
>
SRD> I don't understand what is meant by "requires architectural
support".  Is this a way of saying it is more difficult to implement?
>
> This main drawback was highlighted earlier as well but was
> conveniently ignored while preparing the pros and cons list for the
> self-contained OLR.
>
SRD> Then suggest it be added to the pros and cons list.  But first
explain the concept of "requires architectural support". 
>
>  
>
> Regards,
>
> Nirav.
>
>  
>
> *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *Steve Donovan
> *Sent:* Thursday, December 12, 2013 7:16 PM
> *To:* dime@ietf.org
> *Subject:* Re: [Dime] DOIC: Self-Contained OLRs
>
>  
>
> Maria Cruz,
>
> Can you explain the complexity behind the cross-application
> procedure.  The work required is to ignore any application that the
> Diameter node does not understand.  I don't see this as very complex.
>
> Steve
>
> On 12/12/13 1:26 AM, Maria Cruz Bartolome wrote:
>
>     Yes, I agree consistency is not any longer a problem, since now
>     your intention is that _/any/_ (and multiple) application data
>     could be conveyed within the same message.
>
>     But as mentioned a few times, I consider this not necessary since
>     OLR is sent in every answer.
>
>     A part from that, as mentioned by Lionel, this implies a
>     cross-application procedure at both endpoints, that increases
>     complexity and it is not required for our work (RFC7068)
>
>      
>
>     Cheers
>
>     /MCruz
>
>      
>
>     *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *Steve
>     Donovan
>     *Sent:* miércoles, 11 de diciembre de 2013 20:09
>     *To:* dime@ietf.org 
>     *Subject:* Re: [Dime] DOIC: Self-Contained OLRs
>
>      
>
>     Maria Cruz,
>
>     I don't agree with the assertion that self-contained OLRs results
>     in the potential for data inconsistency.  If a reactor receives an
>     overload report for an application that is not supported by the
>     reactor then the reactor can and should ignore that OLR. 
>
>     The concept of self-contained overload reports would explicitly
>     allow for the contents of the overload report to be different than
>     the message that is carrying the OLR.  As with application-ids, if
>     the reactor doesn't send messages to a reported host or realm then
>     the reactor ignores that part of the overload report.  As such,
>     there is no need to check the implicit data when receiving a
>     self-contained OLR.
>
>     Steve
>
>     On 12/11/13 12:25 PM, Maria Cruz Bartolome wrote:
>
>         Hello (and something else now J, fast key combination, I won't
>         be able to repeat,  was the responsible)
>
>          
>
>         As mentioned before, something else on cons side for
>         self-contained:
>
>          
>
>         A part from that,  one concern with "self-contained OLRs" is
>         that some data is duplicated. Duplication should be avoided,
>         since then we need to assure consistency, and error handing in
>         case implicit and explicit data values are different for any
>         reason... what means that it may always be required to check
>         both implicit and explicit data.
>
>          
>
>         Also, I think this is a pure implementation proposal.
>         Regardless how the data is transported it could be packed in a
>         "self-contained OLRs" within the diameter application, if for
>         any implementation this is preferred.
>
>          
>
>         Best regards
>
>         /MCruz
>
>          
>
>         *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of
>         *TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
>         *Sent:* miércoles, 11 de diciembre de 2013 19:02
>         *To:* dime@ietf.org 
>         *Subject:* Re: [Dime] DOIC: Self-Contained OLRs
>
>          
>
>         Hi Steve
>
>          
>
>         I am sorry, Steve,  I do not see the difference between the
>         Draft Roach scope approach and the self contained OLRs.
>
>          
>
>         With the scope approach in Draft Roach : there is an overload
>         metric AVP  (eg containing a % of traffic reduction) coupled
>         with one or several Overlaod-Infoscope AVPs, an overlaod
>         infoscope identifying an application or a destination host
>         or... . These Overlaod-Infoscope AVPs can be combined  with
>         also  the possibility of  multi instances to have a list of
>         applications, a list of destination hosts etc  to which the
>         overload metric would apply.
>
>          
>
>         With self contained OLR as you have described them, un OLR
>         will also contain an OC-Reduction-Percentage AVP coupled with
>         one or several others AVPs (the self containment approach) to
>         indicate which application(s), destinations host (s) etc the
>           OC-Reduction-Percentage AVP applies.
>
>          
>
>         Where is the difference?
>
>          
>
>         So the drawbacks identified for the scope approach also apply
>         with the self contained approach
>
>          
>
>         Best regards
>
>          
>
>         JJacques
>
>          
>
>          
>
>          
>
>         *De :*DiME [mailto:dime-bounces@ietf.org] *De la part de*
>         Steve Donovan
>         *Envoyé :* mercredi 11 décembre 2013 14:20
>         *À :* dime@ietf.org 
>         *Objet :* Re: [Dime] DOIC: Self-Contained OLRs
>
>          
>
>         JJacques,
>
>         While the self contained overload report concept may be
>         similar to the scopes concept in the Roach draft, they are not
>         the same.  As such, I don't agree with your assertion that the
>         previous rejection of the Roach draft requires us to reject
>         self contained overload reports as currently being discussed.
>
>         Steve
>
>         On 12/11/13 2:27 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:
>
>             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  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
>             >
>             wrote:
>
>
>             OK. Lets call this thread concluded then. I keep the old
>             OC-OLR  semantics
>             regarding its information context then unmodified.
>
>             - Jouni
>
>              
>
>              
>
>             _______________________________________________
>
>             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
>
>  
>


--------------010100060809010508040704
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Nirav,

      

      See my response inline.

      

      Regards,

      

      Steve

      

    
    
On 12/12/13 10:36 AM, Nirav Salot
      (nsalot) wrote:

    

    

      
      
      
      

        
Steve,

        
 

        
Why
            do you always talk about "the application which the Diameter
            node does not understand?"

        
What
            if the reacting node supports two applications and in the
            message for application-X it receives the overload-report
            for application-Y?

        
Do
            you propose to ignore this report as well?

      

    

    SRD> The logic behind self contained reports would be that the
    reactor  use the reports that it makes sense for the reactor to
    use.  I think your question is what should a reactor do if it
    supports application-X and application-Y, sends a request for
    application-X and receives a reply with an overload report for
    application-Y in the answer to that request. The behavior I would
    suggest is that the reactor should (not must) honor the overload
    report for requests sent to application-Y.  If this is particularly
    difficult for the reactor to achieve then it can wait to receive an
    overload for application-Y in answers to requests sent on
    application-Y.

    

      

        

        
 

        
As
            already indicated earlier, by many of us, handling of
            application-Y's data in the application-X's message is not
            how the Diameter applications are designed today. And hence
            this type of proposal requires architectural support for
            handling it. And there lies the complexity.

      

    

    SRD> I don't understand what is meant by "requires architectural
    support".  Is this a way of saying it is more difficult to
    implement?

    

      

        

        
This
            main drawback was highlighted earlier as well but was
            conveniently ignored while preparing the pros and cons list
            for the self-contained OLR.

        

      

    

    SRD> Then suggest it be added to the pros and cons list.  But
    first explain the concept of "requires architectural support".  

    

      

        

        
 

        
Regards,

        
Nirav.

        
 

        

          

            
From:
                DiME [mailto:dime-bounces@ietf.org]
                On Behalf Of Steve Donovan

                Sent: Thursday, December 12, 2013 7:16 PM

                To: dime@ietf.org

                Subject: Re: [Dime] DOIC: Self-Contained OLRs

          

        

        
 

        
Maria Cruz,

          

          Can you explain the complexity behind the cross-application
          procedure.  The work required is to ignore any application
          that the Diameter node does not understand.  I don't see this
          as very complex.

          

          Steve

        

          
On 12/12/13 1:26 AM, Maria Cruz Bartolome
            wrote:

        

        

          
Yes,
              I agree consistency is not any longer a problem, since now
              your intention is that _any_ (and multiple)
              application data could be conveyed within the same
              message.

          
But
              as mentioned a few times, I consider this not necessary
              since OLR is sent in every answer.
            

          
A
              part from that, as mentioned by Lionel, this implies a
              cross-application procedure at both endpoints, that
              increases complexity and it is not required for our work
              (RFC7068)

          
 

          
Cheers

          
/MCruz

          
 

          

            

              
From:
                  DiME [mailto:dime-bounces@ietf.org]
                  On Behalf Of Steve Donovan

                  Sent: miércoles, 11 de diciembre de 2013 20:09

                  To: dime@ietf.org

                  Subject: Re: [Dime] DOIC: Self-Contained OLRs

            

          

          
 

          
Maria Cruz,

            

            I don't agree with the assertion that self-contained OLRs
            results in the potential for data inconsistency.  If a
            reactor receives an overload report for an application that
            is not supported by the reactor then the reactor can and
            should ignore that OLR. 
            

            

            The concept of self-contained overload reports would
            explicitly allow for the contents of the overload report to
            be different than the message that is carrying the OLR.  As
            with application-ids, if the reactor doesn't send messages
            to a reported host or realm then the reactor ignores that
            part of the overload report.  As such, there is no need to
            check the implicit data when receiving a self-contained OLR.

            

            Steve

          

            
On 12/11/13 12:25 PM, Maria Cruz
              Bartolome wrote:

          

          

            
Hello (and something else now 
                J, fast key combination, I won’t be able to
              repeat,  was the responsible)

            
 

            
As mentioned before, something else
              on cons side for self-contained:

            
 

            
A part from
              that,  one concern with "self-contained OLRs" is that some
              data is duplicated. Duplication should be avoided, since
              then we need to assure consistency, and error handing in
              case implicit and explicit data values are different for
              any reason... what means that it may always be required to
              check both implicit and explicit data.

            
 

            
Also, I
              think this is a pure implementation proposal. Regardless
              how the data is transported it could be packed in a
              "self-contained OLRs" within the diameter application, if
              for any implementation this is preferred.

            
 

            
Best
                regards

            
/MCruz

            
 

            

              

                
From:
                    DiME [mailto:dime-bounces@ietf.org]
                    On Behalf Of TROTTIN, JEAN-JACQUES
                    (JEAN-JACQUES)

                    Sent: miércoles, 11 de diciembre de 2013
                    19:02

                    To: dime@ietf.org

                    Subject: Re: [Dime] DOIC: Self-Contained OLRs

              

            

            
 

            
Hi
                Steve

            
 

            
I
                am sorry, Steve,  I do not see the difference between
                the Draft Roach scope approach and the self contained
                OLRs.

            
 

            
With
                the scope approach in Draft Roach : there is an overload
                metric AVP  (eg containing a % of traffic reduction)
                coupled with one or several Overlaod-Infoscope AVPs, an
                overlaod infoscope identifying an application or a
                destination host or… . These Overlaod-Infoscope AVPs can
                be combined  with also  the possibility of  multi
                instances to have a list of applications, a list of
                destination hosts etc  to which the overload metric
                would apply.

            
 

            
With
                self contained OLR as you have described them, un OLR
                will also contain an OC-Reduction-Percentage
               AVP
                coupled with one or several others AVPs (the self
                containment approach) to indicate which application(s),
                destinations host (s) etc the   OC-Reduction-Percentage
               AVP
                applies.
              

            
 

            
Where
                is the difference?

            
 

            
So
                the drawbacks identified for the scope approach also
                apply with the self contained approach
              

            
 

            
Best
                regards

            
 

            
JJacques
              

            
 

            
 

            
 

            

              

                
De : DiME [mailto:dime-bounces@ietf.org]
                    De la part de Steve Donovan

                    Envoyé : mercredi 11 décembre 2013 14:20

                    À : dime@ietf.org

                    Objet : Re: [Dime] DOIC: Self-Contained OLRs

              

            

            
 

            
JJacques,

              

              While the self contained overload report concept may be
              similar to the scopes concept in the Roach draft, they are
              not the same.  As such, I don't agree with your assertion
              that the previous rejection of the Roach draft requires us
              to reject self contained overload reports as currently
              being discussed.

              

              Steve

            

              
On 12/11/13 2:27 AM, TROTTIN,
                JEAN-JACQUES (JEAN-JACQUES) wrote:

            

            

              
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
                      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>
                wrote:

              


                OK. Lets call this thread concluded then. I keep the old
                OC-OLR  semantics

                regarding its information context then unmodified.

                

                - Jouni

              
 

              
 

              
_______________________________________________

              
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

        

        
 

      

    

    

  


--------------010100060809010508040704--

From srdonovan@usdonovans.com  Mon Dec 16 05:34:31 2013
Return-Path: 
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 CA5321AE31B for ; Mon, 16 Dec 2013 05:34:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.12
X-Spam-Level: 
X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no
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 qlDzrs2ZcERr for ; Mon, 16 Dec 2013 05:34:27 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 18FBA1AE317 for ; Mon, 16 Dec 2013 05:34:27 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:61981 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1VsYJQ-0003Sv-4Y; Mon, 16 Dec 2013 05:34:24 -0800
Message-ID: <52AF015B.7050002@usdonovans.com>
Date: Mon, 16 Dec 2013 07:34:19 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: "Wiehe, Ulrich (NSN - DE/Munich)" ,  Jouni 
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DB1B@DEMUMBX014.nsn-intra.net>  <52A5E902.20605@usdonovans.com> <7475B713-1104-4791-96B1-CE97632A0D69@nostrum.com>  <5BCBA1FC2B7F0B4C9D935572D90006681519E476@DEMUMBX014.nsn-intra.net> <1CD20507-B0FE-4367-804A-B831734CF060@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E6DC@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D90006681519E712@DEMUMBX014.nsn-intra.net> <4A151D70-0291-4238-85B1-03BB54B361E6@gmail.com> <52A864FF.10705@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006681519EA91@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681519EA91@DEMUMBX014.nsn-intra.net>
Content-Type: multipart/alternative; boundary="------------060007080605010300090605"
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com
Cc: Ben Campbell , "dime@ietf.org list" 
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Dec 2013 13:34:32 -0000

This is a multi-part message in MIME format.
--------------060007080605010300090605
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Ulrich,

I can see how Ongoing-Throttling-Information could be used to help
agents understand the overload state being sent by other agents.  I
don't, however, think it is a complete solution.

In addition, Ongoing-Throttling-Information is not part of the solution,
at least not yet. 

We need to find a way to drive these discussions to conclusions.

Steve

On 12/13/13 3:05 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
> Steve,
>
>  
>
>      I see a couple of options (others will probably see options I am
> missing):
>
>  
>
> another approach is to let the reacting node indicate
> Ongoing-Throttling-Information in requests. Based on that agents will
> not return out of sync OLRs.
>
> e.g. client C sends 1^st realm type request which is routed via agent
> A1. A1 returns OLR requesting 10% reduction with sequence number s. C
> sends a 2^nd realm type request (which survived the 10% throttling and
> indicates so in the request) which is routed via agent A2. Since it is
> assumed that A2 would also require  a 10% reduction and A2 detects
> that C is already doing a 10% reduction, there is no need for A2 to
> return an OLR which potentially would have an out-of-sync sequence number.
>
> We could also allow the agents to accept a limited deviation in the
> percentage, i.e. if A2 would want a reduction of 9% it still could
> accept the 2^nd request and not return an OLR.
>
>  
>
> Ulrich
>
>  
>
>  
>
>  
>
>  
>
> *From:*ext Steve Donovan [mailto:srdonovan@usdonovans.com]
> *Sent:* Wednesday, December 11, 2013 2:14 PM
> *To:* Jouni; Wiehe, Ulrich (NSN - DE/Munich)
> *Cc:* Ben Campbell; dime@ietf.org list
> *Subject:* Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI:
> comments to 4.3
>
>  
>
> Jouni,
>
> We need the sequence number to be strictly increasing.  I don't see
> the need for it to increase in uniform amounts.  Using time does fit
> these requirements.  I'm ok with using time as long as we don't call
> the AVP timestamp.
>
> Ulrich does bring up an interesting use case, where a client is
> receiving realm reports for the same realm from different agents.  We
> need to define the clients behavior in this case. 
>
> Presumably the client needs to be able to determine who generated the
> realm report.  This cannot be determine based on the content of the
> message or the connection on which the message arrived.  It seems like
> we might need "Report Generator Diameter ID" in the overload report
> specifically for Realm reports. 
>
> Once the client is able to differentiate between realm reports sent by
> different agents (or servers) we need logic defining how the client
> deals with a new overload report. 
>
> I see a couple of options (others will probably see options I am missing):
>
> - Use the last received realm report - This introduces the possibility
> of thrashing between two different reduction values and different
> durations.  Note that this approach does not require the source of the
> report to be included in the report.
>
> - Only listen to one source of realm overload - The approach would be
> to remember who sent the first overload report from the realm and
> ignore realm overload reports from other sources.  This behavior would
> likely be constrained to a single occurrence of realm overload. 
> Meaning that the "memory" of the report source would only last as long
> as that overload event persists.  Once the overload event goes away,
> the report source would be forgotten and a new source could be used
> for the next occurrence.
>
> On the surface, the second approach looks better to me.
>
> Steve
>
> On 12/11/13 2:15 AM, Jouni wrote:
>
>     Ulrich,
>
>      
>
>     I might be slow but.. Section 4.4 says
>
>      
>
>        control endpoints.  The sequence number is only required to be unique
>
>        between two overload control endpoints and does not need to be
>
>      
>
>     Unique between two endpoints..
>
>      
>
>     Section 5.1 talks about endpoints:
>
>      
>
>        of an arbitrary Diameter network.  The overload control information
>
>        is exchanged over on a "DOIC association" between two communication
>
>        endpoints.  The endpoints, namely the "reacting node" and the
>
>        "reporting node" do not need to be adjacent Diameter peer nodes, nor
>
>      
>
>     So if your agents inject realm reports, they need to be endpoints to the
>
>     client. Similar to Figure 5. Therefore the sequence number spaces between
>
>     C-A1 and C-A2 are separate.
>
>      
>
>     Now it is not clear to me, whether in your reasoning the C would see
>
>     the server identity (as the endpoint) when there is an active "DEP
>
>     agent" on the path. That would not clearly work and not be align with
>
>     the endpoint assumption.
>
>      
>
>     Note that at some point of time we had (at least on a discussion level
>
>     in f2f meeting) report originator identity in the OLR. That would make
>
>     endpoint identification trivial. Now a "DEP agent" needs to act as a 
>
>     "server" for its clients in order to appear as an endpoint.
>
>      
>
>     - Jouni
>
>      
>
>     ps: still think the use of Time is simpler..
>
>      
>
>      
>
>     On Dec 11, 2013, at 9:43 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
>      
>
>         That's not predictable. It may be the same server in some cases, and different servers in other cases.
>
>          
>
>         -----Original Message-----
>
>         From: ext Jouni [mailto:jouni.nospam@gmail.com] 
>
>         Sent: Wednesday, December 11, 2013 8:38 AM
>
>         To: Wiehe, Ulrich (NSN - DE/Munich)
>
>         Cc: Ben Campbell; dime@ietf.org  list; Steve Donovan
>
>         Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3
>
>          
>
>          
>
>         Ulrich,
>
>          
>
>         On Dec 11, 2013, at 9:21 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
>          
>
>             Jouni,
>
>              
>
>             ad 1. "monotonically" does not express your intention. What we are looking for may be "stepwise with fixed step".
>
>              
>
>             Ad 2. Is not necessarily a mistake that could result in out-of-sequence sequence numbers. When a client C sends a realm-type requests towards any server in the realm, an agent A1 that selects the server would send back the realm-type OLR with sequence number s1. The next realm-type request sent by C (that survived the throttling) may take a path that does not include A1 but A2. A2 then selects the server and sends back a sequence number s2. Nothing ensures that s1 and s2 are in sequence.
>
>          
>
>         Would the server in both cases (via A1 and A2) be the same?
>
>          
>
>         - Jouni
>
>          
>
>          
>
>              
>
>             Ulrich
>
>              
>
>              
>
>             -----Original Message-----
>
>             From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] 
>
>             Sent: Tuesday, December 10, 2013 10:31 PM
>
>             To: Wiehe, Ulrich (NSN - DE/Munich)
>
>             Cc: Ben Campbell; dime@ietf.org  list; Steve Donovan
>
>             Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3
>
>              
>
>             Ulrich,
>
>              
>
>             On Dec 10, 2013, at 4:31 PM, "Wiehe, Ulrich (NSN - DE/Munich)"   wrote:
>
>              
>
>                 Jouni,
>
>                  
>
>                 1. I find the texts
>
>                 a) "The sequence number ... does not need to be monotonically increasing"
>
>                 and 
>
>              
>
>             Means the delta from old-seqno to new-seqno can be any non-negative integer
>
>             (within the given limits) not something fixed step/delta (like +1). As long as
>
>             "new-seqno >= old-seqno" holds we are fine.
>
>              
>
>                 b) "...the new sequence number MUST be greater or equal than the old sequence number..."
>
>                 contradicting.
>
>                 Can you please clarify.
>
>              
>
>             See above. (mind the overflow case)
>
>              
>
>                 2. The expected behaviour when receiving an out-of-sequence sequence number within OC-OLR is described in 4.3:
>
>                 "The receiver SHOULD discard an OC-OLR AVP with a sequence number that is less than previously received one."
>
>                 I don't find this very robust. Once a higher sequence number (received erroneously by mistake) is accepted you cannot (easily) recover.
>
>              
>
>             I find it more robust in a sense that I should not care about stale old information.
>
>             However, since we are piggybacking (by popular demand) we have little room for seqno
>
>             re-sync negotiation.
>
>              
>
>             What is the mistake you refer here? A misbehaving implementation? In that case, it 
>
>             deserves to get a manual intervention once figured out by admins checking alarms and
>
>             logs. If the mistake is due other things, like endpoints being out of sync, we currently
>
>             have no written down mechanism to survive that.
>
>              
>
>                 3. The expected behaviour when receiving an out-of-sequence sequence number within the OC-Supported-Features AVP is not described. What is the intention here?
>
>              
>
>             No intention. Just a sloppy specification. You are right that something needs to be
>
>             done & clarified here. (again the semantics of Time would nice..)
>
>              
>
>             I'll propose something. Others should too ;)
>
>              
>
>             - Jouni
>
>              
>
>                  
>
>                 Ulrich
>
>                  
>
>                 -----Original Message-----
>
>                 From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Jouni Korhonen
>
>                 Sent: Tuesday, December 10, 2013 8:28 AM
>
>                 To: Ben Campbell; dime@ietf.org  list; Steve Donovan
>
>                 Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3
>
>                  
>
>                  
>
>                 Fine.. lets define then the sequence number semantics. Basic
>
>                 unsigned integer math. The text proposal is the following:
>
>                  
>
>                 4.4.  OC-Sequence-Number AVP
>
>                  
>
>                 The OC-Sequence-Number AVP (AVP code TBD3) is type of Unsigned64.
>
>                 Its usage in the context of the overload control is described in
>
>                 Sections 4.1 and 4.3.
>
>                  
>
>                 From the functionality point of view, the OC-Sequence-Number AVP
>
>                 MUST be used as a non-volatile increasing counter between two
>
>                 overload control endpoints.  The sequence number is only required
>
>                 to be unique between two overload control endpoints and does not
>
>                 need to be monotonically increasing.
>
>                  
>
>                 When comparing two sequence numbers, the new sequence number MUST
>
>                 be greater or equal than the old sequence number within a window
>
>                 that is half of the size of the maximum sequence number. This
>
>                 allows a simple handling of the sequence number overflow using
>
>                 unsigned integer arithmeticf:
>
>                  
>
>                   #define WINDOW 0x8000000000000000ULL
>
>                  
>
>                   bool verify_seqnum( uint64_t newsn, uint64_t oldsn ) {
>
>                       if (newsn - oldsn <= WINDOW)
>
>                           // newsn >= oldsn
>
>                           return true;   
>
>                       } else
>
>                           // outside window or newsn < oldsn
>
>                           return false;  
>
>                       }
>
>                   }
>
>                  
>
>                  
>
>                  
>
>                 The above should even work is someone shovels NTP times into
>
>                 sequence numbers with a blind typecasting.
>
>                  
>
>                 - Jouni
>
>                  
>
>                 On Dec 10, 2013, at 12:34 AM, Ben Campbell   wrote:
>
>                  
>
>                      
>
>                     On Dec 9, 2013, at 10:00 AM, Steve Donovan   wrote:
>
>                      
>
>                         Jouni,
>
>                          
>
>                         I propose that we keep the name OC-Sequence-Number but that we use the Time type for OC-Sequence-Number.  It is misleading and potentially confusing to call it OC-Time-Stamp.  
>
>                          
>
>                      
>
>                     I could live with that, although I would rather just define the expected properties of the sequence number, and leave the implementation up to the implementor. I assume your reasoning for not calling it a timestamp is that you do not want people to try to use it as a time base reference. If so, then we don't require any connection to a clock. We just need it to be monotonically increasing.
>
>                      
>
>                         We might consider expanding on the format of the AVP to make it something like Session-ID, where it is a concatenation of the Diameter-ID of the generating node and a timestamp.  This might help the reacting node keep track of which sequence number it has received.
>
>                          
>
>                      
>
>                     Do we need a uniqueness across multiple nodes property? If so, why?
>
>                      
>
>                         Steve
>
>                          
>
>                         On 12/9/13 5:37 AM, Jouni Korhonen wrote:
>
>                             Folks
>
>                              
>
>                             Could we conclude on the sequence number vs. time stamp vs. something else?
>
>                             We got more important places to spend our energy than this ;)
>
>                              
>
>                             My proposal is the following (based on the original pre-00 design):
>
>                              
>
>                             o We change the OC-Sequence-Number to OC-Time-Stamp in all occurrences
>
>                             in the -01.
>
>                             o We use RFC6733 Time type for the OC-Time-Stamp. RFC6733 gives us
>
>                             already exact definition how to handle the AVP.
>
>                             o Define that the OC-Time-Stamp is the time of the creation of the 
>
>                             "original" AVP within whose context the time stamp is present.
>
>                             o The OC-Time-Stamp AVP uniqueness is still considered to be in scope
>
>                             of the communicating endpoints.
>
>                             o The time stamp can be used to quickly determine if the content of
>
>                             the encapsulating AVP context has changed (among other properties).
>
>                             This would be useful specifically in the future when the encapsulating
>
>                             grouped AVPs  grow in size and functionality.
>
>                              
>
>                              
>
>                             - Jouni
>
>                              
>
>                             _______________________________________________
>
>                             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
>
>              
>
>          
>
>      
>
>      
>
>  
>


--------------060007080605010300090605
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Ulrich,

      

      I can see how Ongoing-Throttling-Information could be used to help
      agents understand the overload state being sent by other agents. 
      I don't, however, think it is a complete solution.

      

      In addition, Ongoing-Throttling-Information is not part of the
      solution, at least not yet.  

      

      We need to find a way to drive these discussions to conclusions.

      

      Steve

      

    
    
On 12/13/13 3:05 AM, Wiehe, Ulrich (NSN
      - DE/Munich) wrote:

    

    

      
      
      
      

        
Steve,

        
 

        
     I see a couple of
            options (others will probably see options I am missing):

            

          

        
 

        
another approach is to let the reacting node
            indicate Ongoing-Throttling-Information in requests. Based
            on that agents will not return out of sync OLRs.

        
e.g. client C sends 1st realm type
            request which is routed via agent A1. A1 returns OLR
            requesting 10% reduction with sequence number s. C sends a 2nd
            realm type request (which survived the 10% throttling and
            indicates so in the request) which is routed via agent A2.
            Since it is assumed that A2 would also require  a 10%
            reduction and A2 detects that C is already doing a 10%
            reduction, there is no need for A2 to return an OLR which
            potentially would have an out-of-sync sequence number.

        
We could also allow the agents to accept a
            limited deviation in the percentage, i.e. if A2 would want a
            reduction of 9% it still could accept the 2nd
            request and not return an OLR.

        
 

        
Ulrich

        
 

        
 

        
 

        
 

        

          

            
From: ext Steve Donovan
                [mailto:srdonovan@usdonovans.com]
                

                Sent: Wednesday, December 11, 2013 2:14 PM

                To: Jouni; Wiehe, Ulrich (NSN - DE/Munich)

                Cc: Ben Campbell; dime@ietf.org list

                Subject: Re: [Dime] Conclusion for Sequence
                Numbers - was Re: OVLI: comments to 4.3

          

        

        
 

        
Jouni,

          

          We need the sequence number to be strictly increasing.  I
          don't see the need for it to increase in uniform amounts. 
          Using time does fit these requirements.  I'm ok with using
          time as long as we don't call the AVP timestamp.

          

          Ulrich does bring up an interesting use case, where a client
          is receiving realm reports for the same realm from different
          agents.  We need to define the clients behavior in this case. 
          

          

          Presumably the client needs to be able to determine who
          generated the realm report.  This cannot be determine based on
          the content of the message or the connection on which the
          message arrived.  It seems like we might need "Report
          Generator Diameter ID" in the overload report specifically for
          Realm reports.  

          

          Once the client is able to differentiate between realm reports
          sent by different agents (or servers) we need logic defining
          how the client deals with a new overload report. 
          

          

          I see a couple of options (others will probably see options I
          am missing):

          

          - Use the last received realm report - This introduces the
          possibility of thrashing between two different reduction
          values and different durations.  Note that this approach does
          not require the source of the report to be included in the
          report.

          

          - Only listen to one source of realm overload - The approach
          would be to remember who sent the first overload report from
          the realm and ignore realm overload reports from other
          sources.  This behavior would likely be constrained to a
          single occurrence of realm overload.  Meaning that the
          "memory" of the report source would only last as long as that
          overload event persists.  Once the overload event goes away,
          the report source would be forgotten and a new source could be
          used for the next occurrence.

          

          On the surface, the second approach looks better to me.

          

          Steve

        

          
On 12/11/13 2:15 AM, Jouni wrote:

        

        

          
Ulrich,

          
 

          
I might be slow but.. Section 4.4 says

          
 

          
   control endpoints.  The sequence number is only required to be unique

          
   between two overload control endpoints and does not need to be

          
 

          
Unique between two endpoints..

          
 

          
Section 5.1 talks about endpoints:

          
 

          
   of an arbitrary Diameter network.  The overload control information

          
   is exchanged over on a "DOIC association" between two communication

          
   endpoints.  The endpoints, namely the "reacting node" and the

          
   "reporting node" do not need to be adjacent Diameter peer nodes, nor

          
 

          
So if your agents inject realm reports, they need to be endpoints to the

          
client. Similar to Figure 5. Therefore the sequence number spaces between

          
C-A1 and C-A2 are separate.

          
 

          
Now it is not clear to me, whether in your reasoning the C would see

          
the server identity (as the endpoint) when there is an active "DEP

          
agent" on the path. That would not clearly work and not be align with

          
the endpoint assumption.

          
 

          
Note that at some point of time we had (at least on a discussion level

          
in f2f meeting) report originator identity in the OLR. That would make

          
endpoint identification trivial. Now a "DEP agent" needs to act as a 

          
"server" for its clients in order to appear as an endpoint.

          
 

          
- Jouni

          
 

          
ps: still think the use of Time is simpler..

          
 

          
 

          
On Dec 11, 2013, at 9:43 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:

          
 

          

            
That's not predictable. It may be the same server in some cases, and different servers in other cases.

            
 

            
-----Original Message-----

            
From: ext Jouni [mailto:jouni.nospam@gmail.com] 

            
Sent: Wednesday, December 11, 2013 8:38 AM

            
To: Wiehe, Ulrich (NSN - DE/Munich)

            
Cc: Ben Campbell; dime@ietf.org list; Steve Donovan

            
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3

            
 

            
 

            
Ulrich,

            
 

            
On Dec 11, 2013, at 9:21 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:

            
 

            

              
Jouni,

              
 

              
ad 1. "monotonically" does not express your intention. What we are looking for may be "stepwise with fixed step".

              
 

              
Ad 2. Is not necessarily a mistake that could result in out-of-sequence sequence numbers. When a client C sends a realm-type requests towards any server in the realm, an agent A1 that selects the server would send back the realm-type OLR with sequence number s1. The next realm-type request sent by C (that survived the throttling) may take a path that does not include A1 but A2. A2 then selects the server and sends back a sequence number s2. Nothing ensures that s1 and s2 are in sequence.

            

            
 

            
Would the server in both cases (via A1 and A2) be the same?

            
 

            
- Jouni

            
 

            
 

            

              
 

              
Ulrich

              
 

              
 

              
-----Original Message-----

              
From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] 

              
Sent: Tuesday, December 10, 2013 10:31 PM

              
To: Wiehe, Ulrich (NSN - DE/Munich)

              
Cc: Ben Campbell; dime@ietf.org list; Steve Donovan

              
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3

              
 

              
Ulrich,

              
 

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

              
 

              

                
Jouni,

                
 

                
1. I find the texts

                
a) "The sequence number ... does not need to be monotonically increasing"

                
and 

              

              
 

              
Means the delta from old-seqno to new-seqno can be any non-negative integer

              
(within the given limits) not something fixed step/delta (like +1). As long as

              
"new-seqno >= old-seqno" holds we are fine.

              
 

              

                
b) "...the new sequence number MUST be greater or equal than the old sequence number..."

                
contradicting.

                
Can you please clarify.

              

              
 

              
See above. (mind the overflow case)

              
 

              

                
2. The expected behaviour when receiving an out-of-sequence sequence number within OC-OLR is described in 4.3:

                
"The receiver SHOULD discard an OC-OLR AVP with a sequence number that is less than previously received one."

                
I don't find this very robust. Once a higher sequence number (received erroneously by mistake) is accepted you cannot (easily) recover.

              

              
 

              
I find it more robust in a sense that I should not care about stale old information.

              
However, since we are piggybacking (by popular demand) we have little room for seqno

              
re-sync negotiation.

              
 

              
What is the mistake you refer here? A misbehaving implementation? In that case, it 

              
deserves to get a manual intervention once figured out by admins checking alarms and

              
logs. If the mistake is due other things, like endpoints being out of sync, we currently

              
have no written down mechanism to survive that.

              
 

              

                
3. The expected behaviour when receiving an out-of-sequence sequence number within the OC-Supported-Features AVP is not described. What is the intention here?

              

              
 

              
No intention. Just a sloppy specification. You are right that something needs to be

              
done & clarified here. (again the semantics of Time would nice..)

              
 

              
I'll propose something. Others should too ;)

              
 

              
- Jouni

              
 

              

                
 

                
Ulrich

                
 

                
-----Original Message-----

                
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Jouni Korhonen

                
Sent: Tuesday, December 10, 2013 8:28 AM

                
To: Ben Campbell; dime@ietf.org list; Steve Donovan

                
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3

                
 

                
 

                
Fine.. lets define then the sequence number semantics. Basic

                
unsigned integer math. The text proposal is the following:

                
 

                
4.4.  OC-Sequence-Number AVP

                
 

                
The OC-Sequence-Number AVP (AVP code TBD3) is type of Unsigned64.

                
Its usage in the context of the overload control is described in

                
Sections 4.1 and 4.3.

                
 

                
From the functionality point of view, the OC-Sequence-Number AVP

                
MUST be used as a non-volatile increasing counter between two

                
overload control endpoints.  The sequence number is only required

                
to be unique between two overload control endpoints and does not

                
need to be monotonically increasing.

                
 

                
When comparing two sequence numbers, the new sequence number MUST

                
be greater or equal than the old sequence number within a window

                
that is half of the size of the maximum sequence number. This

                
allows a simple handling of the sequence number overflow using

                
unsigned integer arithmeticf:

                
 

                
  #define WINDOW 0x8000000000000000ULL

                
 

                
  bool verify_seqnum( uint64_t newsn, uint64_t oldsn ) {

                
      if (newsn - oldsn <= WINDOW)

                
          // newsn >= oldsn

                
          return true;   

                
      } else

                
          // outside window or newsn < oldsn

                
          return false;  

                
      }

                
  }

                
 

                
 

                
 

                
The above should even work is someone shovels NTP times into

                
sequence numbers with a blind typecasting.

                
 

                
- Jouni

                
 

                
On Dec 10, 2013, at 12:34 AM, Ben Campbell <ben@nostrum.com> wrote:

                
 

                

                  
 

                  
On Dec 9, 2013, at 10:00 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:

                  
 

                  

                    
Jouni,

                    
 

                    
I propose that we keep the name OC-Sequence-Number but that we use the Time type for OC-Sequence-Number.  It is misleading and potentially confusing to call it OC-Time-Stamp.  

                    
 

                  

                  
 

                  
I could live with that, although I would rather just define the expected properties of the sequence number, and leave the implementation up to the implementor. I assume your reasoning for not calling it a timestamp is that you do not want people to try to use it as a time base reference. If so, then we don't require any connection to a clock. We just need it to be monotonically increasing.

                  
 

                  

                    
We might consider expanding on the format of the AVP to make it something like Session-ID, where it is a concatenation of the Diameter-ID of the generating node and a timestamp.  This might help the reacting node keep track of which sequence number it has received.

                    
 

                  

                  
 

                  
Do we need a uniqueness across multiple nodes property? If so, why?

                  
 

                  

                    
Steve

                    
 

                    
On 12/9/13 5:37 AM, Jouni Korhonen wrote:

                    

                      
Folks

                      
 

                      
Could we conclude on the sequence number vs. time stamp vs. something else?

                      
We got more important places to spend our energy than this ;)

                      
 

                      
My proposal is the following (based on the original pre-00 design):

                      
 

                      
o We change the OC-Sequence-Number to OC-Time-Stamp in all occurrences

                      
in the -01.

                      
o We use RFC6733 Time type for the OC-Time-Stamp. RFC6733 gives us

                      
already exact definition how to handle the AVP.

                      
o Define that the OC-Time-Stamp is the time of the creation of the 

                      
"original" AVP within whose context the time stamp is present.

                      
o The OC-Time-Stamp AVP uniqueness is still considered to be in scope

                      
of the communicating endpoints.

                      
o The time stamp can be used to quickly determine if the content of

                      
the encapsulating AVP context has changed (among other properties).

                      
This would be useful specifically in the future when the encapsulating

                      
grouped AVPs  grow in size and functionality.

                      
 

                      
 

                      
- Jouni

                      
 

                      
_______________________________________________

                      
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

              

              
 

            

            
 

          

          
 

          
 

        

        
 

      

    

    

  


--------------060007080605010300090605--


From srdonovan@usdonovans.com  Mon Dec 16 05:43:39 2013
Return-Path: 
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 58A511AE32E for ; Mon, 16 Dec 2013 05:43:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.139
X-Spam-Level: 
X-Spam-Status: No, score=-0.139 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no
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 dqakrorYh70C for ; Mon, 16 Dec 2013 05:43:31 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 77CDE1AE328 for ; Mon, 16 Dec 2013 05:43:31 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:61993 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1VsYSD-0004jQ-6s; Mon, 16 Dec 2013 05:43:30 -0800
Message-ID: <52AF037B.4060605@usdonovans.com>
Date: Mon, 16 Dec 2013 07:43:23 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: "Wiehe, Ulrich (NSN - DE/Munich)" ,  "dime@ietf.org" 
References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com>  <5BCBA1FC2B7F0B4C9D935572D90006681519BC90@DEMUMBX014.nsn-intra.net> <6390_1385631044_52970D44_6390_18593_1_6B7134B31289DC4FAF731D844122B36E30748E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519BD19@DEMUMBX014.nsn-intra.net> <26C84DFD55BC3040A45BF70926E55F2587C1D028@SZXEMA512-MBX.china.huawei.com> <5BCBA1FC2B7F0B4C9D935572D90006681519DFC0@DEMUMBX014.nsn-intra.net> <26C84DFD55BC3040A45BF70926E55F2587C1D705@SZXEMA512-MBX.china.huawei.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E2DE@DEMUMBX014.nsn-intra.net> <26C84DFD55BC3040A45BF70926E55F2587C1DC24@SZXEMA512-MBX.china.huawei.com> <52A86839.4010103@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E931@DEMUMBX014.nsn-intra.net> <52A9BF98.6090805@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006681519EA1B@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681519EA1B@DEMUMBX014.nsn-intra.net>
Content-Type: multipart/alternative; boundary="------------060404090105090505090501"
X-OutGoing-Spam-Status: No, score=-1.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Dec 2013 13:43:39 -0000

This is a multi-part message in MIME format.
--------------060404090105090505090501
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Ulrich,

I don't see why there would ever be two (or more) associations for
requests sent through an agent.  I'm trying to understand what you are
proposing and then how it would be signaled.

Is it correct that the model you are proposing as a DOIC-Association per
report type?

Steve

On 12/12/13 10:21 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
> Steve,
>
> =20
>
> so you mean its allways case a) or allways case b) depending on local
> configuration in the agent and not depending on message content.
>
> =20
>
> Anyway, would you agree that in case a) the two DOIC associations may
> have independent different supported features?
>
> =20
>
> Ulrich
>
> =20
>
> *From:*ext Steve Donovan [mailto:srdonovan@usdonovans.com]
> *Sent:* Thursday, December 12, 2013 2:52 PM
> *To:* Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
> *Subject:* Re: [Dime] DOIC: Self-Contained OLRs
>
> =20
>
> Ulrich,
>
> My assumption is that and end-point is an end-point for all messages
> sent between the two end-points.
>
> Steve
>
> On 12/12/13 5:17 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
>     Steve,
>
>     =20
>
>     Isn't it so that the agent may decide (e.g. based on the absence
>     of Destination host in the received request and based of its
>     ability/willingness to select the server)
>
>     either a) to take the role of an endpoint or b) to be transparent
>     with regard to OC AVPs.
>
>     In case a) we end up with two DOIC associations, one between
>     client and agent, another one between agent and server. Different
>     DOIC associations may have different advertised/negotiated
>     features i.e. agent and server may use window algorithm, but
>     client and agent use loss algorithm. Therefore the host-type
>     window OLR must not be sent unchanged to the client.
>
>     In case b) being transparent includes not inserting realm-type AVPs=
=2E
>
>     =20
>
>     We end up with receiving not more than one OLR at the client.
>
>     =20
>
>     Ulrich
>
>     =20
>
>     =20
>
>     =20
>
>     =20
>
>     *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *ext
>     Steve Donovan
>     *Sent:* Wednesday, December 11, 2013 2:27 PM
>     *To:* dime@ietf.org 
>     *Subject:* Re: [Dime] DOIC: Self-Contained OLRs
>
>     =20
>
>     Susan,
>
>     The use case for an agent that sits between a DOIC client and a
>     DOIC server is Realm overload, which the agent might be
>     responsible for reporting.  This will particularly be the case
>     when there are multiple servers sitting behind the agent.  This
>     might be considered a server farm, as you indicate, but we don't
>     have a good definition of server farm, so I'm being explicit.
>
>     In this case, the agent must handle to types of occurrences.=20
>
>     1) Server overload - In this case the agent will receive a node
>     overload report from the server.  The agent should (I'm not sure
>     if we have defined this behavior in the draft yet) send the report
>     unchanged to the client.  The agent will also most likely use the
>     contents of the report to determine the realm overload state.
>
>     2) Realm overload - In this case the agent will insert an overload
>     report into the appropriate answer messages.
>
>     Is this consistent with your thinking?
>
>     Regards,
>
>     Steve
>
>     On 12/11/13 12:24 AM, Shishufeng (Susan) wrote:
>
>         Hi Ulrich,
>
>         =20
>
>         I'm not sure if you are taking the overload of agent into accou=
nt for which we decided to not consider for the time being. If not, I cou=
ldn't understand why an agent which does not serve for a server farm need=
s to be a DOIC endpoint between the client and server if both of them sup=
port overload control. My understanding is that if there is the need for =
an agent to take a role of a DOIC endpoint between a specific server and =
client, it would always do that, otherwise, it just transfer the overload=
 information of the server to the client.
>
>         =20
>
>         Best Regards,
>
>         Susan
>
>         =20
>
>         -----Original Message-----
>
>         From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.=
com]=20
>
>         Sent: Tuesday, December 10, 2013 6:15 PM
>
>         To: Shishufeng (Susan); ext lionel.morand@orange.com ; ext Jouni Korhonen; Ben Campbell
>
>         Cc: dime@ietf.org  list
>
>         Subject: RE: [Dime] DOIC: Self-Contained OLRs
>
>         =20
>
>         Hi Susan,
>
>         =20
>
>         if the agent does not take the role of a DOIC endpont then the =
feature negotiation/adverisement is between client and server and one hos=
t type OLR is sent from server to client. For the agent this is all trans=
parent and there is no need for the agent to support any DOIC feature.
>
>         However, if the agent takes the role of an DOIC endpoint then t=
he feature negotiation/advertisement is between client and agent and a se=
parate feature negotiation/advertisement is between agent and server. An =
OLR sent from server to agent is in-context with the supported features o=
f server and agent but possibly not in-context with supported features of=
 client and agent and therefore must not be (blindly) sent to the client.=
 And in fact there is also no need to do that. For subsequent requests th=
at contain the desination host of the server, the agent will not take the=
 role of a DOIC endpoint.
>
>         =20
>
>         Best regards
>
>         Ulrich
>
>         =20
>
>         -----Original Message-----
>
>         From: ext Shishufeng (Susan) [mailto:susan.shishufeng@huawei.co=
m]
>
>         Sent: Tuesday, December 10, 2013 4:02 AM
>
>         To: Wiehe, Ulrich (NSN - DE/Munich); ext lionel.morand@orange.c=
om ; ext Jouni Korhonen; Ben Campbell
>
>         Cc: dime@ietf.org  list
>
>         Subject: RE: [Dime] DOIC: Self-Contained OLRs
>
>         =20
>
>         Hi Ulrich,
>
>         =20
>
>         Thanks for your clarification. I understood the scenario, while=
 from my point of view, if the agent that selects the HSS is not configur=
ed to serve as a load balancer for the HSS, the agent should not change a=
ny supported/negotiated features between C and S, that would be the norma=
l case. If the agent serve as a load balancer for the HSS, the subsequent=
 request from C towards the S would always go via the agent, in this case=
 whatever the associations between C and A, between A and S are the same =
or not, it doesn't matter. With an E2E solution as we agreed, I don't see=
 the problem with it.
>
>         =20
>
>         Best Regards,
>
>         Susan
>
>         =20
>
>         -----Original Message-----
>
>         From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.=
com]
>
>         Sent: Monday, December 09, 2013 7:43 PM
>
>         To: Shishufeng (Susan); ext lionel.morand@orange.com ; ext Jouni Korhonen; Ben Campbell
>
>         Cc: dime@ietf.org  list
>
>         Subject: RE: [Dime] DOIC: Self-Contained OLRs
>
>         =20
>
>         Hi Susan,
>
>         =20
>
>         let me come back to your S6a example.
>
>         =20
>
>         The MME (C) sends a request without Destination-Host towards th=
e HPLMN (realm). There must be an agent (A) in the HPLMN (realm) that sel=
ects the HSS (S).=20
>
>         We would have two distinct DOIC associations: one between C and=
 A, another between A and S (see figure 5 in clause 5.1). The two DOIC as=
sociations may have different supported/negotiated features. An OLR sent =
from S to A based on supported/negotiated features valid for the DOIC ass=
ociation between A and S is at least problematic (out-of context) when se=
nt from A to C.
>
>         =20
>
>         When the MME (C) sends a subsequent request with Destination-Ho=
st towards the HSS (S), there is no agent that selects the HSS (as the HS=
S is already selected). For this session there is only one DOIC associati=
on between C and S (see figure 3 in clause 5.1) and OLRs sent from S to C=
 are not problematic.
>
>         =20
>
>         Best regards
>
>         Ulrich
>
>         =20
>
>         =20
>
>         -----Original Message-----
>
>         From: ext Shishufeng (Susan) [mailto:susan.shishufeng@huawei.co=
m]
>
>         Sent: Monday, December 09, 2013 11:30 AM
>
>         To: Wiehe, Ulrich (NSN - DE/Munich); ext lionel.morand@orange.c=
om ; ext Jouni Korhonen; Ben Campbell
>
>         Cc: dime@ietf.org  list
>
>         Subject: RE: [Dime] DOIC: Self-Contained OLRs
>
>         =20
>
>         Hi Ulrich,
>
>         =20
>
>         I have different views. In any case, I think the host-type OLR =
should not be ignored by the clients. On the contrary, the realm-type OLR=
 can be thought as optimization, which may not even be needed at all for =
all cases, especially in 3GPP. Here is an example of S6a, in the case the=
 first attach request comes from the UE to the MME, the MME can only deri=
ve the realm information, and sends a request without Destination-Host to=
wards the HPLMN. Since the subscriber corresponding to the UE belongs to =
a specific HSS, and the HSS may provide its overload report to the MME, a=
nd the MME is able to know how to react regarding the requests towards th=
e HSS, which would be the normal case. Whether Realm report will be provi=
ded by the HSS or the agent serving the HSS is kind of optimization which=
 may help the MME to know how to react on the requests towards the realm,=
 not specific to the HSS.
>
>         =20
>
>         Best Regards,
>
>         Susan
>
>         =20
>
>         -----Original Message-----
>
>         From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.=
com]
>
>         Sent: Thursday, November 28, 2013 6:30 PM
>
>         To: ext lionel.morand@orange.com ; ext Jouni Korhonen; Ben Campbell
>
>         Cc: dime@ietf.org  list
>
>         Subject: Re: [Dime] DOIC: Self-Contained OLRs
>
>         =20
>
>         Lionel,
>
>         =20
>
>         my understanding was that _the_ reporting end point provides _t=
he_ OLR.
>
>         =20
>
>         If we go for two OLRs in the answer we should indicate which OL=
R is the actual OLR created by the reporting end point and which OLR is a=
n additional OLR created by another node.
>
>         =20
>
>         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 re=
quest to the selected server and receiving the answer) returns a realm-ty=
pe OLR as the actual reporting-node-created OLR and optionally in additio=
n a host-type OLR as learned from the selected server.  The client may ig=
nore 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 op=
tionally insert a realm-type OLR as additional OLR to the answer. The cli=
ent may ignore the additional OLR.
>
>         =20
>
>         Ulrich
>
>         =20
>
>         =20
>
>         =20
>
>         -----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 Ca=
mpbell
>
>         Cc: dime@ietf.org  list
>
>         Subject: RE: [Dime] DOIC: Self-Contained OLRs
>
>         =20
>
>         Hi,
>
>         =20
>
>         There is no assumption on which entity is providing the realm o=
verload status. It could be provided an agent inserting this info in answ=
ers 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 s=
uccessful answer from the server for an initial request with only Dest-Re=
alm AVP, it should be possible to have both report types in the answer: o=
ne for the server itself, one for the realm for new request sent to the r=
ealm with only Dest-Realm AVP.
>
>         =20
>
>         Lionel
>
>         =20
>
>         -----Message d'origine-----
>
>         De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, U=
lrich (NSN - DE/Munich) Envoy=E9 : jeudi 28 novembre 2013 10:26 =C0 : ext=
 Jouni Korhonen; Ben Campbell Cc : dime@ietf.org  l=
ist Objet : Re: [Dime] DOIC: Self-Contained OLRs
>
>         =20
>
>         Hi,
>
>         =20
>
>         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 "r=
ealm" this indicates to the reacting end point that the reporting end poi=
nt is an agent (e.g. SFE) rather than a server. If the ReportType is "hos=
t" 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?
>
>         =20
>
>         Ulrich
>
>         =20
>
>         -----Original Message-----
>
>         From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Joun=
i Korhonen
>
>         Sent: Wednesday, November 27, 2013 11:44 PM
>
>         To: Ben Campbell
>
>         Cc: dime@ietf.org  list
>
>         Subject: Re: [Dime] DOIC: Self-Contained OLRs
>
>         =20
>
>         =20
>
>         On Nov 28, 2013, at 12:27 AM, Ben Campbell   wrote:
>
>         =20
>
>             Hi,
>
>             =20
>
>             I mentioned in another thread that I prefer putting an expl=
icit=20
>
>             ReportType AVP in an OLR, rather than
>
>         =20
>
>         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 t=
he OC-OLR. Even if the baseline does not have agent overload etc, the Rep=
ortType fits well to the "endpoint principle" we have in the draft. It in=
deed gives more tools to make a host vs. realm base decision on the react=
ing node and is plain more clear.
>
>         =20
>
>         I skip the rest of the mail.. too much text ;-)
>
>         =20
>
>         =20
>
>         - Jouni
>
>         =20
>
>         =20
>
>         =20
>
>         =20
>
>         =20
>
>             making a responding node infer the type or meaning of the O=
LR 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 sep=
arate thread.
>
>             =20
>
>             As currently described, a consumer of an OLR must infer sev=
eral things from other context. In most cases, that context is in the Dia=
meter answer that carries the OLR. For example, the OLR implicitly refers=
 to the application identified by the Application-Id field of the enclosi=
ng answer, the realm identified by Origin-Realm, and so on. This means th=
at the "meaning" of an OLR cannot be determined from the OLR contents alo=
ne; 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 complet=
ely.
>
>             =20
>
>             I think this approach is a mistake. I would greatly prefer =
that we explicitly include such values in the OLR itself, for multiple re=
asons:
>
>             =20
>
>             1) It's more complex to interpret implicit, contextual valu=
es than explicit values. The consumer cannot simply look at the OLR; it m=
ust 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 O=
LR contents get extended (assumedly following the same strategy as the ba=
se spec), the number of "context" avps that must be interpreted can grow =
large. This approach is error prone, and will likely encourage brittle, h=
ard-to-maintain code. Self-contained OLRs would keep all the information =
related to overload in one place. making for simpler implementations.
>
>             =20
>
>             2) It's more complex for the reporting node to send implici=
t values than explicit values. The sender cannot simply set the context t=
o 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 s=
end the OLR. This is particularly troublesome for agents, since they will=
 typically have to insert OLRs into answers created by other nodes.=20
>
>             =20
>
>             If the reporting node screws this up, the meaning of the OL=
R may change significantly. So again, implicit meaning gives us error pro=
ne implementations. Self-contained OLRs are simpler to create and send.
>
>             =20
>
>             3) Implicit values don't work at all for certain problems. =
For=20
>
>             example, if an agent needs to originate an OLR, it typicall=
y needs to=20
>
>             insert that OLR into an existing Diameter answer created by=
 a server.
>
>             It can't create its own answer without affecting the applic=
ation=20
>
>             state. If the responding node assumes the OLR comes from or=
 refers to=20
>
>             the node identified by the Origin-Host AVP in the enclosing=
 answer,=20
>
>             things break. (For examples of when an agent needs to send =
OLRs that=20
>
>             are distinct from those sent by a server, see Steve's agent=
 overload=20
>
>             draft, or my dh/dr example.)
>
>             =20
>
>             OTOH, explicit values will work for all cases where we need=
 to associate some arbitrary value with an OLR.
>
>             =20
>
>             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 ap=
plication. If overload reports were self-contained, one could just reuse =
the report format we specify here. But if the meaning of an OLR depends o=
n the way it's transported, this won't work. We would have to create a ne=
w or significantly modified OLR format if we found a need to transport OL=
Rs in different ways. Self-contained OLRs would allow much greater flexib=
ility.
>
>             =20
>
>             So, in summary, I think that self-contained OLRs would lead=
 to simpler implementations, less brittle deployments, and more flexibili=
ty for future evolution of standards.
>
>             =20
>
>             Thanks!
>
>             =20
>
>             Ben.
>
>             _______________________________________________
>
>             DiME mailing list
>
>             DiME@ietf.org 
>
>             https://www.ietf.org/mailman/listinfo/dime
>
>         =20
>
>         _______________________________________________
>
>         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
>
>         =20
>
>         _______________________________________________________________=
__________________________________________________________
>
>         =20
>
>         Ce message et ses pieces jointes peuvent contenir des informati=
ons 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'alteratio=
n, Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
>
>         =20
>
>         This message and its attachments may contain confidential or pr=
ivileged information that may be protected by law; they should not be dis=
tributed, used or copied without authorisation.
>
>         If you have received this email in error, please notify the sen=
der and delete this message and its attachments.
>
>         As emails may be altered, Orange is not liable for messages tha=
t have been modified, changed or falsified.
>
>         Thank you.
>
>         =20
>
>         =20
>
>         _______________________________________________
>
>         DiME mailing list
>
>         DiME@ietf.org 
>
>         https://www.ietf.org/mailman/listinfo/dime
>
>         =20
>
>     =20
>
> =20
>


--------------060404090105090505090501
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Ulrich,

      

      I don't see why there would ever be two (or more) associations for
      requests sent through an agent.  I'm trying to understand what you
      are proposing and then how it would be signaled.

    

    Is it correct that the model you are
        proposing as a DOIC-Association per report type?

        

        Steve

        

      
    
On 12/12/13 10:21 AM, Wiehe, Ulrich
      (NSN - DE/Munich) wrote:

    

    

      
      
      
      

        
Steve,

        
 

        
so you mean its allways case a) or allways case
            b) depending on local configuration in the agent and not
            depending on message content.

        
 

        
Anyway, would you agree that in case a) the two
            DOIC associations may have independent different supported
            features?

        
 

        
Ulrich

        
 

        

          

            
From: ext Steve Donovan
                [mailto:srdonovan@usdonovans.com]
                

                Sent: Thursday, December 12, 2013 2:52 PM

                To: Wiehe, Ulrich (NSN - DE/Munich);
                dime@ietf.org

                Subject: Re: [Dime] DOIC: Self-Contained OLRs

          

        

        
 

        
Ulrich,

          

          My assumption is that and end-point is an end-point for all
          messages sent between the two end-points.

          

          Steve

        

          
On 12/12/13 5:17 AM, Wiehe, Ulrich (NSN -
            DE/Munich) wrote:

        

        

          
Steve,

          
 

          
Isn’t it so that the agent may decide (e.g.
              based on the absence of Destination host in the received
              request and based of its ability/willingness to select the
              server)

          
either a) to take the role of an endpoint or
              b) to be transparent with regard to OC AVPs.

          
In case a) we end up with two DOIC
              associations, one between client and agent, another one
              between agent and server. Different DOIC associations may
              have different advertised/negotiated features i.e. agent
              and server may use window algorithm, but client and agent
              use loss algorithm. Therefore the host-type window OLR
              must not be sent unchanged to the client.

          
In case b) being transparent includes not
              inserting realm-type AVPs.

          
 

          
We end up with receiving not more than one
              OLR at the client.

          
 

          
Ulrich

          
 

          
 

          
 

          
 

          

            

              
From: DiME [mailto:dime-bounces@ietf.org]
                  On Behalf Of ext Steve Donovan

                  Sent: Wednesday, December 11, 2013 2:27 PM

                  To: dime@ietf.org

                  Subject: Re: [Dime] DOIC: Self-Contained OLRs

            

          

          
 

          
Susan,

            

            The use case for an agent that sits between a DOIC client
            and a DOIC server is Realm overload, which the agent might
            be responsible for reporting.  This will particularly be the
            case when there are multiple servers sitting behind the
            agent.  This might be considered a server farm, as you
            indicate, but we don't have a good definition of server
            farm, so I'm being explicit.

            

            In this case, the agent must handle to types of
            occurrences.  

            

            1) Server overload - In this case the agent will receive a
            node overload report from the server.  The agent should (I'm
            not sure if we have defined this behavior in the draft yet)
            send the report unchanged to the client.  The agent will
            also most likely use the contents of the report to determine
            the realm overload state.

            

            2) Realm overload - In this case the agent will insert an
            overload report into the appropriate answer messages.

            

            Is this consistent with your thinking?

            

            Regards,

            

            Steve

          

            
On 12/11/13 12:24 AM, Shishufeng
              (Susan) wrote:

          

          

            
Hi Ulrich,

            
 

            
I'm not sure if you are taking the overload of agent into account for which we decided to not consider for the time being. If not, I couldn't understand why an agent which does not serve for a server farm needs to be a DOIC endpoint between the client and server if both of them support overload control. My understanding is that if there is the need for an agent to take a role of a DOIC endpoint between a specific server and client, it would always do that, otherwise, it just transfer the overload information of the server to the client.

            
 

            
Best Regards,

            
Susan

            
 

            
-----Original Message-----

            
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] 

            
Sent: Tuesday, December 10, 2013 6:15 PM

            
To: Shishufeng (Susan); ext lionel.morand@orange.com; ext Jouni Korhonen; Ben Campbell

            
Cc: dime@ietf.org list

            
Subject: RE: [Dime] DOIC: Self-Contained OLRs

            
 

            
Hi Susan,

            
 

            
if the agent does not take the role of a DOIC endpont then the feature negotiation/adverisement is between client and server and one host type OLR is sent from server to client. For the agent this is all transparent and there is no need for the agent to support any DOIC feature.

            
However, if the agent takes the role of an DOIC endpoint then the feature negotiation/advertisement is between client and agent and a separate feature negotiation/advertisement is between agent and server. An OLR sent from server to agent is in-context with the supported features of server and agent but possibly not in-context with supported features of client and agent and therefore must not be (blindly) sent to the client. And in fact there is also no need to do that. For subsequent requests that contain the desination host of the server, the agent will not take the role of a DOIC endpoint.

            
 

            
Best regards

            
Ulrich

            
 

            
-----Original Message-----

            
From: ext Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]

            
Sent: Tuesday, December 10, 2013 4:02 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

            
 

            
Hi Ulrich,

            
 

            
Thanks for your clarification. I understood the scenario, while from my point of view, if the agent that selects the HSS is not configured to serve as a load balancer for the HSS, the agent should not change any supported/negotiated features between C and S, that would be the normal case. If the agent serve as a load balancer for the HSS, the subsequent request from C towards the S would always go via the agent, in this case whatever the associations between C and A, between A and S are the same or not, it doesn't matter. With an E2E solution as we agreed, I don't see the problem with it.

            
 

            
Best Regards,

            
Susan

            
 

            
-----Original Message-----

            
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]

            
Sent: Monday, December 09, 2013 7:43 PM

            
To: Shishufeng (Susan); ext lionel.morand@orange.com; ext Jouni Korhonen; Ben Campbell

            
Cc: dime@ietf.org list

            
Subject: RE: [Dime] DOIC: Self-Contained OLRs

            
 

            
Hi Susan,

            
 

            
let me come back to your S6a example.

            
 

            
The MME (C) sends a request without Destination-Host towards the HPLMN (realm). There must be an agent (A) in the HPLMN (realm) that selects the HSS (S). 

            
We would have two distinct DOIC associations: one between C and A, another between A and S (see figure 5 in clause 5.1). The two DOIC associations may have different supported/negotiated features. An OLR sent from S to A based on supported/negotiated features valid for the DOIC association between A and S is at least problematic (out-of context) when sent from A to C.

            
 

            
When the MME (C) sends a subsequent request with Destination-Host towards the HSS (S), there is no agent that selects the HSS (as the HSS is already selected). For this session there is only one DOIC association between C and S (see figure 3 in clause 5.1) and OLRs sent from S to C are not problematic.

            
 

            
Best regards

            
Ulrich

            
 

            
 

            
-----Original Message-----

            
From: ext Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]

            
Sent: Monday, December 09, 2013 11:30 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

            
 

            
Hi Ulrich,

            
 

            
I have different views. In any case, I think the host-type OLR should not be ignored by the clients. On the contrary, the realm-type OLR can be thought as optimization, which may not even be needed at all for all cases, especially in 3GPP. Here is an example of S6a, in the case the first attach request comes from the UE to the MME, the MME can only derive the realm information, and sends a request without Destination-Host towards the HPLMN. Since the subscriber corresponding to the UE belongs to a specific HSS, and the HSS may provide its overload report to the MME, and the MME is able to know how to react regarding the requests towards the HSS, which would be the normal case. Whether Realm report will be provided by the HSS or the agent serving the HSS is kind of optimization which may help the MME to know how to react on the requests towards the realm, not specific to the HSS.

            
 

            
Best Regards,

            
Susan

            
 

            
-----Original Message-----

            
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]

            
Sent: Thursday, November 28, 2013 6:30 PM

            
To: ext lionel.morand@orange.com; ext Jouni Korhonen; Ben Campbell

            
Cc: dime@ietf.org list

            
Subject: 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.

            
 

            
 

            
_______________________________________________

            
DiME mailing list

            
DiME@ietf.org

            
https://www.ietf.org/mailman/listinfo/dime

            
 

          

          
 

        

        
 

      

    

    

  


--------------060404090105090505090501--

From jean-jacques.trottin@alcatel-lucent.com  Mon Dec 16 06:36:25 2013
Return-Path: 
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 06A651AE01E for ; Mon, 16 Dec 2013 06:36:25 -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 I8XM7xquotii for ; Mon, 16 Dec 2013 06:36:23 -0800 (PST)
Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id E80E81ADF76 for ; Mon, 16 Dec 2013 06:36:22 -0800 (PST)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id rBGEaJrd014001 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 16 Dec 2013 08:36:20 -0600 (CST)
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id rBGEaIGY028405 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 16 Dec 2013 15:36:18 +0100
Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.241]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Mon, 16 Dec 2013 15:36:18 +0100
From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
To: "dime@ietf.org" 
Thread-Topic: [Dime] Conclusion for the Report Type
Thread-Index: AQHO9NZTfmjwZl8bgUqgMbcmsBQ2dppM0z6AgAAtMICACeu/gA==
Date: Mon, 16 Dec 2013 14:36:18 +0000
Message-ID: 
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DCBC@DEMUMBX014.nsn-intra.net> <453156F8-9090-46D4-BF8E-A877F40EE3AC@gmail.com>  <2B4A6453-CBF0-48BE-B917-96B279229D3C@gmail.com>
In-Reply-To: <2B4A6453-CBF0-48BE-B917-96B279229D3C@gmail.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.41]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39
Subject: Re: [Dime] Conclusion for the Report Type
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Dec 2013 14:36:25 -0000

Hi Jouni

I am also fine for the statements you proposed.

My understanding for 4) about instances is the following=20
- when an OLR with host report type is present in a message; it is the only=
 OLR instance with this report type
- same for OLR with a realm report type
- but you may have an OLR host report type and another OLR with realm repor=
t type in the same message.

Is my understanding correct?

Best regards=20

JJacques=20

-----Message d'origine-----
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Jouni Korhonen
Envoy=E9=A0: mardi 10 d=E9cembre 2013 08:57
=C0=A0: Nirav Salot
Cc=A0: dime@ietf.org list
Objet=A0: Re: [Dime] Conclusion for the Report Type


On Dec 10, 2013, at 7:15 AM, Nirav Salot (nsalot)  wrote:

> Jouni,
>=20
> I am fine with the principles you have mentioned below for Report Type.
> I also prefer to use enumerated type for this AVP if that does not risk t=
he extendibility of this AVP.
>=20


Ok. Good.

- Jouni


> Regards,
> Nirav.
>=20
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen
> Sent: Monday, December 09, 2013 5:30 PM
> To: dime@ietf.org list
> Subject: [Dime] Conclusion for the Report Type
>=20
> Folks,
>=20
> We need a conclusion here so that I can actually write something into the=
 -01. How about the following (I try to reflect as many points given here a=
s possible):
>=20
> 1) The basic principle for the Report Type use is that only one
>   OLR per report type is allowed unless the report type and the
>   OLR reflecting the new report type define exact semantics how
>   to differentiate between multiple OLRs with the same report
>   type. In 3GPP context, for example, a report type with an AVP
>   that identifies an APN could be such a differentiator.. and that
>   would need a new report type where an implementation exactly
>   knows to look for this additional AVP without guesswork or=20
>   fuzzy heuristics.
>=20
> 2) A new report type or a set of new report types require a new
>   feature to be allocated/defined so that both endpoints know how
>   to handle the new report type that was defined after the
>   publication of the baseline specification. The handling of the
>   new report types must be defined (along with the new AVPs it
>   might need to be included into the OC-OLR AVP).
>=20
> 3) With 2) in place I do not care whether the OC-Report-Type is
>   enumerated or unsigned (flag vector?). I still favour Enumerated
>   myself as it forces the protocol designer to come up with a=20
>   cleaner design ;)
>=20
> 4) For the baseline we only define host and realm report types.
>   We do not allow multiple OLRs with these report types i.e.
>   single instances of OLRs with host and/or realm are allowed.
> =20
> - Jouni
> _______________________________________________
> 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

From nsalot@cisco.com  Mon Dec 16 07:42:14 2013
Return-Path: 
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 AEA811AE33A for ; Mon, 16 Dec 2013 07:42:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.038
X-Spam-Level: 
X-Spam-Status: No, score=-15.038 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.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 L4qC9WIJA7s9 for ; Mon, 16 Dec 2013 07:42:07 -0800 (PST)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 75A3F1AE313 for ; Mon, 16 Dec 2013 07:42:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=56528; q=dns/txt; s=iport; t=1387208526; x=1388418126; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=fpFnYxK6rKVZUEoxRcUJrsOTk3Jc3SU3swddT+Gr4Cg=; b=KS7O2jrM8a7kp8mSTUn7F5FummhwWgwyh1Ni6LouS2M0y/N5v+DGY/UO +zECpxusVqG7zL6Vk+b9cqvXPvKedo1e01SdWhRN0Z5gzx7vUI2Vku+RY h6sTOvaKo8/jpf9FOo/7JDbIV6aLjxMHSDIsjnVFPWwQFGo9iZ+4gsVKf 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ak8FAFEer1KtJXG8/2dsb2JhbABQCYJGRDhVuHKBJRZ0giUBAQEDAQEBARcBEkELBQcEAgEIDgMEAQELFgEGByEGCxQJCAIEAQ0FCBOHVQMJCA3BDQ2HARMEjQaBOCotBAYBBoMdgRMBA5QzgXiORYU6gyqCKg
X-IronPort-AV: E=Sophos;i="4.95,495,1384300800";  d="scan'208,217";a="291793537"
Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-2.cisco.com with ESMTP; 16 Dec 2013 15:42:03 +0000
Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id rBGFg3Mt009604 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 16 Dec 2013 15:42:03 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.227]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Mon, 16 Dec 2013 09:42:03 -0600
From: "Nirav Salot (nsalot)" 
To: Steve Donovan , Jouni Korhonen 
Thread-Topic: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3
Thread-Index: AQHO90VQs8ahl6t/j0WtaMBOVpqI85pQvUrggAZqGID//9O4MA==
Date: Mon, 16 Dec 2013 15:42:02 +0000
Message-ID: 
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DB1B@DEMUMBX014.nsn-intra.net>  <52A5E902.20605@usdonovans.com> <7475B713-1104-4791-96B1-CE97632A0D69@nostrum.com>  <5BCBA1FC2B7F0B4C9D935572D90006681519E476@DEMUMBX014.nsn-intra.net> <1CD20507-B0FE-4367-804A-B831734CF060@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E6DC@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D90006681519E712@DEMUMBX014.nsn-intra.net> <4A151D70-0291-4238-85B1-03BB54B361E6@gmail.com> <52A864FF.10705@usdonovans.com>   <52A9C62A.6010207@usdonovans.com>  <52AEEF27.50208@usdonovans.com>
In-Reply-To: <52AEEF27.50208@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.65.72.21]
Content-Type: multipart/alternative; boundary="_000_A9CA33BB78081F478946E4F34BF9AAA014D33C5Axmbrcdx10ciscoc_"
MIME-Version: 1.0
Cc: Ben Campbell , "dime@ietf.org list" 
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Dec 2013 15:42:14 -0000

--_000_A9CA33BB78081F478946E4F34BF9AAA014D33C5Axmbrcdx10ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Steve,

> The issue with considering only the last report is that it introduces the=
 potential for thrashing between different values.  This could make the ove=
rload event even worse.
I am not sure about this. The two agents are not synchronized only for a ve=
ry small window of time. But even then their reports should be reflecting t=
he status of the realm, approximately if not accurately.
So I don't think using one of the reports will make the situation worse.

I did not understand your argument regarding the security.
The client does not know the agent's identity anyway. So adding agent's ide=
ntity in the overload-report is not going to change the security considerat=
ion anyway.

Regards,
Nirav.

From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Monday, December 16, 2013 5:47 PM
To: Nirav Salot (nsalot); Jouni Korhonen
Cc: Ben Campbell; dime@ietf.org list
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comment=
s to 4.3

Nirav,

The issue with considering only the last report is that it introduces the p=
otential for thrashing between different values.  This could make the overl=
oad event even worse.

I agree that this should be a rare case.  I still think, however, that we n=
eed to have defined behavior.

One other argument for including the sender of the overload report in the r=
eport itself is security.  The ability of a bad actor to insert a malicious=
 overload report can be a very effective DOS attack.  I know we have said w=
e aren't addressing security yet but this seems pretty short sighted.  Bein=
g able to establish that the identity of the sender of an overload report w=
ill be an important part of the security solution.  We should take this ste=
p in that direction.

Steve
On 12/12/13 10:26 AM, Nirav Salot (nsalot) wrote:
Steve,

So as I understand it is not a common case for different agent to provide d=
ifferent view of the same realm and this may have happen during a small win=
dow when synchronization has not taken place between the geographically dis=
tributed agents.
Right?

If so, I can understand the following part of your proposal.
One proposal for how we deal with the fact that different reports can have =
different values is to have the reacting node treat the first reporting nod=
e as the authority for reporting realm overload state for that overload ins=
tance.

i.e. I can understand to define some behavior for the reacting node to hand=
le the case (which is anyway rare case) when two agents provide different r=
ealm-report for the same report.
The behavior could be simply to consider only the last report when two agen=
ts have sent two different reports of the same realm. (And this will also w=
ork when the same agent has sent two different realm-reports, purposefully =
- e.g. due to the change in the realm overload).
But this still does not require adding of agent's identity in the overload-=
report.

Regards,
Nirav.

From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Thursday, December 12, 2013 7:50 PM
To: Nirav Salot (nsalot); Jouni Korhonen
Cc: Ben Campbell; dime@ietf.org list
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comment=
s to 4.3

Nirav,

See inline.

Steve
On 12/12/13 6:40 AM, Nirav Salot (nsalot) wrote:

All,



I do not understand this discussion regarding different agents of the same =
realm having different view of the realm and provide different overload rep=
ort.
We can make the statement that all senders of realm reports should send the=
 same report.  This does not guarantee that it will always happen.  If agen=
ts are sending the report, they are generally distributed elements.  In ver=
y large networks, this distribution can span continents.  There will be a l=
ag in the "synchronization" of the realm overload information.

My concern is that we have well defined behavior for when a reactor receive=
s conflicting realm reports.  We need to avoid thrashing between different =
reduction levels, which could make the overload situation worse.





Additionally, I also do not understand the proposal of adding identity of t=
he agent generating "realm report" into the report.
Adding the endpoint identity is needed to allow the reacting node to know t=
hat it is receiving two different views of Realm overload from two differen=
t reporting end-points.





What is the use of this identity at the reacting node when the report is re=
alm report? Why should the reacting node care who generated the realm repor=
t?
One proposal for how we deal with the fact that different reports can have =
different values is to have the reacting node treat the first reporting nod=
e as the authority for reporting realm overload state for that overload ins=
tance.  In this case, the reacting node would ignore reports received from =
other reporting nodes. In order to ignore reports from non authoritative en=
dpoints requires the reacting node to know which endpoints send which repor=
ts.







Regards,

Nirav.



-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen

Sent: Thursday, December 12, 2013 5:06 PM

To: Steve Donovan

Cc: Ben Campbell; dime@ietf.org list

Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comment=
s to 4.3



Steve,



On Dec 11, 2013, at 3:13 PM, Steve Donovan  wrote:



Jouni,



We need the sequence number to be strictly increasing.  I don't see the nee=
d for it to increase in uniform amounts.  Using time does fit these require=
ments.  I'm ok with using time as long as we don't call the AVP timestamp.



Ulrich does bring up an interesting use case, where a client is receiving r=
ealm reports for the same realm from different agents.  We need to define t=
he clients behavior in this case.



Any suggestions? I mean agents may have hugely different view of the realm =
if they are acting on their own.



Presumably the client needs to be able to determine who generated the realm=
 report.  This cannot be determine based on the content of the message or t=
he connection on which the message arrived.  It seems like we might need "R=
eport Generator Diameter ID" in the overload report specifically for Realm =
reports.



Once the client is able to differentiate between realm reports sent by diff=
erent agents (or servers) we need logic defining how the client deals with =
a new overload report.



I need now to check one of the basic assumptions on DOIC now so that we hav=
e the same understanding. I went back to the endpoint text in Section 5.1. =
There, for example in Figures

4 and 5 the DOIC association and the endpoint assumption does does not work=
 IMHO because we have no endpoint identity in the OLR. In order the endpoin=
t assumption to work (as I drew it on the white board in Porto), it would r=
equire as many Diameter level sessions as there are DOIC associations.



So.. has assumptions shifted in a meanwhile and I have just not paid attent=
ion?



I see a couple of options (others will probably see options I am missing):



- Use the last received realm report - This introduces the possibility of t=
hrashing between two different reduction values and different durations.  N=
ote that this approach does not require the source of the report to be incl=
uded in the report.



- Only listen to one source of realm overload - The approach would be to re=
member who sent the first overload report from the realm and ignore realm o=
verload reports from other sources.  This behavior would likely be constrai=
ned to a single occurrence of realm overload.  Meaning that the "memory" of=
 the report source would only last as long as that overload event persists.=
  Once the overload event goes away, the report source would be forgotten a=
nd a new source could be used for the next occurrence.



On the surface, the second approach looks better to me.



Or add the identity of the OLR originator explicitly if it cannot be determ=
ined implicitly (i.e. from the Diameter message's Origin-Host/Realm).



Or assume the endpoint really is the endpoint in DOIC and Diameter session =
sense.



- Jouni





Steve



On 12/11/13 2:15 AM, Jouni wrote:

Ulrich,



I might be slow but.. Section 4.4 says



   control endpoints.  The sequence number is only required to be unique

   between two overload control endpoints and does not need to be



Unique between two endpoints..



Section 5.1 talks about endpoints:



   of an arbitrary Diameter network.  The overload control information

   is exchanged over on a "DOIC association" between two communication

   endpoints.  The endpoints, namely the "reacting node" and the

   "reporting node" do not need to be adjacent Diameter peer nodes,

nor



So if your agents inject realm reports, they need to be endpoints to

the client. Similar to Figure 5. Therefore the sequence number spaces

between

C-A1 and C-A2 are separate.



Now it is not clear to me, whether in your reasoning the C would see

the server identity (as the endpoint) when there is an active "DEP

agent" on the path. That would not clearly work and not be align with

the endpoint assumption.



Note that at some point of time we had (at least on a discussion

level in f2f meeting) report originator identity in the OLR. That

would make endpoint identification trivial. Now a "DEP agent" needs

to act as a "server" for its clients in order to appear as an endpoint.



- Jouni



ps: still think the use of Time is simpler..





On Dec 11, 2013, at 9:43 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:





That's not predictable. It may be the same server in some cases, and differ=
ent servers in other cases.



-----Original Message-----

From: ext Jouni [

mailto:jouni.nospam@gmail.com

]

Sent: Wednesday, December 11, 2013 8:38 AM

To: Wiehe, Ulrich (NSN - DE/Munich)

Cc: Ben Campbell;

dime@ietf.org

 list; Steve Donovan

Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI:

comments to 4.3





Ulrich,



On Dec 11, 2013, at 9:21 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:





Jouni,



ad 1. "monotonically" does not express your intention. What we are looking =
for may be "stepwise with fixed step".



Ad 2. Is not necessarily a mistake that could result in out-of-sequence seq=
uence numbers. When a client C sends a realm-type requests towards any serv=
er in the realm, an agent A1 that selects the server would send back the re=
alm-type OLR with sequence number s1. The next realm-type request sent by C=
 (that survived the throttling) may take a path that does not include A1 bu=
t A2. A2 then selects the server and sends back a sequence number s2. Nothi=
ng ensures that s1 and s2 are in sequence.



Would the server in both cases (via A1 and A2) be the same?



- Jouni







Ulrich





-----Original Message-----

From: ext Jouni Korhonen [

mailto:jouni.nospam@gmail.com

]

Sent: Tuesday, December 10, 2013 10:31 PM

To: Wiehe, Ulrich (NSN - DE/Munich)

Cc: Ben Campbell;

dime@ietf.org

 list; Steve Donovan

Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI:

comments to 4.3



Ulrich,



On Dec 10, 2013, at 4:31 PM, "Wiehe, Ulrich (NSN - DE/Munich)"



 wrote:





Jouni,



1. I find the texts

a) "The sequence number ... does not need to be monotonically increasing"

and



Means the delta from old-seqno to new-seqno can be any non-negative

integer (within the given limits) not something fixed step/delta

(like +1). As long as "new-seqno >=3D old-seqno" holds we are fine.





b) "...the new sequence number MUST be greater or equal than the old sequen=
ce number..."

contradicting.

Can you please clarify.



See above. (mind the overflow case)





2. The expected behaviour when receiving an out-of-sequence sequence number=
 within OC-OLR is described in 4.3:

"The receiver SHOULD discard an OC-OLR AVP with a sequence number that is l=
ess than previously received one."

I don't find this very robust. Once a higher sequence number (received erro=
neously by mistake) is accepted you cannot (easily) recover.



I find it more robust in a sense that I should not care about stale old inf=
ormation.

However, since we are piggybacking (by popular demand) we have

little room for seqno re-sync negotiation.



What is the mistake you refer here? A misbehaving implementation?

In that case, it deserves to get a manual intervention once figured

out by admins checking alarms and logs. If the mistake is due other

things, like endpoints being out of sync, we currently have no written down=
 mechanism to survive that.





3. The expected behaviour when receiving an out-of-sequence sequence number=
 within the OC-Supported-Features AVP is not described. What is the intenti=
on here?



No intention. Just a sloppy specification. You are right that

something needs to be done & clarified here. (again the semantics

of Time would nice..)



I'll propose something. Others should too ;)



- Jouni





Ulrich



-----Original Message-----

From: DiME [

mailto:dime-bounces@ietf.org

] On Behalf Of ext Jouni Korhonen

Sent: Tuesday, December 10, 2013 8:28 AM

To: Ben Campbell;

dime@ietf.org

 list; Steve Donovan

Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re:

OVLI: comments to 4.3





Fine.. lets define then the sequence number semantics. Basic

unsigned integer math. The text proposal is the following:



4.4.  OC-Sequence-Number AVP



The OC-Sequence-Number AVP (AVP code TBD3) is type of Unsigned64.

Its usage in the context of the overload control is described in

Sections 4.1 and 4.3.



>From the functionality point of view, the OC-Sequence-Number AVP

MUST be used as a non-volatile increasing counter between two

overload control endpoints.  The sequence number is only required

to be unique between two overload control endpoints and does not

need to be monotonically increasing.



When comparing two sequence numbers, the new sequence number MUST

be greater or equal than the old sequence number within a window

that is half of the size of the maximum sequence number. This

allows a simple handling of the sequence number overflow using

unsigned integer arithmeticf:



  #define WINDOW 0x8000000000000000ULL



  bool verify_seqnum( uint64_t newsn, uint64_t oldsn ) {

      if (newsn - oldsn <=3D WINDOW)

          // newsn >=3D oldsn

          return true;

      } else

          // outside window or newsn < oldsn

          return false;

      }

  }







The above should even work is someone shovels NTP times into

sequence numbers with a blind typecasting.



- Jouni



On Dec 10, 2013, at 12:34 AM, Ben Campbell 

 wrote:





On Dec 9, 2013, at 10:00 AM, Steve Donovan 

 wrote:





Jouni,



I propose that we keep the name OC-Sequence-Number but that we use the Time=
 type for OC-Sequence-Number.  It is misleading and potentially confusing t=
o call it OC-Time-Stamp.





I could live with that, although I would rather just define the expected pr=
operties of the sequence number, and leave the implementation up to the imp=
lementor. I assume your reasoning for not calling it a timestamp is that yo=
u do not want people to try to use it as a time base reference. If so, then=
 we don't require any connection to a clock. We just need it to be monotoni=
cally increasing.





We might consider expanding on the format of the AVP to make it something l=
ike Session-ID, where it is a concatenation of the Diameter-ID of the gener=
ating node and a timestamp.  This might help the reacting node keep track o=
f which sequence number it has received.





Do we need a uniqueness across multiple nodes property? If so, why?





Steve



On 12/9/13 5:37 AM, Jouni Korhonen wrote:



Folks



Could we conclude on the sequence number vs. time stamp vs. something else?

We got more important places to spend our energy than this ;)



My proposal is the following (based on the original pre-00 design):



o We change the OC-Sequence-Number to OC-Time-Stamp in all occurrences

in the -01.

o We use RFC6733 Time type for the OC-Time-Stamp. RFC6733 gives us

already exact definition how to handle the AVP.

o Define that the OC-Time-Stamp is the time of the creation of the

"original" AVP within whose context the time stamp is present.

o The OC-Time-Stamp AVP uniqueness is still considered to be in scope

of the communicating endpoints.

o The time stamp can be used to quickly determine if the content of

the encapsulating AVP context has changed (among other properties).

This would be useful specifically in the future when the encapsulating

grouped AVPs  grow in size and functionality.





- Jouni



_______________________________________________

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







_______________________________________________

DiME mailing list

DiME@ietf.org

https://www.ietf.org/mailman/listinfo/dime





--_000_A9CA33BB78081F478946E4F34BF9AAA014D33C5Axmbrcdx10ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Steve,<=
/p>

 <=
/p>

> The issue wit=
h considering only the last report is that it introduces the potential for =
thrashing between different values.  This could make the overload
 event even worse.


I am not sure about this.=
 The two agents are not synchronized only for a very small window of time. =
But even then their reports should be reflecting the status
 of the realm, approximately if not accurately.


So I don’t think us=
ing one of the reports will make the situation worse.



 <=
/p>

I did not understand your=
 argument regarding the security.


The client does not know =
the agent's identity anyway. So adding agent's identity in the overload-rep=
ort is not going to change the security consideration anyway.


 <=
/p>

Regards,


Nirav.<=
/p>

 <=
/p>





From: Steve Donovan [mailto:srdonovan@usdonovans.com]


Sent: Monday, December 16, 2013 5:47 PM

To: Nirav Salot (nsalot); Jouni Korhonen

Cc: Ben Campbell; dime@ietf.org list

Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: =
comments to 4.3






 


Nirav,



The issue with considering only the last report is that it introduces the p=
otential for thrashing between different values.  This could make the =
overload event even worse.



I agree that this should be a rare case.  I still think, however, that=
 we need to have defined behavior.



One other argument for including the sender of the overload report in the r=
eport itself is security.  The ability of a bad actor to insert a mali=
cious overload report can be a very effective DOS attack.  I know we h=
ave said we aren't addressing security yet
 but this seems pretty short sighted.  Being able to establish that th=
e identity of the sender of an overload report will be an important part of=
 the security solution.  We should take this step in that direction.


Steve




On 12/12/13 10:26 AM, Nirav Salot (nsalot) wrote:






Steve,<=
/p>

 <=
/p>

So as I understand it is =
not a common case for different agent to provide different view of the same=
 realm and this may have happen during a small window when
 synchronization has not taken place between the geographically distributed=
 agents.


Right?<=
/p>

 <=
/p>

If so, I can understand t=
he following part of your proposal.


One proposal for how we deal with the fact that diff=
erent reports can have different values is to have the reacting node treat =
the first reporting node as the authority for reporting realm overload stat=
e for that overload instance.


 <=
/p>

i.e. I can understand to =
define some behavior for the reacting node to handle the case (which is any=
way rare case) when two agents provide different realm-report
 for the same report.


The behavior could be sim=
ply to consider only the last report when two agents have sent two differen=
t reports of the same realm. (And this will also work when
 the same agent has sent two different realm-reports, purposefully – =
e.g. due to the change in the realm overload).


But this still does not r=
equire adding of agent's identity in the overload-report.=



 <=
/p>

Regards,


Nirav.<=
/p>

 <=
/p>





From: Steve Donovan [mailto:srdonovan@usdonovans.com]


Sent: Thursday, December 12, 2013 7:50 PM

To: Nirav Salot (nsalot); Jouni Korhonen

Cc: Ben Campbell; dime@ietf.org=
 list

Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: =
comments to 4.3






 


Nirav,



See inline.



Steve




On 12/12/13 6:40 AM, Nirav Salot (nsalot) wrote:






All,


 


I do not understand this discussion regarding different agents of the =
same realm having different view of the realm and provide different overloa=
d report.




We can make the statement that all senders of realm =
reports should send the same report.  This does not guarantee that it =
will always happen.  If agents are sending the report, they are genera=
lly distributed elements.  In very large networks,
 this distribution can span continents.  There will be a lag in the &q=
uot;synchronization" of the realm overload information.



My concern is that we have well defined behavior for when a reactor receive=
s conflicting realm reports.  We need to avoid thrashing between diffe=
rent reduction levels, which could make the overload situation worse.








 


Additionally, I also do not understand the proposal of adding identity=
 of the agent generating "realm report" into the report.


Adding the endpoint identity is needed to allow the =
reacting node to know that it is receiving two different views of Realm ove=
rload from two different reporting end-points.








 


What is the use of this identity at the reacting node when the report =
is realm report? Why should the reacting node care who generated the realm =
report?


One proposal for how we deal with the fact that diff=
erent reports can have different values is to have the reacting node treat =
the first reporting node as the authority for reporting realm overload stat=
e for that overload instance.  In
 this case, the reacting node would ignore reports received from other repo=
rting nodes. In order to ignore reports from non authoritative endpoints re=
quires the reacting node to know which endpoints send which reports.








 


 


Regards,


Nirav.


 


-----Original Message-----


From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of Jouni Korhonen


Sent: Thursday, December 12, 2013 5:06 PM


To: Steve Donovan


Cc: Ben Campbell; dime@ietf.org l=
ist


Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: co=
mments to 4.3


 


Steve,


 


On Dec 11, 2013, at 3:13 PM, Steve Donovan <srdonovan@usdonovans.com> wrote:

 




Jouni,


 


We need the sequence number to be strictly increasing.  I don't s=
ee the need for it to increase in uniform amounts.  Using time does fi=
t these requirements.  I'm ok with using time as long as we don't call=
 the AVP timestamp.


 


Ulrich does bring up an interesting use case, where a client is receiv=
ing realm reports for the same realm from different agents.  We need t=
o define the clients behavior in this case.  




 


Any suggestions? I mean agents may have hugely different view of the r=
ealm if they are acting on their own.


 




Presumably the client needs to be able to determine who generated the =
realm report.  This cannot be determine based on the content of the me=
ssage or the connection on which the message arrived.  It seems like w=
e might need "Report Generator Diameter ID" in the overload repor=
t specifically for Realm reports.  


 


Once the client is able to differentiate between realm reports sent by=
 different agents (or servers) we need logic defining how the client deals =
with a new overload report.  




 


I need now to check one of the basic assumptions on DOIC now so that w=
e have the same understanding. I went back to the endpoint text in Section =
5.1. There, for example in Figures


4 and 5 the DOIC association and the endpoint assumption does does not=
 work IMHO because we have no endpoint identity in the OLR. In order the en=
dpoint assumption to work (as I drew it on the white board in Porto), it wo=
uld require as many Diameter level sessions as there are DOIC associations.=



 


So.. has assumptions shifted in a meanwhile and I have just not paid a=
ttention?


 




I see a couple of options (others will probably see options I am missi=
ng):


 


- Use the last received realm report - This introduces the possibility=
 of thrashing between two different reduction values and different duration=
s.  Note that this approach does not require the source of the report =
to be included in the report.


 


- Only listen to one source of realm overload - The approach would be =
to remember who sent the first overload report from the realm and ignore re=
alm overload reports from other sources.  This behavior would likely b=
e constrained to a single occurrence of realm overload.  Meaning that =
the "memory" of the report source would only last as long as that=
 overload event persists.  Once the overload event goes away, the repo=
rt source would be forgotten and a new source could be used for the next oc=
currence.


 


On the surface, the second approach looks better to me.



 


Or add the identity of the OLR originator explicitly if it cannot be d=
etermined implicitly (i.e. from the Diameter message's Origin-Host/Realm).<=
o:p>


 


Or assume the endpoint really is the endpoint in DOIC and Diameter ses=
sion sense.


 


- Jouni


 




 


Steve


 


On 12/11/13 2:15 AM, Jouni wrote:




Ulrich,


 


I might be slow but.. Section 4.4 says


 


   control endpoints.  The sequence number is only requ=
ired to be unique


   between two overload control endpoints and does not need =
to be


 


Unique between two endpoints..


 


Section 5.1 talks about endpoints:


 


   of an arbitrary Diameter network.  The overload cont=
rol information


   is exchanged over on a "DOIC association" betwe=
en two communication


   endpoints.  The endpoints, namely the "reacting=
 node" and the


   "reporting node" do not need to be adjacent Dia=
meter peer nodes, 


nor


 


So if your agents inject realm reports, they need to be endpoints to <=
o:p>


the client. Similar to Figure 5. Therefore the sequence number spaces =



between


C-A1 and C-A2 are separate.


 


Now it is not clear to me, whether in your reasoning the C would see <=
o:p>


the server identity (as the endpoint) when there is an active "DE=
P 


agent" on the path. That would not clearly work and not be align =
with 


the endpoint assumption.


 


Note that at some point of time we had (at least on a discussion =



level in f2f meeting) report originator identity in the OLR. That 


would make endpoint identification trivial. Now a "DEP agent"=
; needs 


to act as a "server" for its clients in order to appear as a=
n endpoint.


 


- Jouni


 


ps: still think the use of Time is simpler..


 


 


On Dec 11, 2013, at 9:43 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:


 


 




That's not predictable. It may be the same server in some cases, and d=
ifferent servers in other cases.


 


-----Original Message-----


From: ext Jouni [


mailto:jouni.nospam@gmail.co=
m


]


Sent: Wednesday, December 11, 2013 8:38 AM


To: Wiehe, Ulrich (NSN - DE/Munich)


Cc: Ben Campbell;


dime@ietf.org


 list; Steve Donovan


Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: 


comments to 4.3


 


 


Ulrich,


 


On Dec 11, 2013, at 9:21 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:


 


 




Jouni,


 


ad 1. "monotonically" does not express your intention. What =
we are looking for may be "stepwise with fixed step".<=
/pre>

 


Ad 2. Is not necessarily a mistake that could result in out-of-sequenc=
e sequence numbers. When a client C sends a realm-type requests towards any=
 server in the realm, an agent A1 that selects the server would send back t=
he realm-type OLR with sequence number s1. The next realm-type request sent=
 by C (that survived the throttling) may take a path that does not include =
A1 but A2. A2 then selects the server and sends back a sequence number s2. =
Nothing ensures that s1 and s2 are in sequence.


 




Would the server in both cases (via A1 and A2) be the same?=



 


- Jouni


 


 


 




Ulrich


 


 


-----Original Message-----


From: ext Jouni Korhonen [


mailto:jouni.nospam@gmail.co=
m


]


Sent: Tuesday, December 10, 2013 10:31 PM


To: Wiehe, Ulrich (NSN - DE/Munich)


Cc: Ben Campbell;


dime@ietf.org


 list; Steve Donovan


Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: 


comments to 4.3


 


Ulrich,


 


On Dec 10, 2013, at 4:31 PM, "Wiehe, Ulrich (NSN - DE/Munich)&quo=
t; 


<ulrich.wiehe@nsn.com>


 wrote:


 


 




Jouni,


 


1. I find the texts


a) "The sequence number ... does not need to be monotonically inc=
reasing"


and


 




Means the delta from old-seqno to new-seqno can be any non-negative 


integer (within the given limits) not something fixed step/delta =



(like +1). As long as "new-seqno >=3D old-seqno" hold=
s we are fine.


 


 




b) "...the new sequence number MUST be greater or equal than the =
old sequence number..."


contradicting.


Can you please clarify.


 




See above. (mind the overflow case)


 


 




2. The expected behaviour when receiving an out-of-sequence sequence n=
umber within OC-OLR is described in 4.3:


"The receiver SHOULD discard an OC-OLR AVP with a sequence number=
 that is less than previously received one."


I don't find this very robust. Once a higher sequence number (received=
 erroneously by mistake) is accepted you cannot (easily) recover.


 




I find it more robust in a sense that I should not care about stale ol=
d information.


However, since we are piggybacking (by popular demand) we have 


little room for seqno re-sync negotiation.


 


What is the mistake you refer here? A misbehaving implementation? 


In that case, it deserves to get a manual intervention once figured 


out by admins checking alarms and logs. If the mistake is due other 


things, like endpoints being out of sync, we currently have no written=
 down mechanism to survive that.


 


 




3. The expected behaviour when receiving an out-of-sequence sequence n=
umber within the OC-Supported-Features AVP is not described. What is the in=
tention here?


 




No intention. Just a sloppy specification. You are right that 


something needs to be done & clarified here. (again the semantics =



of Time would nice..)


 


I'll propose something. Others should too ;)


 


- Jouni


 


 




Ulrich


 


-----Original Message-----


From: DiME [


mailto:dime-bounces@ietf.org<=
/a>


] On Behalf Of ext Jouni Korhonen


Sent: Tuesday, December 10, 2013 8:28 AM


To: Ben Campbell;


dime@ietf.org


 list; Steve Donovan


Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: 


OVLI: comments to 4.3


 


 


Fine.. lets define then the sequence number semantics. Basic 


unsigned integer math. The text proposal is the following:<=
/pre>

 


4.4.  OC-Sequence-Number AVP


 


The OC-Sequence-Number AVP (AVP code TBD3) is type of Unsigned64.=



Its usage in the context of the overload control is described in =



Sections 4.1 and 4.3.


 


From the functionality point of view, the OC-Sequence-Number AVP =



MUST be used as a non-volatile increasing counter between two 


overload control endpoints.  The sequence number is only required=
 


to be unique between two overload control endpoints and does not =



need to be monotonically increasing.


 


When comparing two sequence numbers, the new sequence number MUST 


be greater or equal than the old sequence number within a window =



that is half of the size of the maximum sequence number. This 


allows a simple handling of the sequence number overflow using 


unsigned integer arithmeticf:


 


  #define WINDOW 0x8000000000000000ULL


 


  bool verify_seqnum( uint64_t newsn, uint64_t oldsn ) {


      if (newsn - oldsn <=3D WINDOW)<=
/o:p>


          // newsn >=
=3D oldsn


          return true;&nb=
sp;  


      } else


          // outside wind=
ow or newsn < oldsn


          return false;&n=
bsp; 


      }


  }


 


 


 


The above should even work is someone shovels NTP times into 


sequence numbers with a blind typecasting.


 


- Jouni


 


On Dec 10, 2013, at 12:34 AM, Ben Campbell <ben@nostrum.com>


 wrote:


 


 




On Dec 9, 2013, at 10:00 AM, Steve Donovan <srdonovan@usdonovans.com>


 wrote:


 


 




Jouni,


 


I propose that we keep the name OC-Sequence-Number but that we use the=
 Time type for OC-Sequence-Number.  It is misleading and potentially c=
onfusing to call it OC-Time-Stamp.  


 


 




I could live with that, although I would rather just define the expect=
ed properties of the sequence number, and leave the implementation up to th=
e implementor. I assume your reasoning for not calling it a timestamp is th=
at you do not want people to try to use it as a time base reference. If so,=
 then we don't require any connection to a clock. We just need it to be mon=
otonically increasing.


 


 




We might consider expanding on the format of the AVP to make it someth=
ing like Session-ID, where it is a concatenation of the Diameter-ID of the =
generating node and a timestamp.  This might help the reacting node ke=
ep track of which sequence number it has received.


 


 




Do we need a uniqueness across multiple nodes property? If so, why?


 


 




Steve


 


On 12/9/13 5:37 AM, Jouni Korhonen wrote:


 




Folks


 


Could we conclude on the sequence number vs. time stamp vs. something =
else?


We got more important places to spend our energy than this ;)


 


My proposal is the following (based on the original pre-00 design):


 


o We change the OC-Sequence-Number to OC-Time-Stamp in all occurrences=



in the -01.


o We use RFC6733 Time type for the OC-Time-Stamp. RFC6733 gives us


already exact definition how to handle the AVP.


o Define that the OC-Time-Stamp is the time of the creation of the 


"original" AVP within whose context the time stamp is presen=
t.


o The OC-Time-Stamp AVP uniqueness is still considered to be in scope<=
o:p>


of the communicating endpoints.


o The time stamp can be used to quickly determine if the content of


the encapsulating AVP context has changed (among other properties).


This would be useful specifically in the future when the encapsulating=



grouped AVPs  grow in size and functionality.


 


 


- Jouni


 


_______________________________________________


DiME mailing list


 


 


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 


 


 


 


 




_______________________________________________


DiME mailing list


 


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime




_______________________________________________


DiME mailing list


 


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime




_______________________________________________


DiME mailing list


 


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime








 




 




 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 


 




 






--_000_A9CA33BB78081F478946E4F34BF9AAA014D33C5Axmbrcdx10ciscoc_--

From nsalot@cisco.com  Mon Dec 16 07:50:14 2013
Return-Path: 
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 4790B1AE351 for ; Mon, 16 Dec 2013 07:50:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.038
X-Spam-Level: 
X-Spam-Status: No, score=-15.038 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.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 Vq-OOL1UxG5I for ; Mon, 16 Dec 2013 07:50:08 -0800 (PST)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id CE8C31AE34F for ; Mon, 16 Dec 2013 07:50:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=62105; q=dns/txt; s=iport; t=1387209007; x=1388418607; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=0Fv5VWtBbO2DqzTvENQBrM5fehz3n4ELuVQB5RfnbaI=; b=BbD1uA4Xtz7S3lk3iHc5bXd5YOUHEPlMTr4LA+5UhAuPJcYYiyF8pFE4 h8fM06gcGciycqjPBZE3QZCv/wyHkalWCiDga4/PG6pET0pQcC6YxZkPd rGViOnwydFgLjbM2PFxbUefWPViAZ1zbI49PDxJguL+XjC2dJaU4Cn2eZ 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ak8FANcgr1KtJXG9/2dsb2JhbABZgkZEOFW4coElFnSCJQEBAQQBAQEXE0EbAgEIDgMBAwEBCxYBBgchBgsUAwYIAgQBEggSAQSHUQMRDcEBDYcBEwSNBoEwMi0KAQaDHYETBIkLiyiBeI5FhTqDKoIq
X-IronPort-AV: E=Sophos;i="4.95,495,1384300800";  d="scan'208,217";a="291640959"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-1.cisco.com with ESMTP; 16 Dec 2013 15:50:05 +0000
Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id rBGFo5dX009623 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 16 Dec 2013 15:50:05 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.227]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Mon, 16 Dec 2013 09:50:04 -0600
From: "Nirav Salot (nsalot)" 
To: Steve Donovan , "dime@ietf.org" 
Thread-Topic: [Dime] DOIC: Self-Contained OLRs
Thread-Index: AQHO67/s/vGpiVuf2UayvwQoJbzwfZo5m/0AgACzUoCAAAFygIAAE14AgAF8EACAACKcAIAANGaAgATJUgCAAAuAAIACAWkAgAAGHYCAAXsigIAALuKAgAAb/4CAAHc6gIAAOZAAgAAO+4CAAAVNAIAABNCAgAAF6QCAAAecAIAF/9gAgAAFIoCAANV2gIAARHaAgAHlZ9CAAEm9gIAAWSGggAACrFCAAAAqoIAAeyEAgADOAYCAAGoDgP//yK3wgAZ6WoD//8JwoA==
Date: Mon, 16 Dec 2013 15:50:03 +0000
Message-ID: 
References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com>  <52A091CE.2000104@usdonovans.com> <13081_1386256433_52A09831_13081_8197_1_6B7134B31289DC4FAF! 731D84412 2B36E32B6EB@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B9209739738@ESESSMB101.ericsson.se>  <8FD63E2D-5203-4DA4-A6DA-C4CA181C9CFB@nostrum.com> <26C84DFD55BC3040A45BF70926E55F2587C1D786@SZXEMA512-MBX.china.huawei.com>  <52A86663.30500@usdonovans.com>  <087A34937E64E74E848732CFF8354B920973A82A@ESESSMB101.ericsson.se> <52A8B862.5040207@usdonovans.com> <087A34937E64E74E848732CFF8354B920973AAF5@ESESSMB101.ericsson.se> <52A9BE1F.7020201@usdonovans.com>  <52AEFED7.5060908@usdonovans.com>
In-Reply-To: <52AEFED7.5060908@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.65.72.21]
Content-Type: multipart/alternative; boundary="_000_A9CA33BB78081F478946E4F34BF9AAA014D33C8Cxmbrcdx10ciscoc_"
MIME-Version: 1.0
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Dec 2013 15:50:14 -0000

--_000_A9CA33BB78081F478946E4F34BF9AAA014D33C8Cxmbrcdx10ciscoc_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Steve,

SRD> I don't understand what is meant by "requires architectural support". =
 Is this a way of saying it is more difficult to implement?
As of today, the Diameter message can only contain data specific to one app=
lication and based on this, the nodes are designed to handle data/AVP speci=
fic to one application.
Thus, cross-application data handling (that you are proposing via "self-con=
tained OLR") is not required to be supported in today's design/architecture=
 of the Diameter node supporting a set of applications.

Regards,
Nirav.

From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Monday, December 16, 2013 6:54 PM
To: Nirav Salot (nsalot); dime@ietf.org
Subject: Re: [Dime] DOIC: Self-Contained OLRs

Nirav,

See my response inline.

Regards,

Steve
On 12/12/13 10:36 AM, Nirav Salot (nsalot) wrote:
Steve,

Why do you always talk about "the application which the Diameter node does =
not understand?"
What if the reacting node supports two applications and in the message for =
application-X it receives the overload-report for application-Y?
Do you propose to ignore this report as well?
SRD> The logic behind self contained reports would be that the reactor  use=
 the reports that it makes sense for the reactor to use.  I think your ques=
tion is what should a reactor do if it supports application-X and applicati=
on-Y, sends a request for application-X and receives a reply with an overlo=
ad report for application-Y in the answer to that request. The behavior I w=
ould suggest is that the reactor should (not must) honor the overload repor=
t for requests sent to application-Y.  If this is particularly difficult fo=
r the reactor to achieve then it can wait to receive an overload for applic=
ation-Y in answers to requests sent on application-Y.


As already indicated earlier, by many of us, handling of application-Y's da=
ta in the application-X's message is not how the Diameter applications are =
designed today. And hence this type of proposal requires architectural supp=
ort for handling it. And there lies the complexity.
SRD> I don't understand what is meant by "requires architectural support". =
 Is this a way of saying it is more difficult to implement?

This main drawback was highlighted earlier as well but was conveniently ign=
ored while preparing the pros and cons list for the self-contained OLR.
SRD> Then suggest it be added to the pros and cons list.  But first explain=
 the concept of "requires architectural support".


Regards,
Nirav.

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: Thursday, December 12, 2013 7:16 PM
To: dime@ietf.org
Subject: Re: [Dime] DOIC: Self-Contained OLRs

Maria Cruz,

Can you explain the complexity behind the cross-application procedure.  The=
 work required is to ignore any application that the Diameter node does not=
 understand.  I don't see this as very complex.

Steve
On 12/12/13 1:26 AM, Maria Cruz Bartolome wrote:
Yes, I agree consistency is not any longer a problem, since now your intent=
ion is that _any_ (and multiple) application data could be conveyed within =
the same message.
But as mentioned a few times, I consider this not necessary since OLR is se=
nt in every answer.
A part from that, as mentioned by Lionel, this implies a cross-application =
procedure at both endpoints, that increases complexity and it is not requir=
ed for our work (RFC7068)

Cheers
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: mi=E9rcoles, 11 de diciembre de 2013 20:09
To: dime@ietf.org
Subject: Re: [Dime] DOIC: Self-Contained OLRs

Maria Cruz,

I don't agree with the assertion that self-contained OLRs results in the po=
tential for data inconsistency.  If a reactor receives an overload report f=
or an application that is not supported by the reactor then the reactor can=
 and should ignore that OLR.

The concept of self-contained overload reports would explicitly allow for t=
he contents of the overload report to be different than the message that is=
 carrying the OLR.  As with application-ids, if the reactor doesn't send me=
ssages to a reported host or realm then the reactor ignores that part of th=
e overload report.  As such, there is no need to check the implicit data wh=
en receiving a self-contained OLR.

Steve
On 12/11/13 12:25 PM, Maria Cruz Bartolome wrote:

Hello (and something else now :), fast key combination, I won't be able to =
repeat,  was the responsible)



As mentioned before, something else on cons side for self-contained:



A part from that,  one concern with "self-contained OLRs" is that some data=
 is duplicated. Duplication should be avoided, since then we need to assure=
 consistency, and error handing in case implicit and explicit data values a=
re different for any reason... what means that it may always be required to=
 check both implicit and explicit data.



Also, I think this is a pure implementation proposal. Regardless how the da=
ta is transported it could be packed in a "self-contained OLRs" within the =
diameter application, if for any implementation this is preferred.

Best regards
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE=
S (JEAN-JACQUES)
Sent: mi=E9rcoles, 11 de diciembre de 2013 19:02
To: dime@ietf.org
Subject: Re: [Dime] DOIC: Self-Contained OLRs

Hi Steve

I am sorry, Steve,  I do not see the difference between the Draft Roach sco=
pe approach and the self contained OLRs.

With the scope approach in Draft Roach : there is an overload metric AVP  (=
eg containing a % of traffic reduction) coupled with one or several Overlao=
d-Infoscope AVPs, an overlaod infoscope identifying an application or a des=
tination host or... . These Overlaod-Infoscope AVPs can be combined  with a=
lso  the possibility of  multi instances to have a list of applications, a =
list of destination hosts etc  to which the overload metric would apply.

With self contained OLR as you have described them, un OLR will also contai=
n an OC-Reduction-Percentage  AVP coupled with one or several others AVPs (=
the self containment approach) to indicate which application(s), destinatio=
ns host (s) etc the   OC-Reduction-Percentage  AVP applies.

Where is the difference?

So the drawbacks identified for the scope approach also apply with the self=
 contained approach

Best regards

JJacques



De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9 : mercredi 11 d=E9cembre 2013 14:20
=C0 : dime@ietf.org
Objet : Re: [Dime] DOIC: Self-Contained OLRs

JJacques,

While the self contained overload report concept may be similar to the scop=
es concept in the Roach draft, they are not the same.  As such, I don't agr=
ee with your assertion that the previous rejection of the Roach draft requi=
res us to reject self contained overload reports as currently being discuss=
ed.

Steve
On 12/11/13 2:27 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:
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 multip=
ly the number of AVPs in the OLRs (AVPs identifying Application, destinatio=
n 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 sel=
f 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 rec=
reate  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 si=
mple way to proceed, which drove to the current draft content. This decisio=
n is a strong argument that still prevails  for the current baseline descri=
bed in the current draft.

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

As also said, when news requirements will appear (eg session group or APN e=
xamples)  the baseline is extensible to support these new requirements .  I=
 prefer this way of progressive extensions , rather than to create a self c=
ontained 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=E9 : mardi 10 d=E9cembre 2013 04:58
=C0 : 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 righ=
t 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 opti=
mization 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 overloa=
d.

-          The last three pros are mainly for the case of overload of agent=
, if I understood them correctly. Overload of agent is still a controversia=
l scenario, we may need more discussion in the future. But anyway, with def=
inition 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-co=
ntained OLR.

Best Regards,
Susan

From: Ben Campbell [mailto:ben@nostrum.com]
Sent: Tuesday, December 10, 2013 7:53 AM
To: 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 wh=
at we do for a later (or final) version.

So far, I've seen 4 people opposed to self-contained OLRs (Lionel, Nirav, M=
aria, 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 lo=
ok 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 firs=
t group explain what they think the pros of implicit OLRs might be beyond t=
hose 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 application=
s at once, instead of having to signal each one separately.
  *   Allows an easy solution to our "loss" algorithm corner case of not be=
ing able to signal the end of a 100% overload condition
  *   Makes it easier to solve the agent overload problem, without requirin=
g 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 transac=
tion 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 trans=
action context and the report type. [I don't understand why this is valuabl=
e, 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 supporte=
d 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 > wrote:

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

- Jouni



_______________________________________________

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



--_000_A9CA33BB78081F478946E4F34BF9AAA014D33C8Cxmbrcdx10ciscoc_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Steve,<=
/p>

 <=
/p>

SRD> I don't understand what is meant by "re=
quires architectural support".  Is this a way of saying it is mor=
e difficult to implement?

As of today, the Diameter message can only conta=
in data specific to one application and based on this, the nodes are design=
ed to handle data/AVP specific to one application.


Thus, cross-application d=
ata handling (that you are proposing via "self-contained OLR") is=
 not required to be supported in today's design/architecture of the
 Diameter node supporting a set of applications.


 <=
/p>

Regards,


Nirav.<=
/p>

 <=
/p>





From: Steve Donovan [mailto:srdonovan@usdonovans.com]


Sent: Monday, December 16, 2013 6:54 PM

To: Nirav Salot (nsalot); dime@ietf.org

Subject: Re: [Dime] DOIC: Self-Contained OLRs






 


Nirav,



See my response inline.



Regards,



Steve




On 12/12/13 10:36 AM, Nirav Salot (nsalot) wrote:






Steve,<=
/p>

 <=
/p>

Why do you always talk ab=
out "the application which the Diameter node does not understand?"=
;


What if the reacting node=
 supports two applications and in the message for application-X it receives=
 the overload-report for application-Y?


Do you propose to ignore =
this report as well?




SRD> The logic behind self contained reports woul=
d be that the reactor  use the reports that it makes sense for the rea=
ctor to use.  I think your question is what should a reactor do if it =
supports application-X and application-Y, sends
 a request for application-X and receives a reply with an overload report f=
or application-Y in the answer to that request. The behavior I would sugges=
t is that the reactor should (not must) honor the overload report for reque=
sts sent to application-Y.  If this
 is particularly difficult for the reactor to achieve then it can wait to r=
eceive an overload for application-Y in answers to requests sent on applica=
tion-Y.






 <=
/p>

As already indicated earl=
ier, by many of us, handling of application-Y's data in the application-X's=
 message is not how the Diameter applications are designed
 today. And hence this type of proposal requires architectural support for =
handling it. And there lies the complexity.


SRD> I don't understand what is meant by "re=
quires architectural support".  Is this a way of saying it is mor=
e difficult to implement?






This main drawback was hi=
ghlighted earlier as well but was conveniently ignored while preparing the =
pros and cons list for the self-contained OLR.


SRD> Then suggest it be added to the pros and con=
s list.  But first explain the concept of "requires architectural=
 support". 







 <=
/p>

Regards,


Nirav.<=
/p>

 <=
/p>





From: DiME [ma=
ilto:dime-bounces@ietf.org]
On Behalf Of Steve Donovan

Sent: Thursday, December 12, 2013 7:16 PM

To: dime@ietf.org

Subject: Re: [Dime] DOIC: Self-Contained OLRs






 


Maria Cruz,



Can you explain the complexity behind the cross-application procedure. =
; The work required is to ignore any application that the Diameter node doe=
s not understand.  I don't see this as very complex.



Steve




On 12/12/13 1:26 AM, Maria Cruz Bartolome wrote:






Yes, I agree consistency =
is not any longer a problem, since now your intention is that _any_ =
(and multiple) application data could be conveyed within
 the same message.


But as mentioned a few ti=
mes, I consider this not necessary since OLR is sent in every answer.



A part from that, as ment=
ioned by Lionel, this implies a cross-application procedure at both endpoin=
ts, that increases complexity and it is not required for
 our work (RFC7068)


 <=
/p>

Cheers<=
/p>

/MCruz<=
/p>

 <=
/p>





From: DiME [ma=
ilto:dime-bounces@ietf.org]
On Behalf Of Steve Donovan

Sent: mi=E9rcoles, 11 de diciembre de 2013 20:09

To: dime@ietf.org

Subject: Re: [Dime] DOIC: Self-Contained OLRs






 


Maria Cruz,



I don't agree with the assertion that self-contained OLRs results in the po=
tential for data inconsistency.  If a reactor receives an overload rep=
ort for an application that is not supported by the reactor then the reacto=
r can and should ignore that OLR. 




The concept of self-contained overload reports would explicitly allow for t=
he contents of the overload report to be different than the message that is=
 carrying the OLR.  As with application-ids, if the reactor doesn't se=
nd messages to a reported host or realm
 then the reactor ignores that part of the overload report.  As such, =
there is no need to check the implicit data when receiving a self-contained=
 OLR.



Steve




On 12/11/13 12:25 PM, Maria Cruz Bartolome wrote:






Hello (and something else now 
J, fast key combination, I won’t be able to repeat,  was =
the responsible)


 


As mentioned before, something else on cons side =
for self-contained:


 


A part from that, =
; one concern with "self-contained OLRs" is that some data is dup=
licated. Duplication should be avoided, since then we need to assure consis=
tency, and error handing in case implicit and explicit
 data values are different for any reason... what means that it may always =
be required to check both implicit and explicit data.


 


Also, I think this is =
a pure implementation proposal. Regardless how the data is transported it c=
ould be packed in a "self-contained OLRs" within the diameter app=
lication, if for any implementation this is preferred.


 <=
/p>

Best regards<=
/o:p>


/MCruz<=
/p>

 <=
/p>





From: DiME [ma=
ilto:dime-bounces@ietf.org]
On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)

Sent: mi=E9rcoles, 11 de diciembre de 2013 19:02

To: dime@ietf.org

Subject: Re: [Dime] DOIC: Self-Contained OLRs






 


Hi Steve


 <=
/p>

I am sorry, Steve,  =
I do not see the difference between the Draft Roach scope approach and the =
self contained OLRs.


 <=
/p>

With the scope approach i=
n Draft Roach : there is an overload metric AVP  (eg containing a % of=
 traffic reduction) coupled with one or several Overlaod-Infoscope
 AVPs, an overlaod infoscope identifying an application or a destination ho=
st or… . These Overlaod-Infoscope AVPs can be combined  with als=
o  the possibility of  multi instances to have a list of applicat=
ions, a list of destination hosts etc  to which the overload
 metric would apply.


 <=
/p>

With self contained OLR a=
s you have described them, un OLR will also contain an OC-Reduction-Percent=
age
 AVP coupled with one or several oth=
ers AVPs (the self containment approach) to indicate which application(s), =
destinations host (s) etc the   OC-Reduction-Percentage
 AVP applies.



 <=
/p>

Where is the difference?<=
/span>


 <=
/p>

So the drawbacks identifi=
ed for the scope approach also apply with the self contained approach



 <=
/p>

Best regards<=
/o:p>


 <=
/p>

JJacques



 <=
/p>

 <=
/p>

 <=
/p>





De =
: DiME [mailto:dime-bounces@ietf.org]
De la part de Steve Donovan

Envoy=E9 : mercredi 11 d=E9cembre 2013 14:20

=C0 : dime@ietf.org

Objet : Re: [Dime] DOIC: Self-Contained OLRs<=
/p>





 


JJacques,



While the self contained overload report concept may be similar to the scop=
es concept in the Roach draft, they are not the same.  As such, I don'=
t agree with your assertion that the previous rejection of the Roach draft =
requires us to reject self contained
 overload reports as currently being discussed.



Steve




On 12/11/13 2:27 AM, TROTTIN, JEAN-JACQUES (JEAN-JAC=
QUES) wrote:






Hi Ben and all



 <=
/p>

I remind my mail of 05/12=
, where the self contained OLRs approach is quite similar to the self conta=
ined 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 i=
n draft Roach).  


This also result in a pig=
gybacking  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 ho=
p, the self contained  OLRs are opened to be reprocessed in order to r=
ecreate  new self contained OLR(s)  to various destinations.



I remind that, now 6 mont=
hs ago:


This is why I remain in f=
avor of the baseline  described in the current  draft, as as I ha=
ve always and regularly  expressed for  a while.


 <=
/p>

As also said, when news r=
equirements will appear (eg session group or APN examples)  the baseli=
ne is extensible to support these new requirements .  I prefer
 this way of progressive extensions , rather than to create a self containe=
d OLR  with an  immediate and not needed complexity   &=
nbsp;


 <=
/p>

Best regards<=
/o:p>


 <=
/p>

JJacques


 <=
/p>

 <=
/p>





De : DiME [mailto:d=
ime-bounces@ietf.org]
De la part de Shishufeng (Susan)

Envoy=E9 : mardi 10 d=E9cembre 2013 04:58

=C0 : Ben Campbell; dime@ietf.=
org list

Objet : Re: [Dime] DOIC: Self-Contained OLRs<=
/p>





 


Hi Ben,=



 <=
/p>

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



 <=
/p>

Quick thinking on the pro=
s you listed for self-contained OLR.


 <=
/p>


-       &nb=
sp; 
The first two pro=
s can be seen as optimization, on which we are still arguing if these optim=
ization are worth doing or not, since such optimization
 brings extra cost.



-       &nb=
sp; 
The third one is =
not a key issue, which could be addressed with several ways as discussed. A=
s a last resort, the overloaded server may send something
 in a request towards the client to inform the end of the overload.<=
o:p>



-       &nb=
sp; 
The last three pr=
os are mainly for the case of overload of agent, if I understood them corre=
ctly. 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.


 <=
/p>

Best Regards,=



Susan

 <=
/p>





From: Ben Camp=
bell [mailto:ben@nostrum.com]


Sent: Tuesday, December 10, 2013 7:53 AM

To: dime@ietf.org list

Subject: Re: [Dime] DOIC: Self-Contained OLRs






 




I am willing to call the discussion concluded for th=
e 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 conse=
nsus. 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 explai=
n 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 no=
t already weighed into this.






 






Self-Contained O=
LRS:






 






Pros:






    

  • 
Allows an easy, generic solution to Maria's "all-application" sco=
ped overload use case.
  • 
Allows an overloaded node to signal overload for multiple applications at o=
nce, instead of having to signal each one separately.
  • 
Allows an easy solution to our "loss" algorithm corner case of no=
t being able to signal the end of a 100% overload condition
    • =

  • 
Makes it easier to solve the agent overload problem, without requiring inco=
nsistent behavior.
  • 
Allows out-of-band transmission of OLRs without a new format
  • 
Makes it easier to do things like adding a dedicated application for overlo=
ad, 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 i=
n 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" s=
cope.
  • 
An overloaded node needs to send a separate report for every supported appl=
ication.
  • 
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.
  •  
    







 






 




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




OK. Lets call this thread concluded then. I keep the old OC-OLR  seman=
tics

regarding its information context then unmodified.



- Jouni


 


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime



 















_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime



 













_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime



 


 





--_000_A9CA33BB78081F478946E4F34BF9AAA014D33C8Cxmbrcdx10ciscoc_--

From jouni.nospam@gmail.com  Mon Dec 16 08:06:53 2013
Return-Path: 
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 0632E1AE338 for ; Mon, 16 Dec 2013 08:06:53 -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 6xcXARbwy7K3 for ; Mon, 16 Dec 2013 08:06:51 -0800 (PST)
Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id D9EC11A9313 for ; Mon, 16 Dec 2013 08:06:50 -0800 (PST)
Received: by mail-la0-f54.google.com with SMTP id b8so2814096lan.27 for ; Mon, 16 Dec 2013 08:06:49 -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=OnyjLByF10dRSM54xpmDpbSB19QS2bfjfGQMF5isZzU=; b=XWkxf7caUBIzPDA6WrpNjAPn+MGwLa/zMaE7B1dx2YnvPwvuzL+FrHXrHhKF20TFra MbhrHmXCkn6JblaUwPKeMBjXTjIHTNHM5gq5qlTO8VHtXxlzLtJlabOLTLiMe+5i/KxW qeNBLSx3i5c+bM1HJWtqknVOWAXGCjzmTP82ruxGzxbd+jgAYlc8O0+8Pi4HK1/bLbtb HlaM+Jwql+EMiQ34gEiVjigasBFhGPbeYeXav0x510Wb8uipcFgwLductCeyfeQ3bcvh cepLM2zCCBE3/YD2x0dtE4hBnJFYdvwtNEOOr7olUdeN3Kyd0dNE5nClDuIECCNT6qnk Xs4A==
X-Received: by 10.112.172.3 with SMTP id ay3mr31478lbc.95.1387210009464; Mon, 16 Dec 2013 08:06:49 -0800 (PST)
Received: from [10.37.103.37] ([77.95.242.69]) by mx.google.com with ESMTPSA id e10sm21573201laa.6.2013.12.16.08.06.48 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 16 Dec 2013 08:06:49 -0800 (PST)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jouni Korhonen 
In-Reply-To: 
Date: Mon, 16 Dec 2013 18:06:47 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <7AEB29F3-422A-4642-AC47-64400E602834@gmail.com>
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DCBC@DEMUMBX014.nsn-intra.net> <453156F8-9090-46D4-BF8E-A877F40EE3AC@gmail.com>  <2B4A6453-CBF0-48BE-B917-96B279229D3C@gmail.com> 
To: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
X-Mailer: Apple Mail (2.1510)
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Conclusion for the Report Type
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Dec 2013 16:06:53 -0000

On Dec 16, 2013, at 4:36 PM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" =
 wrote:

> Hi Jouni
>=20
> I am also fine for the statements you proposed.
>=20
> My understanding for 4) about instances is the following=20
> - when an OLR with host report type is present in a message; it is the =
only OLR instance with this report type
> - same for OLR with a realm report type
> - but you may have an OLR host report type and another OLR with realm =
report type in the same message.
>=20
> Is my understanding correct?

Yes.

- Jouni


>=20
> Best regards=20
>=20
> JJacques=20
>=20
> -----Message d'origine-----
> De : DiME [mailto:dime-bounces@ietf.org] De la part de Jouni Korhonen
> Envoy=E9 : mardi 10 d=E9cembre 2013 08:57
> =C0 : Nirav Salot
> Cc : dime@ietf.org list
> Objet : Re: [Dime] Conclusion for the Report Type
>=20
>=20
> On Dec 10, 2013, at 7:15 AM, Nirav Salot (nsalot)  =
wrote:
>=20
>> Jouni,
>>=20
>> I am fine with the principles you have mentioned below for Report =
Type.
>> I also prefer to use enumerated type for this AVP if that does not =
risk the extendibility of this AVP.
>>=20
>=20
>=20
> Ok. Good.
>=20
> - Jouni
>=20
>=20
>> Regards,
>> Nirav.
>>=20
>> -----Original Message-----
>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen
>> Sent: Monday, December 09, 2013 5:30 PM
>> To: dime@ietf.org list
>> Subject: [Dime] Conclusion for the Report Type
>>=20
>> Folks,
>>=20
>> We need a conclusion here so that I can actually write something into =
the -01. How about the following (I try to reflect as many points given =
here as possible):
>>=20
>> 1) The basic principle for the Report Type use is that only one
>>  OLR per report type is allowed unless the report type and the
>>  OLR reflecting the new report type define exact semantics how
>>  to differentiate between multiple OLRs with the same report
>>  type. In 3GPP context, for example, a report type with an AVP
>>  that identifies an APN could be such a differentiator.. and that
>>  would need a new report type where an implementation exactly
>>  knows to look for this additional AVP without guesswork or=20
>>  fuzzy heuristics.
>>=20
>> 2) A new report type or a set of new report types require a new
>>  feature to be allocated/defined so that both endpoints know how
>>  to handle the new report type that was defined after the
>>  publication of the baseline specification. The handling of the
>>  new report types must be defined (along with the new AVPs it
>>  might need to be included into the OC-OLR AVP).
>>=20
>> 3) With 2) in place I do not care whether the OC-Report-Type is
>>  enumerated or unsigned (flag vector?). I still favour Enumerated
>>  myself as it forces the protocol designer to come up with a=20
>>  cleaner design ;)
>>=20
>> 4) For the baseline we only define host and realm report types.
>>  We do not allow multiple OLRs with these report types i.e.
>>  single instances of OLRs with host and/or realm are allowed.
>>=20
>> - Jouni
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>=20
> _______________________________________________
> 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


From srdonovan@usdonovans.com  Mon Dec 16 08:09:37 2013
Return-Path: 
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 DA7881AE04A for ; Mon, 16 Dec 2013 08:09:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.12
X-Spam-Level: 
X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no
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 KKtbX6oO-VTo for ; Mon, 16 Dec 2013 08:09:31 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id D403F1A9313 for ; Mon, 16 Dec 2013 08:09:31 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:62597 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1VsajX-0006UZ-QP; Mon, 16 Dec 2013 08:09:30 -0800
Message-ID: <52AF25B6.4030702@usdonovans.com>
Date: Mon, 16 Dec 2013 10:09:26 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: "Nirav Salot (nsalot)" ,  Jouni Korhonen 
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DB1B@DEMUMBX014.nsn-intra.net>  <52A5E902.20605@usdonovans.com> <7475B713-1104-4791-96B1-CE97632A0D69@nostrum.com>  <5BCBA1FC2B7F0B4C9D935572D90006681519E476@DEMUMBX014.nsn-intra.net> <1CD20507-B0FE-4367-804A-B831734CF060@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E6DC@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D90006681519E712@DEMUMBX014.nsn-intra.net> <4A151D70-0291-4238-85B1-03BB54B361E6@gmail.com> <52A864FF.10705@usdonovans.com>   <52A9C62A.6010207@usdonovans.com>  <52AEEF27.50208@usdonovans.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------070607040408070807060806"
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com
Cc: Ben Campbell , "dime@ietf.org list" 
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Dec 2013 16:09:38 -0000

This is a multi-part message in MIME format.
--------------070607040408070807060806
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Nirav,

Assume that there are multiple agents reporting on realm overload.  The
method these agents use to determine realm overload is an implementation
decision, but will require some form of exchange of state between the
agents to keep them in sync.  Note that we can't assume that all agents
are getting all host overload reports.

Under normal circumstances, the difference between the overload reports
from these agents should be small, as you assert. 

But consider the case where the replication mechanism between the agents
is either congested or the network used by the agents to exchange state
is no longer available.  It is easy to construct scenarios in this
situation where agents could be reporting widely different realm
overload report values.

This is clearly an unlikely event, but it is one that can easily be
prevented by including the id of the node that sends a report as part of
the report.

Regards,

Steve

On 12/16/13 9:42 AM, Nirav Salot (nsalot) wrote:
>
> Steve,
>
>  
>
> > The issue with considering only the last report is that it introduces
> the potential for thrashing between different values.  This could make
> the overload event even worse.
>
> I am not sure about this. The two agents are not synchronized only for
> a very small window of time. But even then their reports should be
> reflecting the status of the realm, approximately if not accurately.
>
> So I don't think using one of the reports will make the situation worse.
>
>  
>
> I did not understand your argument regarding the security.
>
> The client does not know the agent's identity anyway. So adding
> agent's identity in the overload-report is not going to change the
> security consideration anyway.
>
>  
>
> Regards,
>
> Nirav.
>
>  
>
> *From:*Steve Donovan [mailto:srdonovan@usdonovans.com]
> *Sent:* Monday, December 16, 2013 5:47 PM
> *To:* Nirav Salot (nsalot); Jouni Korhonen
> *Cc:* Ben Campbell; dime@ietf.org list
> *Subject:* Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI:
> comments to 4.3
>
>  
>
> Nirav,
>
> The issue with considering only the last report is that it introduces
> the potential for thrashing between different values.  This could make
> the overload event even worse.
>
> I agree that this should be a rare case.  I still think, however, that
> we need to have defined behavior.
>
> One other argument for including the sender of the overload report in
> the report itself is security.  The ability of a bad actor to insert a
> malicious overload report can be a very effective DOS attack.  I know
> we have said we aren't addressing security yet but this seems pretty
> short sighted.  Being able to establish that the identity of the
> sender of an overload report will be an important part of the security
> solution.  We should take this step in that direction.
>
> Steve
>
> On 12/12/13 10:26 AM, Nirav Salot (nsalot) wrote:
>
>     Steve,
>
>      
>
>     So as I understand it is not a common case for different agent to
>     provide different view of the same realm and this may have happen
>     during a small window when synchronization has not taken place
>     between the geographically distributed agents.
>
>     Right?
>
>      
>
>     If so, I can understand the following part of your proposal.
>
>     One proposal for how we deal with the fact that different reports
>     can have different values is to have the reacting node treat the
>     first reporting node as the authority for reporting realm overload
>     state for that overload instance.
>
>      
>
>     i.e. I can understand to define some behavior for the reacting
>     node to handle the case (which is anyway rare case) when two
>     agents provide different realm-report for the same report.
>
>     The behavior could be simply to consider only the last report when
>     two agents have sent two different reports of the same realm. (And
>     this will also work when the same agent has sent two different
>     realm-reports, purposefully -- e.g. due to the change in the realm
>     overload).
>
>     But this still does not require adding of agent's identity in the
>     overload-report.
>
>      
>
>     Regards,
>
>     Nirav.
>
>      
>
>     *From:*Steve Donovan [mailto:srdonovan@usdonovans.com]
>     *Sent:* Thursday, December 12, 2013 7:50 PM
>     *To:* Nirav Salot (nsalot); Jouni Korhonen
>     *Cc:* Ben Campbell; dime@ietf.org  list
>     *Subject:* Re: [Dime] Conclusion for Sequence Numbers - was Re:
>     OVLI: comments to 4.3
>
>      
>
>     Nirav,
>
>     See inline.
>
>     Steve
>
>     On 12/12/13 6:40 AM, Nirav Salot (nsalot) wrote:
>
>         All,
>
>          
>
>         I do not understand this discussion regarding different agents of the same realm having different view of the realm and provide different overload report.
>
>     We can make the statement that all senders of realm reports should
>     send the same report.  This does not guarantee that it will always
>     happen.  If agents are sending the report, they are generally
>     distributed elements.  In very large networks, this distribution
>     can span continents.  There will be a lag in the "synchronization"
>     of the realm overload information.
>
>     My concern is that we have well defined behavior for when a
>     reactor receives conflicting realm reports.  We need to avoid
>     thrashing between different reduction levels, which could make the
>     overload situation worse.
>
>
>      
>
>     Additionally, I also do not understand the proposal of adding identity of the agent generating "realm report" into the report.
>
>     Adding the endpoint identity is needed to allow the reacting node
>     to know that it is receiving two different views of Realm overload
>     from two different reporting end-points.
>
>
>      
>
>     What is the use of this identity at the reacting node when the report is realm report? Why should the reacting node care who generated the realm report?
>
>     One proposal for how we deal with the fact that different reports
>     can have different values is to have the reacting node treat the
>     first reporting node as the authority for reporting realm overload
>     state for that overload instance.  In this case, the reacting node
>     would ignore reports received from other reporting nodes. In order
>     to ignore reports from non authoritative endpoints requires the
>     reacting node to know which endpoints send which reports.
>
>
>      
>
>      
>
>     Regards,
>
>     Nirav.
>
>      
>
>     -----Original Message-----
>
>     From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen
>
>     Sent: Thursday, December 12, 2013 5:06 PM
>
>     To: Steve Donovan
>
>     Cc: Ben Campbell; dime@ietf.org  list
>
>     Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3
>
>      
>
>     Steve,
>
>      
>
>     On Dec 11, 2013, at 3:13 PM, Steve Donovan   wrote:
>
>      
>
>         Jouni,
>
>          
>
>         We need the sequence number to be strictly increasing.  I don't see the need for it to increase in uniform amounts.  Using time does fit these requirements.  I'm ok with using time as long as we don't call the AVP timestamp.
>
>          
>
>         Ulrich does bring up an interesting use case, where a client is receiving realm reports for the same realm from different agents.  We need to define the clients behavior in this case.  
>
>      
>
>     Any suggestions? I mean agents may have hugely different view of the realm if they are acting on their own.
>
>      
>
>         Presumably the client needs to be able to determine who generated the realm report.  This cannot be determine based on the content of the message or the connection on which the message arrived.  It seems like we might need "Report Generator Diameter ID" in the overload report specifically for Realm reports.  
>
>          
>
>         Once the client is able to differentiate between realm reports sent by different agents (or servers) we need logic defining how the client deals with a new overload report.  
>
>      
>
>     I need now to check one of the basic assumptions on DOIC now so that we have the same understanding. I went back to the endpoint text in Section 5.1. There, for example in Figures
>
>     4 and 5 the DOIC association and the endpoint assumption does does not work IMHO because we have no endpoint identity in the OLR. In order the endpoint assumption to work (as I drew it on the white board in Porto), it would require as many Diameter level sessions as there are DOIC associations.
>
>      
>
>     So.. has assumptions shifted in a meanwhile and I have just not paid attention?
>
>      
>
>         I see a couple of options (others will probably see options I am missing):
>
>          
>
>         - Use the last received realm report - This introduces the possibility of thrashing between two different reduction values and different durations.  Note that this approach does not require the source of the report to be included in the report.
>
>          
>
>         - Only listen to one source of realm overload - The approach would be to remember who sent the first overload report from the realm and ignore realm overload reports from other sources.  This behavior would likely be constrained to a single occurrence of realm overload.  Meaning that the "memory" of the report source would only last as long as that overload event persists.  Once the overload event goes away, the report source would be forgotten and a new source could be used for the next occurrence.
>
>          
>
>         On the surface, the second approach looks better to me.
>
>      
>
>     Or add the identity of the OLR originator explicitly if it cannot be determined implicitly (i.e. from the Diameter message's Origin-Host/Realm).
>
>      
>
>     Or assume the endpoint really is the endpoint in DOIC and Diameter session sense.
>
>      
>
>     - Jouni
>
>      
>
>          
>
>         Steve
>
>          
>
>         On 12/11/13 2:15 AM, Jouni wrote:
>
>             Ulrich,
>
>              
>
>             I might be slow but.. Section 4.4 says
>
>              
>
>                control endpoints.  The sequence number is only required to be unique
>
>                between two overload control endpoints and does not need to be
>
>              
>
>             Unique between two endpoints..
>
>              
>
>             Section 5.1 talks about endpoints:
>
>              
>
>                of an arbitrary Diameter network.  The overload control information
>
>                is exchanged over on a "DOIC association" between two communication
>
>                endpoints.  The endpoints, namely the "reacting node" and the
>
>                "reporting node" do not need to be adjacent Diameter peer nodes, 
>
>             nor
>
>              
>
>             So if your agents inject realm reports, they need to be endpoints to 
>
>             the client. Similar to Figure 5. Therefore the sequence number spaces 
>
>             between
>
>             C-A1 and C-A2 are separate.
>
>              
>
>             Now it is not clear to me, whether in your reasoning the C would see 
>
>             the server identity (as the endpoint) when there is an active "DEP 
>
>             agent" on the path. That would not clearly work and not be align with 
>
>             the endpoint assumption.
>
>              
>
>             Note that at some point of time we had (at least on a discussion 
>
>             level in f2f meeting) report originator identity in the OLR. That 
>
>             would make endpoint identification trivial. Now a "DEP agent" needs 
>
>             to act as a "server" for its clients in order to appear as an endpoint.
>
>              
>
>             - Jouni
>
>              
>
>             ps: still think the use of Time is simpler..
>
>              
>
>              
>
>             On Dec 11, 2013, at 9:43 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
>              
>
>              
>
>                 That's not predictable. It may be the same server in some cases, and different servers in other cases.
>
>                  
>
>                 -----Original Message-----
>
>                 From: ext Jouni [
>
>                 mailto:jouni.nospam@gmail.com
>
>                 ]
>
>                 Sent: Wednesday, December 11, 2013 8:38 AM
>
>                 To: Wiehe, Ulrich (NSN - DE/Munich)
>
>                 Cc: Ben Campbell;
>
>                 dime@ietf.org 
>
>                  list; Steve Donovan
>
>                 Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: 
>
>                 comments to 4.3
>
>                  
>
>                  
>
>                 Ulrich,
>
>                  
>
>                 On Dec 11, 2013, at 9:21 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
>                  
>
>                  
>
>                     Jouni,
>
>                      
>
>                     ad 1. "monotonically" does not express your intention. What we are looking for may be "stepwise with fixed step".
>
>                      
>
>                     Ad 2. Is not necessarily a mistake that could result in out-of-sequence sequence numbers. When a client C sends a realm-type requests towards any server in the realm, an agent A1 that selects the server would send back the realm-type OLR with sequence number s1. The next realm-type request sent by C (that survived the throttling) may take a path that does not include A1 but A2. A2 then selects the server and sends back a sequence number s2. Nothing ensures that s1 and s2 are in sequence.
>
>                      
>
>                 Would the server in both cases (via A1 and A2) be the same?
>
>                  
>
>                 - Jouni
>
>                  
>
>                  
>
>                  
>
>                     Ulrich
>
>                      
>
>                      
>
>                     -----Original Message-----
>
>                     From: ext Jouni Korhonen [
>
>                     mailto:jouni.nospam@gmail.com
>
>                     ]
>
>                     Sent: Tuesday, December 10, 2013 10:31 PM
>
>                     To: Wiehe, Ulrich (NSN - DE/Munich)
>
>                     Cc: Ben Campbell;
>
>                     dime@ietf.org 
>
>                      list; Steve Donovan
>
>                     Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: 
>
>                     comments to 4.3
>
>                      
>
>                     Ulrich,
>
>                      
>
>                     On Dec 10, 2013, at 4:31 PM, "Wiehe, Ulrich (NSN - DE/Munich)" 
>
>                      
>
>                      wrote:
>
>                      
>
>                      
>
>                         Jouni,
>
>                          
>
>                         1. I find the texts
>
>                         a) "The sequence number ... does not need to be monotonically increasing"
>
>                         and
>
>                          
>
>                     Means the delta from old-seqno to new-seqno can be any non-negative 
>
>                     integer (within the given limits) not something fixed step/delta 
>
>                     (like +1). As long as "new-seqno >= old-seqno" holds we are fine.
>
>                      
>
>                      
>
>                         b) "...the new sequence number MUST be greater or equal than the old sequence number..."
>
>                         contradicting.
>
>                         Can you please clarify.
>
>                          
>
>                     See above. (mind the overflow case)
>
>                      
>
>                      
>
>                         2. The expected behaviour when receiving an out-of-sequence sequence number within OC-OLR is described in 4.3:
>
>                         "The receiver SHOULD discard an OC-OLR AVP with a sequence number that is less than previously received one."
>
>                         I don't find this very robust. Once a higher sequence number (received erroneously by mistake) is accepted you cannot (easily) recover.
>
>                          
>
>                     I find it more robust in a sense that I should not care about stale old information.
>
>                     However, since we are piggybacking (by popular demand) we have 
>
>                     little room for seqno re-sync negotiation.
>
>                      
>
>                     What is the mistake you refer here? A misbehaving implementation? 
>
>                     In that case, it deserves to get a manual intervention once figured 
>
>                     out by admins checking alarms and logs. If the mistake is due other 
>
>                     things, like endpoints being out of sync, we currently have no written down mechanism to survive that.
>
>                      
>
>                      
>
>                         3. The expected behaviour when receiving an out-of-sequence sequence number within the OC-Supported-Features AVP is not described. What is the intention here?
>
>                          
>
>                     No intention. Just a sloppy specification. You are right that 
>
>                     something needs to be done & clarified here. (again the semantics 
>
>                     of Time would nice..)
>
>                      
>
>                     I'll propose something. Others should too ;)
>
>                      
>
>                     - Jouni
>
>                      
>
>                      
>
>                         Ulrich
>
>                          
>
>                         -----Original Message-----
>
>                         From: DiME [
>
>                         mailto:dime-bounces@ietf.org
>
>                         ] On Behalf Of ext Jouni Korhonen
>
>                         Sent: Tuesday, December 10, 2013 8:28 AM
>
>                         To: Ben Campbell;
>
>                         dime@ietf.org 
>
>                          list; Steve Donovan
>
>                         Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: 
>
>                         OVLI: comments to 4.3
>
>                          
>
>                          
>
>                         Fine.. lets define then the sequence number semantics. Basic 
>
>                         unsigned integer math. The text proposal is the following:
>
>                          
>
>                         4.4.  OC-Sequence-Number AVP
>
>                          
>
>                         The OC-Sequence-Number AVP (AVP code TBD3) is type of Unsigned64.
>
>                         Its usage in the context of the overload control is described in 
>
>                         Sections 4.1 and 4.3.
>
>                          
>
>                         From the functionality point of view, the OC-Sequence-Number AVP 
>
>                         MUST be used as a non-volatile increasing counter between two 
>
>                         overload control endpoints.  The sequence number is only required 
>
>                         to be unique between two overload control endpoints and does not 
>
>                         need to be monotonically increasing.
>
>                          
>
>                         When comparing two sequence numbers, the new sequence number MUST 
>
>                         be greater or equal than the old sequence number within a window 
>
>                         that is half of the size of the maximum sequence number. This 
>
>                         allows a simple handling of the sequence number overflow using 
>
>                         unsigned integer arithmeticf:
>
>                          
>
>                           #define WINDOW 0x8000000000000000ULL
>
>                          
>
>                           bool verify_seqnum( uint64_t newsn, uint64_t oldsn ) {
>
>                               if (newsn - oldsn <= WINDOW)
>
>                                   // newsn >= oldsn
>
>                                   return true;   
>
>                               } else
>
>                                   // outside window or newsn < oldsn
>
>                                   return false;  
>
>                               }
>
>                           }
>
>                          
>
>                          
>
>                          
>
>                         The above should even work is someone shovels NTP times into 
>
>                         sequence numbers with a blind typecasting.
>
>                          
>
>                         - Jouni
>
>                          
>
>                         On Dec 10, 2013, at 12:34 AM, Ben Campbell  
>
>                          wrote:
>
>                          
>
>                          
>
>                             On Dec 9, 2013, at 10:00 AM, Steve Donovan  
>
>                              wrote:
>
>                              
>
>                              
>
>                                 Jouni,
>
>                                  
>
>                                 I propose that we keep the name OC-Sequence-Number but that we use the Time type for OC-Sequence-Number.  It is misleading and potentially confusing to call it OC-Time-Stamp.  
>
>                                  
>
>                                  
>
>                             I could live with that, although I would rather just define the expected properties of the sequence number, and leave the implementation up to the implementor. I assume your reasoning for not calling it a timestamp is that you do not want people to try to use it as a time base reference. If so, then we don't require any connection to a clock. We just need it to be monotonically increasing.
>
>                              
>
>                              
>
>                                 We might consider expanding on the format of the AVP to make it something like Session-ID, where it is a concatenation of the Diameter-ID of the generating node and a timestamp.  This might help the reacting node keep track of which sequence number it has received.
>
>                                  
>
>                                  
>
>                             Do we need a uniqueness across multiple nodes property? If so, why?
>
>                              
>
>                              
>
>                                 Steve
>
>                                  
>
>                                 On 12/9/13 5:37 AM, Jouni Korhonen wrote:
>
>                                  
>
>                                     Folks
>
>                                      
>
>                                     Could we conclude on the sequence number vs. time stamp vs. something else?
>
>                                     We got more important places to spend our energy than this ;)
>
>                                      
>
>                                     My proposal is the following (based on the original pre-00 design):
>
>                                      
>
>                                     o We change the OC-Sequence-Number to OC-Time-Stamp in all occurrences
>
>                                     in the -01.
>
>                                     o We use RFC6733 Time type for the OC-Time-Stamp. RFC6733 gives us
>
>                                     already exact definition how to handle the AVP.
>
>                                     o Define that the OC-Time-Stamp is the time of the creation of the 
>
>                                     "original" AVP within whose context the time stamp is present.
>
>                                     o The OC-Time-Stamp AVP uniqueness is still considered to be in scope
>
>                                     of the communicating endpoints.
>
>                                     o The time stamp can be used to quickly determine if the content of
>
>                                     the encapsulating AVP context has changed (among other properties).
>
>                                     This would be useful specifically in the future when the encapsulating
>
>                                     grouped AVPs  grow in size and functionality.
>
>                                      
>
>                                      
>
>                                     - Jouni
>
>                                      
>
>                                     _______________________________________________
>
>                                     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
>
>              
>
>          
>
>      
>
>     _______________________________________________
>
>     DiME mailing list
>
>     DiME@ietf.org 
>
>     https://www.ietf.org/mailman/listinfo/dime
>
>      
>
>      
>
>  
>


--------------070607040408070807060806
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Nirav,

      

      Assume that there are multiple agents reporting on realm
      overload.  The method these agents use to determine realm overload
      is an implementation decision, but will require some form of
      exchange of state between the agents to keep them in sync.  Note
      that we can't assume that all agents are getting all host overload
      reports.

      

      Under normal circumstances, the difference between the overload
      reports from these agents should be small, as you assert.  

      

      But consider the case where the replication mechanism between the
      agents is either congested or the network used by the agents to
      exchange state is no longer available.  It is easy to construct
      scenarios in this situation where agents could be reporting widely
      different realm overload report values.

      

      This is clearly an unlikely event, but it is one that can easily
      be prevented by including the id of the node that sends a report
      as part of the report.

      

      Regards,

      

      Steve

      

    
    
On 12/16/13 9:42 AM, Nirav Salot
      (nsalot) wrote:

    

    

      
      
      
      

        
Steve,

        
 

        
>
          The issue with considering only the last report is that it
          introduces the potential for thrashing between different
          values.  This could make the overload event even worse.

        
I
            am not sure about this. The two agents are not synchronized
            only for a very small window of time. But even then their
            reports should be reflecting the status of the realm,
            approximately if not accurately.

        
So
            I don’t think using one of the reports will make the
            situation worse.
            

        
 

        
I
            did not understand your argument regarding the security.

        
The
            client does not know the agent's identity anyway. So adding
            agent's identity in the overload-report is not going to
            change the security consideration anyway.

        
 

        
Regards,

        
Nirav.

        
 

        

          

            
From:
                Steve Donovan [mailto:srdonovan@usdonovans.com]
                

                Sent: Monday, December 16, 2013 5:47 PM

                To: Nirav Salot (nsalot); Jouni Korhonen

                Cc: Ben Campbell; dime@ietf.org list

                Subject: Re: [Dime] Conclusion for Sequence
                Numbers - was Re: OVLI: comments to 4.3

          

        

        
 

        
Nirav,

          

          The issue with considering only the last report is that it
          introduces the potential for thrashing between different
          values.  This could make the overload event even worse.

          

          I agree that this should be a rare case.  I still think,
          however, that we need to have defined behavior.

          

          One other argument for including the sender of the overload
          report in the report itself is security.  The ability of a bad
          actor to insert a malicious overload report can be a very
          effective DOS attack.  I know we have said we aren't
          addressing security yet but this seems pretty short sighted. 
          Being able to establish that the identity of the sender of an
          overload report will be an important part of the security
          solution.  We should take this step in that direction.

          

          Steve

        

          
On 12/12/13 10:26 AM, Nirav Salot
            (nsalot) wrote:

        

        

          
Steve,

          
 

          
So
              as I understand it is not a common case for different
              agent to provide different view of the same realm and this
              may have happen during a small window when synchronization
              has not taken place between the geographically distributed
              agents.

          
Right?

          
 

          
If
              so, I can understand the following part of your proposal.

          
One proposal for how we deal with the
            fact that different reports can have different values is to
            have the reacting node treat the first reporting node as the
            authority for reporting realm overload state for that
            overload instance.

          
 

          
i.e.
              I can understand to define some behavior for the reacting
              node to handle the case (which is anyway rare case) when
              two agents provide different realm-report for the same
              report.

          
The
              behavior could be simply to consider only the last report
              when two agents have sent two different reports of the
              same realm. (And this will also work when the same agent
              has sent two different realm-reports, purposefully – e.g.
              due to the change in the realm overload).

          
But
              this still does not require adding of agent's identity in
              the overload-report.

          
 

          
Regards,

          
Nirav.

          
 

          

            

              
From:
                  Steve Donovan [mailto:srdonovan@usdonovans.com]
                  

                  Sent: Thursday, December 12, 2013 7:50 PM

                  To: Nirav Salot (nsalot); Jouni Korhonen

                  Cc: Ben Campbell; dime@ietf.org list

                  Subject: Re: [Dime] Conclusion for Sequence
                  Numbers - was Re: OVLI: comments to 4.3

            

          

          
 

          
Nirav,

            

            See inline.

            

            Steve

          

            
On 12/12/13 6:40 AM, Nirav Salot
              (nsalot) wrote:

          

          

            
All,

            
 

            
I do not understand this discussion regarding different agents of the same realm having different view of the realm and provide different overload report.

          

          
We can make the statement that all
            senders of realm reports should send the same report.  This
            does not guarantee that it will always happen.  If agents
            are sending the report, they are generally distributed
            elements.  In very large networks, this distribution can
            span continents.  There will be a lag in the
            "synchronization" of the realm overload information.

            

            My concern is that we have well defined behavior for when a
            reactor receives conflicting realm reports.  We need to
            avoid thrashing between different reduction levels, which
            could make the overload situation worse.

            

            

            

          
 

          
Additionally, I also do not understand the proposal of adding identity of the agent generating "realm report" into the report.

          
Adding the endpoint identity is needed to
            allow the reacting node to know that it is receiving two
            different views of Realm overload from two different
            reporting end-points.

            

            

            

          
 

          
What is the use of this identity at the reacting node when the report is realm report? Why should the reacting node care who generated the realm report?

          
One proposal for how we deal with the
            fact that different reports can have different values is to
            have the reacting node treat the first reporting node as the
            authority for reporting realm overload state for that
            overload instance.  In this case, the reacting node would
            ignore reports received from other reporting nodes. In order
            to ignore reports from non authoritative endpoints requires
            the reacting node to know which endpoints send which
            reports.

            

            

            

          
 

          
 

          
Regards,

          
Nirav.

          
 

          
-----Original Message-----

          
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen

          
Sent: Thursday, December 12, 2013 5:06 PM

          
To: Steve Donovan

          
Cc: Ben Campbell; dime@ietf.org list

          
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3

          
 

          
Steve,

          
 

          
On Dec 11, 2013, at 3:13 PM, Steve Donovan <srdonovan@usdonovans.com> wrote:

          
 

          

            
Jouni,

            
 

            
We need the sequence number to be strictly increasing.  I don't see the need for it to increase in uniform amounts.  Using time does fit these requirements.  I'm ok with using time as long as we don't call the AVP timestamp.

            
 

            
Ulrich does bring up an interesting use case, where a client is receiving realm reports for the same realm from different agents.  We need to define the clients behavior in this case.  

          

          
 

          
Any suggestions? I mean agents may have hugely different view of the realm if they are acting on their own.

          
 

          

            
Presumably the client needs to be able to determine who generated the realm report.  This cannot be determine based on the content of the message or the connection on which the message arrived.  It seems like we might need "Report Generator Diameter ID" in the overload report specifically for Realm reports.  

            
 

            
Once the client is able to differentiate between realm reports sent by different agents (or servers) we need logic defining how the client deals with a new overload report.  

          

          
 

          
I need now to check one of the basic assumptions on DOIC now so that we have the same understanding. I went back to the endpoint text in Section 5.1. There, for example in Figures

          
4 and 5 the DOIC association and the endpoint assumption does does not work IMHO because we have no endpoint identity in the OLR. In order the endpoint assumption to work (as I drew it on the white board in Porto), it would require as many Diameter level sessions as there are DOIC associations.

          
 

          
So.. has assumptions shifted in a meanwhile and I have just not paid attention?

          
 

          

            
I see a couple of options (others will probably see options I am missing):

            
 

            
- Use the last received realm report - This introduces the possibility of thrashing between two different reduction values and different durations.  Note that this approach does not require the source of the report to be included in the report.

            
 

            
- Only listen to one source of realm overload - The approach would be to remember who sent the first overload report from the realm and ignore realm overload reports from other sources.  This behavior would likely be constrained to a single occurrence of realm overload.  Meaning that the "memory" of the report source would only last as long as that overload event persists.  Once the overload event goes away, the report source would be forgotten and a new source could be used for the next occurrence.

            
 

            
On the surface, the second approach looks better to me.

          

          
 

          
Or add the identity of the OLR originator explicitly if it cannot be determined implicitly (i.e. from the Diameter message's Origin-Host/Realm).

          
 

          
Or assume the endpoint really is the endpoint in DOIC and Diameter session sense.

          
 

          
- Jouni

          
 

          

            
 

            
Steve

            
 

            
On 12/11/13 2:15 AM, Jouni wrote:

            

              
Ulrich,

              
 

              
I might be slow but.. Section 4.4 says

              
 

              
   control endpoints.  The sequence number is only required to be unique

              
   between two overload control endpoints and does not need to be

              
 

              
Unique between two endpoints..

              
 

              
Section 5.1 talks about endpoints:

              
 

              
   of an arbitrary Diameter network.  The overload control information

              
   is exchanged over on a "DOIC association" between two communication

              
   endpoints.  The endpoints, namely the "reacting node" and the

              
   "reporting node" do not need to be adjacent Diameter peer nodes, 

              
nor

              
 

              
So if your agents inject realm reports, they need to be endpoints to 

              
the client. Similar to Figure 5. Therefore the sequence number spaces 

              
between

              
C-A1 and C-A2 are separate.

              
 

              
Now it is not clear to me, whether in your reasoning the C would see 

              
the server identity (as the endpoint) when there is an active "DEP 

              
agent" on the path. That would not clearly work and not be align with 

              
the endpoint assumption.

              
 

              
Note that at some point of time we had (at least on a discussion 

              
level in f2f meeting) report originator identity in the OLR. That 

              
would make endpoint identification trivial. Now a "DEP agent" needs 

              
to act as a "server" for its clients in order to appear as an endpoint.

              
 

              
- Jouni

              
 

              
ps: still think the use of Time is simpler..

              
 

              
 

              
On Dec 11, 2013, at 9:43 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:

              
 

              
 

              

                
That's not predictable. It may be the same server in some cases, and different servers in other cases.

                
 

                
-----Original Message-----

                
From: ext Jouni [

                
mailto:jouni.nospam@gmail.com

                
]

                
Sent: Wednesday, December 11, 2013 8:38 AM

                
To: Wiehe, Ulrich (NSN - DE/Munich)

                
Cc: Ben Campbell;

                
dime@ietf.org

                
 list; Steve Donovan

                
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: 

                
comments to 4.3

                
 

                
 

                
Ulrich,

                
 

                
On Dec 11, 2013, at 9:21 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:

                
 

                
 

                

                  
Jouni,

                  
 

                  
ad 1. "monotonically" does not express your intention. What we are looking for may be "stepwise with fixed step".

                  
 

                  
Ad 2. Is not necessarily a mistake that could result in out-of-sequence sequence numbers. When a client C sends a realm-type requests towards any server in the realm, an agent A1 that selects the server would send back the realm-type OLR with sequence number s1. The next realm-type request sent by C (that survived the throttling) may take a path that does not include A1 but A2. A2 then selects the server and sends back a sequence number s2. Nothing ensures that s1 and s2 are in sequence.

                  
 

                

                
Would the server in both cases (via A1 and A2) be the same?

                
 

                
- Jouni

                
 

                
 

                
 

                

                  
Ulrich

                  
 

                  
 

                  
-----Original Message-----

                  
From: ext Jouni Korhonen [

                  
mailto:jouni.nospam@gmail.com

                  
]

                  
Sent: Tuesday, December 10, 2013 10:31 PM

                  
To: Wiehe, Ulrich (NSN - DE/Munich)

                  
Cc: Ben Campbell;

                  
dime@ietf.org

                  
 list; Steve Donovan

                  
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: 

                  
comments to 4.3

                  
 

                  
Ulrich,

                  
 

                  
On Dec 10, 2013, at 4:31 PM, "Wiehe, Ulrich (NSN - DE/Munich)" 

                  
<ulrich.wiehe@nsn.com>

                  
 wrote:

                  
 

                  
 

                  

                    
Jouni,

                    
 

                    
1. I find the texts

                    
a) "The sequence number ... does not need to be monotonically increasing"

                    
and

                    
 

                  

                  
Means the delta from old-seqno to new-seqno can be any non-negative 

                  
integer (within the given limits) not something fixed step/delta 

                  
(like +1). As long as "new-seqno >= old-seqno" holds we are fine.

                  
 

                  
 

                  

                    
b) "...the new sequence number MUST be greater or equal than the old sequence number..."

                    
contradicting.

                    
Can you please clarify.

                    
 

                  

                  
See above. (mind the overflow case)

                  
 

                  
 

                  

                    
2. The expected behaviour when receiving an out-of-sequence sequence number within OC-OLR is described in 4.3:

                    
"The receiver SHOULD discard an OC-OLR AVP with a sequence number that is less than previously received one."

                    
I don't find this very robust. Once a higher sequence number (received erroneously by mistake) is accepted you cannot (easily) recover.

                    
 

                  

                  
I find it more robust in a sense that I should not care about stale old information.

                  
However, since we are piggybacking (by popular demand) we have 

                  
little room for seqno re-sync negotiation.

                  
 

                  
What is the mistake you refer here? A misbehaving implementation? 

                  
In that case, it deserves to get a manual intervention once figured 

                  
out by admins checking alarms and logs. If the mistake is due other 

                  
things, like endpoints being out of sync, we currently have no written down mechanism to survive that.

                  
 

                  
 

                  

                    
3. The expected behaviour when receiving an out-of-sequence sequence number within the OC-Supported-Features AVP is not described. What is the intention here?

                    
 

                  

                  
No intention. Just a sloppy specification. You are right that 

                  
something needs to be done & clarified here. (again the semantics 

                  
of Time would nice..)

                  
 

                  
I'll propose something. Others should too ;)

                  
 

                  
- Jouni

                  
 

                  
 

                  

                    
Ulrich

                    
 

                    
-----Original Message-----

                    
From: DiME [

                    
mailto:dime-bounces@ietf.org

                    
] On Behalf Of ext Jouni Korhonen

                    
Sent: Tuesday, December 10, 2013 8:28 AM

                    
To: Ben Campbell;

                    
dime@ietf.org

                    
 list; Steve Donovan

                    
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: 

                    
OVLI: comments to 4.3

                    
 

                    
 

                    
Fine.. lets define then the sequence number semantics. Basic 

                    
unsigned integer math. The text proposal is the following:

                    
 

                    
4.4.  OC-Sequence-Number AVP

                    
 

                    
The OC-Sequence-Number AVP (AVP code TBD3) is type of Unsigned64.

                    
Its usage in the context of the overload control is described in 

                    
Sections 4.1 and 4.3.

                    
 

                    
From the functionality point of view, the OC-Sequence-Number AVP 

                    
MUST be used as a non-volatile increasing counter between two 

                    
overload control endpoints.  The sequence number is only required 

                    
to be unique between two overload control endpoints and does not 

                    
need to be monotonically increasing.

                    
 

                    
When comparing two sequence numbers, the new sequence number MUST 

                    
be greater or equal than the old sequence number within a window 

                    
that is half of the size of the maximum sequence number. This 

                    
allows a simple handling of the sequence number overflow using 

                    
unsigned integer arithmeticf:

                    
 

                    
  #define WINDOW 0x8000000000000000ULL

                    
 

                    
  bool verify_seqnum( uint64_t newsn, uint64_t oldsn ) {

                    
      if (newsn - oldsn <= WINDOW)

                    
          // newsn >= oldsn

                    
          return true;   

                    
      } else

                    
          // outside window or newsn < oldsn

                    
          return false;  

                    
      }

                    
  }

                    
 

                    
 

                    
 

                    
The above should even work is someone shovels NTP times into 

                    
sequence numbers with a blind typecasting.

                    
 

                    
- Jouni

                    
 

                    
On Dec 10, 2013, at 12:34 AM, Ben Campbell <ben@nostrum.com>

                    
 wrote:

                    
 

                    
 

                    

                      
On Dec 9, 2013, at 10:00 AM, Steve Donovan <srdonovan@usdonovans.com>

                      
 wrote:

                      
 

                      
 

                      

                        
Jouni,

                        
 

                        
I propose that we keep the name OC-Sequence-Number but that we use the Time type for OC-Sequence-Number.  It is misleading and potentially confusing to call it OC-Time-Stamp.  

                        
 

                        
 

                      

                      
I could live with that, although I would rather just define the expected properties of the sequence number, and leave the implementation up to the implementor. I assume your reasoning for not calling it a timestamp is that you do not want people to try to use it as a time base reference. If so, then we don't require any connection to a clock. We just need it to be monotonically increasing.

                      
 

                      
 

                      

                        
We might consider expanding on the format of the AVP to make it something like Session-ID, where it is a concatenation of the Diameter-ID of the generating node and a timestamp.  This might help the reacting node keep track of which sequence number it has received.

                        
 

                        
 

                      

                      
Do we need a uniqueness across multiple nodes property? If so, why?

                      
 

                      
 

                      

                        
Steve

                        
 

                        
On 12/9/13 5:37 AM, Jouni Korhonen wrote:

                        
 

                        

                          
Folks

                          
 

                          
Could we conclude on the sequence number vs. time stamp vs. something else?

                          
We got more important places to spend our energy than this ;)

                          
 

                          
My proposal is the following (based on the original pre-00 design):

                          
 

                          
o We change the OC-Sequence-Number to OC-Time-Stamp in all occurrences

                          
in the -01.

                          
o We use RFC6733 Time type for the OC-Time-Stamp. RFC6733 gives us

                          
already exact definition how to handle the AVP.

                          
o Define that the OC-Time-Stamp is the time of the creation of the 

                          
"original" AVP within whose context the time stamp is present.

                          
o The OC-Time-Stamp AVP uniqueness is still considered to be in scope

                          
of the communicating endpoints.

                          
o The time stamp can be used to quickly determine if the content of

                          
the encapsulating AVP context has changed (among other properties).

                          
This would be useful specifically in the future when the encapsulating

                          
grouped AVPs  grow in size and functionality.

                          
 

                          
 

                          
- Jouni

                          
 

                          
_______________________________________________

                          
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

                  

                

              

              
 

            

            
 

          

          
 

          
_______________________________________________

          
DiME mailing list

          
DiME@ietf.org

          
https://www.ietf.org/mailman/listinfo/dime

          
 

          
 

        

        
 

      

    

    

  


--------------070607040408070807060806--

From srdonovan@usdonovans.com  Mon Dec 16 08:12:10 2013
Return-Path: 
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 D65801AE360 for ; Mon, 16 Dec 2013 08:12:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.12
X-Spam-Level: 
X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no
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 jxu-_QY320sK for ; Mon, 16 Dec 2013 08:12:03 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 896021AE357 for ; Mon, 16 Dec 2013 08:12:03 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:62601 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1Vsalz-0001P1-7j; Mon, 16 Dec 2013 08:12:02 -0800
Message-ID: <52AF264E.9070304@usdonovans.com>
Date: Mon, 16 Dec 2013 10:11:58 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: "Nirav Salot (nsalot)" , "dime@ietf.org" 
References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <13081_1386256433_52A09831_13081_8197_1_6B7134B31289DC4FAF! 731D84412 2B36E32B6EB@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B9209739738@ESESSMB101.ericsson.se>  <8FD63E2D-5203-4DA4-A6DA-C4CA181C9CFB@nostrum.com> <26C84DFD55BC3040A45BF70926E55F2587C1D786@SZXEMA512-MBX.china.huawei.com>  <52A86663.30500@usdonovans.com>  <087A34937E64E74E848732CFF8354B920973A82A@ESESSMB101.ericsson.se> <52A8B862.5040207@usdonovans.com> <087A34937E64E74E848732CFF8354B920973AAF5@ESESSMB101.ericsson.se> <52A9BE1F.7020201@usdonovans.com>  <52AEFED7.5060908@usdonovans.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------040106000903020206090100"
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Dec 2013 16:12:10 -0000

This is a multi-part message in MIME format.
--------------040106000903020206090100
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

Nirav,

There is nothing in the self-contained overload report proposal the
requires cross-application data handling.  An implementation can take
advantage of cross-application information if it is able and wants to,
but it is not required to do so.

Regards,

Steve
On 12/16/13 9:50 AM, Nirav Salot (nsalot) wrote:
>
> Steve,
>
>  
>
> SRD> I don't understand what is meant by "requires architectural
> support".  Is this a way of saying it is more difficult to implement?
> As of today, the Diameter message can only contain data specific to
> one application and based on this, the nodes are designed to handle
> data/AVP specific to one application.
>
> Thus, cross-application data handling (that you are proposing via
> "self-contained OLR") is not required to be supported in today's
> design/architecture of the Diameter node supporting a set of applications.
>
>  
>
> Regards,
>
> Nirav.
>
>  
>
> *From:*Steve Donovan [mailto:srdonovan@usdonovans.com]
> *Sent:* Monday, December 16, 2013 6:54 PM
> *To:* Nirav Salot (nsalot); dime@ietf.org
> *Subject:* Re: [Dime] DOIC: Self-Contained OLRs
>
>  
>
> Nirav,
>
> See my response inline.
>
> Regards,
>
> Steve
>
> On 12/12/13 10:36 AM, Nirav Salot (nsalot) wrote:
>
>     Steve,
>
>      
>
>     Why do you always talk about "the application which the Diameter
>     node does not understand?"
>
>     What if the reacting node supports two applications and in the
>     message for application-X it receives the overload-report for
>     application-Y?
>
>     Do you propose to ignore this report as well?
>
> SRD> The logic behind self contained reports would be that the
> reactor  use the reports that it makes sense for the reactor to use. 
> I think your question is what should a reactor do if it supports
> application-X and application-Y, sends a request for application-X and
> receives a reply with an overload report for application-Y in the
> answer to that request. The behavior I would suggest is that the
> reactor should (not must) honor the overload report for requests sent
> to application-Y.  If this is particularly difficult for the reactor
> to achieve then it can wait to receive an overload for application-Y
> in answers to requests sent on application-Y.
>
>  
>
> As already indicated earlier, by many of us, handling of
> application-Y's data in the application-X's message is not how the
> Diameter applications are designed today. And hence this type of
> proposal requires architectural support for handling it. And there
> lies the complexity.
>
> SRD> I don't understand what is meant by "requires architectural
> support".  Is this a way of saying it is more difficult to implement?
>
> This main drawback was highlighted earlier as well but was
> conveniently ignored while preparing the pros and cons list for the
> self-contained OLR.
>
> SRD> Then suggest it be added to the pros and cons list.  But first
> explain the concept of "requires architectural support". 
>
>  
>
> Regards,
>
> Nirav.
>
>  
>
> *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *Steve Donovan
> *Sent:* Thursday, December 12, 2013 7:16 PM
> *To:* dime@ietf.org 
> *Subject:* Re: [Dime] DOIC: Self-Contained OLRs
>
>  
>
> Maria Cruz,
>
> Can you explain the complexity behind the cross-application
> procedure.  The work required is to ignore any application that the
> Diameter node does not understand.  I don't see this as very complex.
>
> Steve
>
> On 12/12/13 1:26 AM, Maria Cruz Bartolome wrote:
>
>     Yes, I agree consistency is not any longer a problem, since now
>     your intention is that _/any/_ (and multiple) application data
>     could be conveyed within the same message.
>
>     But as mentioned a few times, I consider this not necessary since
>     OLR is sent in every answer.
>
>     A part from that, as mentioned by Lionel, this implies a
>     cross-application procedure at both endpoints, that increases
>     complexity and it is not required for our work (RFC7068)
>
>      
>
>     Cheers
>
>     /MCruz
>
>      
>
>     *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *Steve
>     Donovan
>     *Sent:* miércoles, 11 de diciembre de 2013 20:09
>     *To:* dime@ietf.org 
>     *Subject:* Re: [Dime] DOIC: Self-Contained OLRs
>
>      
>
>     Maria Cruz,
>
>     I don't agree with the assertion that self-contained OLRs results
>     in the potential for data inconsistency.  If a reactor receives an
>     overload report for an application that is not supported by the
>     reactor then the reactor can and should ignore that OLR. 
>
>     The concept of self-contained overload reports would explicitly
>     allow for the contents of the overload report to be different than
>     the message that is carrying the OLR.  As with application-ids, if
>     the reactor doesn't send messages to a reported host or realm then
>     the reactor ignores that part of the overload report.  As such,
>     there is no need to check the implicit data when receiving a
>     self-contained OLR.
>
>     Steve
>
>     On 12/11/13 12:25 PM, Maria Cruz Bartolome wrote:
>
>         Hello (and something else now J, fast key combination, I won't
>         be able to repeat,  was the responsible)
>
>          
>
>         As mentioned before, something else on cons side for
>         self-contained:
>
>          
>
>         A part from that,  one concern with "self-contained OLRs" is
>         that some data is duplicated. Duplication should be avoided,
>         since then we need to assure consistency, and error handing in
>         case implicit and explicit data values are different for any
>         reason... what means that it may always be required to check
>         both implicit and explicit data.
>
>          
>
>         Also, I think this is a pure implementation proposal.
>         Regardless how the data is transported it could be packed in a
>         "self-contained OLRs" within the diameter application, if for
>         any implementation this is preferred.
>
>          
>
>         Best regards
>
>         /MCruz
>
>          
>
>         *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of
>         *TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
>         *Sent:* miércoles, 11 de diciembre de 2013 19:02
>         *To:* dime@ietf.org 
>         *Subject:* Re: [Dime] DOIC: Self-Contained OLRs
>
>          
>
>         Hi Steve
>
>          
>
>         I am sorry, Steve,  I do not see the difference between the
>         Draft Roach scope approach and the self contained OLRs.
>
>          
>
>         With the scope approach in Draft Roach : there is an overload
>         metric AVP  (eg containing a % of traffic reduction) coupled
>         with one or several Overlaod-Infoscope AVPs, an overlaod
>         infoscope identifying an application or a destination host
>         or... . These Overlaod-Infoscope AVPs can be combined  with
>         also  the possibility of  multi instances to have a list of
>         applications, a list of destination hosts etc  to which the
>         overload metric would apply.
>
>          
>
>         With self contained OLR as you have described them, un OLR
>         will also contain an OC-Reduction-Percentage AVP coupled with
>         one or several others AVPs (the self containment approach) to
>         indicate which application(s), destinations host (s) etc the
>           OC-Reduction-Percentage AVP applies.
>
>          
>
>         Where is the difference?
>
>          
>
>         So the drawbacks identified for the scope approach also apply
>         with the self contained approach
>
>          
>
>         Best regards
>
>          
>
>         JJacques
>
>          
>
>          
>
>          
>
>         *De :*DiME [mailto:dime-bounces@ietf.org] *De la part de*
>         Steve Donovan
>         *Envoyé :* mercredi 11 décembre 2013 14:20
>         *À :* dime@ietf.org 
>         *Objet :* Re: [Dime] DOIC: Self-Contained OLRs
>
>          
>
>         JJacques,
>
>         While the self contained overload report concept may be
>         similar to the scopes concept in the Roach draft, they are not
>         the same.  As such, I don't agree with your assertion that the
>         previous rejection of the Roach draft requires us to reject
>         self contained overload reports as currently being discussed.
>
>         Steve
>
>         On 12/11/13 2:27 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:
>
>             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  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
>             >
>             wrote:
>
>
>             OK. Lets call this thread concluded then. I keep the old
>             OC-OLR  semantics
>             regarding its information context then unmodified.
>
>             - Jouni
>
>              
>
>              
>
>             _______________________________________________
>
>             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
>
>  
>
>  
>


--------------040106000903020206090100
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Nirav,

      

      There is nothing in the self-contained overload report proposal
      the requires cross-application data handling.  An implementation
      can take advantage of cross-application information if it is able
      and wants to, but it is not required to do so.

      

      Regards,

      

      Steve

    
    
On 12/16/13 9:50 AM, Nirav Salot
      (nsalot) wrote:

    

    

      
      
      
      

        
Steve,

        
 

        
SRD> I don't understand what is meant by
          "requires architectural support".  Is this a way of saying it
          is more difficult to implement?

          As
            of today, the Diameter message can only contain data
            specific to one application and based on this, the nodes are
            designed to handle data/AVP specific to one application.

        
Thus,
            cross-application data handling (that you are proposing via
            "self-contained OLR") is not required to be supported in
            today's design/architecture of the Diameter node supporting
            a set of applications.

        
 

        
Regards,

        
Nirav.

        
 

        

          

            
From:
                Steve Donovan [mailto:srdonovan@usdonovans.com]
                

                Sent: Monday, December 16, 2013 6:54 PM

                To: Nirav Salot (nsalot); dime@ietf.org

                Subject: Re: [Dime] DOIC: Self-Contained OLRs

          

        

        
 

        
Nirav,

          

          See my response inline.

          

          Regards,

          

          Steve

        

          
On 12/12/13 10:36 AM, Nirav Salot
            (nsalot) wrote:

        

        

          
Steve,

          
 

          
Why
              do you always talk about "the application which the
              Diameter node does not understand?"

          
What
              if the reacting node supports two applications and in the
              message for application-X it receives the overload-report
              for application-Y?

          
Do
              you propose to ignore this report as well?

        

        
SRD> The logic behind self contained
          reports would be that the reactor  use the reports that it
          makes sense for the reactor to use.  I think your question is
          what should a reactor do if it supports application-X and
          application-Y, sends a request for application-X and receives
          a reply with an overload report for application-Y in the
          answer to that request. The behavior I would suggest is that
          the reactor should (not must) honor the overload report for
          requests sent to application-Y.  If this is particularly
          difficult for the reactor to achieve then it can wait to
          receive an overload for application-Y in answers to requests
          sent on application-Y.

          

          

        
 

        
As
            already indicated earlier, by many of us, handling of
            application-Y's data in the application-X's message is not
            how the Diameter applications are designed today. And hence
            this type of proposal requires architectural support for
            handling it. And there lies the complexity.

        
SRD> I don't understand what is meant by
          "requires architectural support".  Is this a way of saying it
          is more difficult to implement?

          

          

        
This
            main drawback was highlighted earlier as well but was
            conveniently ignored while preparing the pros and cons list
            for the self-contained OLR.

        
SRD> Then suggest it be added to the
          pros and cons list.  But first explain the concept of
          "requires architectural support". 
          

          

          

        
 

        
Regards,

        
Nirav.

        
 

        

          

            
From:
                DiME [mailto:dime-bounces@ietf.org]
                On Behalf Of Steve Donovan

                Sent: Thursday, December 12, 2013 7:16 PM

                To: dime@ietf.org

                Subject: Re: [Dime] DOIC: Self-Contained OLRs

          

        

        
 

        
Maria Cruz,

          

          Can you explain the complexity behind the cross-application
          procedure.  The work required is to ignore any application
          that the Diameter node does not understand.  I don't see this
          as very complex.

          

          Steve

        

          
On 12/12/13 1:26 AM, Maria Cruz Bartolome
            wrote:

        

        

          
Yes,
              I agree consistency is not any longer a problem, since now
              your intention is that _any_ (and multiple)
              application data could be conveyed within the same
              message.

          
But
              as mentioned a few times, I consider this not necessary
              since OLR is sent in every answer.
            

          
A
              part from that, as mentioned by Lionel, this implies a
              cross-application procedure at both endpoints, that
              increases complexity and it is not required for our work
              (RFC7068)

          
 

          
Cheers

          
/MCruz

          
 

          

            

              
From:
                  DiME [mailto:dime-bounces@ietf.org]
                  On Behalf Of Steve Donovan

                  Sent: miércoles, 11 de diciembre de 2013 20:09

                  To: dime@ietf.org

                  Subject: Re: [Dime] DOIC: Self-Contained OLRs

            

          

          
 

          
Maria Cruz,

            

            I don't agree with the assertion that self-contained OLRs
            results in the potential for data inconsistency.  If a
            reactor receives an overload report for an application that
            is not supported by the reactor then the reactor can and
            should ignore that OLR. 
            

            

            The concept of self-contained overload reports would
            explicitly allow for the contents of the overload report to
            be different than the message that is carrying the OLR.  As
            with application-ids, if the reactor doesn't send messages
            to a reported host or realm then the reactor ignores that
            part of the overload report.  As such, there is no need to
            check the implicit data when receiving a self-contained OLR.

            

            Steve

          

            
On 12/11/13 12:25 PM, Maria Cruz
              Bartolome wrote:

          

          

            
Hello (and something else now 
                J, fast key combination, I won’t be able to
              repeat,  was the responsible)

            
 

            
As mentioned before, something else
              on cons side for self-contained:

            
 

            
A part from
              that,  one concern with "self-contained OLRs" is that some
              data is duplicated. Duplication should be avoided, since
              then we need to assure consistency, and error handing in
              case implicit and explicit data values are different for
              any reason... what means that it may always be required to
              check both implicit and explicit data.

            
 

            
Also, I
              think this is a pure implementation proposal. Regardless
              how the data is transported it could be packed in a
              "self-contained OLRs" within the diameter application, if
              for any implementation this is preferred.

            
 

            
Best
                regards

            
/MCruz

            
 

            

              

                
From:
                    DiME [mailto:dime-bounces@ietf.org]
                    On Behalf Of TROTTIN, JEAN-JACQUES
                    (JEAN-JACQUES)

                    Sent: miércoles, 11 de diciembre de 2013
                    19:02

                    To: dime@ietf.org

                    Subject: Re: [Dime] DOIC: Self-Contained OLRs

              

            

            
 

            
Hi
                Steve

            
 

            
I
                am sorry, Steve,  I do not see the difference between
                the Draft Roach scope approach and the self contained
                OLRs.

            
 

            
With
                the scope approach in Draft Roach : there is an overload
                metric AVP  (eg containing a % of traffic reduction)
                coupled with one or several Overlaod-Infoscope AVPs, an
                overlaod infoscope identifying an application or a
                destination host or… . These Overlaod-Infoscope AVPs can
                be combined  with also  the possibility of  multi
                instances to have a list of applications, a list of
                destination hosts etc  to which the overload metric
                would apply.

            
 

            
With
                self contained OLR as you have described them, un OLR
                will also contain an OC-Reduction-Percentage
               AVP
                coupled with one or several others AVPs (the self
                containment approach) to indicate which application(s),
                destinations host (s) etc the   OC-Reduction-Percentage
               AVP
                applies.
              

            
 

            
Where
                is the difference?

            
 

            
So
                the drawbacks identified for the scope approach also
                apply with the self contained approach
              

            
 

            
Best
                regards

            
 

            
JJacques
              

            
 

            
 

            
 

            

              

                
De : DiME [mailto:dime-bounces@ietf.org]
                    De la part de Steve Donovan

                    Envoyé : mercredi 11 décembre 2013 14:20

                    À : dime@ietf.org

                    Objet : Re: [Dime] DOIC: Self-Contained OLRs

              

            

            
 

            
JJacques,

              

              While the self contained overload report concept may be
              similar to the scopes concept in the Roach draft, they are
              not the same.  As such, I don't agree with your assertion
              that the previous rejection of the Roach draft requires us
              to reject self contained overload reports as currently
              being discussed.

              

              Steve

            

              
On 12/11/13 2:27 AM, TROTTIN,
                JEAN-JACQUES (JEAN-JACQUES) wrote:

            

            

              
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
                      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>
                wrote:

              


                OK. Lets call this thread concluded then. I keep the old
                OC-OLR  semantics

                regarding its information context then unmodified.

                

                - Jouni

              
 

              
 

              
_______________________________________________

              
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

        

        
 

        
 

      

    

    

  


--------------040106000903020206090100--

From nsalot@cisco.com  Mon Dec 16 08:26:24 2013
Return-Path: 
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 7C4841ADF83 for ; Mon, 16 Dec 2013 08:26:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.038
X-Spam-Level: 
X-Spam-Status: No, score=-15.038 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.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 0HE9U_g15qHE for ; Mon, 16 Dec 2013 08:26:16 -0800 (PST)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 7511E1ADF50 for ; Mon, 16 Dec 2013 08:26:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=63529; q=dns/txt; s=iport; t=1387211175; x=1388420775; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=U/YfkFoxrPi9TJz5KTTHVmaD3F5P7I8MbDVJKGNd2nU=; b=enajiMPrlWrC4m8GtQh4t7uJYfroimqaRZoCJIeOm1S/GXO7usLBBhag NeJOqZElMKRCdQNB9GotiwIeV6hbMLP6JiW9TMrhmTWF/C7YkKwq9utAU 7piAOyePrzi8Y0jL9x2rbTpCu2LhomfrxXg9BsljpWuR71SCi5LC0NwsN 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ak8FAN4or1KtJV2Z/2dsb2JhbABQCYJGRDhVuHKBJRZ0giUBAQEDAQEBARcBEkELBQcEAgEIDgMEAQELFgEGByEGCxQJCAIEAQ0FCBOHVQMJCA3BCQ2HARMEjQaBOCotBAYBBoMdgRMBA5QzgXiORYU6gyqCKg
X-IronPort-AV: E=Sophos;i="4.95,495,1384300800";  d="scan'208,217";a="291852104"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP; 16 Dec 2013 16:26:12 +0000
Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rBGGQCpB020995 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 16 Dec 2013 16:26:12 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.227]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Mon, 16 Dec 2013 10:26:12 -0600
From: "Nirav Salot (nsalot)" 
To: Steve Donovan , Jouni Korhonen 
Thread-Topic: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3
Thread-Index: AQHO90VQs8ahl6t/j0WtaMBOVpqI85pQvUrggAZqGID//9O4MIAAbVIA//+eU2A=
Date: Mon, 16 Dec 2013 16:26:11 +0000
Message-ID: 
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DB1B@DEMUMBX014.nsn-intra.net>  <52A5E902.20605@usdonovans.com> <7475B713-1104-4791-96B1-CE97632A0D69@nostrum.com>  <5BCBA1FC2B7F0B4C9D935572D90006681519E476@DEMUMBX014.nsn-intra.net> <1CD20507-B0FE-4367-804A-B831734CF060@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E6DC@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D90006681519E712@DEMUMBX014.nsn-intra.net> <4A151D70-0291-4238-85B1-03BB54B361E6@gmail.com> <52A864FF.10705@usdonovans.com>   <52A9C62A.6010207@usdonovans.com>  <52AEEF27.50208@usdonovans.com>  <52AF25B6.4030702@usdonovans.com>
In-Reply-To: <52AF25B6.4030702@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.65.72.21]
Content-Type: multipart/alternative; boundary="_000_A9CA33BB78081F478946E4F34BF9AAA014D33D5Bxmbrcdx10ciscoc_"
MIME-Version: 1.0
Cc: Ben Campbell , "dime@ietf.org list" 
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Dec 2013 16:26:24 -0000

--_000_A9CA33BB78081F478946E4F34BF9AAA014D33D5Bxmbrcdx10ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Steve,

You are talking about "what if one of the agents in the realm has very skew=
ed view of the state of the realm - for whatever reason".
I guess this is much bigger issue and will lead to bigger problems, e.g. al=
l the clients connected to this agent and not sending any request via other=
 agents of the realm, will always have skewed view of the realm.
So that problem should be solved, first. (of course, not here, not by us).

In general, for realm report to be usable, we need to assume that agents ar=
e synchronized (except for a very small window of time) and have consistent=
 view (if not exactly the same view always) of the same realm.
Otherwise, realm report will itself create issues among different clients a=
nd hence should be avoided completely.

Regards,
Nirav.

From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Monday, December 16, 2013 9:39 PM
To: Nirav Salot (nsalot); Jouni Korhonen
Cc: Ben Campbell; dime@ietf.org list
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comment=
s to 4.3

Nirav,

Assume that there are multiple agents reporting on realm overload.  The met=
hod these agents use to determine realm overload is an implementation decis=
ion, but will require some form of exchange of state between the agents to =
keep them in sync.  Note that we can't assume that all agents are getting a=
ll host overload reports.

Under normal circumstances, the difference between the overload reports fro=
m these agents should be small, as you assert.

But consider the case where the replication mechanism between the agents is=
 either congested or the network used by the agents to exchange state is no=
 longer available.  It is easy to construct scenarios in this situation whe=
re agents could be reporting widely different realm overload report values.

This is clearly an unlikely event, but it is one that can easily be prevent=
ed by including the id of the node that sends a report as part of the repor=
t.

Regards,

Steve
On 12/16/13 9:42 AM, Nirav Salot (nsalot) wrote:
Steve,

> The issue with considering only the last report is that it introduces the=
 potential for thrashing between different values.  This could make the ove=
rload event even worse.
I am not sure about this. The two agents are not synchronized only for a ve=
ry small window of time. But even then their reports should be reflecting t=
he status of the realm, approximately if not accurately.
So I don't think using one of the reports will make the situation worse.

I did not understand your argument regarding the security.
The client does not know the agent's identity anyway. So adding agent's ide=
ntity in the overload-report is not going to change the security considerat=
ion anyway.

Regards,
Nirav.

From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Monday, December 16, 2013 5:47 PM
To: Nirav Salot (nsalot); Jouni Korhonen
Cc: Ben Campbell; dime@ietf.org list
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comment=
s to 4.3

Nirav,

The issue with considering only the last report is that it introduces the p=
otential for thrashing between different values.  This could make the overl=
oad event even worse.

I agree that this should be a rare case.  I still think, however, that we n=
eed to have defined behavior.

One other argument for including the sender of the overload report in the r=
eport itself is security.  The ability of a bad actor to insert a malicious=
 overload report can be a very effective DOS attack.  I know we have said w=
e aren't addressing security yet but this seems pretty short sighted.  Bein=
g able to establish that the identity of the sender of an overload report w=
ill be an important part of the security solution.  We should take this ste=
p in that direction.

Steve
On 12/12/13 10:26 AM, Nirav Salot (nsalot) wrote:
Steve,

So as I understand it is not a common case for different agent to provide d=
ifferent view of the same realm and this may have happen during a small win=
dow when synchronization has not taken place between the geographically dis=
tributed agents.
Right?

If so, I can understand the following part of your proposal.
One proposal for how we deal with the fact that different reports can have =
different values is to have the reacting node treat the first reporting nod=
e as the authority for reporting realm overload state for that overload ins=
tance.

i.e. I can understand to define some behavior for the reacting node to hand=
le the case (which is anyway rare case) when two agents provide different r=
ealm-report for the same report.
The behavior could be simply to consider only the last report when two agen=
ts have sent two different reports of the same realm. (And this will also w=
ork when the same agent has sent two different realm-reports, purposefully =
- e.g. due to the change in the realm overload).
But this still does not require adding of agent's identity in the overload-=
report.

Regards,
Nirav.

From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Thursday, December 12, 2013 7:50 PM
To: Nirav Salot (nsalot); Jouni Korhonen
Cc: Ben Campbell; dime@ietf.org list
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comment=
s to 4.3

Nirav,

See inline.

Steve
On 12/12/13 6:40 AM, Nirav Salot (nsalot) wrote:

All,



I do not understand this discussion regarding different agents of the same =
realm having different view of the realm and provide different overload rep=
ort.
We can make the statement that all senders of realm reports should send the=
 same report.  This does not guarantee that it will always happen.  If agen=
ts are sending the report, they are generally distributed elements.  In ver=
y large networks, this distribution can span continents.  There will be a l=
ag in the "synchronization" of the realm overload information.

My concern is that we have well defined behavior for when a reactor receive=
s conflicting realm reports.  We need to avoid thrashing between different =
reduction levels, which could make the overload situation worse.






Additionally, I also do not understand the proposal of adding identity of t=
he agent generating "realm report" into the report.
Adding the endpoint identity is needed to allow the reacting node to know t=
hat it is receiving two different views of Realm overload from two differen=
t reporting end-points.






What is the use of this identity at the reacting node when the report is re=
alm report? Why should the reacting node care who generated the realm repor=
t?
One proposal for how we deal with the fact that different reports can have =
different values is to have the reacting node treat the first reporting nod=
e as the authority for reporting realm overload state for that overload ins=
tance.  In this case, the reacting node would ignore reports received from =
other reporting nodes. In order to ignore reports from non authoritative en=
dpoints requires the reacting node to know which endpoints send which repor=
ts.








Regards,

Nirav.



-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen

Sent: Thursday, December 12, 2013 5:06 PM

To: Steve Donovan

Cc: Ben Campbell; dime@ietf.org list

Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comment=
s to 4.3



Steve,



On Dec 11, 2013, at 3:13 PM, Steve Donovan  wrote:



Jouni,



We need the sequence number to be strictly increasing.  I don't see the nee=
d for it to increase in uniform amounts.  Using time does fit these require=
ments.  I'm ok with using time as long as we don't call the AVP timestamp.



Ulrich does bring up an interesting use case, where a client is receiving r=
ealm reports for the same realm from different agents.  We need to define t=
he clients behavior in this case.



Any suggestions? I mean agents may have hugely different view of the realm =
if they are acting on their own.



Presumably the client needs to be able to determine who generated the realm=
 report.  This cannot be determine based on the content of the message or t=
he connection on which the message arrived.  It seems like we might need "R=
eport Generator Diameter ID" in the overload report specifically for Realm =
reports.



Once the client is able to differentiate between realm reports sent by diff=
erent agents (or servers) we need logic defining how the client deals with =
a new overload report.



I need now to check one of the basic assumptions on DOIC now so that we hav=
e the same understanding. I went back to the endpoint text in Section 5.1. =
There, for example in Figures

4 and 5 the DOIC association and the endpoint assumption does does not work=
 IMHO because we have no endpoint identity in the OLR. In order the endpoin=
t assumption to work (as I drew it on the white board in Porto), it would r=
equire as many Diameter level sessions as there are DOIC associations.



So.. has assumptions shifted in a meanwhile and I have just not paid attent=
ion?



I see a couple of options (others will probably see options I am missing):



- Use the last received realm report - This introduces the possibility of t=
hrashing between two different reduction values and different durations.  N=
ote that this approach does not require the source of the report to be incl=
uded in the report.



- Only listen to one source of realm overload - The approach would be to re=
member who sent the first overload report from the realm and ignore realm o=
verload reports from other sources.  This behavior would likely be constrai=
ned to a single occurrence of realm overload.  Meaning that the "memory" of=
 the report source would only last as long as that overload event persists.=
  Once the overload event goes away, the report source would be forgotten a=
nd a new source could be used for the next occurrence.



On the surface, the second approach looks better to me.



Or add the identity of the OLR originator explicitly if it cannot be determ=
ined implicitly (i.e. from the Diameter message's Origin-Host/Realm).



Or assume the endpoint really is the endpoint in DOIC and Diameter session =
sense.



- Jouni





Steve



On 12/11/13 2:15 AM, Jouni wrote:

Ulrich,



I might be slow but.. Section 4.4 says



   control endpoints.  The sequence number is only required to be unique

   between two overload control endpoints and does not need to be



Unique between two endpoints..



Section 5.1 talks about endpoints:



   of an arbitrary Diameter network.  The overload control information

   is exchanged over on a "DOIC association" between two communication

   endpoints.  The endpoints, namely the "reacting node" and the

   "reporting node" do not need to be adjacent Diameter peer nodes,

nor



So if your agents inject realm reports, they need to be endpoints to

the client. Similar to Figure 5. Therefore the sequence number spaces

between

C-A1 and C-A2 are separate.



Now it is not clear to me, whether in your reasoning the C would see

the server identity (as the endpoint) when there is an active "DEP

agent" on the path. That would not clearly work and not be align with

the endpoint assumption.



Note that at some point of time we had (at least on a discussion

level in f2f meeting) report originator identity in the OLR. That

would make endpoint identification trivial. Now a "DEP agent" needs

to act as a "server" for its clients in order to appear as an endpoint.



- Jouni



ps: still think the use of Time is simpler..





On Dec 11, 2013, at 9:43 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:





That's not predictable. It may be the same server in some cases, and differ=
ent servers in other cases.



-----Original Message-----

From: ext Jouni [

mailto:jouni.nospam@gmail.com

]

Sent: Wednesday, December 11, 2013 8:38 AM

To: Wiehe, Ulrich (NSN - DE/Munich)

Cc: Ben Campbell;

dime@ietf.org

 list; Steve Donovan

Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI:

comments to 4.3





Ulrich,



On Dec 11, 2013, at 9:21 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:





Jouni,



ad 1. "monotonically" does not express your intention. What we are looking =
for may be "stepwise with fixed step".



Ad 2. Is not necessarily a mistake that could result in out-of-sequence seq=
uence numbers. When a client C sends a realm-type requests towards any serv=
er in the realm, an agent A1 that selects the server would send back the re=
alm-type OLR with sequence number s1. The next realm-type request sent by C=
 (that survived the throttling) may take a path that does not include A1 bu=
t A2. A2 then selects the server and sends back a sequence number s2. Nothi=
ng ensures that s1 and s2 are in sequence.



Would the server in both cases (via A1 and A2) be the same?



- Jouni







Ulrich





-----Original Message-----

From: ext Jouni Korhonen [

mailto:jouni.nospam@gmail.com

]

Sent: Tuesday, December 10, 2013 10:31 PM

To: Wiehe, Ulrich (NSN - DE/Munich)

Cc: Ben Campbell;

dime@ietf.org

 list; Steve Donovan

Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI:

comments to 4.3



Ulrich,



On Dec 10, 2013, at 4:31 PM, "Wiehe, Ulrich (NSN - DE/Munich)"



 wrote:





Jouni,



1. I find the texts

a) "The sequence number ... does not need to be monotonically increasing"

and



Means the delta from old-seqno to new-seqno can be any non-negative

integer (within the given limits) not something fixed step/delta

(like +1). As long as "new-seqno >=3D old-seqno" holds we are fine.





b) "...the new sequence number MUST be greater or equal than the old sequen=
ce number..."

contradicting.

Can you please clarify.



See above. (mind the overflow case)





2. The expected behaviour when receiving an out-of-sequence sequence number=
 within OC-OLR is described in 4.3:

"The receiver SHOULD discard an OC-OLR AVP with a sequence number that is l=
ess than previously received one."

I don't find this very robust. Once a higher sequence number (received erro=
neously by mistake) is accepted you cannot (easily) recover.



I find it more robust in a sense that I should not care about stale old inf=
ormation.

However, since we are piggybacking (by popular demand) we have

little room for seqno re-sync negotiation.



What is the mistake you refer here? A misbehaving implementation?

In that case, it deserves to get a manual intervention once figured

out by admins checking alarms and logs. If the mistake is due other

things, like endpoints being out of sync, we currently have no written down=
 mechanism to survive that.





3. The expected behaviour when receiving an out-of-sequence sequence number=
 within the OC-Supported-Features AVP is not described. What is the intenti=
on here?



No intention. Just a sloppy specification. You are right that

something needs to be done & clarified here. (again the semantics

of Time would nice..)



I'll propose something. Others should too ;)



- Jouni





Ulrich



-----Original Message-----

From: DiME [

mailto:dime-bounces@ietf.org

] On Behalf Of ext Jouni Korhonen

Sent: Tuesday, December 10, 2013 8:28 AM

To: Ben Campbell;

dime@ietf.org

 list; Steve Donovan

Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re:

OVLI: comments to 4.3





Fine.. lets define then the sequence number semantics. Basic

unsigned integer math. The text proposal is the following:



4.4.  OC-Sequence-Number AVP



The OC-Sequence-Number AVP (AVP code TBD3) is type of Unsigned64.

Its usage in the context of the overload control is described in

Sections 4.1 and 4.3.



>From the functionality point of view, the OC-Sequence-Number AVP

MUST be used as a non-volatile increasing counter between two

overload control endpoints.  The sequence number is only required

to be unique between two overload control endpoints and does not

need to be monotonically increasing.



When comparing two sequence numbers, the new sequence number MUST

be greater or equal than the old sequence number within a window

that is half of the size of the maximum sequence number. This

allows a simple handling of the sequence number overflow using

unsigned integer arithmeticf:



  #define WINDOW 0x8000000000000000ULL



  bool verify_seqnum( uint64_t newsn, uint64_t oldsn ) {

      if (newsn - oldsn <=3D WINDOW)

          // newsn >=3D oldsn

          return true;

      } else

          // outside window or newsn < oldsn

          return false;

      }

  }







The above should even work is someone shovels NTP times into

sequence numbers with a blind typecasting.



- Jouni



On Dec 10, 2013, at 12:34 AM, Ben Campbell 

 wrote:





On Dec 9, 2013, at 10:00 AM, Steve Donovan 

 wrote:





Jouni,



I propose that we keep the name OC-Sequence-Number but that we use the Time=
 type for OC-Sequence-Number.  It is misleading and potentially confusing t=
o call it OC-Time-Stamp.





I could live with that, although I would rather just define the expected pr=
operties of the sequence number, and leave the implementation up to the imp=
lementor. I assume your reasoning for not calling it a timestamp is that yo=
u do not want people to try to use it as a time base reference. If so, then=
 we don't require any connection to a clock. We just need it to be monotoni=
cally increasing.





We might consider expanding on the format of the AVP to make it something l=
ike Session-ID, where it is a concatenation of the Diameter-ID of the gener=
ating node and a timestamp.  This might help the reacting node keep track o=
f which sequence number it has received.





Do we need a uniqueness across multiple nodes property? If so, why?





Steve



On 12/9/13 5:37 AM, Jouni Korhonen wrote:



Folks



Could we conclude on the sequence number vs. time stamp vs. something else?

We got more important places to spend our energy than this ;)



My proposal is the following (based on the original pre-00 design):



o We change the OC-Sequence-Number to OC-Time-Stamp in all occurrences

in the -01.

o We use RFC6733 Time type for the OC-Time-Stamp. RFC6733 gives us

already exact definition how to handle the AVP.

o Define that the OC-Time-Stamp is the time of the creation of the

"original" AVP within whose context the time stamp is present.

o The OC-Time-Stamp AVP uniqueness is still considered to be in scope

of the communicating endpoints.

o The time stamp can be used to quickly determine if the content of

the encapsulating AVP context has changed (among other properties).

This would be useful specifically in the future when the encapsulating

grouped AVPs  grow in size and functionality.





- Jouni



_______________________________________________

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







_______________________________________________

DiME mailing list

DiME@ietf.org

https://www.ietf.org/mailman/listinfo/dime






--_000_A9CA33BB78081F478946E4F34BF9AAA014D33D5Bxmbrcdx10ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Steve,<=
/p>

 <=
/p>

You are talking about &qu=
ot;what if one of the agents in the realm has very skewed view of the state=
 of the realm – for whatever reason".


I guess this is much bigg=
er issue and will lead to bigger problems, e.g. all the clients connected t=
o this agent and not sending any request via other agents
 of the realm, will always have skewed view of the realm.=



So that problem should be=
 solved, first. (of course, not here, not by us).


 <=
/p>

In general, for realm rep=
ort to be usable, we need to assume that agents are synchronized (except fo=
r a very small window of time) and have consistent view
 (if not exactly the same view always) of the same realm.=



Otherwise, realm report w=
ill itself create issues among different clients and hence should be avoide=
d completely.



 <=
/p>

Regards,


Nirav.<=
/p>

 <=
/p>





From: Steve Donovan [mailto:srdonovan@usdonovans.com]


Sent: Monday, December 16, 2013 9:39 PM

To: Nirav Salot (nsalot); Jouni Korhonen

Cc: Ben Campbell; dime@ietf.org list

Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: =
comments to 4.3






 


Nirav,



Assume that there are multiple agents reporting on realm overload.  Th=
e method these agents use to determine realm overload is an implementation =
decision, but will require some form of exchange of state between the agent=
s to keep them in sync.  Note that we
 can't assume that all agents are getting all host overload reports.



Under normal circumstances, the difference between the overload reports fro=
m these agents should be small, as you assert. 




But consider the case where the replication mechanism between the agents is=
 either congested or the network used by the agents to exchange state is no=
 longer available.  It is easy to construct scenarios in this situatio=
n where agents could be reporting widely
 different realm overload report values.



This is clearly an unlikely event, but it is one that can easily be prevent=
ed by including the id of the node that sends a report as part of the repor=
t.



Regards,



Steve




On 12/16/13 9:42 AM, Nirav Salot (nsalot) wrote:






Steve,<=
/p>

 <=
/p>

> The issue wit=
h considering only the last report is that it introduces the potential for =
thrashing between different values.  This could make the overload
 event even worse.


I am not sure about this.=
 The two agents are not synchronized only for a very small window of time. =
But even then their reports should be reflecting the status
 of the realm, approximately if not accurately.


So I don’t think us=
ing one of the reports will make the situation worse.



 <=
/p>

I did not understand your=
 argument regarding the security.


The client does not know =
the agent's identity anyway. So adding agent's identity in the overload-rep=
ort is not going to change the security consideration anyway.


 <=
/p>

Regards,


Nirav.<=
/p>

 <=
/p>





From: Steve Donovan [mailto:srdonovan@usdonovans.com]


Sent: Monday, December 16, 2013 5:47 PM

To: Nirav Salot (nsalot); Jouni Korhonen

Cc: Ben Campbell; dime@ietf.org=
 list

Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: =
comments to 4.3






 


Nirav,



The issue with considering only the last report is that it introduces the p=
otential for thrashing between different values.  This could make the =
overload event even worse.



I agree that this should be a rare case.  I still think, however, that=
 we need to have defined behavior.



One other argument for including the sender of the overload report in the r=
eport itself is security.  The ability of a bad actor to insert a mali=
cious overload report can be a very effective DOS attack.  I know we h=
ave said we aren't addressing security yet
 but this seems pretty short sighted.  Being able to establish that th=
e identity of the sender of an overload report will be an important part of=
 the security solution.  We should take this step in that direction.


Steve




On 12/12/13 10:26 AM, Nirav Salot (nsalot) wrote:






Steve,<=
/p>

 <=
/p>

So as I understand it is =
not a common case for different agent to provide different view of the same=
 realm and this may have happen during a small window when
 synchronization has not taken place between the geographically distributed=
 agents.


Right?<=
/p>

 <=
/p>

If so, I can understand t=
he following part of your proposal.


One proposal for how we deal with the fact that diff=
erent reports can have different values is to have the reacting node treat =
the first reporting node as the authority for reporting realm overload stat=
e for that overload instance.


 <=
/p>

i.e. I can understand to =
define some behavior for the reacting node to handle the case (which is any=
way rare case) when two agents provide different realm-report
 for the same report.


The behavior could be sim=
ply to consider only the last report when two agents have sent two differen=
t reports of the same realm. (And this will also work when
 the same agent has sent two different realm-reports, purposefully – =
e.g. due to the change in the realm overload).


But this still does not r=
equire adding of agent's identity in the overload-report.=



 <=
/p>

Regards,


Nirav.<=
/p>

 <=
/p>





From: Steve Donovan [mailto:srdonovan@usdonovans.com]


Sent: Thursday, December 12, 2013 7:50 PM

To: Nirav Salot (nsalot); Jouni Korhonen

Cc: Ben Campbell; dime@ietf.org=
 list

Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: =
comments to 4.3






 


Nirav,



See inline.



Steve




On 12/12/13 6:40 AM, Nirav Salot (nsalot) wrote:






All,


 


I do not understand this discussion regarding different agents of the =
same realm having different view of the realm and provide different overloa=
d report.




We can make the statement that all senders of realm =
reports should send the same report.  This does not guarantee that it =
will always happen.  If agents are sending the report, they are genera=
lly distributed elements.  In very large networks,
 this distribution can span continents.  There will be a lag in the &q=
uot;synchronization" of the realm overload information.



My concern is that we have well defined behavior for when a reactor receive=
s conflicting realm reports.  We need to avoid thrashing between diffe=
rent reduction levels, which could make the overload situation worse.










 


Additionally, I also do not understand the proposal of adding identity=
 of the agent generating "realm report" into the report.


Adding the endpoint identity is needed to allow the =
reacting node to know that it is receiving two different views of Realm ove=
rload from two different reporting end-points.










 


What is the use of this identity at the reacting node when the report =
is realm report? Why should the reacting node care who generated the realm =
report?


One proposal for how we deal with the fact that diff=
erent reports can have different values is to have the reacting node treat =
the first reporting node as the authority for reporting realm overload stat=
e for that overload instance.  In
 this case, the reacting node would ignore reports received from other repo=
rting nodes. In order to ignore reports from non authoritative endpoints re=
quires the reacting node to know which endpoints send which reports.










 


 


Regards,


Nirav.


 


-----Original Message-----


From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of Jouni Korhonen


Sent: Thursday, December 12, 2013 5:06 PM


To: Steve Donovan


Cc: Ben Campbell; dime@ietf.org l=
ist


Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: co=
mments to 4.3


 


Steve,


 


On Dec 11, 2013, at 3:13 PM, Steve Donovan <srdonovan@usdonovans.com> wrote:

 




Jouni,


 


We need the sequence number to be strictly increasing.  I don't s=
ee the need for it to increase in uniform amounts.  Using time does fi=
t these requirements.  I'm ok with using time as long as we don't call=
 the AVP timestamp.


 


Ulrich does bring up an interesting use case, where a client is receiv=
ing realm reports for the same realm from different agents.  We need t=
o define the clients behavior in this case.  




 


Any suggestions? I mean agents may have hugely different view of the r=
ealm if they are acting on their own.


 




Presumably the client needs to be able to determine who generated the =
realm report.  This cannot be determine based on the content of the me=
ssage or the connection on which the message arrived.  It seems like w=
e might need "Report Generator Diameter ID" in the overload repor=
t specifically for Realm reports.  


 


Once the client is able to differentiate between realm reports sent by=
 different agents (or servers) we need logic defining how the client deals =
with a new overload report.  




 


I need now to check one of the basic assumptions on DOIC now so that w=
e have the same understanding. I went back to the endpoint text in Section =
5.1. There, for example in Figures


4 and 5 the DOIC association and the endpoint assumption does does not=
 work IMHO because we have no endpoint identity in the OLR. In order the en=
dpoint assumption to work (as I drew it on the white board in Porto), it wo=
uld require as many Diameter level sessions as there are DOIC associations.=



 


So.. has assumptions shifted in a meanwhile and I have just not paid a=
ttention?


 




I see a couple of options (others will probably see options I am missi=
ng):


 


- Use the last received realm report - This introduces the possibility=
 of thrashing between two different reduction values and different duration=
s.  Note that this approach does not require the source of the report =
to be included in the report.


 


- Only listen to one source of realm overload - The approach would be =
to remember who sent the first overload report from the realm and ignore re=
alm overload reports from other sources.  This behavior would likely b=
e constrained to a single occurrence of realm overload.  Meaning that =
the "memory" of the report source would only last as long as that=
 overload event persists.  Once the overload event goes away, the repo=
rt source would be forgotten and a new source could be used for the next oc=
currence.


 


On the surface, the second approach looks better to me.



 


Or add the identity of the OLR originator explicitly if it cannot be d=
etermined implicitly (i.e. from the Diameter message's Origin-Host/Realm).<=
o:p>


 


Or assume the endpoint really is the endpoint in DOIC and Diameter ses=
sion sense.


 


- Jouni


 




 


Steve


 


On 12/11/13 2:15 AM, Jouni wrote:




Ulrich,


 


I might be slow but.. Section 4.4 says


 


   control endpoints.  The sequence number is only requ=
ired to be unique


   between two overload control endpoints and does not need =
to be


 


Unique between two endpoints..


 


Section 5.1 talks about endpoints:


 


   of an arbitrary Diameter network.  The overload cont=
rol information


   is exchanged over on a "DOIC association" betwe=
en two communication


   endpoints.  The endpoints, namely the "reacting=
 node" and the


   "reporting node" do not need to be adjacent Dia=
meter peer nodes, 


nor


 


So if your agents inject realm reports, they need to be endpoints to <=
o:p>


the client. Similar to Figure 5. Therefore the sequence number spaces =



between


C-A1 and C-A2 are separate.


 


Now it is not clear to me, whether in your reasoning the C would see <=
o:p>


the server identity (as the endpoint) when there is an active "DE=
P 


agent" on the path. That would not clearly work and not be align =
with 


the endpoint assumption.


 


Note that at some point of time we had (at least on a discussion =



level in f2f meeting) report originator identity in the OLR. That 


would make endpoint identification trivial. Now a "DEP agent"=
; needs 


to act as a "server" for its clients in order to appear as a=
n endpoint.


 


- Jouni


 


ps: still think the use of Time is simpler..


 


 


On Dec 11, 2013, at 9:43 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:


 


 




That's not predictable. It may be the same server in some cases, and d=
ifferent servers in other cases.


 


-----Original Message-----


From: ext Jouni [


mailto:jouni.nospam@gmail.co=
m


]


Sent: Wednesday, December 11, 2013 8:38 AM


To: Wiehe, Ulrich (NSN - DE/Munich)


Cc: Ben Campbell;


dime@ietf.org


 list; Steve Donovan


Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: 


comments to 4.3


 


 


Ulrich,


 


On Dec 11, 2013, at 9:21 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:


 


 




Jouni,


 


ad 1. "monotonically" does not express your intention. What =
we are looking for may be "stepwise with fixed step".<=
/pre>

 


Ad 2. Is not necessarily a mistake that could result in out-of-sequenc=
e sequence numbers. When a client C sends a realm-type requests towards any=
 server in the realm, an agent A1 that selects the server would send back t=
he realm-type OLR with sequence number s1. The next realm-type request sent=
 by C (that survived the throttling) may take a path that does not include =
A1 but A2. A2 then selects the server and sends back a sequence number s2. =
Nothing ensures that s1 and s2 are in sequence.


 




Would the server in both cases (via A1 and A2) be the same?=



 


- Jouni


 


 


 




Ulrich


 


 


-----Original Message-----


From: ext Jouni Korhonen [


mailto:jouni.nospam@gmail.co=
m


]


Sent: Tuesday, December 10, 2013 10:31 PM


To: Wiehe, Ulrich (NSN - DE/Munich)


Cc: Ben Campbell;


dime@ietf.org


 list; Steve Donovan


Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: 


comments to 4.3


 


Ulrich,


 


On Dec 10, 2013, at 4:31 PM, "Wiehe, Ulrich (NSN - DE/Munich)&quo=
t; 


<ulrich.wiehe@nsn.com>


 wrote:


 


 




Jouni,


 


1. I find the texts


a) "The sequence number ... does not need to be monotonically inc=
reasing"


and


 




Means the delta from old-seqno to new-seqno can be any non-negative 


integer (within the given limits) not something fixed step/delta =



(like +1). As long as "new-seqno >=3D old-seqno" hold=
s we are fine.


 


 




b) "...the new sequence number MUST be greater or equal than the =
old sequence number..."


contradicting.


Can you please clarify.


 




See above. (mind the overflow case)


 


 




2. The expected behaviour when receiving an out-of-sequence sequence n=
umber within OC-OLR is described in 4.3:


"The receiver SHOULD discard an OC-OLR AVP with a sequence number=
 that is less than previously received one."


I don't find this very robust. Once a higher sequence number (received=
 erroneously by mistake) is accepted you cannot (easily) recover.


 




I find it more robust in a sense that I should not care about stale ol=
d information.


However, since we are piggybacking (by popular demand) we have 


little room for seqno re-sync negotiation.


 


What is the mistake you refer here? A misbehaving implementation? 


In that case, it deserves to get a manual intervention once figured 


out by admins checking alarms and logs. If the mistake is due other 


things, like endpoints being out of sync, we currently have no written=
 down mechanism to survive that.


 


 




3. The expected behaviour when receiving an out-of-sequence sequence n=
umber within the OC-Supported-Features AVP is not described. What is the in=
tention here?


 




No intention. Just a sloppy specification. You are right that 


something needs to be done & clarified here. (again the semantics =



of Time would nice..)


 


I'll propose something. Others should too ;)


 


- Jouni


 


 




Ulrich


 


-----Original Message-----


From: DiME [


mailto:dime-bounces@ietf.org<=
/a>


] On Behalf Of ext Jouni Korhonen


Sent: Tuesday, December 10, 2013 8:28 AM


To: Ben Campbell;


dime@ietf.org


 list; Steve Donovan


Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: 


OVLI: comments to 4.3


 


 


Fine.. lets define then the sequence number semantics. Basic 


unsigned integer math. The text proposal is the following:<=
/pre>

 


4.4.  OC-Sequence-Number AVP


 


The OC-Sequence-Number AVP (AVP code TBD3) is type of Unsigned64.=



Its usage in the context of the overload control is described in =



Sections 4.1 and 4.3.


 


From the functionality point of view, the OC-Sequence-Number AVP =



MUST be used as a non-volatile increasing counter between two 


overload control endpoints.  The sequence number is only required=
 


to be unique between two overload control endpoints and does not =



need to be monotonically increasing.


 


When comparing two sequence numbers, the new sequence number MUST 


be greater or equal than the old sequence number within a window =



that is half of the size of the maximum sequence number. This 


allows a simple handling of the sequence number overflow using 


unsigned integer arithmeticf:


 


  #define WINDOW 0x8000000000000000ULL


 


  bool verify_seqnum( uint64_t newsn, uint64_t oldsn ) {


      if (newsn - oldsn <=3D WINDOW)<=
/o:p>


          // newsn >=
=3D oldsn


          return true;&nb=
sp;  


      } else


          // outside wind=
ow or newsn < oldsn


          return false;&n=
bsp; 


      }


  }


 


 


 


The above should even work is someone shovels NTP times into 


sequence numbers with a blind typecasting.


 


- Jouni


 


On Dec 10, 2013, at 12:34 AM, Ben Campbell <ben@nostrum.com>


 wrote:


 


 




On Dec 9, 2013, at 10:00 AM, Steve Donovan <srdonovan@usdonovans.com>


 wrote:


 


 




Jouni,


 


I propose that we keep the name OC-Sequence-Number but that we use the=
 Time type for OC-Sequence-Number.  It is misleading and potentially c=
onfusing to call it OC-Time-Stamp.  


 


 




I could live with that, although I would rather just define the expect=
ed properties of the sequence number, and leave the implementation up to th=
e implementor. I assume your reasoning for not calling it a timestamp is th=
at you do not want people to try to use it as a time base reference. If so,=
 then we don't require any connection to a clock. We just need it to be mon=
otonically increasing.


 


 




We might consider expanding on the format of the AVP to make it someth=
ing like Session-ID, where it is a concatenation of the Diameter-ID of the =
generating node and a timestamp.  This might help the reacting node ke=
ep track of which sequence number it has received.


 


 




Do we need a uniqueness across multiple nodes property? If so, why?


 


 




Steve


 


On 12/9/13 5:37 AM, Jouni Korhonen wrote:


 




Folks


 


Could we conclude on the sequence number vs. time stamp vs. something =
else?


We got more important places to spend our energy than this ;)


 


My proposal is the following (based on the original pre-00 design):


 


o We change the OC-Sequence-Number to OC-Time-Stamp in all occurrences=



in the -01.


o We use RFC6733 Time type for the OC-Time-Stamp. RFC6733 gives us


already exact definition how to handle the AVP.


o Define that the OC-Time-Stamp is the time of the creation of the 


"original" AVP within whose context the time stamp is presen=
t.


o The OC-Time-Stamp AVP uniqueness is still considered to be in scope<=
o:p>


of the communicating endpoints.


o The time stamp can be used to quickly determine if the content of


the encapsulating AVP context has changed (among other properties).


This would be useful specifically in the future when the encapsulating=



grouped AVPs  grow in size and functionality.


 


 


- Jouni


 


_______________________________________________


DiME mailing list


 


 


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 


 


 


 


 




_______________________________________________


DiME mailing list


 


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime




_______________________________________________


DiME mailing list


 


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime




_______________________________________________


DiME mailing list


 


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime








 




 




 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 


 




 




 






--_000_A9CA33BB78081F478946E4F34BF9AAA014D33D5Bxmbrcdx10ciscoc_--

From nsalot@cisco.com  Mon Dec 16 08:32:14 2013
Return-Path: 
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 F02DB1ADF83 for ; Mon, 16 Dec 2013 08:32:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.038
X-Spam-Level: 
X-Spam-Status: No, score=-15.038 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.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 p3GtKT_1uIlg for ; Mon, 16 Dec 2013 08:32:05 -0800 (PST)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 2DCB41ADF50 for ; Mon, 16 Dec 2013 08:32:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=66679; q=dns/txt; s=iport; t=1387211525; x=1388421125; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=WeJmj/dxC8dSPMJT2PvH5uUI+FjeJlA2qiBTTgWiChs=; b=TQLoYdzkdg+iVp+3BAzjDIb+CidFGS22lBg4uWcfQ0zcnz7Kyuk6JpOz 1aipknIR5lmwg/Xv6uQedvwQXk+/qkr2r43KTcOfAiD/AS/jIFfhwIBpp NOzdW9c8q/qEqUXSLzfXpWydWBYaTI6fmocaxE25rJ9Yk0m1tn/I7sWbc M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ak8FAMYpr1KtJXHB/2dsb2JhbABZgkZEOFW4coElFnSCJQEBAQQBAQEXEz8CCBMCAQgOAwEDAQELFgEGByEGCxQDBggCBAESCBIBBIdRAxENwQsNhwETBI0GgTAyLQoBBoMdgRMEiQuLKIF4jkWFOoMqgio
X-IronPort-AV: E=Sophos;i="4.95,495,1384300800";  d="scan'208,217";a="291868257"
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-3.cisco.com with ESMTP; 16 Dec 2013 16:32:02 +0000
Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id rBGGW2Df001514 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 16 Dec 2013 16:32:02 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.227]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Mon, 16 Dec 2013 10:32:01 -0600
From: "Nirav Salot (nsalot)" 
To: Steve Donovan , "dime@ietf.org" 
Thread-Topic: [Dime] DOIC: Self-Contained OLRs
Thread-Index: AQHO67/s/vGpiVuf2UayvwQoJbzwfZo5m/0AgACzUoCAAAFygIAAE14AgAF8EACAACKcAIAANGaAgATJUgCAAAuAAIACAWkAgAAGHYCAAXsigIAALuKAgAAb/4CAAHc6gIAAOZAAgAAO+4CAAAVNAIAABNCAgAAF6QCAAAecAIAF/9gAgAAFIoCAANV2gIAARHaAgAHlZ9CAAEm9gIAAWSGggAACrFCAAAAqoIAAeyEAgADOAYCAAGoDgP//yK3wgAZ6WoD//8JwoIAAbJwA//+fpjA=
Date: Mon, 16 Dec 2013 16:32:00 +0000
Message-ID: 
References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <13081_1386256433_52A09831_13081_8197_1_6B7134B31289DC4FAF! 731D84412 2B36E32B6EB@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B9209739738@ESESSMB101.ericsson.se>  <8FD63E2D-5203-4DA4-A6DA-C4CA181C9CFB@nostrum.com> <26C84DFD55BC3040A45BF70926E55F2587C1D786@SZXEMA512-MBX.china.huawei.com>  <52A86663.30500@usdonovans.com>  <087A34937E64E74E848732CFF8354B920973A82A@ESESSMB101.ericsson.se> <52A8B862.5040207@usdonovans.com> <087A34937E64E74E848732CFF8354B920973AAF5@ESESSMB101.ericsson.se> <52A9BE1F.7020201@usdonovans.com>  <52AEFED7.5060908@usdonovans.com>  <52AF264E.9070304@usdonovans.com>
In-Reply-To: <52AF264E.9070304@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.65.72.21]
Content-Type: multipart/alternative; boundary="_000_A9CA33BB78081F478946E4F34BF9AAA014D33D9Axmbrcdx10ciscoc_"
MIME-Version: 1.0
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Dec 2013 16:32:14 -0000

--_000_A9CA33BB78081F478946E4F34BF9AAA014D33D9Axmbrcdx10ciscoc_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Steve,

In that case, I do not see any use of "self-contained OLR".
e.g. the server sends application-Y's report in application-X's message. Th=
e client may ignore the application-Y's report and hence the server has to =
ensure to send application-Y's report in application-Y's message as well.
So what is the gain here?

I do not understand the need to define such a mechanism.

Regards,
Nirav.

From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Monday, December 16, 2013 9:42 PM
To: Nirav Salot (nsalot); dime@ietf.org
Subject: Re: [Dime] DOIC: Self-Contained OLRs

Nirav,

There is nothing in the self-contained overload report proposal the require=
s cross-application data handling.  An implementation can take advantage of=
 cross-application information if it is able and wants to, but it is not re=
quired to do so.

Regards,

Steve
On 12/16/13 9:50 AM, Nirav Salot (nsalot) wrote:
Steve,

SRD> I don't understand what is meant by "requires architectural support". =
 Is this a way of saying it is more difficult to implement?
As of today, the Diameter message can only contain data specific to one app=
lication and based on this, the nodes are designed to handle data/AVP speci=
fic to one application.
Thus, cross-application data handling (that you are proposing via "self-con=
tained OLR") is not required to be supported in today's design/architecture=
 of the Diameter node supporting a set of applications.

Regards,
Nirav.

From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Monday, December 16, 2013 6:54 PM
To: Nirav Salot (nsalot); dime@ietf.org
Subject: Re: [Dime] DOIC: Self-Contained OLRs

Nirav,

See my response inline.

Regards,

Steve
On 12/12/13 10:36 AM, Nirav Salot (nsalot) wrote:
Steve,

Why do you always talk about "the application which the Diameter node does =
not understand?"
What if the reacting node supports two applications and in the message for =
application-X it receives the overload-report for application-Y?
Do you propose to ignore this report as well?
SRD> The logic behind self contained reports would be that the reactor  use=
 the reports that it makes sense for the reactor to use.  I think your ques=
tion is what should a reactor do if it supports application-X and applicati=
on-Y, sends a request for application-X and receives a reply with an overlo=
ad report for application-Y in the answer to that request. The behavior I w=
ould suggest is that the reactor should (not must) honor the overload repor=
t for requests sent to application-Y.  If this is particularly difficult fo=
r the reactor to achieve then it can wait to receive an overload for applic=
ation-Y in answers to requests sent on application-Y.



As already indicated earlier, by many of us, handling of application-Y's da=
ta in the application-X's message is not how the Diameter applications are =
designed today. And hence this type of proposal requires architectural supp=
ort for handling it. And there lies the complexity.
SRD> I don't understand what is meant by "requires architectural support". =
 Is this a way of saying it is more difficult to implement?


This main drawback was highlighted earlier as well but was conveniently ign=
ored while preparing the pros and cons list for the self-contained OLR.
SRD> Then suggest it be added to the pros and cons list.  But first explain=
 the concept of "requires architectural support".



Regards,
Nirav.

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: Thursday, December 12, 2013 7:16 PM
To: dime@ietf.org
Subject: Re: [Dime] DOIC: Self-Contained OLRs

Maria Cruz,

Can you explain the complexity behind the cross-application procedure.  The=
 work required is to ignore any application that the Diameter node does not=
 understand.  I don't see this as very complex.

Steve
On 12/12/13 1:26 AM, Maria Cruz Bartolome wrote:
Yes, I agree consistency is not any longer a problem, since now your intent=
ion is that _any_ (and multiple) application data could be conveyed within =
the same message.
But as mentioned a few times, I consider this not necessary since OLR is se=
nt in every answer.
A part from that, as mentioned by Lionel, this implies a cross-application =
procedure at both endpoints, that increases complexity and it is not requir=
ed for our work (RFC7068)

Cheers
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: mi=E9rcoles, 11 de diciembre de 2013 20:09
To: dime@ietf.org
Subject: Re: [Dime] DOIC: Self-Contained OLRs

Maria Cruz,

I don't agree with the assertion that self-contained OLRs results in the po=
tential for data inconsistency.  If a reactor receives an overload report f=
or an application that is not supported by the reactor then the reactor can=
 and should ignore that OLR.

The concept of self-contained overload reports would explicitly allow for t=
he contents of the overload report to be different than the message that is=
 carrying the OLR.  As with application-ids, if the reactor doesn't send me=
ssages to a reported host or realm then the reactor ignores that part of th=
e overload report.  As such, there is no need to check the implicit data wh=
en receiving a self-contained OLR.

Steve
On 12/11/13 12:25 PM, Maria Cruz Bartolome wrote:

Hello (and something else now :), fast key combination, I won't be able to =
repeat,  was the responsible)



As mentioned before, something else on cons side for self-contained:



A part from that,  one concern with "self-contained OLRs" is that some data=
 is duplicated. Duplication should be avoided, since then we need to assure=
 consistency, and error handing in case implicit and explicit data values a=
re different for any reason... what means that it may always be required to=
 check both implicit and explicit data.



Also, I think this is a pure implementation proposal. Regardless how the da=
ta is transported it could be packed in a "self-contained OLRs" within the =
diameter application, if for any implementation this is preferred.

Best regards
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE=
S (JEAN-JACQUES)
Sent: mi=E9rcoles, 11 de diciembre de 2013 19:02
To: dime@ietf.org
Subject: Re: [Dime] DOIC: Self-Contained OLRs

Hi Steve

I am sorry, Steve,  I do not see the difference between the Draft Roach sco=
pe approach and the self contained OLRs.

With the scope approach in Draft Roach : there is an overload metric AVP  (=
eg containing a % of traffic reduction) coupled with one or several Overlao=
d-Infoscope AVPs, an overlaod infoscope identifying an application or a des=
tination host or... . These Overlaod-Infoscope AVPs can be combined  with a=
lso  the possibility of  multi instances to have a list of applications, a =
list of destination hosts etc  to which the overload metric would apply.

With self contained OLR as you have described them, un OLR will also contai=
n an OC-Reduction-Percentage  AVP coupled with one or several others AVPs (=
the self containment approach) to indicate which application(s), destinatio=
ns host (s) etc the   OC-Reduction-Percentage  AVP applies.

Where is the difference?

So the drawbacks identified for the scope approach also apply with the self=
 contained approach

Best regards

JJacques



De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9 : mercredi 11 d=E9cembre 2013 14:20
=C0 : dime@ietf.org
Objet : Re: [Dime] DOIC: Self-Contained OLRs

JJacques,

While the self contained overload report concept may be similar to the scop=
es concept in the Roach draft, they are not the same.  As such, I don't agr=
ee with your assertion that the previous rejection of the Roach draft requi=
res us to reject self contained overload reports as currently being discuss=
ed.

Steve
On 12/11/13 2:27 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:
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 multip=
ly the number of AVPs in the OLRs (AVPs identifying Application, destinatio=
n 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 sel=
f 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 rec=
reate  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 si=
mple way to proceed, which drove to the current draft content. This decisio=
n is a strong argument that still prevails  for the current baseline descri=
bed in the current draft.

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

As also said, when news requirements will appear (eg session group or APN e=
xamples)  the baseline is extensible to support these new requirements .  I=
 prefer this way of progressive extensions , rather than to create a self c=
ontained 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=E9 : mardi 10 d=E9cembre 2013 04:58
=C0 : 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 righ=
t 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 opti=
mization 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 overloa=
d.

-          The last three pros are mainly for the case of overload of agent=
, if I understood them correctly. Overload of agent is still a controversia=
l scenario, we may need more discussion in the future. But anyway, with def=
inition 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-co=
ntained OLR.

Best Regards,
Susan

From: Ben Campbell [mailto:ben@nostrum.com]
Sent: Tuesday, December 10, 2013 7:53 AM
To: 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 wh=
at we do for a later (or final) version.

So far, I've seen 4 people opposed to self-contained OLRs (Lionel, Nirav, M=
aria, 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 lo=
ok 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 firs=
t group explain what they think the pros of implicit OLRs might be beyond t=
hose 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 application=
s at once, instead of having to signal each one separately.
  *   Allows an easy solution to our "loss" algorithm corner case of not be=
ing able to signal the end of a 100% overload condition
  *   Makes it easier to solve the agent overload problem, without requirin=
g 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 transac=
tion 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 trans=
action context and the report type. [I don't understand why this is valuabl=
e, 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 supporte=
d 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 > wrote:

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

- Jouni



_______________________________________________

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




--_000_A9CA33BB78081F478946E4F34BF9AAA014D33D9Axmbrcdx10ciscoc_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Steve,<=
/p>

 <=
/p>

In that case, I do not se=
e any use of "self-contained OLR".


e.g. the server sends app=
lication-Y's report in application-X's message. The client may ignore the a=
pplication-Y's report and hence the server has to ensure
 to send application-Y's report in application-Y's message as well.


So what is the gain here?=



 <=
/p>

I do not understand the n=
eed to define such a mechanism.


 <=
/p>

Regards,


Nirav.<=
/p>

 <=
/p>





From: Steve Donovan [mailto:srdonovan@usdonovans.com]


Sent: Monday, December 16, 2013 9:42 PM

To: Nirav Salot (nsalot); dime@ietf.org

Subject: Re: [Dime] DOIC: Self-Contained OLRs






 


Nirav,



There is nothing in the self-contained overload report proposal the require=
s cross-application data handling.  An implementation can take advanta=
ge of cross-application information if it is able and wants to, but it is n=
ot required to do so.



Regards,



Steve




On 12/16/13 9:50 AM, Nirav Salot (nsalot) wrote:






Steve,<=
/p>

 <=
/p>

SRD> I don't understand what is meant by "re=
quires architectural support".  Is this a way of saying it is mor=
e difficult to implement?

As of today, the Diameter message can only conta=
in data specific to one application and based on this, the nodes are design=
ed to handle data/AVP specific to one application.


Thus, cross-application d=
ata handling (that you are proposing via "self-contained OLR") is=
 not required to be supported in today's design/architecture of the
 Diameter node supporting a set of applications.


 <=
/p>

Regards,


Nirav.<=
/p>

 <=
/p>





From: Steve Donovan [mailto:srdonovan@usdonovans.com]


Sent: Monday, December 16, 2013 6:54 PM

To: Nirav Salot (nsalot); dime@ietf=
.org

Subject: Re: [Dime] DOIC: Self-Contained OLRs






 


Nirav,



See my response inline.



Regards,



Steve




On 12/12/13 10:36 AM, Nirav Salot (nsalot) wrote:






Steve,<=
/p>

 <=
/p>

Why do you always talk ab=
out "the application which the Diameter node does not understand?"=
;


What if the reacting node=
 supports two applications and in the message for application-X it receives=
 the overload-report for application-Y?


Do you propose to ignore =
this report as well?




SRD> The logic behind self contained reports woul=
d be that the reactor  use the reports that it makes sense for the rea=
ctor to use.  I think your question is what should a reactor do if it =
supports application-X and application-Y, sends
 a request for application-X and receives a reply with an overload report f=
or application-Y in the answer to that request. The behavior I would sugges=
t is that the reactor should (not must) honor the overload report for reque=
sts sent to application-Y.  If this
 is particularly difficult for the reactor to achieve then it can wait to r=
eceive an overload for application-Y in answers to requests sent on applica=
tion-Y.








 <=
/p>

As already indicated earl=
ier, by many of us, handling of application-Y's data in the application-X's=
 message is not how the Diameter applications are designed
 today. And hence this type of proposal requires architectural support for =
handling it. And there lies the complexity.


SRD> I don't understand what is meant by "re=
quires architectural support".  Is this a way of saying it is mor=
e difficult to implement?








This main drawback was hi=
ghlighted earlier as well but was conveniently ignored while preparing the =
pros and cons list for the self-contained OLR.


SRD> Then suggest it be added to the pros and con=
s list.  But first explain the concept of "requires architectural=
 support". 









 <=
/p>

Regards,


Nirav.<=
/p>

 <=
/p>





From: DiME [ma=
ilto:dime-bounces@ietf.org]
On Behalf Of Steve Donovan

Sent: Thursday, December 12, 2013 7:16 PM

To: dime@ietf.org

Subject: Re: [Dime] DOIC: Self-Contained OLRs






 


Maria Cruz,



Can you explain the complexity behind the cross-application procedure. =
; The work required is to ignore any application that the Diameter node doe=
s not understand.  I don't see this as very complex.



Steve




On 12/12/13 1:26 AM, Maria Cruz Bartolome wrote:






Yes, I agree consistency =
is not any longer a problem, since now your intention is that _any_ =
(and multiple) application data could be conveyed within
 the same message.


But as mentioned a few ti=
mes, I consider this not necessary since OLR is sent in every answer.



A part from that, as ment=
ioned by Lionel, this implies a cross-application procedure at both endpoin=
ts, that increases complexity and it is not required for
 our work (RFC7068)


 <=
/p>

Cheers<=
/p>

/MCruz<=
/p>

 <=
/p>





From: DiME [ma=
ilto:dime-bounces@ietf.org]
On Behalf Of Steve Donovan

Sent: mi=E9rcoles, 11 de diciembre de 2013 20:09

To: dime@ietf.org

Subject: Re: [Dime] DOIC: Self-Contained OLRs






 


Maria Cruz,



I don't agree with the assertion that self-contained OLRs results in the po=
tential for data inconsistency.  If a reactor receives an overload rep=
ort for an application that is not supported by the reactor then the reacto=
r can and should ignore that OLR. 




The concept of self-contained overload reports would explicitly allow for t=
he contents of the overload report to be different than the message that is=
 carrying the OLR.  As with application-ids, if the reactor doesn't se=
nd messages to a reported host or realm
 then the reactor ignores that part of the overload report.  As such, =
there is no need to check the implicit data when receiving a self-contained=
 OLR.



Steve




On 12/11/13 12:25 PM, Maria Cruz Bartolome wrote:






Hello (and something else now 
J, fast key combination, I won’t be able to repeat,  was =
the responsible)


 


As mentioned before, something else on cons side =
for self-contained:


 


A part from that, =
; one concern with "self-contained OLRs" is that some data is dup=
licated. Duplication should be avoided, since then we need to assure consis=
tency, and error handing in case implicit and explicit
 data values are different for any reason... what means that it may always =
be required to check both implicit and explicit data.


 


Also, I think this is =
a pure implementation proposal. Regardless how the data is transported it c=
ould be packed in a "self-contained OLRs" within the diameter app=
lication, if for any implementation this is preferred.


 <=
/p>

Best regards<=
/o:p>


/MCruz<=
/p>

 <=
/p>





From: DiME [ma=
ilto:dime-bounces@ietf.org]
On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)

Sent: mi=E9rcoles, 11 de diciembre de 2013 19:02

To: dime@ietf.org

Subject: Re: [Dime] DOIC: Self-Contained OLRs






 


Hi Steve


 <=
/p>

I am sorry, Steve,  =
I do not see the difference between the Draft Roach scope approach and the =
self contained OLRs.


 <=
/p>

With the scope approach i=
n Draft Roach : there is an overload metric AVP  (eg containing a % of=
 traffic reduction) coupled with one or several Overlaod-Infoscope
 AVPs, an overlaod infoscope identifying an application or a destination ho=
st or… . These Overlaod-Infoscope AVPs can be combined  with als=
o  the possibility of  multi instances to have a list of applicat=
ions, a list of destination hosts etc  to which the overload
 metric would apply.


 <=
/p>

With self contained OLR a=
s you have described them, un OLR will also contain an OC-Reduction-Percent=
age
 AVP coupled with one or several oth=
ers AVPs (the self containment approach) to indicate which application(s), =
destinations host (s) etc the   OC-Reduction-Percentage
 AVP applies.



 <=
/p>

Where is the difference?<=
/span>


 <=
/p>

So the drawbacks identifi=
ed for the scope approach also apply with the self contained approach



 <=
/p>

Best regards<=
/o:p>


 <=
/p>

JJacques



 <=
/p>

 <=
/p>

 <=
/p>





De =
: DiME [mailto:dime-bounces@ietf.org]
De la part de Steve Donovan

Envoy=E9 : mercredi 11 d=E9cembre 2013 14:20

=C0 : dime@ietf.org

Objet : Re: [Dime] DOIC: Self-Contained OLRs<=
/p>





 


JJacques,



While the self contained overload report concept may be similar to the scop=
es concept in the Roach draft, they are not the same.  As such, I don'=
t agree with your assertion that the previous rejection of the Roach draft =
requires us to reject self contained
 overload reports as currently being discussed.



Steve




On 12/11/13 2:27 AM, TROTTIN, JEAN-JACQUES (JEAN-JAC=
QUES) wrote:






Hi Ben and all



 <=
/p>

I remind my mail of 05/12=
, where the self contained OLRs approach is quite similar to the self conta=
ined 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 i=
n draft Roach).  


This also result in a pig=
gybacking  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 ho=
p, the self contained  OLRs are opened to be reprocessed in order to r=
ecreate  new self contained OLR(s)  to various destinations.



I remind that, now 6 mont=
hs ago:


This is why I remain in f=
avor of the baseline  described in the current  draft, as as I ha=
ve always and regularly  expressed for  a while.


 <=
/p>

As also said, when news r=
equirements will appear (eg session group or APN examples)  the baseli=
ne is extensible to support these new requirements .  I prefer
 this way of progressive extensions , rather than to create a self containe=
d OLR  with an  immediate and not needed complexity   &=
nbsp;


 <=
/p>

Best regards<=
/o:p>


 <=
/p>

JJacques


 <=
/p>

 <=
/p>





De : DiME [mailto:d=
ime-bounces@ietf.org]
De la part de Shishufeng (Susan)

Envoy=E9 : mardi 10 d=E9cembre 2013 04:58

=C0 : Ben Campbell; dime@ietf.=
org list

Objet : Re: [Dime] DOIC: Self-Contained OLRs<=
/p>





 


Hi Ben,=



 <=
/p>

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



 <=
/p>

Quick thinking on the pro=
s you listed for self-contained OLR.


 <=
/p>


-       &nb=
sp; 
The first two pro=
s can be seen as optimization, on which we are still arguing if these optim=
ization are worth doing or not, since such optimization
 brings extra cost.



-       &nb=
sp; 
The third one is =
not a key issue, which could be addressed with several ways as discussed. A=
s a last resort, the overloaded server may send something
 in a request towards the client to inform the end of the overload.<=
o:p>



-       &nb=
sp; 
The last three pr=
os are mainly for the case of overload of agent, if I understood them corre=
ctly. 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.


 <=
/p>

Best Regards,=



Susan

 <=
/p>





From: Ben Camp=
bell [mailto:ben@nostrum.com]


Sent: Tuesday, December 10, 2013 7:53 AM

To: dime@ietf.org list

Subject: Re: [Dime] DOIC: Self-Contained OLRs






 




I am willing to call the discussion concluded for th=
e 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 conse=
nsus. 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 explai=
n 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 no=
t already weighed into this.






 






Self-Contained O=
LRS:






 






Pros:






    

  • 
Allows an easy, generic solution to Maria's "all-application" sco=
ped overload use case.
  • 
Allows an overloaded node to signal overload for multiple applications at o=
nce, instead of having to signal each one separately.
  • 
Allows an easy solution to our "loss" algorithm corner case of no=
t being able to signal the end of a 100% overload condition
    • =

  • 
Makes it easier to solve the agent overload problem, without requiring inco=
nsistent behavior.
  • 
Allows out-of-band transmission of OLRs without a new format
  • 
Makes it easier to do things like adding a dedicated application for overlo=
ad, 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 i=
n 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" s=
cope.
  • 
An overloaded node needs to send a separate report for every supported appl=
ication.
  • 
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.
  •  
    







 






 




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




OK. Lets call this thread concluded then. I keep the old OC-OLR  seman=
tics

regarding its information context then unmodified.



- Jouni


 


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime



 

















_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime



 















_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime



 


 



 





--_000_A9CA33BB78081F478946E4F34BF9AAA014D33D9Axmbrcdx10ciscoc_--

From maria.cruz.bartolome@ericsson.com  Mon Dec 16 08:38:13 2013
Return-Path: 
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 84BDD1AE366 for ; Mon, 16 Dec 2013 08:38:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.239
X-Spam-Level: 
X-Spam-Status: No, score=-1.239 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
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 oEUNervPOcMu for ; Mon, 16 Dec 2013 08:38:03 -0800 (PST)
Received: from sesbmg21.mgmt.ericsson.se (sesbmg21.ericsson.net [193.180.251.49]) by ietfa.amsl.com (Postfix) with ESMTP id 555771AE037 for ; Mon, 16 Dec 2013 08:38:02 -0800 (PST)
X-AuditID: c1b4fb31-b7fa78e0000005dd-44-52af2c6823af
Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg21.mgmt.ericsson.se (Symantec Mail Security) with SMTP id DD.3B.01501.86C2FA25; Mon, 16 Dec 2013 17:38:00 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.73]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.02.0347.000; Mon, 16 Dec 2013 17:37:50 +0100
From: Maria Cruz Bartolome 
To: "Nirav Salot (nsalot)" , Steve Donovan , "dime@ietf.org" 
Thread-Topic: [Dime] DOIC: Self-Contained OLRs
Thread-Index: AQHO8HrX2PaAGa/GgUyaCwjRxXVUh5o5m/0AgACzUoCAAAFygIAAE14AgAF8EACAACKcAIAANGaAgATJUgCAAAuAAIACAWkAgAAGHYCAAXsigIAALuKAgAAb/4CAAHc6gIAAOZAAgAAO+4CAAAVNAIAABNCAgAAF6QCAAAecAIAF/9gAgAAFIoCAANV2gIAARHaAgAHlZ9CAAEm9gIAAWSGggAACrFCAAAAqoIAAeyEAgADOAYCAAGoDgP//yK3wgAZ6WoD//8JwoIAAbJwA//+fpjAAANtccA==
Date: Mon, 16 Dec 2013 16:37:49 +0000
Message-ID: <087A34937E64E74E848732CFF8354B92097564DE@ESESSMB101.ericsson.se>
References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <13081_1386256433_52A09831_13081_8197_1_6B7134B31289DC4FAF! 731D84412 2B36E32B6EB@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B9209739738@ESESSMB101.ericsson.se>  <8FD63E2D-5203-4DA4-A6DA-C4CA181C9CFB@nostrum.com> <26C84DFD55BC3040A45BF70926E55F2587C1D786@SZXEMA512-MBX.china.huawei.com>  <52A86663.30500@usdonovans.com>  <087A34937E64E74E848732CFF8354B920973A82A@ESESSMB101.ericsson.se> <52A8B862.5040207@usdonovans.com> <087A34937E64E74E848732CFF8354B920973AAF5@ESESSMB101.ericsson.se> <52A9BE1F.7020201@usdonovans.com>  <52AEFED7.5060908@usdonovans.com>  <52AF264E.9070304@usdonovans.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.148]
Content-Type: multipart/alternative; boundary="_000_087A34937E64E74E848732CFF8354B92097564DEESESSMB101erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCLMWRmVeSWpSXmKPExsUyM+JvrW6Gzvogg3sLzSzm9q5gs3i2KsVi QxOPA7PHlN8bWT2WLPnJ5LHqbR9rAHMUl01Kak5mWWqRvl0CV8aB3o2MBUvnslScWb2erYHx 8y3mLkZODgkBE4l5f85D2WISF+6tZ+ti5OIQEjjBKPGs4RsLhLOYUeJ79w1GkCo2ATuJS6df MIHYIgJVEremzGQBsYUFdCW2nfrADBHXk3hxciUTSLOIwCYmiXsPpoMVsQioShxsPwJUxMHB K+ArMbmVGWLBAw6JT7PXgdVwAsW3nWsHG8QIdNL3U2vAljELiEvcejKfCeJUAYkle2DOFpV4 +fgfK4StJNG45AkryHxmgXyJ9l/WIGFeAUGJkzOfsExgFJmFZNIshKpZSKogSvQkbkydwgZh a0ssW/iaGcLWlZjx7xALsvgCRvZVjJLFqcVJuelGhnq56bkleqlFmcnFxfl5esWpmxiBMXdw y2/DHYwTr9kfYpTmYFES52WY3hkkJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgXH6t3e2pcFP VOpviK+PzJ7+4w5n+fZ/7s526w+KtV2Ytfifb9G3ffU8l8VWliSEc9+cWH3KJthUWig74NuR gsaLn6u+/zvP3v3HouCLFaN+hbXvlD0/Sn3atJrYOC51mB7uv6ka943ruNQ/rjt7+Jck7Oiq ueWykZnF8N53keTVX04tumz+Za0SS3FGoqEWc1FxIgDRoyC+hwIAAA==
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Dec 2013 16:38:13 -0000

--_000_087A34937E64E74E848732CFF8354B92097564DEESESSMB101erics_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Steve, Nirav, all,

I totally agree with Nirav.
I think we need to focus on requirements fulfillment, and avoid any extra c=
omplexity that is not required.

Regards
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Nirav Salot (nsalot)
Sent: lunes, 16 de diciembre de 2013 17:32
To: Steve Donovan; dime@ietf.org
Subject: Re: [Dime] DOIC: Self-Contained OLRs

Steve,

In that case, I do not see any use of "self-contained OLR".
e.g. the server sends application-Y's report in application-X's message. Th=
e client may ignore the application-Y's report and hence the server has to =
ensure to send application-Y's report in application-Y's message as well.
So what is the gain here?

I do not understand the need to define such a mechanism.

Regards,
Nirav.

From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Monday, December 16, 2013 9:42 PM
To: Nirav Salot (nsalot); dime@ietf.org
Subject: Re: [Dime] DOIC: Self-Contained OLRs

Nirav,

There is nothing in the self-contained overload report proposal the require=
s cross-application data handling.  An implementation can take advantage of=
 cross-application information if it is able and wants to, but it is not re=
quired to do so.

Regards,

Steve
On 12/16/13 9:50 AM, Nirav Salot (nsalot) wrote:
Steve,

SRD> I don't understand what is meant by "requires architectural support". =
 Is this a way of saying it is more difficult to implement?
As of today, the Diameter message can only contain data specific to one app=
lication and based on this, the nodes are designed to handle data/AVP speci=
fic to one application.
Thus, cross-application data handling (that you are proposing via "self-con=
tained OLR") is not required to be supported in today's design/architecture=
 of the Diameter node supporting a set of applications.

Regards,
Nirav.

From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Monday, December 16, 2013 6:54 PM
To: Nirav Salot (nsalot); dime@ietf.org
Subject: Re: [Dime] DOIC: Self-Contained OLRs

Nirav,

See my response inline.

Regards,

Steve
On 12/12/13 10:36 AM, Nirav Salot (nsalot) wrote:
Steve,

Why do you always talk about "the application which the Diameter node does =
not understand?"
What if the reacting node supports two applications and in the message for =
application-X it receives the overload-report for application-Y?
Do you propose to ignore this report as well?
SRD> The logic behind self contained reports would be that the reactor  use=
 the reports that it makes sense for the reactor to use.  I think your ques=
tion is what should a reactor do if it supports application-X and applicati=
on-Y, sends a request for application-X and receives a reply with an overlo=
ad report for application-Y in the answer to that request. The behavior I w=
ould suggest is that the reactor should (not must) honor the overload repor=
t for requests sent to application-Y.  If this is particularly difficult fo=
r the reactor to achieve then it can wait to receive an overload for applic=
ation-Y in answers to requests sent on application-Y.


As already indicated earlier, by many of us, handling of application-Y's da=
ta in the application-X's message is not how the Diameter applications are =
designed today. And hence this type of proposal requires architectural supp=
ort for handling it. And there lies the complexity.
SRD> I don't understand what is meant by "requires architectural support". =
 Is this a way of saying it is more difficult to implement?

This main drawback was highlighted earlier as well but was conveniently ign=
ored while preparing the pros and cons list for the self-contained OLR.
SRD> Then suggest it be added to the pros and cons list.  But first explain=
 the concept of "requires architectural support".


Regards,
Nirav.

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: Thursday, December 12, 2013 7:16 PM
To: dime@ietf.org
Subject: Re: [Dime] DOIC: Self-Contained OLRs

Maria Cruz,

Can you explain the complexity behind the cross-application procedure.  The=
 work required is to ignore any application that the Diameter node does not=
 understand.  I don't see this as very complex.

Steve
On 12/12/13 1:26 AM, Maria Cruz Bartolome wrote:
Yes, I agree consistency is not any longer a problem, since now your intent=
ion is that _any_ (and multiple) application data could be conveyed within =
the same message.
But as mentioned a few times, I consider this not necessary since OLR is se=
nt in every answer.
A part from that, as mentioned by Lionel, this implies a cross-application =
procedure at both endpoints, that increases complexity and it is not requir=
ed for our work (RFC7068)

Cheers
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: mi=E9rcoles, 11 de diciembre de 2013 20:09
To: dime@ietf.org
Subject: Re: [Dime] DOIC: Self-Contained OLRs

Maria Cruz,

I don't agree with the assertion that self-contained OLRs results in the po=
tential for data inconsistency.  If a reactor receives an overload report f=
or an application that is not supported by the reactor then the reactor can=
 and should ignore that OLR.

The concept of self-contained overload reports would explicitly allow for t=
he contents of the overload report to be different than the message that is=
 carrying the OLR.  As with application-ids, if the reactor doesn't send me=
ssages to a reported host or realm then the reactor ignores that part of th=
e overload report.  As such, there is no need to check the implicit data wh=
en receiving a self-contained OLR.

Steve
On 12/11/13 12:25 PM, Maria Cruz Bartolome wrote:

Hello (and something else now :), fast key combination, I won't be able to =
repeat,  was the responsible)



As mentioned before, something else on cons side for self-contained:



A part from that,  one concern with "self-contained OLRs" is that some data=
 is duplicated. Duplication should be avoided, since then we need to assure=
 consistency, and error handing in case implicit and explicit data values a=
re different for any reason... what means that it may always be required to=
 check both implicit and explicit data.



Also, I think this is a pure implementation proposal. Regardless how the da=
ta is transported it could be packed in a "self-contained OLRs" within the =
diameter application, if for any implementation this is preferred.

Best regards
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE=
S (JEAN-JACQUES)
Sent: mi=E9rcoles, 11 de diciembre de 2013 19:02
To: dime@ietf.org
Subject: Re: [Dime] DOIC: Self-Contained OLRs

Hi Steve

I am sorry, Steve,  I do not see the difference between the Draft Roach sco=
pe approach and the self contained OLRs.

With the scope approach in Draft Roach : there is an overload metric AVP  (=
eg containing a % of traffic reduction) coupled with one or several Overlao=
d-Infoscope AVPs, an overlaod infoscope identifying an application or a des=
tination host or... . These Overlaod-Infoscope AVPs can be combined  with a=
lso  the possibility of  multi instances to have a list of applications, a =
list of destination hosts etc  to which the overload metric would apply.

With self contained OLR as you have described them, un OLR will also contai=
n an OC-Reduction-Percentage  AVP coupled with one or several others AVPs (=
the self containment approach) to indicate which application(s), destinatio=
ns host (s) etc the   OC-Reduction-Percentage  AVP applies.

Where is the difference?

So the drawbacks identified for the scope approach also apply with the self=
 contained approach

Best regards

JJacques



De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9 : mercredi 11 d=E9cembre 2013 14:20
=C0 : dime@ietf.org
Objet : Re: [Dime] DOIC: Self-Contained OLRs

JJacques,

While the self contained overload report concept may be similar to the scop=
es concept in the Roach draft, they are not the same.  As such, I don't agr=
ee with your assertion that the previous rejection of the Roach draft requi=
res us to reject self contained overload reports as currently being discuss=
ed.

Steve
On 12/11/13 2:27 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:
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 multip=
ly the number of AVPs in the OLRs (AVPs identifying Application, destinatio=
n 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 sel=
f 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 rec=
reate  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 si=
mple way to proceed, which drove to the current draft content. This decisio=
n is a strong argument that still prevails  for the current baseline descri=
bed in the current draft.

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

As also said, when news requirements will appear (eg session group or APN e=
xamples)  the baseline is extensible to support these new requirements .  I=
 prefer this way of progressive extensions , rather than to create a self c=
ontained 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=E9 : mardi 10 d=E9cembre 2013 04:58
=C0 : 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 righ=
t 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 opti=
mization 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 overloa=
d.

-          The last three pros are mainly for the case of overload of agent=
, if I understood them correctly. Overload of agent is still a controversia=
l scenario, we may need more discussion in the future. But anyway, with def=
inition 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-co=
ntained OLR.

Best Regards,
Susan

From: Ben Campbell [mailto:ben@nostrum.com]
Sent: Tuesday, December 10, 2013 7:53 AM
To: 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 wh=
at we do for a later (or final) version.

So far, I've seen 4 people opposed to self-contained OLRs (Lionel, Nirav, M=
aria, 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 lo=
ok 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 firs=
t group explain what they think the pros of implicit OLRs might be beyond t=
hose 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 application=
s at once, instead of having to signal each one separately.
  *   Allows an easy solution to our "loss" algorithm corner case of not be=
ing able to signal the end of a 100% overload condition
  *   Makes it easier to solve the agent overload problem, without requirin=
g 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 transac=
tion 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 trans=
action context and the report type. [I don't understand why this is valuabl=
e, 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 supporte=
d 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 > wrote:

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

- Jouni



_______________________________________________

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




--_000_087A34937E64E74E848732CFF8354B92097564DEESESSMB101erics_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Steve, Nirav, all,


 <=
/p>

I totally agree with Nira=
v.


I think we need to focus =
on requirements fulfillment, and avoid any extra complexity that is not req=
uired.


 <=
/p>

Regards=



/MCruz<=
/p>

 <=
/p>





From: DiME [mailto:dime-bounces@ietf.org]
On Behalf Of Nirav Salot (nsalot)

Sent: lunes, 16 de diciembre de 2013 17:32

To: Steve Donovan; dime@ietf.org

Subject: Re: [Dime] DOIC: Self-Contained OLRs






 


Steve,<=
/p>

 <=
/p>

In that case, I do not se=
e any use of "self-contained OLR".


e.g. the server sends app=
lication-Y's report in application-X's message. The client may ignore the a=
pplication-Y's report and hence the server has to ensure
 to send application-Y's report in application-Y's message as well.


So what is the gain here?=



 <=
/p>

I do not understand the n=
eed to define such a mechanism.


 <=
/p>

Regards,


Nirav.<=
/p>

 <=
/p>





From: Steve Donovan [mailto:srdonovan@usdonovans.com]


Sent: Monday, December 16, 2013 9:42 PM

To: Nirav Salot (nsalot); dime@ietf.org

Subject: Re: [Dime] DOIC: Self-Contained OLRs






 


Nirav,



There is nothing in the self-contained overload report proposal the require=
s cross-application data handling.  An implementation can take advanta=
ge of cross-application information if it is able and wants to, but it is n=
ot required to do so.



Regards,



Steve




On 12/16/13 9:50 AM, Nirav Salot (nsalot) wrote:






Steve,<=
/p>

 <=
/p>

SRD> I don't understand what is meant by "re=
quires architectural support".  Is this a way of saying it is mor=
e difficult to implement?

As of today, the Diameter message can only conta=
in data specific to one application and based on this, the nodes are design=
ed to handle data/AVP specific to one application.


Thus, cross-application d=
ata handling (that you are proposing via "self-contained OLR") is=
 not required to be supported in today's design/architecture of the
 Diameter node supporting a set of applications.


 <=
/p>

Regards,


Nirav.<=
/p>

 <=
/p>





From: Steve Donovan [mailto:srdonovan@usdonovans.com]


Sent: Monday, December 16, 2013 6:54 PM

To: Nirav Salot (nsalot); dime@ietf=
.org

Subject: Re: [Dime] DOIC: Self-Contained OLRs






 


Nirav,



See my response inline.



Regards,



Steve




On 12/12/13 10:36 AM, Nirav Salot (nsalot) wrote:






Steve,<=
/p>

 <=
/p>

Why do you always talk ab=
out "the application which the Diameter node does not understand?"=
;


What if the reacting node=
 supports two applications and in the message for application-X it receives=
 the overload-report for application-Y?


Do you propose to ignore =
this report as well?




SRD> The logic beh=
ind self contained reports would be that the reactor  use the reports =
that it makes sense for the reactor to use.  I think your question is =
what should a reactor do if it supports application-X
 and application-Y, sends a request for application-X and receives a reply =
with an overload report for application-Y in the answer to that request. Th=
e behavior I would suggest is that the reactor should (not must) honor the =
overload report for requests sent
 to application-Y.  If this is particularly difficult for the reactor =
to achieve then it can wait to receive an overload for application-Y in ans=
wers to requests sent on application-Y.






 <=
/p>

As already indicated earl=
ier, by many of us, handling of application-Y's data in the application-X's=
 message is not how the Diameter applications are designed
 today. And hence this type of proposal requires architectural support for =
handling it. And there lies the complexity.


SRD> I don't under=
stand what is meant by "requires architectural support".  Is=
 this a way of saying it is more difficult to implement?






This main drawback was hi=
ghlighted earlier as well but was conveniently ignored while preparing the =
pros and cons list for the self-contained OLR.


SRD> Then suggest =
it be added to the pros and cons list.  But first explain the concept =
of "requires architectural support". 







 <=
/p>

Regards,


Nirav.<=
/p>

 <=
/p>





From: DiME [ma=
ilto:dime-bounces@ietf.org]
On Behalf Of Steve Donovan

Sent: Thursday, December 12, 2013 7:16 PM

To: dime@ietf.org

Subject: Re: [Dime] DOIC: Self-Contained OLRs






 


Maria Cruz,



Can you explain the complexity behind the cross-application procedure. =
; The work required is to ignore any application that the Diameter node doe=
s not understand.  I don't see this as very complex.



Steve




On 12/12/13 1:26 AM, Maria Cruz Bartolome wrote:






Yes, I agree consistency =
is not any longer a problem, since now your intention is that _any_ =
(and multiple) application data could be conveyed within
 the same message.


But as mentioned a few ti=
mes, I consider this not necessary since OLR is sent in every answer.



A part from that, as ment=
ioned by Lionel, this implies a cross-application procedure at both endpoin=
ts, that increases complexity and it is not required for
 our work (RFC7068)


 <=
/p>

Cheers<=
/p>

/MCruz<=
/p>

 <=
/p>





From: DiME [ma=
ilto:dime-bounces@ietf.org]
On Behalf Of Steve Donovan

Sent: mi=E9rcoles, 11 de diciembre de 2013 20:09

To: dime@ietf.org

Subject: Re: [Dime] DOIC: Self-Contained OLRs






 


Maria Cruz,



I don't agree with the assertion that self-contained OLRs results in the po=
tential for data inconsistency.  If a reactor receives an overload rep=
ort for an application that is not supported by the reactor then the reacto=
r can and should ignore that OLR. 




The concept of self-contained overload reports would explicitly allow for t=
he contents of the overload report to be different than the message that is=
 carrying the OLR.  As with application-ids, if the reactor doesn't se=
nd messages to a reported host or realm
 then the reactor ignores that part of the overload report.  As such, =
there is no need to check the implicit data when receiving a self-contained=
 OLR.



Steve




On 12/11/13 12:25 PM, Maria Cruz Bartolome wrote:






Hello (and something else now 
J, fast key combination, I won’t be able to repeat,  was =
the responsible)


 


As mentioned before, something else on cons side =
for self-contained:


 


A part from that,&nb=
sp; one concern with "self-contained OLRs" is that some data is d=
uplicated. Duplication should be avoided, since then we need to assure cons=
istency, and error handing in case implicit and explicit
 data values are different for any reason... what means that it may always =
be required to check both implicit and explicit data.


 

Also, I think this i=
s a pure implementation proposal. Regardless how the data is transported it=
 could be packed in a "self-contained OLRs" within the diameter a=
pplication, if for any implementation this is
 preferred.


 <=
/p>

Best regards<=
/o:p>


/MCruz<=
/p>

 <=
/p>





From: DiME [ma=
ilto:dime-bounces@ietf.org]
On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)

Sent: mi=E9rcoles, 11 de diciembre de 2013 19:02

To: dime@ietf.org

Subject: Re: [Dime] DOIC: Self-Contained OLRs






 


Hi Steve


 <=
/p>

I am sorry, Steve,  =
I do not see the difference between the Draft Roach scope approach and the =
self contained OLRs.


 <=
/p>

With the scope approach i=
n Draft Roach : there is an overload metric AVP  (eg containing a % of=
 traffic reduction) coupled with one or several Overlaod-Infoscope
 AVPs, an overlaod infoscope identifying an application or a destination ho=
st or… . These Overlaod-Infoscope AVPs can be combined  with als=
o  the possibility of  multi instances to have a list of applicat=
ions, a list of destination hosts etc  to which the overload
 metric would apply.


 <=
/p>

With self contained OLR a=
s you have described them, un OLR will also contain an OC-Reduction-Percent=
age
 AVP coupled with one or several oth=
ers AVPs (the self containment approach) to indicate which application(s), =
destinations host (s) etc the   OC-Reduction-Percentage
 AVP applies.



 <=
/p>

Where is the difference?<=
/span>


 <=
/p>

So the drawbacks identifi=
ed for the scope approach also apply with the self contained approach



 <=
/p>

Best regards<=
/o:p>


 <=
/p>

JJacques



 <=
/p>

 <=
/p>

 <=
/p>





De =
: DiME [mailto:dime-bounces@ietf.org]
De la part de Steve Donovan

Envoy=E9 : mercredi 11 d=E9cembre 2013 14:20

=C0 : dime@ietf.org

Objet : Re: [Dime] DOIC: Self-Contained OLRs<=
/p>





 


JJacques,



While the self contained overload report concept may be similar to the scop=
es concept in the Roach draft, they are not the same.  As such, I don'=
t agree with your assertion that the previous rejection of the Roach draft =
requires us to reject self contained
 overload reports as currently being discussed.



Steve




On 12/11/13 2:27 AM, TROTTIN, JEAN-JACQUES (JEAN-JAC=
QUES) wrote:






Hi Ben and all



 <=
/p>

I remind my mail of 05/12=
, where the self contained OLRs approach is quite similar to the self conta=
ined 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 i=
n draft Roach).  


This also result in a pig=
gybacking  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 ho=
p, the self contained  OLRs are opened to be reprocessed in order to r=
ecreate  new self contained OLR(s)  to various destinations.



I remind that, now 6 mont=
hs 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 con=
tent. This decision is a strong argument that still prevails  for the =
current baseline described in the current draft.


 


This is why I remain in f=
avor of the baseline  described in the current  draft, as as I ha=
ve always and regularly  expressed for  a while.


 <=
/p>

As also said, when news r=
equirements will appear (eg session group or APN examples)  the baseli=
ne is extensible to support these new requirements .  I prefer
 this way of progressive extensions , rather than to create a self containe=
d OLR  with an  immediate and not needed complexity   &=
nbsp;


 <=
/p>

Best regards<=
/o:p>


 <=
/p>

JJacques


 <=
/p>

 <=
/p>





De : DiME [mailto:d=
ime-bounces@ietf.org]
De la part de Shishufeng (Susan)

Envoy=E9 : mardi 10 d=E9cembre 2013 04:58

=C0 : Ben Campbell; dime@ietf.=
org list

Objet : Re: [Dime] DOIC: Self-Contained OLRs<=
/p>





 


Hi Ben,=



 <=
/p>

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



 <=
/p>

Quick thinking on the pro=
s you listed for self-contained OLR.


 <=
/p>


-       &nb=
sp; 
The first two pro=
s can be seen as optimization, on which we are still arguing if these optim=
ization are worth doing or not, since such optimization
 brings extra cost.



-       &nb=
sp; 
The third one is =
not a key issue, which could be addressed with several ways as discussed. A=
s a last resort, the overloaded server may send something
 in a request towards the client to inform the end of the overload.<=
o:p>



-       &nb=
sp; 
The last three pr=
os are mainly for the case of overload of agent, if I understood them corre=
ctly. 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.


 <=
/p>

Best Regards,=



Susan

 <=
/p>





From: Ben Camp=
bell [mailto:ben@nostrum.com]


Sent: Tuesday, December 10, 2013 7:53 AM

To: dime@ietf.org list

Subject: Re: [Dime] DOIC: Self-Contained OLRs






 




I am willing to call the discussion concluded for th=
e 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 conse=
nsus. 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 explai=
n 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 no=
t already weighed into this.






 






Self-Contained O=
LRS:






 






Pros:






    

  • 
Allows an easy, generic solution to Maria's "all-application" sco=
ped overload use case.
  • 
Allows an overloaded node to signal overload for multiple applications at o=
nce, instead of having to signal each one separately.
  • 
Allows an easy solution to our "loss" algorithm corner case of no=
t being able to signal the end of a 100% overload condition
    • =

  • 
Makes it easier to solve the agent overload problem, without requiring inco=
nsistent behavior.
  • 
Allows out-of-band transmission of OLRs without a new format
  • 
Makes it easier to do things like adding a dedicated application for overlo=
ad, 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 i=
n 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" s=
cope.
  • 
An overloaded node needs to send a separate report for every supported appl=
ication.
  • 
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.
  •  
    







 






 




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




OK. Lets call this thread concluded then. I keep the old OC-OLR  seman=
tics

regarding its information context then unmodified.



- Jouni


 


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime



 















_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime



 













_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime



 


 



 





--_000_087A34937E64E74E848732CFF8354B92097564DEESESSMB101erics_--

From jouni.nospam@gmail.com  Mon Dec 16 08:46:47 2013
Return-Path: 
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 F164B1ADF50 for ; Mon, 16 Dec 2013 08:46:46 -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 bRfqLMf5gOyV for ; Mon, 16 Dec 2013 08:46:44 -0800 (PST)
Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 73E251AE062 for ; Mon, 16 Dec 2013 08:46:44 -0800 (PST)
Received: by mail-la0-f41.google.com with SMTP id eo20so2843466lab.28 for ; Mon, 16 Dec 2013 08:46:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=0EpEq625EIaupLMyBzqWFrVf4TBaZGuoST/ZrvdNSMA=; b=IxHMZk2SJ/yuCds0Of+UM8LtXmPooyvGMQZoKKlm0Jr94bxMdUbjFx7FXCbbSh9jlH LM4C6RkAv/L95GOyZ7Qk/WxIZXVu9U0E72BWyBmwndq225sfD3y1cO2JdONJputYrdMj gB7Qa38yUr437UBpjOP2Rn0yoSV7i/G28EZ04dpe8KOGsR5YFEkLuhkbBUtXhywQ/zWX 6+bRBWyRXBoU0TrF2D+UPsNKSuV/m+La2ify5dlrQbm3FiNqLy3y6w3BAEXdK+8we6ax nxAAg4hJhDedMceaKebxNNG/FfwBD52QWbr3EnYc+o8/0Iculq0gOF7kwia6jtwoopqW oRbA==
X-Received: by 10.152.87.211 with SMTP id ba19mr7209349lab.13.1387212403047; Mon, 16 Dec 2013 08:46:43 -0800 (PST)
Received: from [10.37.103.37] ([77.95.242.69]) by mx.google.com with ESMTPSA id bo10sm10150347lbb.16.2013.12.16.08.46.40 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 16 Dec 2013 08:46:42 -0800 (PST)
From: Jouni Korhonen 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <70089680-BBFD-4E4C-B550-30FEAB5C611C@gmail.com>
Date: Mon, 16 Dec 2013 18:46:37 +0200
To: "dime@ietf.org list" 
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
X-Mailer: Apple Mail (2.1510)
Subject: [Dime] Submission of draft-ietf-dime-ovli-01
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Dec 2013 16:46:47 -0000

Folks,

I am somewhat tempted to publish -01 even if we still have some very =
rough edges
and then continue from there. Any strong disagreements?

The place we lack text more or less entirely is Section 5.5.3. (for a =
reason) but
will type in something later tonight (or so).

- Jouni


From maria.cruz.bartolome@ericsson.com  Mon Dec 16 08:50:53 2013
Return-Path: 
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 399A11AE067 for ; Mon, 16 Dec 2013 08:50:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.24
X-Spam-Level: 
X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no
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 27uvRS0jcc3a for ; Mon, 16 Dec 2013 08:50:52 -0800 (PST)
Received: from sessmg21.mgmt.ericsson.se (sessmg21.ericsson.net [193.180.251.40]) by ietfa.amsl.com (Postfix) with ESMTP id C55611AE073 for ; Mon, 16 Dec 2013 08:50:51 -0800 (PST)
X-AuditID: c1b4fb28-b7f268e000001b97-b4-52af2f6abd17
Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg21.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 10.7F.07063.A6F2FA25; Mon, 16 Dec 2013 17:50:50 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.73]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.02.0347.000; Mon, 16 Dec 2013 17:50:40 +0100
From: Maria Cruz Bartolome 
To: Jouni Korhonen , "dime@ietf.org list" 
Thread-Topic: [Dime] Submission of draft-ietf-dime-ovli-01
Thread-Index: AQHO+n5lP7TSq67d8k+S06iMQUyI/ZpXCJDw
Date: Mon, 16 Dec 2013 16:50:39 +0000
Message-ID: <087A34937E64E74E848732CFF8354B920975651D@ESESSMB101.ericsson.se>
References: <70089680-BBFD-4E4C-B550-30FEAB5C611C@gmail.com>
In-Reply-To: <70089680-BBFD-4E4C-B550-30FEAB5C611C@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.148]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrELMWRmVeSWpSXmKPExsUyM+JvrW6W/vogg1l7FSzm9q5gs9i/roHJ gclj56y77B5LlvxkCmCK4rJJSc3JLEst0rdL4Mo4+kCk4DNbxduH59gaGK+wdjFyckgImEg0 zrrPCGGLSVy4t56ti5GLQ0jgBKPEsSlnmCGcxYwSBz51soNUsQnYSVw6/YIJxBYRCJZYuL2V GcQWFrCU2DKtBypuJbH42BJGCNtI4vHv5WA1LAKqEu+fTwOzeQV8JWZvvMgCYgsJ2Ejc+/oN 7CJOAVuJhpcNYDWMQBd9P7UGbCazgLjErSfzmSAuFZBYsuc8M4QtKvHy8T+ob5QkGpc8YYWo 15FYsPsTG4StLbFs4WuovYISJ2c+YZnAKDoLydhZSFpmIWmZhaRlASPLKkbJ4tTi4tx0I0O9 3PTcEr3Uoszk4uL8PL3i1E2MwHg5uOW3xg7G7mv2hxilOViUxHmrZnYGCQmkJ5akZqemFqQW xReV5qQWH2Jk4uCUamDcZJio87DknGnru0ePdXX2m2RHmyhfXmqipJYYuUss4Drjm2u2tY1t YtxGiQmSBS8+OjgZ7vk9qzRV2uv7lwmTJRhC1ojO/uz79MgtWc7QzwGLfR6K8GvuP6Es+CCp +fu/FaoclvI3v4iurj7hfGox232940IcVwym2S3UjZiR9fFi0MLVgWFKLMUZiYZazEXFiQCx zCNtZQIAAA==
Subject: Re: [Dime] Submission of draft-ietf-dime-ovli-01
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Dec 2013 16:50:53 -0000

Hello Jouni, all,

We got some open discussion without any conclusion yet, if you prefer to pu=
blish .01 version, I would suggest these open issues are properly covered t=
here, or all related text is omitted.
Cheers
/MCruz

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen
Sent: lunes, 16 de diciembre de 2013 17:47
To: dime@ietf.org list
Subject: [Dime] Submission of draft-ietf-dime-ovli-01

Folks,

I am somewhat tempted to publish -01 even if we still have some very rough =
edges and then continue from there. Any strong disagreements?

The place we lack text more or less entirely is Section 5.5.3. (for a reaso=
n) but will type in something later tonight (or so).

- Jouni

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

From maria.cruz.bartolome@ericsson.com  Mon Dec 16 09:04:43 2013
Return-Path: 
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 31B9F1AE09D for ; Mon, 16 Dec 2013 09:04:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.24
X-Spam-Level: 
X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no
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 TEQ767Z9sk31 for ; Mon, 16 Dec 2013 09:04:37 -0800 (PST)
Received: from sesbmg21.mgmt.ericsson.se (sesbmg21.ericsson.net [193.180.251.49]) by ietfa.amsl.com (Postfix) with ESMTP id 185A11AE08A for ; Mon, 16 Dec 2013 09:04:36 -0800 (PST)
X-AuditID: c1b4fb31-b7fa78e0000005dd-27-52af32a369d4
Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg21.mgmt.ericsson.se (Symantec Mail Security) with SMTP id BF.EC.01501.3A23FA25; Mon, 16 Dec 2013 18:04:35 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.73]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0347.000; Mon, 16 Dec 2013 18:04:25 +0100
From: Maria Cruz Bartolome 
To: Jouni Korhonen , "dime@ietf.org list" 
Thread-Topic: [Dime] Conclusion for the Report Type
Thread-Index: AQHO9NZBkR5KHZ79W0mkFVMNJsC5E5pXFi8A
Date: Mon, 16 Dec 2013 17:04:25 +0000
Message-ID: <087A34937E64E74E848732CFF8354B920975653A@ESESSMB101.ericsson.se>
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DCBC@DEMUMBX014.nsn-intra.net> <453156F8-9090-46D4-BF8E-A877F40EE3AC@gmail.com>
In-Reply-To: <453156F8-9090-46D4-BF8E-A877F40EE3AC@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.148]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrILMWRmVeSWpSXmKPExsUyM+Jvre5io/VBBge3mVrM7V3BZrF/XQOT A5PHzll32T2WLPnJFMAUxWWTkpqTWZZapG+XwJXRPXcDU8EB/orWixINjNN5uhg5OSQETCTa fi5nhrDFJC7cW8/WxcjFISRwglFiTedDJpCEkMBiRomns8xAbDYBO4lLp1+AxUUEgiUWbm8F aubgEBYwkuhbWwwRNpaYeuUZG4RtJPF/7gywchYBVYkdaxeA7eIV8JVYt/ol1K4mRokbZ++z giQ4BWwlGle9BrMZgQ76fmoNWDOzgLjErSfzmSAOFZBYsuc81NGiEi8f/2OFsJUkGpc8YYWo 15FYsPsTG4StLbFs4WuoxYISJ2c+YZnAKDoLydhZSFpmIWmZhaRlASPLKkbJ4tTipNx0I0O9 3PTcEr3Uoszk4uL8PL3i1E2MwGg5uOW34Q7GidfsDzFKc7AoifMyTO8MEhJITyxJzU5NLUgt ii8qzUktPsTIxMEp1cAobXt+sdOkFc+ro63D9x3/l/Lfc2ZX+sToOO7AbA7mNOF9J+xKDzE5 XahvTtgjZ8J3Mchzl32szEHZOAMO06u3p59euNzfoj9j0Vm+DRwXljLcqAroU9ZLCPYX4FUv Or7oU6L7woKPhjudI1efbNWwT1m3+Db3Wl8m9QNrc/7OfZvz3Dp92XYlluKMREMt5qLiRAA0 FrhEZAIAAA==
Subject: Re: [Dime] Conclusion for the Report Type
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Dec 2013 17:04:43 -0000

Hello,

I agree on the principles.
Enumerated is fine for me as well.

Best regards
/MCruz

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen
Sent: lunes, 09 de diciembre de 2013 13:00
To: dime@ietf.org list
Subject: [Dime] Conclusion for the Report Type

Folks,

We need a conclusion here so that I can actually write something into the -=
01. How about the following (I try to reflect as many points given here as =
possible):

1) The basic principle for the Report Type use is that only one
   OLR per report type is allowed unless the report type and the
   OLR reflecting the new report type define exact semantics how
   to differentiate between multiple OLRs with the same report
   type. In 3GPP context, for example, a report type with an AVP
   that identifies an APN could be such a differentiator.. and that
   would need a new report type where an implementation exactly
   knows to look for this additional AVP without guesswork or=20
   fuzzy heuristics.

2) A new report type or a set of new report types require a new
   feature to be allocated/defined so that both endpoints know how
   to handle the new report type that was defined after the
   publication of the baseline specification. The handling of the
   new report types must be defined (along with the new AVPs it
   might need to be included into the OC-OLR AVP).

3) With 2) in place I do not care whether the OC-Report-Type is
   enumerated or unsigned (flag vector?). I still favour Enumerated
   myself as it forces the protocol designer to come up with a=20
   cleaner design ;)

4) For the baseline we only define host and realm report types.
   We do not allow multiple OLRs with these report types i.e.
   single instances of OLRs with host and/or realm are allowed.

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

From jean-jacques.trottin@alcatel-lucent.com  Mon Dec 16 09:53:00 2013
Return-Path: 
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 0AD111AE0C3 for ; Mon, 16 Dec 2013 09:53:00 -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 eYa8UHglTe-r for ; Mon, 16 Dec 2013 09:52:58 -0800 (PST)
Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id EECF21ADF9B for ; Mon, 16 Dec 2013 09:52:57 -0800 (PST)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id rBGHqtVM005678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 16 Dec 2013 11:52:56 -0600 (CST)
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id rBGHqsFG009208 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 16 Dec 2013 18:52:54 +0100
Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.241]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Mon, 16 Dec 2013 18:52:54 +0100
From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
To: "dime@ietf.org list" 
Thread-Topic: [Dime] Conclusion for the Report Type
Thread-Index: AQHO9NZTfmjwZl8bgUqgMbcmsBQ2dppXB06AgAAcu4A=
Date: Mon, 16 Dec 2013 17:52:54 +0000
Message-ID: 
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DCBC@DEMUMBX014.nsn-intra.net> <453156F8-9090-46D4-BF8E-A877F40EE3AC@gmail.com> <087A34937E64E74E848732CFF8354B920975653A@ESESSMB101.ericsson.se>
In-Reply-To: <087A34937E64E74E848732CFF8354B920975653A@ESESSMB101.ericsson.se>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.39]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35
Subject: Re: [Dime] Conclusion for the Report Type
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Dec 2013 17:53:00 -0000

Hi=20

About Enumerated versus unsigned (flag vector), Lionel is in favour of usin=
g unsigned (flag vector) due to the issue  for adding a new emulated value =
in the future to the existing one, creating backward compatibility. In  3GP=
P CT4 it is the unsigned (flag vector rule we apply for new AVPs, so I woul=
d prefer to be consistent by using the same rule. It would be good to have =
Lionel's view on this.

Best regards

JJacques=20

 =20

-----Message d'origine-----
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolo=
me
Envoy=E9=A0: lundi 16 d=E9cembre 2013 18:04
=C0=A0: Jouni Korhonen; dime@ietf.org list
Objet=A0: Re: [Dime] Conclusion for the Report Type

Hello,

I agree on the principles.
Enumerated is fine for me as well.

Best regards
/MCruz

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen
Sent: lunes, 09 de diciembre de 2013 13:00
To: dime@ietf.org list
Subject: [Dime] Conclusion for the Report Type

Folks,

We need a conclusion here so that I can actually write something into the -=
01. How about the following (I try to reflect as many points given here as =
possible):

1) The basic principle for the Report Type use is that only one
   OLR per report type is allowed unless the report type and the
   OLR reflecting the new report type define exact semantics how
   to differentiate between multiple OLRs with the same report
   type. In 3GPP context, for example, a report type with an AVP
   that identifies an APN could be such a differentiator.. and that
   would need a new report type where an implementation exactly
   knows to look for this additional AVP without guesswork or=20
   fuzzy heuristics.

2) A new report type or a set of new report types require a new
   feature to be allocated/defined so that both endpoints know how
   to handle the new report type that was defined after the
   publication of the baseline specification. The handling of the
   new report types must be defined (along with the new AVPs it
   might need to be included into the OC-OLR AVP).

3) With 2) in place I do not care whether the OC-Report-Type is
   enumerated or unsigned (flag vector?). I still favour Enumerated
   myself as it forces the protocol designer to come up with a=20
   cleaner design ;)

4) For the baseline we only define host and realm report types.
   We do not allow multiple OLRs with these report types i.e.
   single instances of OLRs with host and/or realm are allowed.

- Jouni
_______________________________________________
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

From jouni.nospam@gmail.com  Mon Dec 16 12:08:26 2013
Return-Path: 
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 8C2451A1F4C for ; Mon, 16 Dec 2013 12:08:26 -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 SNbUwmfPCcv1 for ; Mon, 16 Dec 2013 12:08:24 -0800 (PST)
Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id E72151AC829 for ; Mon, 16 Dec 2013 12:08:23 -0800 (PST)
Received: by mail-la0-f49.google.com with SMTP id er20so2880993lab.36 for ; Mon, 16 Dec 2013 12:08:22 -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=gV5mvwC9jtWqM+kQTZ7w99rMlAAcFvG/rrdNyZLG9mw=; b=hqagyrHh+8pxlT0a2+XuIjiX++SqlmNNBX6sU6jjdQYUWknJEVUydxMeqtbet6SUWr KR83TsN+1u6O47z8ISwssfoJp5xm5xuJ2Q+65H+ZxjM1Kw/z2n+bOtSdTU3NWu7NE1Uo FNweX+GzLdBkncRJbAzD3LujQ8i27eoZCpDHDtxYYGw5BKAcZm3lKsp/DfuZyHBCIPow +4YJ7kOJ+EM/+qbg4XZ1GUh4OoMAA5afNgiKr/sPgcFZXwQdUXYwMGAlqX7twOcEbTFJ o6ne6F+B4B4tESPca+Tu9pxuKDBJS1BkhzrEana55Hn7fF323ZTWb9QPDyuaCNlFYz51 9nQQ==
X-Received: by 10.112.11.170 with SMTP id r10mr4532744lbb.23.1387224502447; Mon, 16 Dec 2013 12:08:22 -0800 (PST)
Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id y11sm10690857lbm.13.2013.12.16.12.08.21 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 16 Dec 2013 12:08:21 -0800 (PST)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jouni Korhonen 
In-Reply-To: 
Date: Mon, 16 Dec 2013 22:08:18 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <7EFF91A0-7EF4-4AED-8219-11833BC7231D@gmail.com>
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DCBC@DEMUMBX014.nsn-intra.net> <453156F8-9090-46D4-BF8E-A877F40EE3AC@gmail.com> <087A34937E64E74E848732CFF8354B920975653A@ESESSMB101.ericsson.se> 
To: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
X-Mailer: Apple Mail (2.1510)
Cc: "dime@ietf.org list" 
Subject: Re: [Dime] Conclusion for the Report Type
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Dec 2013 20:08:26 -0000

Hi,

My take is that a flag field would have exactly the same issues as =
enumerated if it used in a similar manner as enumerated.=20

If new enumerated values are only used and _included_ into =
OC-Report-Type when both ends are known to support it, there is no =
issue. And that is, for example, exactly one reason we have the =
OC-Feature-Vector for. All we need to do is to make sure that (a set of) =
new report types in future specifications also imply a definition of a =
new feature vector flag.=20

- Jouni

On Dec 16, 2013, at 7:52 PM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" =
 wrote:

> Hi=20
>=20
> About Enumerated versus unsigned (flag vector), Lionel is in favour of =
using unsigned (flag vector) due to the issue  for adding a new emulated =
value in the future to the existing one, creating backward =
compatibility. In  3GPP CT4 it is the unsigned (flag vector rule we =
apply for new AVPs, so I would prefer to be consistent by using the same =
rule. It would be good to have Lionel's view on this.
>=20
> Best regards
>=20
> JJacques=20
>=20
>=20
>=20
> -----Message d'origine-----
> De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz =
Bartolome
> Envoy=E9 : lundi 16 d=E9cembre 2013 18:04
> =C0 : Jouni Korhonen; dime@ietf.org list
> Objet : Re: [Dime] Conclusion for the Report Type
>=20
> Hello,
>=20
> I agree on the principles.
> Enumerated is fine for me as well.
>=20
> Best regards
> /MCruz
>=20
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen
> Sent: lunes, 09 de diciembre de 2013 13:00
> To: dime@ietf.org list
> Subject: [Dime] Conclusion for the Report Type
>=20
> Folks,
>=20
> We need a conclusion here so that I can actually write something into =
the -01. How about the following (I try to reflect as many points given =
here as possible):
>=20
> 1) The basic principle for the Report Type use is that only one
>   OLR per report type is allowed unless the report type and the
>   OLR reflecting the new report type define exact semantics how
>   to differentiate between multiple OLRs with the same report
>   type. In 3GPP context, for example, a report type with an AVP
>   that identifies an APN could be such a differentiator.. and that
>   would need a new report type where an implementation exactly
>   knows to look for this additional AVP without guesswork or=20
>   fuzzy heuristics.
>=20
> 2) A new report type or a set of new report types require a new
>   feature to be allocated/defined so that both endpoints know how
>   to handle the new report type that was defined after the
>   publication of the baseline specification. The handling of the
>   new report types must be defined (along with the new AVPs it
>   might need to be included into the OC-OLR AVP).
>=20
> 3) With 2) in place I do not care whether the OC-Report-Type is
>   enumerated or unsigned (flag vector?). I still favour Enumerated
>   myself as it forces the protocol designer to come up with a=20
>   cleaner design ;)
>=20
> 4) For the baseline we only define host and realm report types.
>   We do not allow multiple OLRs with these report types i.e.
>   single instances of OLRs with host and/or realm are allowed.
>=20
> - Jouni
> _______________________________________________
> 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


From ben@nostrum.com  Mon Dec 16 13:02:38 2013
Return-Path: 
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 96DC91A1F5E for ; Mon, 16 Dec 2013 13:02:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.439
X-Spam-Level: 
X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, 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 TOdG49L9mwow for ; Mon, 16 Dec 2013 13:02:34 -0800 (PST)
Received: from shaman.nostrum.com (shaman.nostrum.com [72.232.179.90]) by ietfa.amsl.com (Postfix) with ESMTP id 2A2181ACCE4 for ; Mon, 16 Dec 2013 13:02:34 -0800 (PST)
Received: from [172.20.10.7] (mobile-166-147-068-041.mycingular.net [166.147.68.41]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rBGKxuUv095346 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 16 Dec 2013 14:59:57 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Ben Campbell 
In-Reply-To: <087A34937E64E74E848732CFF8354B920973AF29@ESESSMB101.ericsson.se>
Date: Mon, 16 Dec 2013 14:59:48 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <087A34937E64E74E848732CFF8354B920973AB4B@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B920973AF29@ESESSMB101.ericsson.se>
To: Maria Cruz Bartolome 
X-Mailer: Apple Mail (2.1822)
Received-SPF: pass (shaman.nostrum.com: 166.147.68.41 is authenticated by a trusted mechanism)
Cc: "dime@ietf.org" 
Subject: Re: [Dime] OVLI: OC-Validity-Duration
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Dec 2013 21:02:39 -0000

On Dec 12, 2013, at 10:38 AM, Maria Cruz Bartolome =
 wrote:

> Jouni,
>=20
> I think the best way to manage "something unpredictable" is not to =
provide an estimation (on an unpredictable event) from the server.
> If you really think that scheduled cleanups are helpful, this could =
always be considered in the client, with a default value, that does not =
need to be sent from the reporting node.

The point is not for the reporting node to predict how long it's likely =
to be overloaded, it's to make sure things get cleaned up if some =
_other_ unpredictable event occurs. The idea is to set a time out so =
that, if the reacting node doesn't see an update in some period of time, =
it can discard the state. Otherwise, it could assume the overload =
condition to last forever. It's up to the implementation, but typically =
you choose your validity times to balance how long you are willing to =
let an expired report "hang" vs how many "update" messages you are =
willing to tolerate. I think it will be typical that servers choose a =
fixed timeout value (possibly configured) for all reports.

Soft state like this is a well known protocol design pattern used in =
many IETF protocols. The idea is that, if some failure occurs so that =
the recipient fails to get an update, the problem eventually expires, =
and heals itself.

>=20
> Regards
> /MCrzu
>=20
> -----Original Message-----
> From: Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
> Sent: jueves, 12 de diciembre de 2013 9:39
> To: Maria Cruz Bartolome
> Cc: dime@ietf.org
> Subject: Re: [Dime] OVLI: OC-Validity-Duration
>=20
> Hi,
>=20
> I kind of like scheduled cleanups.. just to make sure there is no
> stuff left hanging around when something unpredictable happens in
> the network system.
>=20
> Again, I would say this is a wrong place to "optimize".
>=20
>=20
> - Jouni
>=20
> On Dec 12, 2013, at 9:53 AM, Maria Cruz Bartolome =
 wrote:
>=20
>> Dear all,
>>=20
>> I would like to reconsider the real need for the OC-Validity-Duration =
AVP to be included into overload report.
>> Overload mechanism is being design with a principle in mind: as soon =
as reporting node determines a reacting node overload behavior should =
change, reporting node sends a fresh overload report to this reacting =
node.
>> Therefore, latest overload report received will be always applicable =
until a new report is received, and then I do not see the value, but =
just complexity, of including a Duration in the report.
>>=20
>> Let me know your views.
>> Best regards
>> /MCruz
>>=20
>>=20
>>=20
>>=20
>>=20
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From ben@nostrum.com  Mon Dec 16 13:09:12 2013
Return-Path: 
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 EF59D1ADBD5 for ; Mon, 16 Dec 2013 13:09:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Level: 
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no
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 BDKYExfTYwsY for ; Mon, 16 Dec 2013 13:09:08 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id C1C081AC862 for ; Mon, 16 Dec 2013 13:09:04 -0800 (PST)
Received: from [172.20.10.7] (mobile-166-147-068-041.mycingular.net [166.147.68.41]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rBGL90oE095775 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 16 Dec 2013 15:09:01 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Ben Campbell 
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681519E9FE@DEMUMBX014.nsn-intra.net>
Date: Mon, 16 Dec 2013 15:08:54 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <16007791-B5AF-45A4-839D-1A4DB42A48D1@nostrum.com>
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DA3E@DEMUMBX014.nsn-intra.net> <09616DA2-D1ED-40EE-8E89-755DFCD81092@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E02B@DEMUMBX014.nsn-intra.net> <1A402C59-E390-4C95-8E30-97F1F9D3EF0F@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E05C@DEMUMBX014.nsn-intra.net> <790F1603-64D5-40E2-BC59-FD4C104EEF1B@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E0D9@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D90006681519E331@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D90006681519E3C4@DEMUMBX014.nsn-intra.net> <0CDBF4BB-4E38-41D6-A5E2-9218FFEFEA43@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E6EF@DEMUMBX014.nsn-intra.net> <52A869AD.6080305@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E89B@DEMUMBX014.nsn-intra.net> <52A9C040.40206@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E9BE@DEMUMBX014.nsn-intra.net> <52A9! D74B.8070404@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E9FE@DEMUMBX014.nsn-intra.net>
To: "Wiehe, Ulrich (NSN - DE/Munich)" 
X-Mailer: Apple Mail (2.1822)
Received-SPF: pass (shaman.nostrum.com: 166.147.68.41 is authenticated by a trusted mechanism)
Cc: "dime@ietf.org" 
Subject: Re: [Dime] OVLI: comments to 4.1
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Dec 2013 21:09:12 -0000

On Dec 12, 2013, at 10:02 AM, Wiehe, Ulrich (NSN - DE/Munich) =
 wrote:

> Steve,
> ok, but then its only fair to let individual implementers (of reacting =
nodes) make the decision whether or not to spend the effort of include a =
sequence number in the OC-Supported-Features (i.e. make the sequence =
number optional).=20

I don't think that's the sort of fairness the requirements contemplated =
:-)

Reacting Nodes would only need to calculate a new sequence number if =
it's capabilities change. That won't happen often. Also, it's trivially =
easy to calculate a new sequence number. If the reacting node does not =
include one, the reporting node is forced to re-check the capabilities =
on every single Diameter request that includes one. (Which will likely =
be "all requests".)

> =20
> Isn=92t the situation similar to the proposal to introduce =
Ongoing-Throttling-Information mandatorily in requests and let =
implementers of reporting nodes decide whether they want to make use of =
this information?

No, I don't think it is. That only matters in overload situations. This =
applies to every single request all the time.

> =20
> Ulrich
> =20
> See also inline
> =20
> =20
> From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]=20
> Sent: Thursday, December 12, 2013 4:34 PM
> To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
> Subject: Re: [Dime] OVLI: comments to 4.1
> =20
> Ulrich,
>=20
> Thanks for the correction -- obviously typed pre coffee this morning.
>=20
> The tradeoff is requiring processing on every request versus =
maintaining state to allow avoiding that processing on 99.99% of =
requests.
>=20
> [Wiehe, Ulrich (NSN - DE/Munich)] The tradeoff is between a) checking =
the Supported_Features in every request and know what to do, and b) =
checking the sequence number in every request, looking up a database and =
then (in 99.99% of cases) know what to do.
>=20
>=20
>=20
> We should let individual implementers make the decision on which =
approach they prefer.
>=20
> Steve
>=20
> On 12/12/13 9:22 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> Steve,
> =20
> you probably mean =84=85can=92t  be optional=85=93 rather than =93=85can=
=92t be mandatory=85=94
> =20
> If so, I understand your logic but this means that  reacting nodes are =
forced to  implement sequence numbers in OC-Supported-Features just =
because some reporting nodes prefer to do things complicated rather than =
simple and I=92m not convinced that this would be the way to go.
> =20
> Ulrich
> =20
> =20
> From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]=20
> Sent: Thursday, December 12, 2013 2:55 PM
> To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
> Subject: Re: [Dime] OVLI: comments to 4.1
> =20
> Ulrich,
>=20
> No, the sequence number can't be mandatory.  It always needs to be =
sent to allow for end-points that what to use the logic I proposed.
>=20
> An endpoint that receives the sequence number can choose to ignore it, =
but endpoints must always send sequence numbers.
>=20
> Steve
>=20
> On 12/12/13 3:30 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> Steve,
> =20
> do you mean =84 keep sequence number in OC-Supported-Features as an =
optional AVP that may be ignored by the receiver and need notbe included =
by the sender=94?
> =20
> Ulrich
> =20
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve =
Donovan
> Sent: Wednesday, December 11, 2013 2:34 PM
> To: dime@ietf.org
> Subject: Re: [Dime] OVLI: comments to 4.1
> =20
> Ulrich,
>=20
> My email showed how a reporting node could avoid the work of =
recalculating capability information on a message by message basis using =
the sequence number.  This approach does require maintaining state.
>=20
> As Ben pointed out, it is also possible to not follow my logic and do =
as you propose by ignoring the sequence number and going through the =
work of calculating the response every time. =20
>=20
> Which approach to take is clearly an implementation decision.  We =
should keep the sequence number to allow for the stateful approach for =
implementations that are willing to take advantage of maintaining state =
to avoid work.
>=20
> Steve
>=20
> On 12/11/13 1:34 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> Jouni,
> =20
> I do not agree.
> =20
> My statement was general: reporting node may be server or SFA; =
supported features may be defined features (default algo) or future =
extensions.
> =20
> Ulrich
> =20
> -----Original Message-----
> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
> Sent: Tuesday, December 10, 2013 10:46 PM
> To: Wiehe, Ulrich (NSN - DE/Munich)
> Cc: dime@ietf.org
> Subject: Re: [Dime] OVLI: comments to 4.1
> =20
> Ulrich,
> =20
> On Dec 10, 2013, at 2:18 PM, "Wiehe, Ulrich (NSN - DE/Munich)" =
 wrote:
> =20
> =20
> =20
> -----Original Message-----
> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
> Sent: Tuesday, December 10, 2013 12:32 PM
> To: Wiehe, Ulrich (NSN - DE/Munich)
> Cc: dime@ietf.org
> Subject: Re: [Dime] OVLI: comments to 4.1
> =20
> =20
> On Dec 10, 2013, at 12:41 PM, "Wiehe, Ulrich (NSN - DE/Munich)" =
 wrote:
> =20
> Hi Jouni,
> =20
> my understanding from Steve's clarification was that the reporting =
node would setup and maintain a database of "states", one per reacting =
node where a state of a reacting node is identified by a sequence number =
and the database entry would contain the pre-calculated OLR.=20
> Hard to see how this is done without consuming resources.
> =20
> It is mostly static information. Still I do not see how
> you would get away without any state.
> [Wiehe, Ulrich (NSN - DE/Munich)] There is no need for the reporting =
node to store and maintain information per reacting node because the =
reacting node actually tells within the request message all information =
the reporting node needs to know. The reporting node simply fetches the =
pre-calculated OLR that matches the supported features of the reacting =
node as indicated in the request and appends it to the answer.
> =20
> This could be true for the default algorithm in this spec. However,
> given the extension mechanism we have in place it is quite possible
> that the assumption does not hold for new features.
> =20
> Also, if I were to implement a server front end agent that would
> definitely need state and still ought to comply the protocol spec.
> =20
> - Jouni
> =20
> =20
> =20
> =20
> Furthermore,
> Why would the reacting node be interested in config changes of the =
reporting node?
> Isn't it so that the reacting node is only interested in OLR changes?
> =20
> Sigh.. say the traffic abatement algorithm changes or new features
> get added. Those have more impact than just OLR change.
> =20
> - Jouni
> =20
> =20
> Ulrich
> =20
> -----Original Message-----
> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
> Sent: Tuesday, December 10, 2013 9:41 AM
> To: Wiehe, Ulrich (NSN - DE/Munich)
> Cc: dime@ietf.org
> Subject: Re: [Dime] OVLI: comments to 4.1
> =20
> =20
> On Dec 9, 2013, at 4:43 PM, "Wiehe, Ulrich (NSN - DE/Munich)" =
 wrote:
> =20
> But maintaining a specific state per reacting node is very resource =
consuming for the (overloaded) reporting node. It is simpler and more =
efficient to base any processing logic on actual information received in =
the request rather than on information stored from previous =
communication.
> =20
> The "state" in a reporting node is merely the current configuration
> and a counter for sequence number. Hard to me see that as resource
> consuming function.
> =20
> And the earlier comment of mine is done from reacting node point
> of view, since it is more interested in the possible config changes
> in the reporting node (e.g. S6a is stateless application, =
configuration
> can change at any time).
> =20
> - Jouni
> =20
> =20
> =20
> Ulrich
> =20
> -----Original Message-----
> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
> Sent: Monday, December 09, 2013 2:25 PM
> To: Wiehe, Ulrich (NSN - DE/Munich)
> Cc: dime@ietf.org
> Subject: Re: [Dime] OVLI: comments to 4.1
> =20
> =20
> On Dec 9, 2013, at 3:13 PM, "Wiehe, Ulrich (NSN - DE/Munich)" =
 wrote:
> =20
> There is a fundamental difference:
> OLRs need to be stored, Feature-Vectors not.
> =20
> How come feature vector does not need to be stored? I do not
> get that? I would set my implementation to a specific state
> or mode based on the feature vector. When that changes I'd
> like to know that. And then keep functioning based on that.
> =20
> - Jouni
> =20
> When receiving an OLR you may want to know whether its worth the =
effort to replace an already stored OLR with the received OLR.
> When receiving a Feature-Vector you just act on it.
> =20
> Ulrich=20
> =20
> -----Original Message-----
> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
> Sent: Monday, December 09, 2013 1:55 PM
> To: Wiehe, Ulrich (NSN - DE/Munich)
> Cc: dime@ietf.org
> Subject: Re: [Dime] OVLI: comments to 4.1
> =20
> =20
> In the same vein as folks wanted send OLRs with the new or old =
information,
> the feature vector should behave in a same way IMHO. That implies =
there are
> situations when a reception of the feature vector does not change =
anything
> in an endpoint current behavior.
> =20
> - Jouni
> =20
> On Dec 9, 2013, at 2:47 PM, "Wiehe, Ulrich (NSN - DE/Munich)" =
 wrote:
> =20
> Isn't it so that the Feature-Vector (if present) always contains =
something that an implementation needs to act upon?
> =20
> Ulrich
> =20
> -----Original Message-----
> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
> Sent: Monday, December 09, 2013 1:12 PM
> To: Wiehe, Ulrich (NSN - DE/Munich)
> Cc: dime@ietf.org
> Subject: Re: [Dime] OVLI: comments to 4.1
> =20
> Ulrich,
> =20
> On Dec 6, 2013, at 3:03 PM, "Wiehe, Ulrich (NSN - DE/Munich)" =
 wrote:
> =20
> Hi Jouni,
> =20
> thank you for your response.
> =20
> With regard to 3)=20
> I still fail to see the usecase for Sequence-Number or TimeStamp =
within OC-Feature-Vector. Please clarify.
> =20
> Since we also allow extending the OC-Feature-Vector beyond =
recognition,=20
> it has good chances become a rather complex grouped AVP. In that =
context
> the Sequence-Number allows an easy and quick way to check if the =
feature
> vector contains something that an implementation needs to act upon.
> =20
> With regard to 4)
> This was not obvious to me. (The obvious typo is the missing "of" =
between "one" and "the").
> =20
> Ack. Fixed the missing 'of'.
> =20
> - Jouni
> =20
> =20
> Best regards
> Ulrich
> =20
> =20
> -----Original Message-----
> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
> Sent: Friday, December 06, 2013 11:17 AM
> To: Wiehe, Ulrich (NSN - DE/Munich)
> Cc: dime@ietf.org
> Subject: Re: [Dime] OVLI: comments to 4.1
> =20
> =20
> On Dec 5, 2013, at 3:23 PM, "Wiehe, Ulrich (NSN - DE/Munich)" =
 wrote:
> =20
> Dear all,
> =20
> here are comments to clause 4.1:
> =20
> 1. The OC-Feature-Vector AVP is no longer a vector; the name of the =
AVP may be misleading. Proposal is to rename it to =
"OC-Supported-Features AVP"
> =20
> OK with me.
> =20
> 2. The OC-Feature AVP is a vector of features. Proposal is to rename =
it to "OC-Feature-Vector AVP"
> =20
> OK with me.
> =20
> 3. The OC-Sequence-Number within OC-Feature-Vector only makes sense if =
the receiving reporting endpoint can determine the identity of the =
reacting endpoint (which is not necessarily the origin host (client),
> =20
> My original proposal was to have seqnr as a timestamp. Some folks =
argued
> it is no good and suggested seqnr. I still think time makes more sense =
than
> seqnr.
> =20
> it may be an agent and it may not always be the same agent), and if =
the reporting endpoint is required to store the OC-Feature-Vector / =
reacting-endpoint-identity pair (which I think both is not required). =
The reporting endpoint can base its processing logic on the actually =
received OC-Feature-Vector value, no matter whether it is brand-new or =
old but stil valid. Proposal is to delete OC-Sequence-Number AVP from =
OC-Feature-Vector.
> =20
> Do not agree removing it.
> =20
> 4. The text
> =20
> The reporting node that sends the answer also includes the OC-
> Feature-Vector AVP that describe the capabilities it supports.  The
> set of capabilities advertised by the reporting node depends on local
> policies.  At least one the announced capabilities MUST match
> mutually.  If there is no single matching capability the reacting
> node MUST act as if it does not implement DOIC and cease inserting
> any DOIC related AVPs into any Diameter messages with this specific
> reacting node.
> =20
> is not clear.  Would the reporting node include the OC-Feature-Vector =
AVP in the answer only if there is at least one matching capability?=20
> =20
> Because then they have found a way to exchange something that both =
ends
> know how to handle it.
> =20
> Mandating the reacting node to cease for all time inserting =
OC-Feature-Vector AVPs if it did not get back=20
> =20
> There is an obvious typo. It should say:
> =20
> policies.  At least one the announced capabilities MUST match
> mutually.  If there is no single matching capability the reporting
> node MUST act as if it does not implement DOIC and cease inserting
> any DOIC related AVPs into any Diameter messages with this specific
> reacting node.
> =20
> - JOuni
> =20
> =20
> at least one match is also not ok. The request might have been a =
realm-type request (i.e. without Destination Host) and the reacting node =
cannot control whether subsequent requests will take the same path to =
the same reporting node.
> Even if the request contains a destination host the reacting node =
cannot know wether the reacting node's capabilities have been modified =
by the time a subsequent request is sent.=20
> Proposal is to keep only the first sentence and delete the rest.
> =20
> Ulrich
> =20
> =20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
> =20
> =20
> =20
> =20
> =20
> =20
> =20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
> =20
> =20
> =20
> =20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From ben@nostrum.com  Mon Dec 16 13:10:24 2013
Return-Path: 
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 B83381ADBD7 for ; Mon, 16 Dec 2013 13:10:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Level: 
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no
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 5cuG4J1bMNjq for ; Mon, 16 Dec 2013 13:10:24 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id D30301AD942 for ; Mon, 16 Dec 2013 13:10:23 -0800 (PST)
Received: from [172.20.10.7] (mobile-166-147-068-041.mycingular.net [166.147.68.41]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rBGLAGmi095870 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 16 Dec 2013 15:10:17 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Ben Campbell 
In-Reply-To: <36AA0D1A-C1A8-4C3D-B47A-67606862E3F6@gmail.com>
Date: Mon, 16 Dec 2013 15:10:10 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <49120039-2D60-4F78-BD70-1827BDE105DD@nostrum.com>
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DA3E@DEMUMBX014.nsn-intra.net> <09616DA2-D1ED-40EE-8E89-755DFCD81092@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E02B@DEMUMBX014.nsn-intra.net> <1A402C59-E390-4C95-8E30-97F1F9D3EF0F@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E05C@DEMUMBX014.nsn-intra.net> <790F1603-64D5-40E2-BC59-FD4C104EEF1B@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E0D9@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D90006681519E331@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D90006681519E3C4@DEMUMBX014.nsn-intra.net> <0CDBF4BB-4E38-41D6-A5E2-9218FFEFEA43@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E6EF@DEMUMBX014.nsn-intra.net> <52A869AD.6080305@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E89B@DEMUMBX014.nsn-intra.net> <52A9C040.40206@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E9BE@DEMUMBX014.nsn-intra.net> <52A9! D74B.8070 404@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E9FE@DEMUMBX014.nsn-intra.net> <36AA0D1A-C1A8-4C3D-B47A-67606862E3F6@gmail.com>
To: Jouni Korhonen 
X-Mailer: Apple Mail (2.1822)
Received-SPF: pass (shaman.nostrum.com: 166.147.68.41 is authenticated by a trusted mechanism)
Cc: "dime@ietf.org" 
Subject: Re: [Dime] OVLI: comments to 4.1
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Dec 2013 21:10:24 -0000

On Dec 13, 2013, at 7:33 AM, Jouni Korhonen  =
wrote:

>=20
> On Dec 12, 2013, at 6:02 PM, "Wiehe, Ulrich (NSN - DE/Munich)" =
 wrote:
>=20
>> Steve,
>> ok, but then its only fair to let individual implementers (of =
reacting nodes) make the decision whether or not to spend the effort of =
include a sequence number in the OC-Supported-Features (i.e. make the =
sequence number optional).=20
>=20
> Having a mandatory to send but optional to process AVP would fit here.
> That would not be optional in a Diameter CCF point of view but text
> saying on the receiver side "MAY process seqno.." or "SHOULD process
> seqno..". Just avoiding MUST should do.

+1

>=20
> - JOuni
>=20


From ben@nostrum.com  Mon Dec 16 13:10:44 2013
Return-Path: 
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 EDBD01ADD02 for ; Mon, 16 Dec 2013 13:10:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Level: 
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no
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 3L4bYxwrAv0L for ; Mon, 16 Dec 2013 13:10:43 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id E973E1AC862 for ; Mon, 16 Dec 2013 13:10:42 -0800 (PST)
Received: from [172.20.10.7] (mobile-166-147-068-041.mycingular.net [166.147.68.41]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rBGLAGmj095870 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 16 Dec 2013 15:10:39 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Ben Campbell 
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151A5D34@DEMUMBX014.nsn-intra.net>
Date: Mon, 16 Dec 2013 15:10:39 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <9FE7A52E-2087-4058-B8C1-E577605F8BC1@nostrum.com>
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DA3E@DEMUMBX014.nsn-intra.net> <09616DA2-D1ED-40EE-8E89-755DFCD81092@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E02B@DEMUMBX014.nsn-intra.net> <1A402C59-E390-4C95-8E30-97F1F9D3EF0F@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E05C@DEMUMBX014.nsn-intra.net> <790F1603-64D5-40E2-BC59-FD4C104EEF1B@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E0D9@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D90006681519E331@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D90006681519E3C4@DEMUMBX014.nsn-intra.net> <0CDBF4BB-4E38-41D6-A5E2-9218FFEFEA43@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E6EF@DEMUMBX014.nsn-intra.net> <52A869AD.6080305@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E89B@DEMUMBX014.nsn-intra.net> <52A9C040.40206@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E9BE@DEMUMBX014.nsn-intra.net> <52A9! D74B.8070404@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E9FE@DEMUMBX014.nsn-intra.net> <36AA0D1A-C1A8-4C3D-B47A-67606862E3F6@gmail.com> <5BCBA1FC2B7F0B4C9D935572D9000668151A5D34@DEMUMBX014.nsn-intra.net>
To: "Wiehe, Ulrich (NSN - DE/Munich)" 
X-Mailer: Apple Mail (2.1822)
Received-SPF: pass (shaman.nostrum.com: 166.147.68.41 is authenticated by a trusted mechanism)
Cc: "dime@ietf.org" 
Subject: Re: [Dime] OVLI: comments to 4.1
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Dec 2013 21:10:44 -0000

On Dec 16, 2013, at 4:22 AM, Wiehe, Ulrich (NSN - DE/Munich) =
 wrote:

> Then let's do the same way with Ongoing-Throttling-Information.
>=20

-1 (see my comment to earlier email.)

> -----Original Message-----
> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
> Sent: Friday, December 13, 2013 2:33 PM
> To: Wiehe, Ulrich (NSN - DE/Munich)
> Cc: ext Steve Donovan; dime@ietf.org
> Subject: Re: [Dime] OVLI: comments to 4.1
>=20
>=20
> On Dec 12, 2013, at 6:02 PM, "Wiehe, Ulrich (NSN - DE/Munich)" =
 wrote:
>=20
>> Steve,
>> ok, but then its only fair to let individual implementers (of =
reacting nodes) make the decision whether or not to spend the effort of =
include a sequence number in the OC-Supported-Features (i.e. make the =
sequence number optional).=20
>=20
> Having a mandatory to send but optional to process AVP would fit here.
> That would not be optional in a Diameter CCF point of view but text
> saying on the receiver side "MAY process seqno.." or "SHOULD process
> seqno..". Just avoiding MUST should do.
>=20
> - JOuni
>=20


From ben@nostrum.com  Mon Dec 16 13:16:50 2013
Return-Path: 
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 30B011AD8F0 for ; Mon, 16 Dec 2013 13:16:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Level: 
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no
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 OniTYwAow5Tz for ; Mon, 16 Dec 2013 13:16:47 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 078431AC3DD for ; Mon, 16 Dec 2013 13:16:46 -0800 (PST)
Received: from [172.20.10.7] (mobile-166-147-068-041.mycingular.net [166.147.68.41]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rBGLGe53096140 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 16 Dec 2013 15:16:41 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Ben Campbell 
In-Reply-To: 
Date: Mon, 16 Dec 2013 15:16:34 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <86FEF8F1-5C85-4A6E-A133-CC80A0D940A1@nostrum.com>
References:  
To: Jouni Korhonen 
X-Mailer: Apple Mail (2.1822)
Received-SPF: pass (shaman.nostrum.com: 166.147.68.41 is authenticated by a trusted mechanism)
Cc: "dime@ietf.org" 
Subject: Re: [Dime] OC-Supported Feature AVP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Dec 2013 21:16:50 -0000

On Dec 16, 2013, at 6:49 AM, Jouni Korhonen  =
wrote:

>=20
> Hi,
>=20
> On Dec 13, 2013, at 3:44 PM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" =
 wrote:
>=20
>> Dear all
>>=20
>> When analysing the discussion of the sequence number in the =
OC-Supported-Features AVP , it has driven me to some other =
considerations regarding this  feature negotiation that I hereafter =
present:  it is a bit long but it raises  a certain number of questions  =
 and then we have to draw some conclusion  and adapt the text  of the =
draft if needed
>>=20
>> A)     Behaviours for sending the  OC-Supported-Features AVP
>> Currently there is only one default algorithm. So the use of  =
OC-Supported-Features AVP containing the OC-Feature-Vector is  only to =
indicate the support of DOIC with the default algorithm, given that en =
entity not supporting DOIC will never sends the OC-Supported-Features =
AVP.
>>=20
>> This AVP in the future  will allow to add new feature/capabilities .
>>=20
>> This AVP is needed initially to advertise the mutual  capabilities =
between reacting and reporting node  and  when changes occur in the  =
supported  features (eg in general to add a new feature, but may be also =
to remove  one). A sequence number was introduced to manage these =
changes, but this introduction is still under discussion (cf Ulrich=92s =
mails questioning this point)
>>=20
>> Then there is the question about when the OC-Supported-Features AVP =
is sent.  The current draft  has related statements in 3.2 and 4.1  :
>> The several hereafter possible  behaviors are compliant for me with =
3.2 and 4.1  statements (are you sharing this reading?), we have to see =
if the draft allows all of them or if additional rules must be  =
fulfilled:
>>=20
>> a)      The reacting node sends the OC-Supported-Features AVP in each =
request and the reporting node sends back its own OC-Supported-Features =
AVP in each answer.
>> b)      The reacting nodes initially sends its  OC-Supported-Features =
AVP, but does not repeat it any more , until a change in the features to =
be advertised  happens or after a node restart
>> c)       Something intermediate, so when there is a change as in b)  =
plus  a periodic advertisement of the supported features although =
unchanged
>=20
> I would be strongly supporting a) type of behaviour specifically for =
Diameter applications that do not maintain state. b) or c) could work =
for applications that have a state on Diameter level.

As I've mentioned before, I don't see that tying OC-Supported-Features =
to the lifetime of Diameter application state to be very useful. In the =
example of user sessions, you will typically have many (maybe millions) =
of sessions come and go, and features are typically not going to change =
nearly that often.

We might consider adding a validity time ;-)  (I'm only partially =
joking.)


>=20
>>=20
>> About a):
>> Steve,  and I agree,   indicated that the features are quite stable =
over time, and modifications will appear when a new feature is deployed =
(OAM case); I think  it is also needed at restart. So there are very few =
events over the year where the advertisement is actually needed (have =
you others in mind?) . Now my questioning:   why to permanently do such =
an exchange in each request/answer?  I observe that this behavior  is =
used in 3GPP where supported features are advertised in each =
request/answer, so we can apply  the same principle, but I nevertheless =
raise the question.
>=20
> Because for applications that do not maintain state you typically need =
to send everything to express your intentions properly. As said earlier =
for certain types of applications you can drop AVPs once your intentions =
regarding behaviour have been made clear.
>=20
>>=20
>> About the sequence number:
>> o   the receiving node has to open the sequence number AVP and checks =
if it has changed, given the value will change only a few times a year.  =
A besides  question,  which value the seq number takes after a restart
>> o   if we do not use the sequence number, the  receiving node has to =
open the OC-feature-Vector AVP and see if it has changed, so I do not =
see much difference with the above
>> o   the sequence number has the property  to be equal  or to increase =
in order to detect an eventual  change of the order of the messages and =
avoid to come back to a previous value of the feature-vector. But =
further messages will all be with the new feature-vector, so the right =
result. I am not sure that the seq number bring a value for the =
transient period when the supported feature is  modified. So question: =
can we suppress the seq number in this a) behaviour?
>=20
> IMHO the above is good reasoning/analysis why not use seqnum in =
OC-Supported-Features. My counter argument has been (and still is) =
whether we could have a situation where the OC-Feature-Vector remain =
unchanged but some additional AVPs related to the supported features =
would change? At the moment I do not have a valid use case in mind, =
specifically outside 3GPP context, but could those arise? In that case =
just looking into OC-Feature-Vector would not tell the difference but =
you would need to parse the whole OC-Supported-Features.

I think that if we have some feature related AVPs that change a lot more =
often than "feature support" changes, those values belong somewhere =
other than in OC-Supported-Features.

>=20
>> In this a ) behaviour, if the OC-Supported-Features AVP is no more =
present in a message (and in later messages) ,  it would  be interpreted =
 that DOIC is no more supported . ( so different from the b) or c) case)
>>=20
>> About b): this is the other extreme use case compared to a).
>> Here in practice all the messages will not contain an  =
OC-Supported-Features AVP (except in the  rare cases of a change or =
after a restart), So the absence of this AVP in a message  does not mean =
that DOIC is not supported. Capability negotiation  happens once and =
remain valid until a change. At restart or when a change  a reacting =
node sends an OC-Supported-Features AVP in a request, and wait for an =
OC-Supported-Features AVP   in the answer; if nothing, it means the =
reporting node is not supporting DOIC. If the answer is lost the =
reacting node may repeat the request or use another one with its OC =
Supported-feature AVP.
>>=20
>> If the change occurs in the reporting node, it cannot wait for a =
request coming from the reacting node with an OC Supported-feature AVP,  =
(as it will  never come if no change at the reacting node side), so the =
reporting node should advertise the  OC Supported-feature AVP in answers =
(although the corresponding request do not contain this AVP).  I think =
this behavior is currently allowed by the draft text, do you agree?.   =
To secure a bit more, the reacting node may then  send a request with =
its own OC Supported-feature AVP, acting as an acknowledgement to the =
reporting node. The reporting node may repeat if needed  or to be more =
secure.
>> There may be some corner cases to investigate more, but I currently =
stop here. =20
>>=20
>> In this use case, I do not see a need  for a sequence number .
>>=20
>> Do you think such an approach is applicable? it will save many checks =
compared to a).
>>=20
>> About c): it is the same principle as in b) but with some periodic  =
=93refresh=94 that may make the a) approach  still more secure. But not =
sure  it is actually needed.
>>=20
>> So do you think the draft should  allow these different  behaviors  =
or only mandate one?
>> Then do you think we need a sequence number for the =
OC-Supported-Features AVP?
>>=20
>>=20
>> B)      Another point also related to the OC-Supported-Features AVP =
and OC-Feature-Vector:
>>=20
>> For example a node can use the default mechanism  and in addition =
support extensions (eg the APN or the session group examples). I would =
think extensions should be advertized by the reacting node , otherwise =
the server does not know if it can use an extension or not, and  a =
server should avoid  to send OLRs that the client will not understand .  =
 =20
>> So here we may have  a set of extensions compatible with the default =
mechanism
>>=20
>> The other example is =93exclusive=94 or not compatible features, for =
example Traffic reduction %control  and rate control. I do not consider  =
a reporting node  will  use both with a reacting node. A reacting node , =
even if it supports both does not want to mix  throttling based on % =
traffic and throttling on rate control with the same reporting node. But =
the current  text does not say anything about which feature is selected =
.
>> I remember that in our initial discussions, the reacting node was =
advertising its features / capabilities and the reporting node was =
selecting the ones it wants to use. Should not we come back to this =
rule? or
>=20
> I would love to come back to this rule where the reporting node picks =
up one common feature. Now the text just mandates that at least one =
feature must be common on both side (and be advertised by both). This =
does not preclude reporting node implementations to do the "select one =
common feature" though. They can advertise back only the one selected =
but they do not have to.. they can add more information on will. IMHO =
this complicates implementations. For example if both ends have three =
common (and advertised) features, the reacting node must be prepared to =
receive OLRs on any of those for the same reporting node in parallel =
(why would the reporting node do so, no idea, but it could based on the =
spec).
>=20
>> do you consider that when we will introduce new features , we will =
introduce statements  to indicate rules on their presence in =
OC-Feature-Vector. Personnaly, I think  the advertisement  followed  by =
selection  was a good approach. Views on this?
>=20
> Agree.
>=20
> - Jouni
>=20
>>=20
>> I have  described this B part  here, as it may have some interaction =
with the  A part.
>>=20
>> Best regards
>>=20
>> JJacques
>>=20
>>=20
>>=20
>>=20
>>=20
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From ben@nostrum.com  Mon Dec 16 13:32:00 2013
Return-Path: 
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 0D1C11AD942 for ; Mon, 16 Dec 2013 13:32:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Level: 
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no
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 yMiUV0910Beu for ; Mon, 16 Dec 2013 13:31:59 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 220AE1AD8EC for ; Mon, 16 Dec 2013 13:31:58 -0800 (PST)
Received: from [172.20.10.7] (mobile-166-147-068-041.mycingular.net [166.147.68.41]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rBGLVr7f096770 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 16 Dec 2013 15:31:54 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Ben Campbell 
In-Reply-To: 
Date: Mon, 16 Dec 2013 15:31:48 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com>  <52A088D0.2020406@usdonovans.com>  <52A091CE.2000104@usdonovans.com> <13081_1386256433_52A09831_13081_8197_1_6B7134B31289DC4FAF! 731D84412 2B36E32B6EB@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B9209739738@ESESSMB101.ericsson.se>  <8FD63E2D-5203-4DA4-A6DA-C4CA181C9CFB@nostrum.com> <26C84DFD55BC3040A45BF70926E55F2587C1D786@SZXEMA512-MBX.china.huawei.com>  <52A86663.30500@usdonovans.com>  <087A34937E64E74E848732CFF8354B920973A82A@ESESSMB101.ericsson.se> <52A8B862.5040207@usdonovans.com> <087A34937E64E74E848732CFF8354B920973AAF5@ESESSMB101.ericsson.se> <52! A9BE1F.7020201@usdonovans.com> 
To: "Nirav Salot (nsalot)" 
X-Mailer: Apple Mail (2.1822)
Received-SPF: pass (shaman.nostrum.com: 166.147.68.41 is authenticated by a trusted mechanism)
Cc: "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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Dec 2013 21:32:00 -0000

On Dec 12, 2013, at 10:36 AM, Nirav Salot (nsalot)  =
wrote:

> As already indicated earlier, by many of us, handling of =
application-Y's data in the application-X's message is not how the =
Diameter applications are designed today. And hence this type of =
proposal requires architectural support for handling it. And there lies =
the complexity.
> This main drawback was highlighted earlier as well but was =
conveniently ignored while preparing the pros and cons list for the =
self-contained OLR.
> =20

As I have argued in the past, I don't think overload reports are =
application data. They are protocol data.=

From maria.cruz.bartolome@ericsson.com  Mon Dec 16 13:34:47 2013
Return-Path: 
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 3EBAC1ADED5 for ; Mon, 16 Dec 2013 13:34:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.851
X-Spam-Level: 
X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 5dIRY4bUeKRx for ; Mon, 16 Dec 2013 13:34:45 -0800 (PST)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id CE4091A1F1B for ; Mon, 16 Dec 2013 13:34:44 -0800 (PST)
X-AuditID: c1b4fb2d-b7f1c8e000005ceb-3b-52af71f2365c
Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id DB.77.23787.2F17FA25; Mon, 16 Dec 2013 22:34:43 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.73]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.02.0347.000; Mon, 16 Dec 2013 22:34:32 +0100
From: Maria Cruz Bartolome 
To: Ben Campbell 
Thread-Topic: [Dime] OVLI: OC-Validity-Duration
Thread-Index: Ac73DRNgVjMdaw2ATnC3EBEvo4YB4gAABXsAABLFinAA0EgEAAADM9cA
Date: Mon, 16 Dec 2013 21:34:31 +0000
Message-ID: <087A34937E64E74E848732CFF8354B920975660A@ESESSMB101.ericsson.se>
References: <087A34937E64E74E848732CFF8354B920973AB4B@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B920973AF29@ESESSMB101.ericsson.se> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.150]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+Jvre7nwvVBBpNncljM7zzNbjG3dwWb xf51DUwOzB47Z91l91iy5CeTx6ydT1gCmKO4bFJSczLLUov07RK4Mg5tP8pS0CRd8bP9AFMD 4yvRLkZODgkBE4n3W/4xQdhiEhfurWfrYuTiEBI4xCgxo+kHC4SzmFFiV8dndpAqNgE7iUun X4B1iAgoSTxv3soCYjML+Egsv74QyObgEBbQk7h9SB+iRF9i04QLLBC2m0TntLlsIDaLgKrE +8tHwUbyCvhKLP+6mwli109Gickb3zKBzOEUsJd4c4QVpIYR6Ljvp9YwQawSl7j1ZD7U0QIS S/acZ4awRSVePv7HCmErSazYfokRol5HYsHuT2wQtrbEsoWvmSH2CkqcnPmEZQKj2CwkY2ch aZmFpGUWkpYFjCyrGNlzEzNz0ssNNzEC4+bglt+6OxhPnRM5xCjNwaIkzvvhrXOQkEB6Yklq dmpqQWpRfFFpTmrxIUYmDk6pBsbai6u5XvXnVn7Z4GOQ8NToavSiDUIBD/ROJE0NeSiq/+BR 3dZ1j2+dz6hUWLlohlr2yU1rLx0peXiXqW1ezob315jly2d7qnLwsP1tezlNZZf2pBfhmcVN Chtzjuy9yn+qt6nCbNYKjomrTbymP9wgVn1zZxxXVlDLhDdtvZu28v351L1r61V5JZbijERD Leai4kQAedvG/mkCAAA=
Cc: "dime@ietf.org" 
Subject: Re: [Dime] OVLI: OC-Validity-Duration
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Dec 2013 21:34:47 -0000

Ben,

But does a reporting node need to send a Validity-Duration AVP in each mess=
age if this is just going to be used for clean-up purposes? Even more if we=
 think it could be a pre-configured default value?

/MCruz


-----Original Message-----
From: Ben Campbell [mailto:ben@nostrum.com]=20
Sent: lunes, 16 de diciembre de 2013 22:00
To: Maria Cruz Bartolome
Cc: Jouni Korhonen; dime@ietf.org
Subject: Re: [Dime] OVLI: OC-Validity-Duration


On Dec 12, 2013, at 10:38 AM, Maria Cruz Bartolome  wrote:

> Jouni,
>=20
> I think the best way to manage "something unpredictable" is not to provid=
e an estimation (on an unpredictable event) from the server.
> If you really think that scheduled cleanups are helpful, this could alway=
s be considered in the client, with a default value, that does not need to =
be sent from the reporting node.

The point is not for the reporting node to predict how long it's likely to =
be overloaded, it's to make sure things get cleaned up if some _other_ unpr=
edictable event occurs. The idea is to set a time out so that, if the react=
ing node doesn't see an update in some period of time, it can discard the s=
tate. Otherwise, it could assume the overload condition to last forever. It=
's up to the implementation, but typically you choose your validity times t=
o balance how long you are willing to let an expired report "hang" vs how m=
any "update" messages you are willing to tolerate. I think it will be typic=
al that servers choose a fixed timeout value (possibly configured) for all =
reports.

Soft state like this is a well known protocol design pattern used in many I=
ETF protocols. The idea is that, if some failure occurs so that the recipie=
nt fails to get an update, the problem eventually expires, and heals itself=
.

>=20
> Regards
> /MCrzu
>=20
> -----Original Message-----
> From: Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
> Sent: jueves, 12 de diciembre de 2013 9:39
> To: Maria Cruz Bartolome
> Cc: dime@ietf.org
> Subject: Re: [Dime] OVLI: OC-Validity-Duration
>=20
> Hi,
>=20
> I kind of like scheduled cleanups.. just to make sure there is no
> stuff left hanging around when something unpredictable happens in
> the network system.
>=20
> Again, I would say this is a wrong place to "optimize".
>=20
>=20
> - Jouni
>=20
> On Dec 12, 2013, at 9:53 AM, Maria Cruz Bartolome  wrote:
>=20
>> Dear all,
>>=20
>> I would like to reconsider the real need for the OC-Validity-Duration AV=
P to be included into overload report.
>> Overload mechanism is being design with a principle in mind: as soon as =
reporting node determines a reacting node overload behavior should change, =
reporting node sends a fresh overload report to this reacting node.
>> Therefore, latest overload report received will be always applicable unt=
il a new report is received, and then I do not see the value, but just comp=
lexity, of including a Duration in the report.
>>=20
>> Let me know your views.
>> Best regards
>> /MCruz
>>=20
>>=20
>>=20
>>=20
>>=20
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From ben@nostrum.com  Mon Dec 16 13:35:05 2013
Return-Path: 
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 998531ADED5 for ; Mon, 16 Dec 2013 13:35:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Level: 
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no
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 LpoC68Vsm4sV for ; Mon, 16 Dec 2013 13:35:04 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id C45071ADE84 for ; Mon, 16 Dec 2013 13:35:04 -0800 (PST)
Received: from [172.20.10.7] (mobile-166-147-068-041.mycingular.net [166.147.68.41]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rBGLZ0Am096847 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 16 Dec 2013 15:35:01 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Ben Campbell 
In-Reply-To: <52AF264E.9070304@usdonovans.com>
Date: Mon, 16 Dec 2013 15:34:54 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <8933972A-65A8-4EBC-8FAA-7DC64EEE808A@nostrum.com>
References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <13081_1386256433_52A09831_13081_8197_1_6B7134B31289DC4FAF! 731D84412 2B36E32B6EB@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B9209739738@ESESSMB101.ericsson.se>  <8FD63E2D-5203-4DA4-A6DA-C4CA181C9CFB@nostrum.com> <26C84DFD55BC3040A45BF70926E55F2587C1D786@SZXEMA512-MBX.china.huawei.com>  <52A86663.30500@usdonovans.com>  <087A34937E64E74E848732CFF8354B920973A82A@ESESSMB101.ericsson.se> <52A8B862.5040207@usdonovans.com> <087A34937E64E74E848732CFF8354B920973AAF5@ESESSMB101.ericsson.se> <52A9BE1F.7020201@usdonovans.com>  <52AEFED7.5060908@usdonovans.com>  <52! AF264E.9070304@usdonovans.com>
To: Steve Donovan 
X-Mailer: Apple Mail (2.1822)
Received-SPF: pass (shaman.nostrum.com: 166.147.68.41 is authenticated by a trusted mechanism)
Cc: "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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Dec 2013 21:35:05 -0000

On Dec 16, 2013, at 10:11 AM, Steve Donovan  =
wrote:

> There is nothing in the self-contained overload report proposal the =
requires cross-application data handling.  An implementation can take =
advantage of cross-application information if it is able and wants to, =
but it is not required to do so.

I'm not sure I agree on that point. If an endpoint that _supports_ =
application Y receives a report _about_ application Y, it needs to honor =
that report regardless of what what application the enclosing Diameter =
message was tied to. (This is part of why I've commented in the past =
that I think overload reports are protocol data.)



From ben@nostrum.com  Mon Dec 16 13:37:01 2013
Return-Path: 
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 AB7531ADBCD for ; Mon, 16 Dec 2013 13:37:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Level: 
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no
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 G_Ea7InEBsnp for ; Mon, 16 Dec 2013 13:37:00 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 53D671A1F1B for ; Mon, 16 Dec 2013 13:37:00 -0800 (PST)
Received: from [172.20.10.7] (mobile-166-147-068-041.mycingular.net [166.147.68.41]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rBGLathl097007 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 16 Dec 2013 15:36:56 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Ben Campbell 
In-Reply-To: <087A34937E64E74E848732CFF8354B920975660A@ESESSMB101.ericsson.se>
Date: Mon, 16 Dec 2013 15:36:50 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <087A34937E64E74E848732CFF8354B920973AB4B@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B920973AF29@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B920975660A@ESESSMB101.ericsson.se>
To: Maria Cruz Bartolome 
X-Mailer: Apple Mail (2.1822)
Received-SPF: pass (shaman.nostrum.com: 166.147.68.41 is authenticated by a trusted mechanism)
Cc: "dime@ietf.org" 
Subject: Re: [Dime] OVLI: OC-Validity-Duration
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Dec 2013 21:37:01 -0000

On Dec 16, 2013, at 3:34 PM, Maria Cruz Bartolome =
 wrote:

> Ben,
>=20
> But does a reporting node need to send a Validity-Duration AVP in each =
message if this is just going to be used for clean-up purposes? Even =
more if we think it could be a pre-configured default value?

I think it is a pre-configured value at the reporting node. But it still =
needs to be communicated to the receiving node. (You really _don't_ want =
to have to configure it for both, and keep the configuration in sync =
between them.)

This is exactly like how the Expires header works for SIP.

>=20
> /MCruz
>=20
>=20
> -----Original Message-----
> From: Ben Campbell [mailto:ben@nostrum.com]=20
> Sent: lunes, 16 de diciembre de 2013 22:00
> To: Maria Cruz Bartolome
> Cc: Jouni Korhonen; dime@ietf.org
> Subject: Re: [Dime] OVLI: OC-Validity-Duration
>=20
>=20
> On Dec 12, 2013, at 10:38 AM, Maria Cruz Bartolome =
 wrote:
>=20
>> Jouni,
>>=20
>> I think the best way to manage "something unpredictable" is not to =
provide an estimation (on an unpredictable event) from the server.
>> If you really think that scheduled cleanups are helpful, this could =
always be considered in the client, with a default value, that does not =
need to be sent from the reporting node.
>=20
> The point is not for the reporting node to predict how long it's =
likely to be overloaded, it's to make sure things get cleaned up if some =
_other_ unpredictable event occurs. The idea is to set a time out so =
that, if the reacting node doesn't see an update in some period of time, =
it can discard the state. Otherwise, it could assume the overload =
condition to last forever. It's up to the implementation, but typically =
you choose your validity times to balance how long you are willing to =
let an expired report "hang" vs how many "update" messages you are =
willing to tolerate. I think it will be typical that servers choose a =
fixed timeout value (possibly configured) for all reports.
>=20
> Soft state like this is a well known protocol design pattern used in =
many IETF protocols. The idea is that, if some failure occurs so that =
the recipient fails to get an update, the problem eventually expires, =
and heals itself.
>=20
>>=20
>> Regards
>> /MCrzu
>>=20
>> -----Original Message-----
>> From: Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
>> Sent: jueves, 12 de diciembre de 2013 9:39
>> To: Maria Cruz Bartolome
>> Cc: dime@ietf.org
>> Subject: Re: [Dime] OVLI: OC-Validity-Duration
>>=20
>> Hi,
>>=20
>> I kind of like scheduled cleanups.. just to make sure there is no
>> stuff left hanging around when something unpredictable happens in
>> the network system.
>>=20
>> Again, I would say this is a wrong place to "optimize".
>>=20
>>=20
>> - Jouni
>>=20
>> On Dec 12, 2013, at 9:53 AM, Maria Cruz Bartolome =
 wrote:
>>=20
>>> Dear all,
>>>=20
>>> I would like to reconsider the real need for the =
OC-Validity-Duration AVP to be included into overload report.
>>> Overload mechanism is being design with a principle in mind: as soon =
as reporting node determines a reacting node overload behavior should =
change, reporting node sends a fresh overload report to this reacting =
node.
>>> Therefore, latest overload report received will be always applicable =
until a new report is received, and then I do not see the value, but =
just complexity, of including a Duration in the report.
>>>=20
>>> Let me know your views.
>>> Best regards
>>> /MCruz
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>> _______________________________________________
>>> DiME mailing list
>>> DiME@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dime
>>=20
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From ben@nostrum.com  Mon Dec 16 13:38:57 2013
Return-Path: 
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 E20B11ADBCD for ; Mon, 16 Dec 2013 13:38:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Level: 
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no
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 kyWCOh40hKun for ; Mon, 16 Dec 2013 13:38:56 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id B350E1ADEC0 for ; Mon, 16 Dec 2013 13:38:56 -0800 (PST)
Received: from [172.20.10.7] (mobile-166-147-068-041.mycingular.net [166.147.68.41]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rBGLcmos097044 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 16 Dec 2013 15:38:49 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Ben Campbell 
In-Reply-To: <087A34937E64E74E848732CFF8354B920975651D@ESESSMB101.ericsson.se>
Date: Mon, 16 Dec 2013 15:38:43 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <70089680-BBFD-4E4C-B550-30FEAB5C611C@gmail.com> <087A34937E64E74E848732CFF8354B920975651D@ESESSMB101.ericsson.se>
To: Maria Cruz Bartolome 
X-Mailer: Apple Mail (2.1822)
Received-SPF: pass (shaman.nostrum.com: 166.147.68.41 is authenticated by a trusted mechanism)
Cc: "dime@ietf.org list" 
Subject: Re: [Dime] Submission of draft-ietf-dime-ovli-01
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Dec 2013 21:38:58 -0000

I agree with submitting 01.=20

I disagree about removing controversial text, although I don't mind =
marking it as controversial. But I think it would be a better approach =
would be to take 01 as a baseline and start putting open issues in the =
issue tracker.

On Dec 16, 2013, at 10:50 AM, Maria Cruz Bartolome =
 wrote:

> Hello Jouni, all,
>=20
> We got some open discussion without any conclusion yet, if you prefer =
to publish .01 version, I would suggest these open issues are properly =
covered there, or all related text is omitted.
> Cheers
> /MCruz
>=20
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen
> Sent: lunes, 16 de diciembre de 2013 17:47
> To: dime@ietf.org list
> Subject: [Dime] Submission of draft-ietf-dime-ovli-01
>=20
> Folks,
>=20
> I am somewhat tempted to publish -01 even if we still have some very =
rough edges and then continue from there. Any strong disagreements?
>=20
> The place we lack text more or less entirely is Section 5.5.3. (for a =
reason) but will type in something later tonight (or so).
>=20
> - Jouni
>=20
> _______________________________________________
> 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


From jouni.nospam@gmail.com  Mon Dec 16 13:50:41 2013
Return-Path: 
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 E92CA1ADEA6 for ; Mon, 16 Dec 2013 13:50:40 -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 AW8kw3KcHI1s for ; Mon, 16 Dec 2013 13:50:38 -0800 (PST)
Received: from mail-bk0-x234.google.com (mail-bk0-x234.google.com [IPv6:2a00:1450:4008:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 587AE1ADF0F for ; Mon, 16 Dec 2013 13:50:38 -0800 (PST)
Received: by mail-bk0-f52.google.com with SMTP id u14so2509880bkz.25 for ; Mon, 16 Dec 2013 13:50:37 -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=ULb5gcRPsVCT9aO1qfV07g5u4ebUJqsC/X9KS5fzjec=; b=fROeMtS+GCV39rubu4wULxaHQFMBBwXtfp1wT69BePLYutl5NprityNwon9Kd096en xltu8+Cnd7x9h3si87bNqrfTSVQ0CiCd/WTGjGnKR/Bi7Dhq+OR/muaaEALqUxtSXrdt JDA9wM+gyWCMUu8hx8wkgvLY0kuVjcoXeFQRbjDHMyA8ionUji7C6bw8ZPOQznZ9Y7Al puekSzqttzP42uEXj77ggZaoxcVIbSMn5y2yV6Qqjfuw+GyjbbUSl9Ds7sSabpapW+gW B0j5EOBt/wreu0KX0K4QKe3tMBcITooSc4aFpGHZUuEmdPqt8rje7ZiwjVeWujP2wk+1 c1Jw==
X-Received: by 10.205.20.132 with SMTP id qo4mr74087bkb.110.1387230637003; Mon, 16 Dec 2013 13:50:37 -0800 (PST)
Received: from ?IPv6:2001:1bc8:101:f101:71c6:4907:507a:5262? ([2001:1bc8:101:f101:71c6:4907:507a:5262]) by mx.google.com with ESMTPSA id xm9sm11635258bkb.1.2013.12.16.13.50.36 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 16 Dec 2013 13:50:36 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jouni Korhonen 
In-Reply-To: 
Date: Mon, 16 Dec 2013 23:50:35 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <70089680-BBFD-4E4C-B550-30FEAB5C611C@gmail.com> <087A34937E64E74E848732CFF8354B920975651D@ESESSMB101.ericsson.se> 
To: Ben Campbell 
X-Mailer: Apple Mail (2.1510)
Cc: "dime@ietf.org list" 
Subject: Re: [Dime] Submission of draft-ietf-dime-ovli-01
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Dec 2013 21:50:41 -0000

On Dec 16, 2013, at 11:38 PM, Ben Campbell  wrote:

> I agree with submitting 01.=20
>=20
> I disagree about removing controversial text, although I don't mind =
marking it as controversial. But I think it would be a better approach =
would be to take 01 as a baseline and start putting open issues in the =
issue tracker.

+1=20

Issue tracker would make this stuff somewhat more manageable.. and since =
we got a WG doc, issue tracker works just fine.

- Jouni


>=20
> On Dec 16, 2013, at 10:50 AM, Maria Cruz Bartolome =
 wrote:
>=20
>> Hello Jouni, all,
>>=20
>> We got some open discussion without any conclusion yet, if you prefer =
to publish .01 version, I would suggest these open issues are properly =
covered there, or all related text is omitted.
>> Cheers
>> /MCruz
>>=20
>> -----Original Message-----
>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen
>> Sent: lunes, 16 de diciembre de 2013 17:47
>> To: dime@ietf.org list
>> Subject: [Dime] Submission of draft-ietf-dime-ovli-01
>>=20
>> Folks,
>>=20
>> I am somewhat tempted to publish -01 even if we still have some very =
rough edges and then continue from there. Any strong disagreements?
>>=20
>> The place we lack text more or less entirely is Section 5.5.3. (for a =
reason) but will type in something later tonight (or so).
>>=20
>> - Jouni
>>=20
>> _______________________________________________
>> 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
>=20


From srdonovan@usdonovans.com  Mon Dec 16 14:02:23 2013
Return-Path: 
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 CDEE61A1F02 for ; Mon, 16 Dec 2013 14:02:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level: 
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no
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 0n-DNm-AFNvB for ; Mon, 16 Dec 2013 14:02:23 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 43DCA1A1DBD for ; Mon, 16 Dec 2013 14:02:23 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:63397 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1VsgF2-0008Ha-O1; Mon, 16 Dec 2013 14:02:21 -0800
Message-ID: <52AF786B.30100@usdonovans.com>
Date: Mon, 16 Dec 2013 16:02:19 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Ben Campbell 
References: <832D36A4-E2D5-4640-A8D5-F9B3EEDBC56A@nostrum.com> <087A34937E64E74E848732CFF8354B9209739738@ESESSMB101.ericsson.se>  <8FD63E2D-5203-4DA4-A6DA-C4CA181C9CFB@nostrum.com> <26C84DFD55BC3040A45BF70926E55F2587C1D786@SZXEMA512-MBX.china.huawei.com>  <52A86663.30500@usdonovans.com>  <087A34937E64E74E848732CFF8354B920973A82A@ESESSMB101.ericsson.se> <52A8B862.5040207@usdonovans.com> <087A34937E64E74E848732CFF8354B920973AAF5@ESESSMB101.ericsson.se> <52A9BE1F.7020201@usdonovans.com>  <52AEFED7.5060908@usdonovans.com>  <52! AF264E.9070304@usdonovans.com> <8933972A-65A8-4EBC-8FAA-7DC64EEE808A@nostrum.com>
In-Reply-To: <8933972A-65A8-4EBC-8FAA-7DC64EEE808A@nostrum.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-OutGoing-Spam-Status: No, score=-2.6
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com
Cc: "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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Dec 2013 22:02:23 -0000

On 12/16/13 3:34 PM, Ben Campbell wrote:
> On Dec 16, 2013, at 10:11 AM, Steve Donovan  wrote:
>
>> There is nothing in the self-contained overload report proposal the requires cross-application data handling.  An implementation can take advantage of cross-application information if it is able and wants to, but it is not required to do so.
> I'm not sure I agree on that point. If an endpoint that _supports_ application Y receives a report _about_ application Y, it needs to honor that report regardless of what what application the enclosing Diameter message was tied to. (This is part of why I've commented in the past that I think overload reports are protocol data.)
>
I agree that it SHOULD, I don't see how we can make it a MUST.
>


From jouni.nospam@gmail.com  Mon Dec 16 14:02:33 2013
Return-Path: 
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 2237F1ACCD9 for ; Mon, 16 Dec 2013 14:02:33 -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 qakYfHR4G_qN for ; Mon, 16 Dec 2013 14:02:31 -0800 (PST)
Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) by ietfa.amsl.com (Postfix) with ESMTP id E66581A1F3E for ; Mon, 16 Dec 2013 14:02:30 -0800 (PST)
Received: by mail-lb0-f180.google.com with SMTP id x18so1089455lbi.25 for ; Mon, 16 Dec 2013 14:02:29 -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=lQdDhcbpf1MbKwCxt1d1FSHvhxyiYhSUwmwfzRI/o1E=; b=MTe9lYFk9CeHShlwWCLauuZ/y7iYsSko/7ug+xfum0pWVTbAHd1EzUR/wJ2ToosNGz UgYijXQg0VhE7Uitq4uOd/QdpJyyLAF5/vEJ4lsTu90d2VDISxsiidrjNO/IrSBlToVe tGk4NB8IatQneZgBTlu2XQTUrwEr6fF8DgOFXf1AQOLXX8Uh9yV5c1UqRKo2JqN9h7WO 1E6UTn2NBmNGKuFvwXX2kfXsV564z/Lccl+Z0PvyZbJWumbgWEDirPo21h4eFVILZSGC 42PANgVsl9ZqoGFF7eLuj9yvye2rx1HktL4IhYv6hPcQ4c47xgXHsdYcmaPcVMFWhyX/ FInQ==
X-Received: by 10.152.116.46 with SMTP id jt14mr7739014lab.31.1387231349426; Mon, 16 Dec 2013 14:02:29 -0800 (PST)
Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id e6sm10967749lbs.3.2013.12.16.14.02.24 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 16 Dec 2013 14:02:25 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jouni Korhonen 
In-Reply-To: <087A34937E64E74E848732CFF8354B920975660A@ESESSMB101.ericsson.se>
Date: Tue, 17 Dec 2013 00:02:24 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <02C20B51-F92F-4F16-A282-2069808DD7F6@gmail.com>
References: <087A34937E64E74E848732CFF8354B920973AB4B@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B920973AF29@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B920975660A@ESESSMB101.ericsson.se>
To: Maria Cruz Bartolome 
X-Mailer: Apple Mail (2.1510)
Cc: Ben Campbell , "dime@ietf.org" 
Subject: Re: [Dime] OVLI: OC-Validity-Duration
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Dec 2013 22:02:33 -0000

On Dec 16, 2013, at 11:34 PM, Maria Cruz Bartolome =
 wrote:

> Ben,
>=20
> But does a reporting node need to send a Validity-Duration AVP in each =
message if this is just going to be used for clean-up purposes? Even =
more if we think it could be a pre-configured default value?

Typically in a "client-server" communication, like we have here, the =
server decides and the client obeys. Less places to configure =
something..=20

- Jouni


>=20
> /MCruz
>=20
>=20
> -----Original Message-----
> From: Ben Campbell [mailto:ben@nostrum.com]=20
> Sent: lunes, 16 de diciembre de 2013 22:00
> To: Maria Cruz Bartolome
> Cc: Jouni Korhonen; dime@ietf.org
> Subject: Re: [Dime] OVLI: OC-Validity-Duration
>=20
>=20
> On Dec 12, 2013, at 10:38 AM, Maria Cruz Bartolome =
 wrote:
>=20
>> Jouni,
>>=20
>> I think the best way to manage "something unpredictable" is not to =
provide an estimation (on an unpredictable event) from the server.
>> If you really think that scheduled cleanups are helpful, this could =
always be considered in the client, with a default value, that does not =
need to be sent from the reporting node.
>=20
> The point is not for the reporting node to predict how long it's =
likely to be overloaded, it's to make sure things get cleaned up if some =
_other_ unpredictable event occurs. The idea is to set a time out so =
that, if the reacting node doesn't see an update in some period of time, =
it can discard the state. Otherwise, it could assume the overload =
condition to last forever. It's up to the implementation, but typically =
you choose your validity times to balance how long you are willing to =
let an expired report "hang" vs how many "update" messages you are =
willing to tolerate. I think it will be typical that servers choose a =
fixed timeout value (possibly configured) for all reports.
>=20
> Soft state like this is a well known protocol design pattern used in =
many IETF protocols. The idea is that, if some failure occurs so that =
the recipient fails to get an update, the problem eventually expires, =
and heals itself.
>=20
>>=20
>> Regards
>> /MCrzu
>>=20
>> -----Original Message-----
>> From: Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
>> Sent: jueves, 12 de diciembre de 2013 9:39
>> To: Maria Cruz Bartolome
>> Cc: dime@ietf.org
>> Subject: Re: [Dime] OVLI: OC-Validity-Duration
>>=20
>> Hi,
>>=20
>> I kind of like scheduled cleanups.. just to make sure there is no
>> stuff left hanging around when something unpredictable happens in
>> the network system.
>>=20
>> Again, I would say this is a wrong place to "optimize".
>>=20
>>=20
>> - Jouni
>>=20
>> On Dec 12, 2013, at 9:53 AM, Maria Cruz Bartolome =
 wrote:
>>=20
>>> Dear all,
>>>=20
>>> I would like to reconsider the real need for the =
OC-Validity-Duration AVP to be included into overload report.
>>> Overload mechanism is being design with a principle in mind: as soon =
as reporting node determines a reacting node overload behavior should =
change, reporting node sends a fresh overload report to this reacting =
node.
>>> Therefore, latest overload report received will be always applicable =
until a new report is received, and then I do not see the value, but =
just complexity, of including a Duration in the report.
>>>=20
>>> Let me know your views.
>>> Best regards
>>> /MCruz
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>> _______________________________________________
>>> DiME mailing list
>>> DiME@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dime
>>=20
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>=20


From srdonovan@usdonovans.com  Mon Dec 16 14:04:07 2013
Return-Path: 
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 9A0E31A1F55 for ; Mon, 16 Dec 2013 14:04:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.12
X-Spam-Level: 
X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no
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 2vGIYkxKBTAy for ; Mon, 16 Dec 2013 14:04:06 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 2E2F51A82E2 for ; Mon, 16 Dec 2013 14:04:06 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:63401 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1VsgGh-0002WB-KD for dime@ietf.org; Mon, 16 Dec 2013 14:04:04 -0800
Message-ID: <52AF78D3.2060506@usdonovans.com>
Date: Mon, 16 Dec 2013 16:04:03 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: dime@ietf.org
References: <70089680-BBFD-4E4C-B550-30FEAB5C611C@gmail.com> <087A34937E64E74E848732CFF8354B920975651D@ESESSMB101.ericsson.se>  
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------000403080301050601080901"
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com
Subject: Re: [Dime] Submission of draft-ietf-dime-ovli-01
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Dec 2013 22:04:07 -0000

This is a multi-part message in MIME format.
--------------000403080301050601080901
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

+1
On 12/16/13 3:50 PM, Jouni Korhonen wrote:
> On Dec 16, 2013, at 11:38 PM, Ben Campbell  wrote:
>
>> I agree with submitting 01. 
>>
>> I disagree about removing controversial text, although I don't mind marking it as controversial. But I think it would be a better approach would be to take 01 as a baseline and start putting open issues in the issue tracker.
> +1 
>
> Issue tracker would make this stuff somewhat more manageable.. and since we got a WG doc, issue tracker works just fine.
>
> - Jouni
>
>
>> On Dec 16, 2013, at 10:50 AM, Maria Cruz Bartolome  wrote:
>>
>>> Hello Jouni, all,
>>>
>>> We got some open discussion without any conclusion yet, if you prefer to publish .01 version, I would suggest these open issues are properly covered there, or all related text is omitted.
>>> Cheers
>>> /MCruz
>>>
>>> -----Original Message-----
>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen
>>> Sent: lunes, 16 de diciembre de 2013 17:47
>>> To: dime@ietf.org list
>>> Subject: [Dime] Submission of draft-ietf-dime-ovli-01
>>>
>>> Folks,
>>>
>>> I am somewhat tempted to publish -01 even if we still have some very rough edges and then continue from there. Any strong disagreements?
>>>
>>> The place we lack text more or less entirely is Section 5.5.3. (for a reason) but will type in something later tonight (or so).
>>>
>>> - Jouni
>>>
>>> _______________________________________________
>>> 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
>


--------------000403080301050601080901
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    +1

    
On 12/16/13 3:50 PM, Jouni Korhonen
      wrote:

    

    

      
On Dec 16, 2013, at 11:38 PM, Ben Campbell <ben@nostrum.com> wrote:



      

        
I agree with submitting 01. 

I disagree about removing controversial text, although I don't mind marking it as controversial. But I think it would be a better approach would be to take 01 as a baseline and start putting open issues in the issue tracker.


      

      
+1 

Issue tracker would make this stuff somewhat more manageable.. and since we got a WG doc, issue tracker works just fine.

- Jouni




      

        
On Dec 16, 2013, at 10:50 AM, Maria Cruz Bartolome <maria.cruz.bartolome@ericsson.com> wrote:



        

          
Hello Jouni, all,

We got some open discussion without any conclusion yet, if you prefer to publish .01 version, I would suggest these open issues are properly covered there, or all related text is omitted.
Cheers
/MCruz

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen
Sent: lunes, 16 de diciembre de 2013 17:47
To: dime@ietf.org list
Subject: [Dime] Submission of draft-ietf-dime-ovli-01

Folks,

I am somewhat tempted to publish -01 even if we still have some very rough edges and then continue from there. Any strong disagreements?

The place we lack text more or less entirely is Section 5.5.3. (for a reason) but will type in something later tonight (or so).

- Jouni

_______________________________________________
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



    

    

  


--------------000403080301050601080901--

From md3135@att.com  Mon Dec 16 14:15:43 2013
Return-Path: 
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 D7BE81AD8E1 for ; Mon, 16 Dec 2013 14:15:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.737
X-Spam-Level: 
X-Spam-Status: No, score=-4.737 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538] 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 dbMr1Uq6iSpe for ; Mon, 16 Dec 2013 14:15:41 -0800 (PST)
Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id 0BE6F1AD7C5 for ; Mon, 16 Dec 2013 14:15:40 -0800 (PST)
Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id c8b7fa25.0.4516137.00-2071.12609159.nbfkord-smmo06.seg.att.com (envelope-from );  Mon, 16 Dec 2013 22:15:40 +0000 (UTC)
X-MXL-Hash: 52af7b8c07450bde-d32c537c8100fed4d70be19f1e3868159c4eee05
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id rBGMFd9C005340; Mon, 16 Dec 2013 17:15:39 -0500
Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id rBGMFWej005215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Dec 2013 17:15:35 -0500
Received: from MISOUT7MSGHUB9D.ITServices.sbc.com (MISOUT7MSGHUB9D.itservices.sbc.com [144.151.223.93]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Mon, 16 Dec 2013 22:15:18 GMT
Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9D.ITServices.sbc.com ([144.151.223.93]) with mapi id 14.03.0158.001; Mon, 16 Dec 2013 17:15:18 -0500
From: "DOLLY, MARTIN C" 
To: Steve Donovan 
Thread-Topic: [Dime] Submission of draft-ietf-dime-ovli-01
Thread-Index: AQHO+qdAROROh2btzU6TgZiRdghkpppXsDaAgAADw4D//69S2w==
Date: Mon, 16 Dec 2013 22:15:17 +0000
Message-ID: 
References: <70089680-BBFD-4E4C-B550-30FEAB5C611C@gmail.com> <087A34937E64E74E848732CFF8354B920975651D@ESESSMB101.ericsson.se>  , <52AF78D3.2060506@usdonovans.com>
In-Reply-To: <52AF78D3.2060506@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_BEC8A69475B44CB4B875C3D7DC52C7B5attcom_"
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-AnalysisOut: [v=2.0 cv=KeZlR3kD c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a]
X-AnalysisOut: [=sWlxvq5nJ24A:10 a=ofMgfj31e3cA:10 a=BLceEmwcHowA:10 a=zQP]
X-AnalysisOut: [7CpKOAAAA:8 a=KlJXIuD6BQwA:10 a=yakATiurAAAA:8 a=Z80JlwQ0A]
X-AnalysisOut: [AAA:8 a=0FD05c-RAAAA:8 a=48vgC7mUAAAA:8 a=lIIKv8pXcx8cCrZa]
X-AnalysisOut: [RrMA:9 a=CjuIK1q_8ugA:10 a=qM39cor4HRgA:10 a=Hz7IrDYlS0cA:]
X-AnalysisOut: [10 a=BMZHtSBzE-QA:10 a=0MAqpqVwYqEA:10 a=f7GxY0FH8QIA:10 a]
X-AnalysisOut: [=lZB815dzVvQA:10 a=VoFctKSfOFJWXRb2:21 a=bXnjBA5BIOxqLEXN:]
X-AnalysisOut: [21 a=pGLkceISAAAA:8 a=_W_S_7VecoQA:10 a=MSl-tDqOz04A:10 a=]
X-AnalysisOut: [f-u9NA7JlfjjdNqE:21 a=aSEf5SwRO4ckoXdm:21 a=Qf7aqBCyVaDh30]
X-AnalysisOut: [OV:21]
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)]
X-MAIL-FROM: 
X-SOURCE-IP: [144.160.229.24]
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Submission of draft-ietf-dime-ovli-01
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Dec 2013 22:15:44 -0000

--_000_BEC8A69475B44CB4B875C3D7DC52C7B5attcom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Issue tracker is fine with a note at the  relevant spot making reference to=
 the issue number

Martin Dolly
Lead Member of Technical Staff
Core Network & Gov't/Regulatory Standards
AT&T Standards and Industry Alliances
+1-609-903-3360
md3135@att.com

On Dec 16, 2013, at 5:04 PM, "Steve Donovan" > wrote:

+1
On 12/16/13 3:50 PM, Jouni Korhonen wrote:

On Dec 16, 2013, at 11:38 PM, Ben Campbell  wrote:



I agree with submitting 01.

I disagree about removing controversial text, although I don't mind marking=
 it as controversial. But I think it would be a better approach would be to=
 take 01 as a baseline and start putting open issues in the issue tracker.


+1

Issue tracker would make this stuff somewhat more manageable.. and since we=
 got a WG doc, issue tracker works just fine.

- Jouni




On Dec 16, 2013, at 10:50 AM, Maria Cruz Bartolome  wrote:



Hello Jouni, all,

We got some open discussion without any conclusion yet, if you prefer to pu=
blish .01 version, I would suggest these open issues are properly covered t=
here, or all related text is omitted.
Cheers
/MCruz

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen
Sent: lunes, 16 de diciembre de 2013 17:47
To: dime@ietf.org list
Subject: [Dime] Submission of draft-ietf-dime-ovli-01

Folks,

I am somewhat tempted to publish -01 even if we still have some very rough =
edges and then continue from there. Any strong disagreements?

The place we lack text more or less entirely is Section 5.5.3. (for a reaso=
n) but will type in something later tonight (or so).

- Jouni

_______________________________________________
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

--_000_BEC8A69475B44CB4B875C3D7DC52C7B5attcom_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable







Issue tracker is fine with a note at the  relevant spot making re=
ference to the issue number





Martin Dolly


Lead Member of Technical Staff


Core Network & Gov't/Regulatory Standards  


AT&T Standards and Industry Alliances


+1-609-903-3360







On Dec 16, 2013, at 5:04 PM, "Steve Donovan" <srdonovan@usdonovans.com> wrote:








+1


On 12/16/13 3:50 PM, Jouni Korhonen wrote:





On Dec 16, 2013, at 11:38 PM, Ben Campbell <ben@nostrum.com> wrote:






I agree with submitting 01.=20

I disagree about removing controversial text, although I don't mind marking=
 it as controversial. But I think it would be a better approach would be to=
 take 01 as a baseline and start putting open issues in the issue tracker.





+1=20

Issue tracker would make this stuff somewhat more manageable.. and since we=
 got a WG doc, issue tracker works just fine.

- Jouni







On Dec 16, 2013, at 10:50 AM, Maria Cruz Bartolome <maria.cruz.bartolome@ericsson.com> wrote:






Hello Jouni, all,

We got some open discussion without any conclusion yet, if you prefer to pu=
blish .01 version, I would suggest these open issues are properly covered t=
here, or all related text is omitted.
Cheers
/MCruz

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen
Sent: lunes, 16 de diciembre de 2013 17:47
To: dim=
e@ietf.org list
Subject: [Dime] Submission of draft-ietf-dime-ovli-01

Folks,

I am somewhat tempted to publish -01 even if we still have some very rough =
edges and then continue from there. Any strong disagreements?

The place we lack text more or less entirely is Section 5.5.3. (for a reaso=
n) but will type in something later tonight (or so).

- Jouni

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









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














_______________________________________________

DiME mailing list

DiME@ietf.org

https://www.ie=
tf.org/mailman/listinfo/dime








--_000_BEC8A69475B44CB4B875C3D7DC52C7B5attcom_--

From jouni.nospam@gmail.com  Mon Dec 16 14:29:21 2013
Return-Path: 
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 3C14E1ADF38 for ; Mon, 16 Dec 2013 14:29:21 -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 hLe7vpVGX8GW for ; Mon, 16 Dec 2013 14:29:19 -0800 (PST)
Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 193FD1A1F62 for ; Mon, 16 Dec 2013 14:29:18 -0800 (PST)
Received: by mail-la0-f54.google.com with SMTP id b8so2897980lan.41 for ; Mon, 16 Dec 2013 14:29:17 -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=DBWJZsOzCYpqBGyQWMMaKxkxQ6ijbVWu2EFtGFqati4=; b=vw2ISK+Ryu5S6bu8e6GxT4kur5rRsv/0+CsucpqRiMAWDVFKy+oRCHB1NJyQSDIJM4 qy8eb7JzCGmcZablNTm+wbF+5yXLZfBAjPeceBSrQXasB5n/QBv+OwdoVjhotvSlh9CV FVTivrsKbGBJM/0HeylqL1zBzr21P6MTAoDUKl09K26SFG3hoPUIy535+2zsl9I1RF1b 2S+goVgbdt1RaG1BrcxUYHlmxb/xfw13T85q/8Pwwt+BeCzFhNToETR+LipUvwEn2aWc ITl4/ozBKEj6O9xHkz38Oh2X1NgFC5hr/fBH6UM6LpsCeep3Zt4EpyvQFBmBy5uKkIC7 /5ww==
X-Received: by 10.112.13.169 with SMTP id i9mr1543572lbc.73.1387232467447; Mon, 16 Dec 2013 14:21:07 -0800 (PST)
Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id tc8sm11014682lbb.9.2013.12.16.14.21.06 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 16 Dec 2013 14:21:06 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jouni Korhonen 
In-Reply-To: 
Date: Tue, 17 Dec 2013 00:21:05 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <023DEE16-3AA6-447C-AE69-8ECC02673E26@gmail.com>
References: <70089680-BBFD-4E4C-B550-30FEAB5C611C@gmail.com> <087A34937E64E74E848732CFF8354B920975651D@ESESSMB101.ericsson.se> 
To: "dime@ietf.org list" 
X-Mailer: Apple Mail (2.1510)
Cc: Ben Campbell 
Subject: Re: [Dime] Submission of draft-ietf-dime-ovli-01
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Dec 2013 22:29:21 -0000

I am gonna submit current Github version of -01 in the morning. =46rom =
that
on, the normal "process" continues but in addition if you want something =
to
be addressed in a manner that it does not get forgotten into these email
threads, issues a ticket, write your description and possibly a proposed
solution. The ticket issuer is supposed to close the ticket when the =
consensus
has been reached.

In a meantime, folks should take a look at how to use the issue tracker. =
Typical
web-based "goodness" ;-) You might need to ask wiki access rights from =
the
secretariat.=20

http://tools.ietf.org/wg/dime/trac/report/1

- Jouni


On Dec 16, 2013, at 11:38 PM, Ben Campbell  wrote:

> I agree with submitting 01.=20
>=20
> I disagree about removing controversial text, although I don't mind =
marking it as controversial. But I think it would be a better approach =
would be to take 01 as a baseline and start putting open issues in the =
issue tracker.
>=20
> On Dec 16, 2013, at 10:50 AM, Maria Cruz Bartolome =
 wrote:
>=20
>> Hello Jouni, all,
>>=20
>> We got some open discussion without any conclusion yet, if you prefer =
to publish .01 version, I would suggest these open issues are properly =
covered there, or all related text is omitted.
>> Cheers
>> /MCruz
>>=20
>> -----Original Message-----
>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen
>> Sent: lunes, 16 de diciembre de 2013 17:47
>> To: dime@ietf.org list
>> Subject: [Dime] Submission of draft-ietf-dime-ovli-01
>>=20
>> Folks,
>>=20
>> I am somewhat tempted to publish -01 even if we still have some very =
rough edges and then continue from there. Any strong disagreements?
>>=20
>> The place we lack text more or less entirely is Section 5.5.3. (for a =
reason) but will type in something later tonight (or so).
>>=20
>> - Jouni
>>=20
>> _______________________________________________
>> 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
>=20


From kristian.poscic@alcatel-lucent.com  Mon Dec 16 17:05:40 2013
Return-Path: 
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 0BA931ADF90 for ; Mon, 16 Dec 2013 17:05:40 -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 qYPv4euuszJc for ; Mon, 16 Dec 2013 17:05:37 -0800 (PST)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 1364A1ADFD6 for ; Mon, 16 Dec 2013 17:05:30 -0800 (PST)
Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id rBH15SW9005471 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 16 Dec 2013 19:05:28 -0600 (CST)
Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id rBH15Sma000892 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 16 Dec 2013 20:05:28 -0500
Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.36]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.02.0247.003; Mon, 16 Dec 2013 20:05:28 -0500
From: "Poscic, Kristian (Kristian)" 
To: "dime@ietf.org" 
Thread-Topic: diameter overload protection
Thread-Index: Ac76wsQ8yoNHBVHUT3itLREA+CwZzg==
Date: Tue, 17 Dec 2013 01:05:27 +0000
Message-ID: <7921F977B17D5B49B8DCC955A339D2F02ACC8A68@US70UWXCHMBA05.zam.alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.5.27.16]
Content-Type: multipart/alternative; boundary="_000_7921F977B17D5B49B8DCC955A339D2F02ACC8A68US70UWXCHMBA05z_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
Subject: [Dime] diameter overload protection
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Dec 2013 01:05:40 -0000

--_000_7921F977B17D5B49B8DCC955A339D2F02ACC8A68US70UWXCHMBA05z_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,
I've been reading through the draft-docdt-dime-ovli-01 draft and would appreciate one clarific=
ation.
I know that a lot of discussions has been going on about the exact mechanis=
ms and treatment of the AVPs but I'm missing something more basic.

It seems like that the draft suggests that for session aware applications (=
I'm interested in Gx application in particular), the mechanism relies on th=
e reporting node to send the overload capability and indication over a sess=
ion (piggybacking).
Does this mean that the reacting node throttles traffic for all Gx sessions=
 destined to the dest-host/realm (as reported in ReportType), or only the t=
raffic for that particular session over the report is received.
I would imagine that the reacting node would need to throttle all traffic (=
otherwise the overload protection mechanism would be greatly diminished), a=
lthough this seems very unnatural - to receive the request over a single se=
ssion but the action should be applied to all sessions.
Thanks,
Kris

--_000_7921F977B17D5B49B8DCC955A339D2F02ACC8A68US70UWXCHMBA05z_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi,


I’ve been reading through the 
draft-docdt-dime-ovli-01 draft and =
would appreciate one clarification.


I know that a lot of discussions has been going on a=
bout the exact mechanisms and treatment of the AVPs but I’m missing s=
omething more basic.


 


It seems like that the draft suggests that for sessi=
on aware applications (I’m interested in Gx application in particular=
), the mechanism relies on the reporting node to send the overload capabili=
ty and indication over a session (piggybacking).


Does this mean that the reacting node throttles traf=
fic for all Gx sessions destined to the dest-host/realm (as reported in Rep=
ortType), or only the traffic for that particular session over the report i=
s received.



I would imagine that the reacting node would need to=
 throttle all traffic (otherwise the overload protection mechanism would be=
 greatly diminished), although this seems very unnatural – to receive=
 the request over a single session but the
 action should be applied to all sessions.


Thanks,


Kris 






--_000_7921F977B17D5B49B8DCC955A339D2F02ACC8A68US70UWXCHMBA05z_--

From jean-jacques.trottin@alcatel-lucent.com  Tue Dec 17 00:12:50 2013
Return-Path: 
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 04E2B1AE0F3 for ; Tue, 17 Dec 2013 00:12:50 -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 m2K64uFRxUUw for ; Tue, 17 Dec 2013 00:12:46 -0800 (PST)
Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id C54321AE0EF for ; Tue, 17 Dec 2013 00:12:46 -0800 (PST)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id rBH8CdBl009632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 17 Dec 2013 02:12:40 -0600 (CST)
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id rBH8CaKw015005 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 17 Dec 2013 09:12:39 +0100
Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.241]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Tue, 17 Dec 2013 09:12:37 +0100
From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
To: "Poscic, Kristian (Kristian)" , "dime@ietf.org list" 
Thread-Topic: diameter overload protection
Thread-Index: Ac76wsQ8yoNHBVHUT3itLREA+CwZzgAOYXog
Date: Tue, 17 Dec 2013 08:12:36 +0000
Message-ID: 
References: <7921F977B17D5B49B8DCC955A339D2F02ACC8A68@US70UWXCHMBA05.zam.alcatel-lucent.com>
In-Reply-To: <7921F977B17D5B49B8DCC955A339D2F02ACC8A68@US70UWXCHMBA05.zam.alcatel-lucent.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.39]
Content-Type: multipart/alternative; boundary="_000_E194C2E18676714DACA9C3A2516265D201CB5B9AFR712WXCHMBA12z_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39
Subject: Re: [Dime] diameter overload protection
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Dec 2013 08:12:50 -0000

--_000_E194C2E18676714DACA9C3A2516265D201CB5B9AFR712WXCHMBA12z_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Kristian and  all

The main principle is that overload reports (OLR) are send from a reporting=
 node (eg a server)   to a reacting node (eg a client) for a given Diameter=
 application (eg Gx) with a traffic % reduction that the reacting node  wil=
l apply to the traffic it sends to this reporting node.  In addition we hav=
e the realm OLR that address a traffic  reduction to apply to requests sent=
  to a realm when the server  is not known. About piggybacking, the above d=
escribed OLRs  are conveyed  in the Diameter answers between the concerned =
 server (or realm) and client for  a given Diameter application , and does =
not depend of the Diameter session
This resume the baseline mechanism   aimed in the draft, given that extensi=
bility facilities are included to allow future extensions according to new =
requirements.

Regarding  your  remark that the % of reduction may apply to the traffic of=
  a Diameter session , this option was evocated  at the beginning of Diamet=
er overlaod  discussions. This option  is not part of the baseline mechanis=
m described  in this draft as having a too fine granularity and as you indi=
cated diminishing the  efficiency of the overload control.  This option may=
 be studied again in the future if there are relevant t requirements for it=
.

We will check and possibly review the wording of the draft  to avoid any am=
biguity on the above.

Best regards


JJacques



De : DiME [mailto:dime-bounces@ietf.org] De la part de Poscic, Kristian (Kr=
istian)
Envoy=E9 : mardi 17 d=E9cembre 2013 02:05
=C0 : dime@ietf.org
Objet : [Dime] diameter overload protection

Hi,
I've been reading through the draft-docdt-dime-ovli-01 draft and would appreciate one clarific=
ation.
I know that a lot of discussions has been going on about the exact mechanis=
ms and treatment of the AVPs but I'm missing something more basic.

It seems like that the draft suggests that for session aware applications (=
I'm interested in Gx application in particular), the mechanism relies on th=
e reporting node to send the overload capability and indication over a sess=
ion (piggybacking).
Does this mean that the reacting node throttles traffic for all Gx sessions=
 destined to the dest-host/realm (as reported in ReportType), or only the t=
raffic for that particular session over the report is received.
I would imagine that the reacting node would need to throttle all traffic (=
otherwise the overload protection mechanism would be greatly diminished), a=
lthough this seems very unnatural - to receive the request over a single se=
ssion but the action should be applied to all sessions.
Thanks,
Kris

--_000_E194C2E18676714DACA9C3A2516265D201CB5B9AFR712WXCHMBA12z_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hi Kristian and  =
all 


 


The main principle is =
that overload reports (OLR) are send from a reporting node (eg a server) &n=
bsp; to a reacting node (eg a client) for a given Diameter application=
 (eg Gx) with a traffic % reduction that the reacting
 node  will apply to the traffic it sends to this reporting node. &nbs=
p;In addition we have the realm OLR that address a traffic  reduction =
to apply to requests sent  to a realm when the server  is not kno=
wn. About piggybacking, the above described OLRs  are conveyed
  in the Diameter answers between the concerned  server (or realm=
) and client for  a given Diameter application , and does not depend o=
f the Diameter session


This resume the baseli=
ne mechanism   aimed in the draft, given that extensibility facil=
ities are included to allow future extensions according to new requirements=
.   


 


Regarding  your &=
nbsp;remark that the % of reduction may apply to the traffic of  a Dia=
meter session , this option was evocated  at the beginning of Diameter=
 overlaod  discussions. This option  is not part of the
 baseline mechanism described  in this draft as having a too fine gran=
ularity and as you indicated diminishing the  efficiency of the overlo=
ad control.  This option may be studied again in the future if there a=
re relevant t requirements for it.



 


We will check and poss=
ibly review the wording of the draft  to avoid any ambiguity on the ab=
ove.



 


Best regards


 


 


JJacques 


 


 


 






De : DiME [mailto:dime-bounces@ietf.org]
De la part de Poscic, Kristian (Kristian)

Envoy=E9 : mardi 17 d=E9cembre 2013 02:05

=C0 : dime@ietf.org

Objet : [Dime] diameter overload protection





 


Hi,


I’ve been reading through the 
draft-docdt-dime-ovli-01 draft and =
would appreciate one clarification.


I know that a lot of discussions has been going on a=
bout the exact mechanisms and treatment of the AVPs but I’m missing s=
omething more basic.


 


It seems like that the draft suggests that for sessi=
on aware applications (I’m interested in Gx application in particular=
), the mechanism relies on the reporting node to send the overload capabili=
ty and indication over a session (piggybacking).


Does this mean that the reacting node throttles traf=
fic for all Gx sessions destined to the dest-host/realm (as reported in Rep=
ortType), or only the traffic for that particular session over the report i=
s received.



I would imagine that the reacting node would need to=
 throttle all traffic (otherwise the overload protection mechanism would be=
 greatly diminished), although this seems very unnatural – to receive=
 the request over a single session but the
 action should be applied to all sessions.


Thanks,


Kris 






--_000_E194C2E18676714DACA9C3A2516265D201CB5B9AFR712WXCHMBA12z_--

From jean-jacques.trottin@alcatel-lucent.com  Tue Dec 17 00:54:44 2013
Return-Path: 
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 425A21AE134 for ; Tue, 17 Dec 2013 00:54:44 -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 rRlbljUEJsiq for ; Tue, 17 Dec 2013 00:54:42 -0800 (PST)
Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 8F83B1AE12C for ; Tue, 17 Dec 2013 00:54:42 -0800 (PST)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id rBH8scl9027388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 17 Dec 2013 02:54:39 -0600 (CST)
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id rBH8sb6B024952 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 17 Dec 2013 09:54:37 +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; Tue, 17 Dec 2013 09:54:37 +0100
From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
To: "dime@ietf.org list" 
Thread-Topic: DOIC Section 5.5.2 Diameter application
Thread-Index: AQHO+wWdMUNdyIGkS0C4YandtgshKQ==
Date: Tue, 17 Dec 2013 08:54:36 +0000
Message-ID: 
References: <7921F977B17D5B49B8DCC955A339D2F02ACC8A68@US70UWXCHMBA05.zam.alcatel-lucent.com> 
In-Reply-To: 
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.39]
Content-Type: multipart/alternative; boundary="_000_E194C2E18676714DACA9C3A2516265D201CB5BC9FR712WXCHMBA12z_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35
Subject: [Dime] DOIC Section 5.5.2 Diameter application
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Dec 2013 08:54:44 -0000

--_000_E194C2E18676714DACA9C3A2516265D201CB5BC9FR712WXCHMBA12z_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


In 5.5.2 Reacting nodes consideration., it is well mentioned that the OLR a=
pplies to the Host identified by Origin-Host AVP or the  Realm identified b=
y Origin-Realm AVP., but nothing is said about the Diameter Application ide=
ntified  by the Application ID, so I propose, to add the following paragrap=
h in 5.5.2 :

The reacting node learns the Diameter application to which the overload rep=
ort applies from the Application-ID of the answer message containing the OC=
-OLR AVP.

This paragraph  can be inserted just before the hereafter  existing paragra=
ph
   From the OC-Report-Type AVP the reacting node learns whether the
   overload condition report concerns a specific host (as identified by
   the Origin-Host AVP of the answer message containing the OC-OLR AVP)
   or the entire realm (as identified by the Origin-Realm AVP of the
   answer message containing the OC-OLR AVP).


Best regards

JJacques




--_000_E194C2E18676714DACA9C3A2516265D201CB5BC9FR712WXCHMBA12z_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











 


In 5.5.2 Reacting node=
s consideration., it is well mentioned that the OLR applies to the Host ide=
ntified by Origin-Host AVP or the  Realm identified by Origin-Realm AV=
P., but nothing is said about the Diameter
 Application identified  by the Application ID, so I propose, to add t=
he following paragraph in 5.5.2 :


 


The reacting no=
de learns the Diameter application to which the overload report applies fro=
m the Application-ID of the answer message containing
 the OC-OLR AVP.


 


This paragraph  c=
an be inserted just before the hereafter  existing paragraph



   From the OC-Report-Type AVP the reacting=
 node learns whether the


   overload condition report concerns a spe=
cific host (as identified by


   the Origin-Host AVP of the answer messag=
e containing the OC-OLR AVP)


   or the entire realm (as identified by th=
e Origin-Realm AVP of the


   answer message containing the OC-OLR AVP=
). 



 


 


Best regards


 


JJacques


 


 




 








--_000_E194C2E18676714DACA9C3A2516265D201CB5BC9FR712WXCHMBA12z_--

From jouni.nospam@gmail.com  Tue Dec 17 01:53:53 2013
Return-Path: 
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 9308F1ADFD1 for ; Tue, 17 Dec 2013 01:53:53 -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 jewIJfmM0Oi7 for ; Tue, 17 Dec 2013 01:53:52 -0800 (PST)
Received: from mail-bk0-x235.google.com (mail-bk0-x235.google.com [IPv6:2a00:1450:4008:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id C432E1ADFB2 for ; Tue, 17 Dec 2013 01:53:51 -0800 (PST)
Received: by mail-bk0-f53.google.com with SMTP id na10so2711157bkb.40 for ; Tue, 17 Dec 2013 01:53:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=QoyPpF+0N9Zpl31zWKSvUMIOg5NJ5WgWWTZpeQvLubk=; b=luK/Pj9mkuoCvikLNq6zLqJBKfkm/h+aEhnk70Nu544rbmBe0pGa/i9MUC3TZq49+n lfHWplxi/Jd/y6pDQaASZRhPtMnnS5AmPYs/AE23gQbcK6jR/yCP5LjyVDSE975lXtKE gLaPcs2SgEzG4GoaQaWJXJv7X8RV3BEnoVchTs71ewL5BIB+Wr2qECz0BtMFGK2rQb2W nAE7Td3m/rZKlZj60DHiVayibMFgU0K61tHgru+vLt6CCXDqFj5kitii9++8p/cvkVz0 ITIAuz7nlUPvxkVu1XK1ywJtkBv1LvqTBZDIoQR7mVp/k8KHbrd+Gw9y+VTPAitB7Don 7blw==
X-Received: by 10.204.171.15 with SMTP id f15mr302226bkz.116.1387274030279; Tue, 17 Dec 2013 01:53:50 -0800 (PST)
Received: from ?IPv6:2001:1bc8:101:f101:8d49:90a9:b3bb:5ae9? ([2001:1bc8:101:f101:8d49:90a9:b3bb:5ae9]) by mx.google.com with ESMTPSA id bf8sm13023276bkb.14.2013.12.17.01.53.47 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Dec 2013 01:53:47 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=us-ascii
From: Jouni 
In-Reply-To: 
Date: Tue, 17 Dec 2013 11:53:46 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <6C49E6F9-37B4-4DC8-B9AD-D074E4B36100@gmail.com>
References: <7921F977B17D5B49B8DCC955A339D2F02ACC8A68@US70UWXCHMBA05.zam.alcatel-lucent.com>  
To: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
X-Mailer: Apple Mail (2.1283)
Cc: "dime@ietf.org list" 
Subject: Re: [Dime] DOIC Section 5.5.2 Diameter application
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Dec 2013 09:53:53 -0000

Good point. Will clarify.

On Dec 17, 2013, at 10:54 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) =
wrote:

> =20
> In 5.5.2 Reacting nodes consideration., it is well mentioned that the =
OLR applies to the Host identified by Origin-Host AVP or the  Realm =
identified by Origin-Realm AVP., but nothing is said about the Diameter =
Application identified  by the Application ID, so I propose, to add the =
following paragraph in 5.5.2 :
> =20
> The reacting node learns the Diameter application to which the =
overload report applies from the Application-ID of the answer message =
containing the OC-OLR AVP.
> =20
> This paragraph  can be inserted just before the hereafter  existing =
paragraph
>    =46rom the OC-Report-Type AVP the reacting node learns whether the
>    overload condition report concerns a specific host (as identified =
by
>    the Origin-Host AVP of the answer message containing the OC-OLR =
AVP)
>    or the entire realm (as identified by the Origin-Realm AVP of the
>    answer message containing the OC-OLR AVP).=20
> =20
> =20
> Best regards
> =20
> JJacques
> =20
> =20
> =20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From ulrich.wiehe@nsn.com  Tue Dec 17 02:15:30 2013
Return-Path: 
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 E08131AE154 for ; Tue, 17 Dec 2013 02:15:30 -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 9NxrYwLPTHBH for ; Tue, 17 Dec 2013 02:15:24 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id C66EA1AE148 for ; Tue, 17 Dec 2013 02:15:22 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rBHAFGSU006730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 17 Dec 2013 11:15:16 +0100
Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rBHAFFO5013485 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Dec 2013 11:15:15 +0100
Received: from DEMUHTC011.nsn-intra.net (10.159.42.42) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 17 Dec 2013 11:15:15 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.217]) by DEMUHTC011.nsn-intra.net ([10.159.42.42]) with mapi id 14.03.0123.003; Tue, 17 Dec 2013 11:15:15 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: "ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" , "dime@ietf.org" 
Thread-Topic: OC-Supported Feature AVP
Thread-Index: Ac74CX1Hcx+hHoLfTg+cADFSVxx9GADAT4Xw
Date: Tue, 17 Dec 2013 10:15:15 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151A5EDE@DEMUMBX014.nsn-intra.net>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.109]
Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D9000668151A5EDEDEMUMBX014nsnin_"
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: 34932
X-purgate-ID: 151667::1387275317-00000661-8198393E/0-0/0-0
Subject: Re: [Dime] OC-Supported Feature AVP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Dec 2013 10:15:31 -0000

--_000_5BCBA1FC2B7F0B4C9D935572D9000668151A5EDEDEMUMBX014nsnin_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi JJacques,

ad A)
I support to mandate a) for applications that do and also for applications =
that do not maintain state, because:
                for applications that do not maintain state: "if the OC-Sup=
ported-Features AVP is no more present in a message (and in later messages)=
 ,  it would  be interpreted  that DOIC is no more supported"     and
                for applications that maintain state: State is maintained a=
t session endpoints which are not necessarily DOIC endpoints.

With regard to SequenceNumber it has been argued that
we could have a situation where the OC-Feature-Vector remain unchanged but =
some additional AVPs related to the supported features would change
however, we should cross the bridge when we come to it , e.g. the additiona=
l AVP, when introduced, could be of type grouped with a sequence number as =
first component.

Ad B)
Advertisement (OC-Supported-Features AVP in request messages) followed by s=
election (OC-OLR AVP in answer messages) is a good approach. I never unders=
tood why we need the  OC-Supported-Features AVP in answer messages as long =
as no extension is defined.

Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext TROTTIN, JEAN-JA=
CQUES (JEAN-JACQUES)
Sent: Friday, December 13, 2013 2:45 PM
To: dime@ietf.org
Subject: [Dime] OC-Supported Feature AVP

Dear all

When analysing the discussion of the sequence number in the OC-Supported-Fe=
atures AVP , it has driven me to some other considerations regarding this  =
feature negotiation that I hereafter present:  it is a bit long but it rais=
es  a certain number of questions   and then we have to draw some conclusio=
n  and adapt the text  of the draft if needed


A)     Behaviours for sending the  OC-Supported-Features AVP

Currently there is only one default algorithm. So the use of  OC-Supported-=
Features AVP containing the OC-Feature-Vector is  only to indicate the supp=
ort of DOIC with the default algorithm, given that en entity not supporting=
 DOIC will never sends the OC-Supported-Features AVP.



This AVP in the future  will allow to add new feature/capabilities .


This AVP is needed initially to advertise the mutual  capabilities between =
reacting and reporting node  and  when changes occur in the  supported  fea=
tures (eg in general to add a new feature, but may be also to remove  one).=
 A sequence number was introduced to manage these changes, but this introdu=
ction is still under discussion (cf Ulrich's mails questioning this point)



Then there is the question about when the OC-Supported-Features AVP is sent=
.  The current draft  has related statements in 3.2 and 4.1  :

The several hereafter possible  behaviors are compliant for me with 3.2 and=
 4.1  statements (are you sharing this reading?), we have to see if the dra=
ft allows all of them or if additional rules must be  fulfilled:



a)      The reacting node sends the OC-Supported-Features AVP in each reque=
st and the reporting node sends back its own OC-Supported-Features AVP in e=
ach answer.

b)      The reacting nodes initially sends its  OC-Supported-Features AVP, =
but does not repeat it any more , until a change in the features to be adve=
rtised  happens or after a node restart

c)       Something intermediate, so when there is a change as in b)  plus  =
a periodic advertisement of the supported features although unchanged




About a):

Steve,  and I agree,   indicated that the features are quite stable over ti=
me, and modifications will appear when a new feature is deployed (OAM case)=
; I think  it is also needed at restart. So there are very few events over =
the year where the advertisement is actually needed (have you others in min=
d?) . Now my questioning:   why to permanently do such an exchange in each =
request/answer?  I observe that this behavior  is used in 3GPP where suppor=
ted features are advertised in each request/answer, so we can apply  the sa=
me principle, but I nevertheless raise the question.



About the sequence number:

o   the receiving node has to open the sequence number AVP and checks if it=
 has changed, given the value will change only a few times a year.  A besid=
es  question,  which value the seq number takes after a restart

o   if we do not use the sequence number, the  receiving node has to open t=
he OC-feature-Vector AVP and see if it has changed, so I do not see much di=
fference with the above

o   the sequence number has the property  to be equal  or to increase in or=
der to detect an eventual  change of the order of the messages and avoid to=
 come back to a previous value of the feature-vector. But further messages =
will all be with the new feature-vector, so the right result. I am not sure=
 that the seq number bring a value for the transient period when the suppor=
ted feature is  modified. So question: can we suppress the seq number in th=
is a) behaviour?
In this a ) behaviour, if the OC-Supported-Features AVP is no more present =
in a message (and in later messages) ,  it would  be interpreted  that DOIC=
 is no more supported . ( so different from the b) or c) case)


About b): this is the other extreme use case compared to a).

Here in practice all the messages will not contain an  OC-Supported-Feature=
s AVP (except in the  rare cases of a change or after a restart), So the ab=
sence of this AVP in a message  does not mean that DOIC is not supported. C=
apability negotiation  happens once and remain valid until a change. At res=
tart or when a change  a reacting node sends an OC-Supported-Features AVP i=
n a request, and wait for an OC-Supported-Features AVP   in the answer; if =
nothing, it means the reporting node is not supporting DOIC. If the answer =
is lost the reacting node may repeat the request or use another one with it=
s OC Supported-feature AVP.



If the change occurs in the reporting node, it cannot wait for a request co=
ming from the reacting node with an OC Supported-feature AVP,  (as it will =
 never come if no change at the reacting node side), so the reporting node =
should advertise the  OC Supported-feature AVP in answers (although the cor=
responding request do not contain this AVP).  I think this behavior is curr=
ently allowed by the draft text, do you agree?.   To secure a bit more, the=
 reacting node may then  send a request with its own OC Supported-feature A=
VP, acting as an acknowledgement to the reporting node. The reporting node =
may repeat if needed  or to be more secure.

There may be some corner cases to investigate more, but I currently stop he=
re.



In this use case, I do not see a need  for a sequence number .


Do you think such an approach is applicable? it will save many checks compa=
red to a).


About c): it is the same principle as in b) but with some periodic  "refres=
h" that may make the a) approach  still more secure. But not sure  it is ac=
tually needed.



So do you think the draft should  allow these different  behaviors  or only=
 mandate one?

Then do you think we need a sequence number for the OC-Supported-Features A=
VP?





B)      Another point also related to the OC-Supported-Features AVP and OC-=
Feature-Vector:


For example a node can use the default mechanism  and in addition support e=
xtensions (eg the APN or the session group examples). I would think extensi=
ons should be advertized by the reacting node , otherwise the server does n=
ot know if it can use an extension or not, and  a server should avoid  to s=
end OLRs that the client will not understand .
 So here we may have  a set of extensions compatible with the default mecha=
nism

The other example is "exclusive" or not compatible features, for example Tr=
affic reduction %control  and rate control. I do not consider  a reporting =
node  will  use both with a reacting node. A reacting node , even if it sup=
ports both does not want to mix  throttling based on % traffic and throttli=
ng on rate control with the same reporting node. But the current  text does=
 not say anything about which feature is selected .
I remember that in our initial discussions, the reacting node was advertisi=
ng its features / capabilities and the reporting node was selecting the one=
s it wants to use. Should not we come back to this rule? or do you consider=
 that when we will introduce new features , we will introduce statements  t=
o indicate rules on their presence in OC-Feature-Vector. Personnaly, I thin=
k  the advertisement  followed  by selection  was a good approach. Views on=
 this?

I have  described this B part  here, as it may have some interaction with t=
he  A part.

Best regards

JJacques










--_000_5BCBA1FC2B7F0B4C9D935572D9000668151A5EDEDEMUMBX014nsnin_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi JJac=
ques,


&n=
bsp;


ad A) <=
o:p>


I suppo=
rt to mandate a) for applications that do and also for applications that do=
 not maintain state, because:


 &=
nbsp;           &nbs=
p;  for applications that do not maintain state: “if the OC-Supported-Features AVP is no more present in a mess=
age (and in later messages) ,  it would  be interpreted
  that DOIC is no more supported”     and


 &=
nbsp;           &nbs=
p;  for applications that maintain state: State is maintained at sessi=
on endpoints which are not necessarily DOIC endpoints.



&n=
bsp;


With re=
gard to SequenceNumber it has been argued that



we could have a situation where=
 the OC-Feature-Vector remain unchanged but some additional AVPs related to=
 the supported features would change


however=
, we should cross the bridge when we come to it , e.g. the additional AVP, =
when introduced, could be of type grouped with a sequence number as first c=
omponent.


&n=
bsp;


Ad B)


Adverti=
sement (OC-Supported-Features AVP in request messages) followed by selectio=
n (OC-OLR AVP in answer messages) is a good approach. I never understood wh=
y we need the  OC-Supported-Features AVP
 in answer messages as long as no extension is defined.

&n=
bsp;


Ulrich<=
o:p>


&n=
bsp;






From: DiME [mailto:dime-bounces@ietf.org]
On Behalf Of ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES)

Sent: Friday, December 13, 2013 2:45 PM

To: dime@ietf.org

Subject: [Dime] OC-Supported Feature AVP






 


Dear all 


 


When analysing the discussion o=
f the sequence number in the OC-Supported-Features AVP , it has driven me t=
o some other considerations regarding this  feature negotiation that I=
 hereafter present:  it is a bit long but
 it raises  a certain number of questions   and then we have=
 to draw some conclusion  and adapt the text  of the draft if nee=
ded



 



A=
)   &=
nbsp;
Behaviours for sending =
the  OC-Supported-Features AVP


Currently there is only one default algorithm. So the use of  OC-Sup=
ported-Features AVP containing the OC-Feature-Vector is  only to indic=
ate the support of DOIC with the default algorithm,
 given that en entity not supporting DOIC will never sends the OC-Supported=
-Features AVP.



 


This AVP in the future  will allow to add new feature/capabilities .



 


This AVP is needed initially to advertise the mutual  capabilities b=
etween reacting and reporting node  and  when changes occur in th=
e  supported  features (eg in general to add a new feature,
 but may be also to remove  one). A sequence number was introduced to =
manage these changes, but this introduction is still under discussion (cf U=
lrich’s mails questioning this point)



 


Then there is the question about when the OC-Supported-Features AVP is se=
nt.  The current draft  has related statements in 3.2 and 4.1 &nb=
sp;:



The several hereafter possible  behaviors are compliant for me with =
3.2 and 4.1  statements (are you sharing this reading?), we have to se=
e if the draft allows all of them or
if additional rules must be  fulfilled:


 



a=
)   &=
nbsp; 
The reacting node sends=
 the OC-Supported-Features AVP in each request and the reporting node sends=
 back its own OC-Supported-Features AVP in each answer.




b=
)   &=
nbsp; 
The reacting nodes init=
ially sends its  OC-Supported-Features AVP, but does not repeat it any=
 more , until a change in the features to be advertised  happens or af=
ter a node restart



c=
)   &=
nbsp;  
Something intermediate,=
 so when there is a change as in b)  plus  a periodic advertiseme=
nt of the supported features although unchanged


 


 


About a):


Steve,  and I agree,   indicated that the features are qui=
te stable over time, and modifications will appear when a new feature is de=
ployed (OAM case); I think  it is also needed at restart.
 So there are very few events over the year where the advertisement is actu=
ally needed (have you others in mind?) . Now my questioning:   wh=
y to permanently do such an exchange in each request/answer?  I observ=
e that this behavior  is used in 3GPP where supported
 features are advertised in each request/answer, so we can apply  the =
same principle, but I nevertheless raise the question.

 


About the sequence number:



o  
the receiving node has =
to open the sequence number AVP and checks if it has changed, given the val=
ue will change only a few times a year.  A besides  question, &nb=
sp;which value the seq number takes after a restart




o  
if we do not use the se=
quence number, the  receiving node has to open the OC-feature-Vector A=
VP and see if it has changed, so I do not see much difference with the abov=
e




o  
the sequence number has=
 the property  to be equal  or to increase in order to detect an =
eventual  change of the order of the messages and avoid to come back t=
o a previous value of the feature-vector. But further
 messages will all be with the new feature-vector, so the right result. I a=
m not sure that the seq number bring a value for the transient period when =
the supported feature is  modified. So question: can we suppress the s=
eq number in this a) behaviour?


In=
 this a ) behaviour, if the OC-Supported-Features AVP is no more present in=
 a message (and in later messages) ,  it would  be interpreted &n=
bsp;that DOIC is no more supported . ( so different from
 the b) or c) case) 


   


About b): this is the other extreme us=
e case compared to a).



Here in practice all the messages will not contain an  OC-Supported-=
Features AVP (except in the  rare cases of a change or after a restart=
), So the absence of this AVP in a message  does
 not mean that DOIC is not supported. Capability negotiation  happens =
once and remain valid until a change. At restart or when a change  a r=
eacting node sends an OC-Supported-Features AVP in a request, and wait for =
an OC-Supported-Features AVP   in the answer;
 if nothing, it means the reporting node is not supporting DOIC. If the ans=
wer is lost the reacting node may repeat the request or use another one wit=
h its OC Supported-feature AVP.



 


If the change occurs in the reporting node, it cannot wait for a request =
coming from the reacting node with an OC Supported-feature AVP,  (as i=
t will  never come if no change at the reacting
 node side), so the reporting node should advertise the  OC Supported-=
feature AVP in answers (although the corresponding request do not contain t=
his AVP).  I think this behavior is currently allowed by the draft tex=
t, do you agree?.   To secure a bit more,
 the reacting node may then  send a request with its own OC Supported-=
feature AVP, acting as an acknowledgement to the reporting node. The report=
ing node may repeat if needed  or to be more secure.=



There may be some corner cases to investigate more, but I currently stop =
here.  


 


In this use case, I do not see a need  for a sequence number .



     <=
o:p>


Do you think such an approach is applicable? it will save many checks com=
pared to a).


 


About c): it is the same principle as =
in b) but with some periodic  “refresh” that may make the =
a) approach  still more secure. But not sure  it is actually
 needed.


 


So do you think the draft should  allow these different  behavi=
ors  or only mandate one?


Then do you think we need a sequence number for the OC-Supported-Features=
 AVP?


 


 



B=
)   &=
nbsp; 
Another point also rela=
ted to the OC-Supported-Features AVP and OC-Feature-Vector:


 


For example a node can use the =
default mechanism  and in addition support extensions (eg the APN or t=
he session group examples). I would think extensions should be advertized b=
y the reacting node , otherwise the server
 does not know if it can use an extension or not, and  a server should=
 avoid  to send OLRs that the client will not understand .  =
  



 So here we may have =
 a set of extensions compatible with the default mechanism


 


The other example is “exc=
lusive” or not compatible features, for example Traffic reduction %co=
ntrol  and rate control. I do not consider  a reporting node &nbs=
p;will  use both with a reacting node. A reacting node , even if
 it supports both does not want to mix  throttling based on % traffic =
and throttling on rate control with the same reporting node. But the curren=
t  text does not say anything about which feature is selected .



I remember that in our initial =
discussions, the reacting node was advertising its features / capabilities =
and the reporting node was selecting the ones it wants to use. Should not w=
e come back to this rule? or do you
 consider that when we will introduce new features , we will introduce stat=
ements  to indicate rules on their presence in OC-Feature-Vector. Pers=
onnaly, I think  the advertisement  followed  by selection &=
nbsp;was a good approach. Views on this?



 


I have  described this B p=
art  here, as it may have some interaction with the  A part.=



 


Best regards<=
/p>

 


JJacques 


 


 =



 =



    =
 


 =







--_000_5BCBA1FC2B7F0B4C9D935572D9000668151A5EDEDEMUMBX014nsnin_--

From jari.arkko@piuha.net  Tue Dec 17 02:54:52 2013
Return-Path: 
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 CC1161AE0A7; Tue, 17 Dec 2013 02:54:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.438
X-Spam-Level: 
X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] 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 7LCcCmwauEXo; Tue, 17 Dec 2013 02:54:52 -0800 (PST)
Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id C07461ADDD3; Tue, 17 Dec 2013 02:54:51 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 82FAA2CCC1; Tue, 17 Dec 2013 12:54:49 +0200 (EET)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rQJTAW1cA4PF; Tue, 17 Dec 2013 12:54:49 +0200 (EET)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id DBAB32CC48; Tue, 17 Dec 2013 12:54:47 +0200 (EET)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jari Arkko 
In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712026ADFB0E7@MX15A.corp.emc.com>
Date: Tue, 17 Dec 2013 05:54:47 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <618C82A6-51AC-43BA-8B30-952D0BCD9F0F@piuha.net>
References: <8D3D17ACE214DC429325B2B98F3AE712026ADFB0E7@MX15A.corp.emc.com>
To: "Black, David" 
X-Mailer: Apple Mail (2.1510)
Cc: dime-chairs@tools.ietf.org, draft-ietf-dime-rfc4005bis@tools.ietf.org, gen-art@ietf.org, dime@ietf.org
Subject: Re: [Dime] [Gen-art] Gen-ART review of draft-ietf-dime-rfc4005bis-14
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Dec 2013 10:54:53 -0000

David,

Thank you for your review and the re-review. And thank you authors (and =
David) for addressing the issues!

I have balloted a no-obj position for this document on this week's IESG =
telechat agenda.

Jari


From internet-drafts@ietf.org  Tue Dec 17 05:55:52 2013
Return-Path: 
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 C05D91AE1C0; Tue, 17 Dec 2013 05:55:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 N2Yr_6Pe21Go; Tue, 17 Dec 2013 05:55:50 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B14B71AC441; Tue, 17 Dec 2013 05:55:50 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.83.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20131217135549.12226.14755.idtracker@ietfa.amsl.com>
Date: Tue, 17 Dec 2013 05:55:49 -0800
Cc: dime@ietf.org
Subject: [Dime] I-D Action: draft-ietf-dime-ovli-01.txt
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Dec 2013 13:55:53 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the Diameter Maintenance and Extensions Worki=
ng Group of the IETF.

	Title           : Diameter Overload Indication Conveyance
	Author(s)       : Jouni Korhonen
                          Steve Donovan
                          Ben Campbell
                          Lionel Morand
	Filename        : draft-ietf-dime-ovli-01.txt
	Pages           : 38
	Date            : 2013-12-17

Abstract:
   This specification documents a Diameter Overload Control (DOC) base
   solution and the dissemination of the overload report information.

Requirements

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dime-ovli

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dime-ovli-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-ovli-01


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From kristian.poscic@alcatel-lucent.com  Tue Dec 17 09:52:23 2013
Return-Path: 
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 EE8991AE069 for ; Tue, 17 Dec 2013 09:52:22 -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 7ISd-oGjJml2 for ; Tue, 17 Dec 2013 09:52:20 -0800 (PST)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id EDD221ADE8A for ; Tue, 17 Dec 2013 09:52:19 -0800 (PST)
Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id rBHHqH0G027425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 17 Dec 2013 11:52:17 -0600 (CST)
Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id rBHHqGFA030640 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 17 Dec 2013 12:52:17 -0500
Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.36]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Tue, 17 Dec 2013 12:52:16 -0500
From: "Poscic, Kristian (Kristian)" 
To: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" , "dime@ietf.org list" 
Thread-Topic: diameter overload protection
Thread-Index: Ac76wsQ8yoNHBVHUT3itLREA+CwZzgAOYXogABUTZnA=
Date: Tue, 17 Dec 2013 17:52:15 +0000
Message-ID: <7921F977B17D5B49B8DCC955A339D2F02ACC9683@US70UWXCHMBA05.zam.alcatel-lucent.com>
References: <7921F977B17D5B49B8DCC955A339D2F02ACC8A68@US70UWXCHMBA05.zam.alcatel-lucent.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.5.27.16]
Content-Type: multipart/alternative; boundary="_000_7921F977B17D5B49B8DCC955A339D2F02ACC9683US70UWXCHMBA05z_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
Subject: Re: [Dime] diameter overload protection
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Dec 2013 17:52:23 -0000

--_000_7921F977B17D5B49B8DCC955A339D2F02ACC9683US70UWXCHMBA05z_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Ok, makes sense. Thanks JJ.

From: TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Sent: Tuesday, December 17, 2013 12:13 AM
To: Poscic, Kristian (Kristian); dime@ietf.org list
Subject: RE: diameter overload protection

Hi Kristian and  all

The main principle is that overload reports (OLR) are send from a reporting=
 node (eg a server)   to a reacting node (eg a client) for a given Diameter=
 application (eg Gx) with a traffic % reduction that the reacting node  wil=
l apply to the traffic it sends to this reporting node.  In addition we hav=
e the realm OLR that address a traffic  reduction to apply to requests sent=
  to a realm when the server  is not known. About piggybacking, the above d=
escribed OLRs  are conveyed  in the Diameter answers between the concerned =
 server (or realm) and client for  a given Diameter application , and does =
not depend of the Diameter session
This resume the baseline mechanism   aimed in the draft, given that extensi=
bility facilities are included to allow future extensions according to new =
requirements.

Regarding  your  remark that the % of reduction may apply to the traffic of=
  a Diameter session , this option was evocated  at the beginning of Diamet=
er overlaod  discussions. This option  is not part of the baseline mechanis=
m described  in this draft as having a too fine granularity and as you indi=
cated diminishing the  efficiency of the overload control.  This option may=
 be studied again in the future if there are relevant t requirements for it=
.

We will check and possibly review the wording of the draft  to avoid any am=
biguity on the above.

Best regards


JJacques



De : DiME [mailto:dime-bounces@ietf.org] De la part de Poscic, Kristian (Kr=
istian)
Envoy=E9 : mardi 17 d=E9cembre 2013 02:05
=C0 : dime@ietf.org
Objet : [Dime] diameter overload protection

Hi,
I've been reading through the draft-docdt-dime-ovli-01 draft and would appreciate one clarific=
ation.
I know that a lot of discussions has been going on about the exact mechanis=
ms and treatment of the AVPs but I'm missing something more basic.

It seems like that the draft suggests that for session aware applications (=
I'm interested in Gx application in particular), the mechanism relies on th=
e reporting node to send the overload capability and indication over a sess=
ion (piggybacking).
Does this mean that the reacting node throttles traffic for all Gx sessions=
 destined to the dest-host/realm (as reported in ReportType), or only the t=
raffic for that particular session over the report is received.
I would imagine that the reacting node would need to throttle all traffic (=
otherwise the overload protection mechanism would be greatly diminished), a=
lthough this seems very unnatural - to receive the request over a single se=
ssion but the action should be applied to all sessions.
Thanks,
Kris

--_000_7921F977B17D5B49B8DCC955A339D2F02ACC9683US70UWXCHMBA05z_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Ok, makes sense. Thank=
s JJ.


 






From: TROTTIN,=
 JEAN-JACQUES (JEAN-JACQUES)


Sent: Tuesday, December 17, 2013 12:13 AM

To: Poscic, Kristian (Kristian); dime@ietf.org list

Subject: RE: diameter overload protection






 


Hi Kristian and  =
all 


 


The main principle is =
that overload reports (OLR) are send from a reporting node (eg a server) &n=
bsp; to a reacting node (eg a client) for a given Diameter application=
 (eg Gx) with a traffic % reduction that the reacting
 node  will apply to the traffic it sends to this reporting node. &nbs=
p;In addition we have the realm OLR that address a traffic  reduction =
to apply to requests sent  to a realm when the server  is not kno=
wn. About piggybacking, the above described OLRs  are conveyed
  in the Diameter answers between the concerned  server (or realm=
) and client for  a given Diameter application , and does not depend o=
f the Diameter session


This resume the baseli=
ne mechanism   aimed in the draft, given that extensibility facil=
ities are included to allow future extensions according to new requirements=
.   


 


Regarding  your &=
nbsp;remark that the % of reduction may apply to the traffic of  a Dia=
meter session , this option was evocated  at the beginning of Diameter=
 overlaod  discussions. This option  is not part of the
 baseline mechanism described  in this draft as having a too fine gran=
ularity and as you indicated diminishing the  efficiency of the overlo=
ad control.  This option may be studied again in the future if there a=
re relevant t requirements for it.



 


We will check and poss=
ibly review the wording of the draft  to avoid any ambiguity on the ab=
ove.



 


Best regards


 


 


JJacques 


 


 


 






De : DiME [mailto:d=
ime-bounces@ietf.org]
De la part de Poscic, Kristian (Kristian)

Envoy=E9 : mardi 17 d=E9cembre 2013 02:05

=C0 : dime@ietf.org

Objet : [Dime] diameter overload protection





 


Hi,


I’ve been reading through the 
draft-docdt-dime-ovli-01 draft and =
would appreciate one clarification.


I know that a lot of discussions has been going on a=
bout the exact mechanisms and treatment of the AVPs but I’m missing s=
omething more basic.


 


It seems like that the draft suggests that for sessi=
on aware applications (I’m interested in Gx application in particular=
), the mechanism relies on the reporting node to send the overload capabili=
ty and indication over a session (piggybacking).


Does this mean that the reacting node throttles traf=
fic for all Gx sessions destined to the dest-host/realm (as reported in Rep=
ortType), or only the traffic for that particular session over the report i=
s received.



I would imagine that the reacting node would need to=
 throttle all traffic (otherwise the overload protection mechanism would be=
 greatly diminished), although this seems very unnatural – to receive=
 the request over a single session but the
 action should be applied to all sessions.


Thanks,


Kris 






--_000_7921F977B17D5B49B8DCC955A339D2F02ACC9683US70UWXCHMBA05z_--

From internet-drafts@ietf.org  Thu Dec 19 10:00:03 2013
Return-Path: 
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 C30331AE3B7; Thu, 19 Dec 2013 10:00:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 9EkxbrHC08pE; Thu, 19 Dec 2013 10:00:02 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 496131AE392; Thu, 19 Dec 2013 10:00:02 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.84
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20131219180002.17883.59885.idtracker@ietfa.amsl.com>
Date: Thu, 19 Dec 2013 10:00:02 -0800
Cc: dime@ietf.org
Subject: [Dime] I-D Action: draft-ietf-dime-app-design-guide-21.txt
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Dec 2013 18:00:04 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the Diameter Maintenance and Extensions Worki=
ng Group of the IETF.

	Title           : Diameter Applications Design Guidelines
	Author(s)       : Lionel Morand
                          Victor Fajardo
                          Hannes Tschofenig
	Filename        : draft-ietf-dime-app-design-guide-21.txt
	Pages           : 25
	Date            : 2013-12-19

Abstract:
   The Diameter base protocol provides facilities for protocol
   extensibility enabling to define new Diameter applications or modify
   existing applications.  This document is a companion document to the
   Diameter Base protocol that further explains and clarifies the rules
   to extend Diameter.  It is meant as a guidelines document and
   therefore as informative in nature.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dime-app-design-guide

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dime-app-design-guide-21

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-app-design-guide-21


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From jouni.nospam@gmail.com  Fri Dec 20 02:14:50 2013
Return-Path: 
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 6D12D1AE188 for ; Fri, 20 Dec 2013 02:14:50 -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 raLz4TW0b7yU for ; Fri, 20 Dec 2013 02:14:48 -0800 (PST)
Received: from mail-bk0-x231.google.com (mail-bk0-x231.google.com [IPv6:2a00:1450:4008:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 858D01AE147 for ; Fri, 20 Dec 2013 02:14:48 -0800 (PST)
Received: by mail-bk0-f49.google.com with SMTP id my13so1106405bkb.22 for ; Fri, 20 Dec 2013 02:14:45 -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 :content-transfer-encoding:message-id:references:to; bh=dA3tWeo9OF829J2w60uRZlKqOWA+C3VGHDYexSWGHzw=; b=lwUGnR7UZmGWimPZo5SiFHJirgaNwO18v5fxBZcQfIeARzEN/jbFvw7iMvvcpy5IXq YpLxLlexKAu9czPsi6CaSXXSr1RHgyfZX0tnThu2iNAqytcH+d6i7m8tg9P3OYZaBYHv LZZd6K7PgnxWRx3kndc6CmIYda8nrx0u4WvLCdBAecYtLI+Fbd4KAYR9IqZDegND/dW/ lUSIpX5+tRMx3yzYhs18ZUVYBxd2VcTEKKovXBtL2rVgWM03hjZlslal/Qqbjzt/c2fR SRg1sVnNXaqZfRWx1vJpl+5+uglt126MDyFdoGUmnqCfZQxLSnqkbCvSCCCodSTPYxKa DWgA==
X-Received: by 10.204.114.12 with SMTP id c12mr394373bkq.61.1387534485581; Fri, 20 Dec 2013 02:14:45 -0800 (PST)
Received: from ?IPv6:2001:1bc8:101:f101:9524:173b:b463:7a9? ([2001:1bc8:101:f101:9524:173b:b463:7a9]) by mx.google.com with ESMTPSA id d5sm6112079bkc.9.2013.12.20.02.14.40 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 20 Dec 2013 02:14:40 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jouni Korhonen 
In-Reply-To: <20131217135549.12226.14755.idtracker@ietfa.amsl.com>
Date: Fri, 20 Dec 2013 12:14:41 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <80A9D7CA-A112-4404-9010-AD047F20A47E@gmail.com>
References: <20131217135549.12226.14755.idtracker@ietfa.amsl.com>
To: "dime@ietf.org list" 
X-Mailer: Apple Mail (2.1510)
Subject: [Dime] On  draft-ietf-dime-ovli-01..
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Dec 2013 10:14:50 -0000

Folks,

Now it is time to review -01 and start working on the -02 revision.
Most of you are probably on a vacation so you got 24/7 time to put
into this document :-)

- Jouni=20



On Dec 17, 2013, at 3:55 PM, internet-drafts@ietf.org wrote:

>=20
> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
> This draft is a work item of the Diameter Maintenance and Extensions =
Working Group of the IETF.
>=20
> 	Title           : Diameter Overload Indication Conveyance
> 	Author(s)       : Jouni Korhonen
>                          Steve Donovan
>                          Ben Campbell
>                          Lionel Morand
> 	Filename        : draft-ietf-dime-ovli-01.txt
> 	Pages           : 38
> 	Date            : 2013-12-17
>=20
> Abstract:
>   This specification documents a Diameter Overload Control (DOC) base
>   solution and the dissemination of the overload report information.
>=20
> Requirements
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dime-ovli
>=20
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-dime-ovli-01
>=20
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-ovli-01
>=20
>=20
> Please note that it may take a couple of minutes from the time of =
submission
> until the htmlized version and diff are available at tools.ietf.org.
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From iesg-secretary@ietf.org  Mon Dec 23 09:28:14 2013
Return-Path: 
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 249521AE1DE; Mon, 23 Dec 2013 09:28:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 scRPZ0x_w5Yz; Mon, 23 Dec 2013 09:28:12 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 216D01AE1F5; Mon, 23 Dec 2013 09:28:10 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG 
To: IETF-Announce 
X-Test-IDTracker: no
X-IETF-IDTracker: 4.90
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20131223172810.8627.34400.idtracker@ietfa.amsl.com>
Date: Mon, 23 Dec 2013 09:28:10 -0800
Cc: dime mailing list , dime chair , RFC Editor 
Subject: [Dime] Protocol Action: 'Diameter Network Access Server Application' to Proposed Standard (draft-ietf-dime-rfc4005bis-14.txt)
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Dec 2013 17:28:14 -0000

The IESG has approved the following document:
- 'Diameter Network Access Server Application'
  (draft-ietf-dime-rfc4005bis-14.txt) as Proposed Standard

This document is the product of the Diameter Maintenance and Extensions
Working Group.

The IESG contact persons are Benoit Claise and Joel Jaeggli.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-dime-rfc4005bis/




Technical Summary

    This document obsoletes RFC 4005 and is not backward compatible with
    that document. The main change compared to the RFC 4005 is the removal
    of all of the material related to RADIUS/Diameter protocol interactions,
    which was underspecified and misleading. Moreover, the Command Code Format
    (CCF) for the Accounting-Request and Accounting-Answer messages has been
    changed to explicitly require the inclusion of the Acct-Application-Id AVP and
    exclude the Vendor-Specific-Application-Id AVP. The accounting model to be
    used with this application is also specified.

Working Group Summary

   The document spent almost two years as WG document and the
   proposed changes from RFC 4005 were straightforward and roughly
   endorsed by the Working Group. There was no controversy on its
   final content.

Document Quality

   A number of vendors have indicated interest on implementing
  the specification due it correcting several known flaws.
  There has been no MIB Doctor or Media Type reviews as those
  were not seen relevant for the bis version of the specification.
  There has not been explicitly requested expert reviews outside
  the WG as we believe most if not all important technical experts
  are already represented in the WG and its mailing list. The
  document has received multiple reviews while in WGLC.

Personnel

 Lionel Morand (lionel.morand@orange.com) is the Document Shepherd, as Dime WG co-chair. 
 Benoit Claise (bclaise@cisco.com) is the Responsible Area Director.

RFC Editor Note

  Please add RFC 4005 as an informative reference