Re: [Dime] DOIC: Self-Contained OLRs

<lionel.morand@orange.com> Thu, 05 December 2013 12:56 UTC

Return-Path: <lionel.morand@orange.com>
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED5081ADFAB for <dime@ietfa.amsl.com>; 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 <dime@ietfa.amsl.com>; 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 <dime@ietf.org>; 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: lionel.morand@orange.com
To: Steve Donovan <srdonovan@usdonovans.com>, "dime@ietf.org" <dime@ietf.org>
Thread-Topic: [Dime] DOIC: Self-Contained OLRs
Thread-Index: AQHO67/so7y6FFeeaEmQ38aKczpYQJo6EVYAgACzUoCAAAFygIAAE10AgAF8EQD//7X5YIAHfJgAgAHAgTCAAD+1gIAAEa8g
Date: Thu, 05 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> <B1154CAE-28B5-4B4C-B0DA-5D56DBE1B655@gmail.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> <A9CA33BB78081F478946E4F34BF9AAA014D1F867@xmb-rcd-x10.cisco.com> <0E3F4DF0-0C5F-482D-8CA4-F77B5B2A5F09@nostrum.com> <A9CA33BB78081F478946E4F34BF9AAA014D24EF0@xmb-rcd-x10.cisco.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 <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime/>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Dec 2013 12:56:58 -0000

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<mailto: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><mailto: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<mailto: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><mailto: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> [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<mailto: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<mailto: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<mailto:dime@ietf.org> list

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





On Nov 28, 2013, at 12:27 AM, Ben Campbell <ben@nostrum.com><mailto: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<mailto:DiME@ietf.org>

https://www.ietf.org/mailman/listinfo/dime



_______________________________________________

DiME mailing list

DiME@ietf.org<mailto:DiME@ietf.org>

https://www.ietf.org/mailman/listinfo/dime

_______________________________________________

DiME mailing list

DiME@ietf.org<mailto: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<mailto:DiME@ietf.org>

https://www.ietf.org/mailman/listinfo/dime

_______________________________________________

DiME mailing list

DiME@ietf.org<mailto:DiME@ietf.org>

https://www.ietf.org/mailman/listinfo/dime



_______________________________________________

DiME mailing list

DiME@ietf.org<mailto: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.