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

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Sun, 1 Dec 2013 19:38:16 +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 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:[email-masked]] 
Sent: Friday, November 29, 2013 4:49 PM
To: Wiehe, Ulrich (NSN - DE/Munich); ext [email-masked]; ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] 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:[email-masked]] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
Sent: Friday, November 29, 2013 5:36 PM
To: ext [email-masked]; ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] 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 [email-masked] [mailto:[email-masked]]
Sent: Friday, November 29, 2013 11:13 AM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] 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:[email-masked]] Envoyé : jeudi 28 novembre 2013 11:30 À : MORAND Lionel IMT/OLN; ext Jouni Korhonen; Ben Campbell Cc : [email-masked] 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 [email-masked] [mailto:[email-masked]]
Sent: Thursday, November 28, 2013 10:31 AM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] 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:[email-masked]] De la part de Wiehe, Ulrich (NSN - DE/Munich) Envoyé : jeudi 28 novembre 2013 10:26 À : ext Jouni Korhonen; Ben Campbell Cc : [email-masked] 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:[email-masked]] On Behalf Of ext Jouni Korhonen
Sent: Wednesday, November 27, 2013 11:44 PM
To: Ben Campbell
Cc: [email-masked] list
Subject: Re: [Dime] DOIC: Self-Contained OLRs

On Nov 28, 2013, at 12:27 AM, Ben Campbell <[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime
_______________________________________________
DiME mailing list
[email-masked]
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
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

---

From: "Nirav Salot (nsalot)" <[email-masked]>
Date: Mon, 2 Dec 2013 06:05:02 +0000

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. 

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. 

If we strictly want to ensure that the realm-type OLR is not sent out-of-context, 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 to allow the inclusion of host-type and realm-type OLRs in the response message.
If we say that the client can ignore one of the OLRs, then what is the point 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 ignored.

Regards,
Nirav.

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:[email-masked]] 
Sent: Monday, December 02, 2013 1:08 AM
To: Nirav Salot (nsalot); ext [email-masked]; ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Hi Nirav,

Best regards
Ulrich 

-----Original Message-----
From: ext Nirav Salot (nsalot) [mailto:[email-masked]]
Sent: Friday, November 29, 2013 4:49 PM
To: Wiehe, Ulrich (NSN - DE/Munich); ext [email-masked]; ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Hi Ulrich,

Regards,
Nirav.

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
Sent: Friday, November 29, 2013 5:36 PM
To: ext [email-masked]; ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: Re: [Dime] DOIC: Self-Contained OLRs

Hi Lionel,

Ulrich

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]]
Sent: Friday, November 29, 2013 11:13 AM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Hi Ulrich,

Lionel

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

Lionel,

We have two cases:

Ulrich

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]]
Sent: Thursday, November 28, 2013 10:31 AM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Hi,

Lionel

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

Hi,

Ulrich

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext Jouni Korhonen
Sent: Wednesday, November 27, 2013 11:44 PM
To: Ben Campbell
Cc: [email-masked] list
Subject: Re: [Dime] DOIC: Self-Contained OLRs

- Jouni

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 2 Dec 2013 10:59:37 +0000

Hi Nirav,

please see inline.

Regards
Ulrich

-----Original Message-----
From: ext Nirav Salot (nsalot) [mailto:[email-masked]] 
Sent: Monday, December 02, 2013 7:05 AM
To: Wiehe, Ulrich (NSN - DE/Munich); ext [email-masked]; ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] 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:[email-masked]] 
Sent: Monday, December 02, 2013 1:08 AM
To: Nirav Salot (nsalot); ext [email-masked]; ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Hi Nirav,

Best regards
Ulrich 

-----Original Message-----
From: ext Nirav Salot (nsalot) [mailto:[email-masked]]
Sent: Friday, November 29, 2013 4:49 PM
To: Wiehe, Ulrich (NSN - DE/Munich); ext [email-masked]; ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Hi Ulrich,

Regards,
Nirav.

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
Sent: Friday, November 29, 2013 5:36 PM
To: ext [email-masked]; ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: Re: [Dime] DOIC: Self-Contained OLRs

Hi Lionel,

Ulrich

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]]
Sent: Friday, November 29, 2013 11:13 AM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Hi Ulrich,

Lionel

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

Lionel,

We have two cases:

Ulrich

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]]
Sent: Thursday, November 28, 2013 10:31 AM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Hi,

Lionel

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

Hi,

Ulrich

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext Jouni Korhonen
Sent: Wednesday, November 27, 2013 11:44 PM
To: Ben Campbell
Cc: [email-masked] list
Subject: Re: [Dime] DOIC: Self-Contained OLRs

- Jouni

---

From: "Nirav Salot (nsalot)" <[email-masked]>
Date: Mon, 2 Dec 2013 11:24:51 +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 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:[email-masked]] 
Sent: Monday, December 02, 2013 4:30 PM
To: Nirav Salot (nsalot); ext [email-masked]; ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Hi Nirav,

please see inline.

Regards
Ulrich

-----Original Message-----
From: ext Nirav Salot (nsalot) [mailto:[email-masked]]
Sent: Monday, December 02, 2013 7:05 AM
To: Wiehe, Ulrich (NSN - DE/Munich); ext [email-masked]; ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Ulrich,

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)

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

Regards,
Nirav.

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:[email-masked]]
Sent: Monday, December 02, 2013 1:08 AM
To: Nirav Salot (nsalot); ext [email-masked]; ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Hi Nirav,

Best regards
Ulrich 

-----Original Message-----
From: ext Nirav Salot (nsalot) [mailto:[email-masked]]
Sent: Friday, November 29, 2013 4:49 PM
To: Wiehe, Ulrich (NSN - DE/Munich); ext [email-masked]; ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Hi Ulrich,

Regards,
Nirav.

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
Sent: Friday, November 29, 2013 5:36 PM
To: ext [email-masked]; ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: Re: [Dime] DOIC: Self-Contained OLRs

Hi Lionel,

Ulrich

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]]
Sent: Friday, November 29, 2013 11:13 AM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Hi Ulrich,

Lionel

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

Lionel,

We have two cases:

Ulrich

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]]
Sent: Thursday, November 28, 2013 10:31 AM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Hi,

Lionel

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

Hi,

Ulrich

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext Jouni Korhonen
Sent: Wednesday, November 27, 2013 11:44 PM
To: Ben Campbell
Cc: [email-masked] list
Subject: Re: [Dime] DOIC: Self-Contained OLRs

- Jouni

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 2 Dec 2013 11:57:43 +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 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:[email-masked]] 
Sent: Monday, December 02, 2013 12:25 PM
To: Wiehe, Ulrich (NSN - DE/Munich); ext [email-masked]; ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Ulrich,

I have a basic question.

Regards,
Nirav.

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:[email-masked]] 
Sent: Monday, December 02, 2013 4:30 PM
To: Nirav Salot (nsalot); ext [email-masked]; ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Hi Nirav,

please see inline.

Regards
Ulrich

-----Original Message-----
From: ext Nirav Salot (nsalot) [mailto:[email-masked]]
Sent: Monday, December 02, 2013 7:05 AM
To: Wiehe, Ulrich (NSN - DE/Munich); ext [email-masked]; ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Ulrich,

Regards,
Nirav.

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:[email-masked]]
Sent: Monday, December 02, 2013 1:08 AM
To: Nirav Salot (nsalot); ext [email-masked]; ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Hi Nirav,

Best regards
Ulrich 

-----Original Message-----
From: ext Nirav Salot (nsalot) [mailto:[email-masked]]
Sent: Friday, November 29, 2013 4:49 PM
To: Wiehe, Ulrich (NSN - DE/Munich); ext [email-masked]; ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Hi Ulrich,

Regards,
Nirav.

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
Sent: Friday, November 29, 2013 5:36 PM
To: ext [email-masked]; ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: Re: [Dime] DOIC: Self-Contained OLRs

Hi Lionel,

Ulrich

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]]
Sent: Friday, November 29, 2013 11:13 AM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Hi Ulrich,

Lionel

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

Lionel,

We have two cases:

Ulrich

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]]
Sent: Thursday, November 28, 2013 10:31 AM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Hi,

Lionel

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

Hi,

Ulrich

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext Jouni Korhonen
Sent: Wednesday, November 27, 2013 11:44 PM
To: Ben Campbell
Cc: [email-masked] list
Subject: Re: [Dime] DOIC: Self-Contained OLRs

- Jouni

---

From: "Nirav Salot (nsalot)" <[email-masked]>
Date: Mon, 2 Dec 2013 13:58:13 +0000

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)" <[email-masked]> wrote:
Nirav,

Ulrich

-----Original Message-----
From: ext Nirav Salot (nsalot) [mailto:[email-masked]]
Sent: Monday, December 02, 2013 12:25 PM
To: Wiehe, Ulrich (NSN - DE/Munich); ext [email-masked]; ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Ulrich,

I have a basic question.

Regards,
Nirav.

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:[email-masked]]
Sent: Monday, December 02, 2013 4:30 PM
To: Nirav Salot (nsalot); ext [email-masked]; ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Hi Nirav,

please see inline.

Regards
Ulrich

-----Original Message-----
From: ext Nirav Salot (nsalot) [mailto:[email-masked]]
Sent: Monday, December 02, 2013 7:05 AM
To: Wiehe, Ulrich (NSN - DE/Munich); ext [email-masked]; ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Ulrich,

Regards,
Nirav.

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:[email-masked]]
Sent: Monday, December 02, 2013 1:08 AM
To: Nirav Salot (nsalot); ext [email-masked]; ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Hi Nirav,

Best regards
Ulrich

-----Original Message-----
From: ext Nirav Salot (nsalot) [mailto:[email-masked]]
Sent: Friday, November 29, 2013 4:49 PM
To: Wiehe, Ulrich (NSN - DE/Munich); ext [email-masked]; ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Hi Ulrich,

Regards,
Nirav.

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
Sent: Friday, November 29, 2013 5:36 PM
To: ext [email-masked]; ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: Re: [Dime] DOIC: Self-Contained OLRs

Hi Lionel,

Ulrich

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]]
Sent: Friday, November 29, 2013 11:13 AM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Hi Ulrich,

Lionel

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

Lionel,

We have two cases:

Ulrich

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]]
Sent: Thursday, November 28, 2013 10:31 AM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Hi,

Lionel

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

Hi,

Ulrich

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext Jouni Korhonen
Sent: Wednesday, November 27, 2013 11:44 PM
To: Ben Campbell
Cc: [email-masked] list
Subject: Re: [Dime] DOIC: Self-Contained OLRs

- Jouni

---

From: <[email-masked]>
Date: Mon, 2 Dec 2013 14:19:45 +0000

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:[email-masked]]
Envoyé : lundi 2 décembre 2013 14:58
À : Wiehe, Ulrich (NSN - DE/Munich)
Cc : [email-masked] list; ext Jouni Korhonen; MORAND Lionel IMT/OLN; Ben Campbell
Objet : RE: [Dime] DOIC: Self-Contained OLRs

Ulrich,

Regards,
Nirav.

Ulrich

-----Original Message-----
From: ext Nirav Salot (nsalot) [mailto:[email-masked]]
Sent: Monday, December 02, 2013 12:25 PM
To: Wiehe, Ulrich (NSN - DE/Munich); ext [email-masked]; ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Ulrich,

I have a basic question.

Regards,
Nirav.

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:[email-masked]]
Sent: Monday, December 02, 2013 4:30 PM
To: Nirav Salot (nsalot); ext [email-masked]; ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Hi Nirav,

please see inline.

Regards
Ulrich

-----Original Message-----
From: ext Nirav Salot (nsalot) [mailto:[email-masked]]
Sent: Monday, December 02, 2013 7:05 AM
To: Wiehe, Ulrich (NSN - DE/Munich); ext [email-masked]; ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Ulrich,

Regards,
Nirav.

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:[email-masked]]
Sent: Monday, December 02, 2013 1:08 AM
To: Nirav Salot (nsalot); ext [email-masked]; ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Hi Nirav,

Best regards
Ulrich

-----Original Message-----
From: ext Nirav Salot (nsalot) [mailto:[email-masked]]
Sent: Friday, November 29, 2013 4:49 PM
To: Wiehe, Ulrich (NSN - DE/Munich); ext [email-masked]; ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Hi Ulrich,

Regards,
Nirav.

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
Sent: Friday, November 29, 2013 5:36 PM
To: ext [email-masked]; ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: Re: [Dime] DOIC: Self-Contained OLRs

Hi Lionel,

Ulrich

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]]
Sent: Friday, November 29, 2013 11:13 AM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Hi Ulrich,

Lionel

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

Lionel,

We have two cases:

Ulrich

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]]
Sent: Thursday, November 28, 2013 10:31 AM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Hi,

Lionel

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

Hi,

Ulrich

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext Jouni Korhonen
Sent: Wednesday, November 27, 2013 11:44 PM
To: Ben Campbell
Cc: [email-masked] list
Subject: Re: [Dime] DOIC: Self-Contained OLRs

- Jouni

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.

---

From: Jouni Korhonen <[email-masked]>
Date: Mon, 2 Dec 2013 16:38:07 +0200

My understanding (and current editing) has already been towards
what Lionel said below.

- Jouni

---

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Mon, 2 Dec 2013 15:15:32 +0000

Hi Ulrich 

I do not also well see to introduce this concept of in-context versus out-of 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 certain 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 server, if overloaded will send a host OLR, then the DA having selected the server, 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 introduce an in-context versus out-of context.

So I join Nirav and Lionel views

Best regards

JJacques 

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de Jouni Korhonen
Envoyé : lundi 2 décembre 2013 15:38
À : [email-masked]
Cc : Ben Campbell; [email-masked] list
Objet : 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, [email-masked] wrote:

> De : Nirav Salot (nsalot) [mailto:[email-masked]] Envoyé : lundi 2 
> décembre 2013 14:58 À : Wiehe, Ulrich (NSN - DE/Munich) Cc : 
> [email-masked] list; ext Jouni Korhonen; MORAND Lionel IMT/OLN; Ben 
> Campbell Objet : RE: [Dime] DOIC: Self-Contained OLRs
>  
> Ulrich,
> 
> 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)
> 
> If we say that the client can ignore one of the OLRs [Wiehe, Ulrich 
> (NSN - DE/Munich)] only the out-of-context one
> 
> De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:[email-masked]] 
> Envoyé : jeudi 28 novembre 2013 11:30 À : MORAND Lionel IMT/OLN; ext 
> Jouni Korhonen; Ben Campbell Cc : [email-masked] list Objet : RE: 
> [Dime] DOIC: Self-Contained OLRs
> 
> Lionel,
> 
> De : DiME [mailto:[email-masked]] De la part de Wiehe, Ulrich 
> (NSN - DE/Munich) Envoyé : jeudi 28 novembre 2013 10:26 À : ext Jouni 
> Korhonen; Ben Campbell Cc : [email-masked] list Objet : Re: [Dime] 
> DOIC: Self-Contained OLRs
> 
> Hi,
> 
> > 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.
> > 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.)
> > 
> ______________________________________________________________________
> ___________________________________________________
> 
> ______________________________________________________________________
> ___________________________________________________
> 
> ______________________________________________________________________
> ___________________________________________________
> 
> 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.

---

From: Steve Donovan <[email-masked]>
Date: Mon, 02 Dec 2013 09:21:12 -0600

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

---

From: Steve Donovan <[email-masked]>
Date: Mon, 02 Dec 2013 09:24:06 -0600

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

---

From: Steve Donovan <[email-masked]>
Date: Mon, 02 Dec 2013 09:37:20 -0600

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, [email-masked] 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
>
> De : DiME [mailto:[email-masked]] De la part de Nirav Salot (nsalot)
> Envoyé : vendredi 29 novembre 2013 12:24
> À : Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); [email-masked] list
> Cc : Ben Campbell
> 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.
>
> From: DiME [mailto:[email-masked]] On Behalf Of Jouni Korhonen
> Sent: Friday, November 29, 2013 2:50 PM
> To: Wiehe, Ulrich (NSN - DE/Munich); [email-masked] list
> Cc: Ben Campbell
> 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)" <[email-masked]> 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
>>
>>
>>
>> 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.
>>

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Mon, 2 Dec 2013 15:55:21 +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 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:[email-masked]] On Behalf Of Jouni Korhonen
Sent: lunes, 02 de diciembre de 2013 15:38
To: [email-masked]
Cc: Ben Campbell; [email-masked] list
Subject: Re: [Dime] DOIC: Self-Contained OLRs

- Jouni

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Mon, 2 Dec 2013 15:57:36 +0000

Dear all,

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.

Best regards
/MCruz

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Sent: viernes, 29 de noviembre de 2013 16:05
To: [email-masked]
Subject: Re: [Dime] DOIC: Self-Contained OLRs

Dear all

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

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. 

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.

Currently I do not see drawbacks on the OLRs defined for the baseline mechanism. So my comments join the Nirav and Lionel's ones.

Best regards 

JJacques 

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de [email-masked] Envoyé : vendredi 29 novembre 2013 15:32 À : Nirav Salot (nsalot); Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); [email-masked] list Cc : Ben Campbell Objet : Re: [Dime] DOIC: Self-Contained OLRs

Regards,

Lionel

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

Jouni, Ben,

Regards,
Nirav.

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

- JOuni

---

From: <[email-masked]>
Date: Mon, 2 Dec 2013 16:18:30 +0000

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
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:[email-masked]] De la part de Steve Donovan
Envoyé : lundi 2 décembre 2013 16:37
À : [email-masked]
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, [email-masked]<mailto:[email-masked]> wrote:

Regards,

Lionel

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

À : Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); [email-masked]<mailto:[email-masked]> list

Cc : Ben Campbell

Jouni, Ben,

Regards,

Nirav.

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

To: Wiehe, Ulrich (NSN - DE/Munich); [email-masked]<mailto:[email-masked]> list

Cc: Ben Campbell

- JOuni

On Nov 28, 2013, at 12:40 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]><mailto:[email-masked]> wrote:

Hi,

another question:

Ulrich

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

From: ext [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]

Cc: [email-masked]<mailto:[email-masked]> list

Hi,

Lionel

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

Korhonen; Ben Campbell Cc : [email-masked]<mailto:[email-masked]> list Objet : Re: [Dime]

Hi,

Ulrich

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

From: DiME [mailto:[email-masked]] On Behalf Of ext Jouni

Korhonen

To: Ben Campbell

Cc: [email-masked]<mailto:[email-masked]> list

On Nov 28, 2013, at 12:27 AM, Ben Campbell <[email-masked]><mailto:[email-masked]> wrote:

Hi,

- Jouni

Thanks!

Ben.

DiME mailing list

[email-masked]<mailto:[email-masked]>

DiME mailing list

[email-masked]<mailto:[email-masked]>

DiME mailing list

[email-masked]<mailto:[email-masked]>

Thank you.

DiME mailing list

[email-masked]<mailto:[email-masked]>

DiME mailing list

[email-masked]<mailto:[email-masked]>

Thank you.

DiME mailing list

[email-masked]<mailto:[email-masked]>

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 3 Dec 2013 09:20:59 +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 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:[email-masked]] On Behalf Of ext Maria Cruz Bartolome
Sent: Monday, December 02, 2013 4:55 PM
To: [email-masked] list
Subject: Re: [Dime] DOIC: Self-Contained OLRs

Dear all,

Best regards
/MCruz

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Jouni Korhonen
Sent: lunes, 02 de diciembre de 2013 15:38
To: [email-masked]
Cc: Ben Campbell; [email-masked] list
Subject: Re: [Dime] DOIC: Self-Contained OLRs

- Jouni

---

From: <[email-masked]>
Date: Tue, 3 Dec 2013 10:04:38 +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 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:[email-masked]] De la part de Wiehe, Ulrich (NSN - DE/Munich)
Envoyé : mardi 3 décembre 2013 10:21
À : ext Maria Cruz Bartolome; [email-masked] list
Objet : Re: [Dime] DOIC: Self-Contained OLRs

Dear MCruz,

Ulrich

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext Maria Cruz Bartolome
Sent: Monday, December 02, 2013 4:55 PM
To: [email-masked] list
Subject: Re: [Dime] DOIC: Self-Contained OLRs

Dear all,

Best regards
/MCruz

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Jouni Korhonen
Sent: lunes, 02 de diciembre de 2013 15:38
To: [email-masked]
Cc: Ben Campbell; [email-masked] list
Subject: Re: [Dime] DOIC: Self-Contained OLRs

- Jouni

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 3 Dec 2013 10:45:49 +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 

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, December 03, 2013 11:05 AM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Maria Cruz Bartolome; [email-masked] list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Hi Ulrich,

Regards,

Lionel 

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

Dear MCruz,

Ulrich

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext Maria Cruz Bartolome
Sent: Monday, December 02, 2013 4:55 PM
To: [email-masked] list
Subject: Re: [Dime] DOIC: Self-Contained OLRs

Dear all,

Best regards
/MCruz

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Jouni Korhonen
Sent: lunes, 02 de diciembre de 2013 15:38
To: [email-masked]
Cc: Ben Campbell; [email-masked] list
Subject: Re: [Dime] DOIC: Self-Contained OLRs

- Jouni

---

From: <[email-masked]>
Date: Tue, 3 Dec 2013 10:51:28 +0000

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:[email-masked]] 
Envoyé : mardi 3 décembre 2013 11:46
À : MORAND Lionel IMT/OLN; ext Maria Cruz Bartolome; [email-masked] list
Objet : RE: [Dime] DOIC: Self-Contained OLRs

Hi Lionel,

my point is simple:

Ulrich 

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, December 03, 2013 11:05 AM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Maria Cruz Bartolome; [email-masked] list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Hi Ulrich,

Regards,

Lionel 

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

Dear MCruz,

Ulrich

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext Maria Cruz Bartolome
Sent: Monday, December 02, 2013 4:55 PM
To: [email-masked] list
Subject: Re: [Dime] DOIC: Self-Contained OLRs

Dear all,

Best regards
/MCruz

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Jouni Korhonen
Sent: lunes, 02 de diciembre de 2013 15:38
To: [email-masked]
Cc: Ben Campbell; [email-masked] list
Subject: Re: [Dime] DOIC: Self-Contained OLRs

- Jouni

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 3 Dec 2013 13:52:23 +0000

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 [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, December 03, 2013 11:51 AM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Maria Cruz Bartolome; [email-masked] list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Hi Ulrich,

Regards,

Lionel

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

Hi Lionel,

my point is simple:

Ulrich 

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, December 03, 2013 11:05 AM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Maria Cruz Bartolome; [email-masked] list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Hi Ulrich,

Regards,

Lionel 

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

Dear MCruz,

Ulrich

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext Maria Cruz Bartolome
Sent: Monday, December 02, 2013 4:55 PM
To: [email-masked] list
Subject: Re: [Dime] DOIC: Self-Contained OLRs

Dear all,

Best regards
/MCruz

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Jouni Korhonen
Sent: lunes, 02 de diciembre de 2013 15:38
To: [email-masked]
Cc: Ben Campbell; [email-masked] list
Subject: Re: [Dime] DOIC: Self-Contained OLRs

- Jouni

---

From: Steve Donovan <[email-masked]>
Date: Tue, 03 Dec 2013 09:47:22 -0600

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

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 3 Dec 2013 15:56:24 +0000

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:[email-masked]] On Behalf Of ext Steve Donovan
Sent: Tuesday, December 03, 2013 4:47 PM
To: [email-masked]
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

Hi Lionel,

Best regards

Ulrich

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

To: Wiehe, Ulrich (NSN - DE/Munich); ext Maria Cruz Bartolome; [email-masked]<mailto:[email-masked]> list

Hi Ulrich,

Regards,

Lionel

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

À : MORAND Lionel IMT/OLN; ext Maria Cruz Bartolome; [email-masked]<mailto:[email-masked]> list

Hi Lionel,

my point is simple:

Ulrich

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

To: Wiehe, Ulrich (NSN - DE/Munich); ext Maria Cruz Bartolome; [email-masked]<mailto:[email-masked]> list

Hi Ulrich,

Regards,

Lionel

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

À : ext Maria Cruz Bartolome; [email-masked]<mailto:[email-masked]> list

Dear MCruz,

Ulrich

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

To: [email-masked]<mailto:[email-masked]> list

Dear all,

Best regards

/MCruz

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

To: [email-masked]<mailto:[email-masked]>

Cc: Ben Campbell; [email-masked]<mailto:[email-masked]> list

- Jouni

On Dec 2, 2013, at 4:19 PM, [email-masked]<mailto:[email-masked]> wrote:

Regards,

Lionel

[email-masked]<mailto:[email-masked]> list; ext Jouni Korhonen; MORAND Lionel IMT/OLN; Ben

Ulrich,

Regards,

Nirav.

On Dec 2, 2013 5:27 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]><mailto:[email-masked]> wrote:

Nirav,

Ulrich

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

To: Wiehe, Ulrich (NSN - DE/Munich); ext [email-masked]<mailto:[email-masked]>; ext

Jouni Korhonen; Ben Campbell

Ulrich,

I have a basic question.

Regards,

Nirav.

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

To: Nirav Salot (nsalot); ext [email-masked]<mailto:[email-masked]>; ext Jouni

Korhonen; Ben Campbell

Hi Nirav,

please see inline.

Regards

Ulrich

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

To: Wiehe, Ulrich (NSN - DE/Munich); ext [email-masked]<mailto:[email-masked]>; ext

Jouni Korhonen; Ben Campbell

Ulrich,

Regards,

Nirav.

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

To: Nirav Salot (nsalot); ext [email-masked]<mailto:[email-masked]>; ext Jouni

Korhonen; Ben Campbell

Hi Nirav,

Best regards

Ulrich

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

To: Wiehe, Ulrich (NSN - DE/Munich); ext [email-masked]<mailto:[email-masked]>; ext

Jouni Korhonen; Ben Campbell

Hi Ulrich,

Regards,

Nirav.

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

From: DiME [mailto:[email-masked]] On Behalf Of Wiehe, Ulrich

(NSN - DE/Munich)

To: ext [email-masked]<mailto:[email-masked]>; ext Jouni Korhonen; Ben Campbell

Hi Lionel,

Ulrich

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

Hi Ulrich,

Lionel

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

Jouni Korhonen; Ben Campbell Cc : [email-masked]<mailto:[email-masked]> list Objet : RE:

Lionel,

We have two cases:

Ulrich

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

Hi,

Lionel

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

Hi,

Ulrich

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

Korhonen

To: Ben Campbell

Hi,

- Jouni

Thanks!

Ben.

DiME mailing list

DiME mailing list

DiME mailing list

Thank you.

Thank you.

DiME mailing list

Thank you.

DiME mailing list

DiME mailing list

DiME mailing list

Thank you.

Thank you.

DiME mailing list

---

From: Steve Donovan <[email-masked]>
Date: Tue, 03 Dec 2013 09:58:45 -0600

Ulrich,

Thanks for your clarification.

Steve

On 12/3/13 9:56 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> 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:[email-masked]] *On Behalf Of *ext Steve
> Donovan
> *Sent:* Tuesday, December 03, 2013 4:47 PM
> *To:* [email-masked]
> *Subject:* Re: [Dime] DOIC: Self-Contained OLRs
>
>  
>
>     From: ext [email-masked] <mailto:[email-masked]> [mailto:[email-masked]] 
>
>     To: Wiehe, Ulrich (NSN - DE/Munich); ext Maria Cruz Bartolome; [email-masked] <mailto:[email-masked]> list
>
>     À : MORAND Lionel IMT/OLN; ext Maria Cruz Bartolome; [email-masked] <mailto:[email-masked]> list
>
>     From: ext [email-masked] <mailto:[email-masked]> [mailto:[email-masked]] 
>
>     To: Wiehe, Ulrich (NSN - DE/Munich); ext Maria Cruz Bartolome; [email-masked] <mailto:[email-masked]> list
>
>     À : ext Maria Cruz Bartolome; [email-masked] <mailto:[email-masked]> list
>
>     To: [email-masked] <mailto:[email-masked]> list
>
>     To: [email-masked] <mailto:[email-masked]>
>
>     Cc: Ben Campbell; [email-masked] <mailto:[email-masked]> list
>
>     On Dec 2, 2013, at 4:19 PM, [email-masked] <mailto:[email-masked]> wrote:
>
>      
>
>         [email-masked] <mailto:[email-masked]> list; ext Jouni Korhonen; MORAND Lionel IMT/OLN; Ben 
>
>         On Dec 2, 2013 5:27 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]> <mailto:[email-masked]> wrote:
>
>         Nirav,
>
>          
>
>         To: Wiehe, Ulrich (NSN - DE/Munich); ext [email-masked] <mailto:[email-masked]>; ext 
>
>         Cc: [email-masked] <mailto:[email-masked]> list
>
>         To: Nirav Salot (nsalot); ext [email-masked] <mailto:[email-masked]>; ext Jouni 
>
>         Korhonen; Ben Campbell
>
>         Cc: [email-masked] <mailto:[email-masked]> list
>
>         To: Wiehe, Ulrich (NSN - DE/Munich); ext [email-masked] <mailto:[email-masked]>; ext 
>
>         Cc: [email-masked] <mailto:[email-masked]> list
>
>         To: Nirav Salot (nsalot); ext [email-masked] <mailto:[email-masked]>; ext Jouni 
>
>         Korhonen; Ben Campbell
>
>         Cc: [email-masked] <mailto:[email-masked]> list
>
>         To: Wiehe, Ulrich (NSN - DE/Munich); ext [email-masked] <mailto:[email-masked]>; ext 
>
>         Cc: [email-masked] <mailto:[email-masked]> list
>
>         To: ext [email-masked] <mailto:[email-masked]>; ext Jouni Korhonen; Ben Campbell
>
>         Cc: [email-masked] <mailto:[email-masked]> list
>
>         From: ext [email-masked] <mailto:[email-masked]> [mailto:[email-masked]]
>
>         Cc: [email-masked] <mailto:[email-masked]> list
>
>         Jouni Korhonen; Ben Campbell Cc : [email-masked] <mailto:[email-masked]> list Objet : RE: 
>
>         From: ext [email-masked] <mailto:[email-masked]> [mailto:[email-masked]]
>
>         Cc: [email-masked] <mailto:[email-masked]> list
>
>         Korhonen; Ben Campbell Cc : [email-masked] <mailto:[email-masked]> list Objet : Re: [Dime] 
>
>         Cc: [email-masked] <mailto:[email-masked]> list
>
>         On Nov 28, 2013, at 12:27 AM, Ben Campbell <[email-masked]> <mailto:[email-masked]> wrote:
>
>          
>
>             Hi,
>
>              
>
>             [email-masked] <mailto:[email-masked]>
>
>         [email-masked] <mailto:[email-masked]>
>
>         [email-masked] <mailto:[email-masked]>
>
>         [email-masked] <mailto:[email-masked]>
>
>     [email-masked] <mailto:[email-masked]>
>
>     [email-masked] <mailto:[email-masked]>
>
>     [email-masked] <mailto:[email-masked]>
>
>     [email-masked] <mailto:[email-masked]>
>

---

From: Ben Campbell <[email-masked]>
Date: Tue, 3 Dec 2013 16:36:55 -0600

> 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 pigg…

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

---

From: Ben Campbell <[email-masked]>
Date: Tue, 3 Dec 2013 16:44:03 -0600

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

---

From: Ben Campbell <[email-masked]>
Date: Tue, 3 Dec 2013 16:51:04 -0600

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 <[email-masked]> wrote:

>> From: ext 
>> [email-masked] [mailto:[email-masked]
>> ] 
>> To: Wiehe, Ulrich (NSN - DE/Munich); ext Maria Cruz Bartolome; 
>> [email-masked]
>>  list
>> De : Wiehe, Ulrich (NSN - DE/Munich) [
>> mailto:[email-masked]
>> ] 
>> À : MORAND Lionel IMT/OLN; ext Maria Cruz Bartolome; 
>> [email-masked]
>>  list
>> From: ext 
>> [email-masked] [mailto:[email-masked]
>> ] 
>> To: Wiehe, Ulrich (NSN - DE/Munich); ext Maria Cruz Bartolome; 
>> [email-masked]
>>  list
>> De : DiME [
>> mailto:[email-masked]
>> ] De la part de Wiehe, Ulrich (NSN - DE/Munich)
>> À : ext Maria Cruz Bartolome; 
>> [email-masked]
>>  list
>> From: DiME [
>> mailto:[email-masked]
>> ] On Behalf Of ext Maria Cruz Bartolome
>> To: 
>> [email-masked]
>>  list
>> From: DiME [
>> mailto:[email-masked]
>> ] On Behalf Of Jouni Korhonen
>> Cc: Ben Campbell; 
>> [email-masked]
>>  list
>> On Dec 2, 2013, at 4:19 PM, 
>> [email-masked]
>>  wrote:
>> 
>> 
>>> De : Nirav Salot (nsalot) [
>>> mailto:[email-masked]
>>> ] Envoyé : lundi 2 
>>> [email-masked]
>>>  list; ext Jouni Korhonen; MORAND Lionel IMT/OLN; Ben 
>>> On Dec 2, 2013 5:27 PM, "Wiehe, Ulrich (NSN - DE/Munich)" 
>>> <[email-masked]>
>>>  wrote:
>>> Nirav,
>>> 
>>> From: ext Nirav Salot (nsalot) [
>>> mailto:[email-masked]
>>> ]
>>> To: Wiehe, Ulrich (NSN - DE/Munich); ext 
>>> [email-masked]
>>> ; ext 
>>> Cc: 
>>> [email-masked]
>>>  list
>>> From: Wiehe, Ulrich (NSN - DE/Munich) [
>>> mailto:[email-masked]
>>> ]
>>> To: Nirav Salot (nsalot); ext 
>>> [email-masked]
>>> ; ext Jouni 
>>> Korhonen; Ben Campbell
>>> Cc: 
>>> [email-masked]
>>>  list
>>> From: ext Nirav Salot (nsalot) [
>>> mailto:[email-masked]
>>> ]
>>> To: Wiehe, Ulrich (NSN - DE/Munich); ext 
>>> [email-masked]
>>> ; ext 
>>> Cc: 
>>> [email-masked]
>>>  list
>>> From: Wiehe, Ulrich (NSN - DE/Munich) [
>>> mailto:[email-masked]
>>> ]
>>> To: Nirav Salot (nsalot); ext 
>>> [email-masked]
>>> ; ext Jouni 
>>> Korhonen; Ben Campbell
>>> Cc: 
>>> [email-masked]
>>>  list
>>> From: ext Nirav Salot (nsalot) [
>>> mailto:[email-masked]
>>> ]
>>> To: Wiehe, Ulrich (NSN - DE/Munich); ext 
>>> [email-masked]
>>> ; ext 
>>> Cc: 
>>> [email-masked]
>>>  list
>>> From: DiME [
>>> mailto:[email-masked]
>>> ] On Behalf Of Wiehe, Ulrich 
>>> (NSN - DE/Munich)
>>> To: ext 
>>> [email-masked]
>>> ; ext Jouni Korhonen; Ben Campbell
>>> Cc: 
>>> [email-masked]
>>>  list
>>> From: ext 
>>> [email-masked] [mailto:[email-masked]
>>> ]
>>> Cc: 
>>> [email-masked]
>>>  list
>>> De : Wiehe, Ulrich (NSN - DE/Munich) [
>>> mailto:[email-masked]
>>> ] 
>>> Jouni Korhonen; Ben Campbell Cc : 
>>> [email-masked]
>>>  list Objet : RE: 
>>> From: ext 
>>> [email-masked] [mailto:[email-masked]
>>> ]
>>> Cc: 
>>> [email-masked]
>>>  list
>>> De : DiME [
>>> mailto:[email-masked]
>>> ] De la part de Wiehe, Ulrich 
>>> Korhonen; Ben Campbell Cc : 
>>> [email-masked]
>>>  list Objet : Re: [Dime] 
>>> From: DiME [
>>> mailto:[email-masked]
>>> ] On Behalf Of ext Jouni 
>>> Korhonen
>>> Cc: 
>>> [email-masked]
>>>  list
>>> On Nov 28, 2013, at 12:27 AM, Ben Campbell 
>>> <[email-masked]>
>>>  wrote:
>>> 
>>> 
>>>> Hi,
>>>>

---

From: Ben Campbell <[email-masked]>
Date: Tue, 3 Dec 2013 16:52:34 -0600

On Dec 3, 2013, at 9:56 AM, Wiehe, Ulrich (NSN - DE/Munich) <[email-masked]> wrote:

> Steve,
>  
> I didn’t say that there can never be more than one OLR.

Can we restate the "not forced to process" to say "not be forced to choose between ambiguous" OLRs?

---

From: Ben Campbell <[email-masked]>
Date: Tue, 3 Dec 2013 16:56:04 -0600

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

---

From: Ben Campbell <[email-masked]>
Date: Tue, 3 Dec 2013 17:00:10 -0600

On Dec 2, 2013, at 9:24 AM, Steve Donovan <[email-masked]> wrote:

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

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

>> ] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
>> mailto:[email-masked]] Envoyé : jeudi 28 novembre 2013 11:30 À : MORAND Lionel IMT/OLN; ext Jouni Korhonen; Ben Campbell Cc : [email-masked]
>>  list Objet : RE: [Dime] DOIC: Self-Contained OLRs
>> 
>> Lionel,
>> 
>> mailto:[email-masked]] De la part de Wiehe, Ulrich (NSN - DE/Munich) Envoyé : jeudi 28 novembre 2013 10:26 À : ext Jouni Korhonen; Ben Campbell Cc : [email-masked]
>>  list Objet : Re: [Dime] DOIC: Self-Contained OLRs
>> 
>> Hi,
>> 
>> ] On Behalf Of ext Jouni Korhonen

---

From: Ben Campbell <[email-masked]>
Date: Tue, 3 Dec 2013 17:01:52 -0600

> 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…

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.

---

From: Ben Campbell <[email-masked]>
Date: Tue, 3 Dec 2013 17:15:08 -0600

(oops, sorry, I sent my previous response before I was finished.

> 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…

It's not clear to me that piggybacking implies any particular relationship between an OLR and the enclosing message, other than transport.

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

>  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 overl…

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.

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

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

---

From: <[email-masked]>
Date: Tue, 3 Dec 2013 23:17:57 +0000

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

Regards,

Lionel

-----Message d'origine-----
De : Ben Campbell [mailto:[email-masked]] 
Envoyé : mardi 3 décembre 2013 23:56
À : MORAND Lionel IMT/OLN
Cc : Steve Donovan; [email-masked]
Objet : Re: [Dime] DOIC: Self-Contained OLRs

---

From: <[email-masked]>
Date: Tue, 3 Dec 2013 23:50:15 +0000

In addition, if a totally application-independent solution to convey any type of overload report for any application, the more straightforward solution would have been the definition of a new application.

I think that we have to be pragmatic. A lot of meeting time and email discussions have been spent on this topic since more than one year and we are about to miss the deadline for a stable document that could be used as reference 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 in order to let 3GPP know what to do.

Regards,

Lionel

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de [email-masked]
Envoyé : mercredi 4 décembre 2013 00:18
À : Ben Campbell
Cc : [email-masked]
Objet : Re: [Dime] DOIC: Self-Contained OLRs

Hi Ben,

Regards,

Lionel

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 4 Dec 2013 08:23:18 +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 which are ambiguous?

Let's try to avoid complexity.

Ulrich

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 4 Dec 2013 08:40:31 +0000

Ben,

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.

Ulrich

---

From: Ben Campbell <[email-masked]>
Date: Wed, 4 Dec 2013 15:43:21 -0600

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

---

From: Ben Campbell <[email-masked]>
Date: Wed, 4 Dec 2013 15:44:18 -0600

> 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 n…

Assuming we add ReportType to the list of things for which we advertise support, I agree.

---

From: Ben Campbell <[email-masked]>
Date: Wed, 4 Dec 2013 15:54:55 -0600

> 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 po…

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 mig…

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

---

From: <[email-masked]>
Date: Thu, 5 Dec 2013 00:03:26 +0000

Hi Ben, Ulrich,

Please see below.

Lionel

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de Ben Campbell
Envoyé : mercredi 4 décembre 2013 22:43
À : Wiehe, Ulrich (NSN - DE/Munich)
Cc : [email-masked]
Objet : Re: [Dime] DOIC: Self-Contained OLRs

[LM] it is why it is proposed to avoid multiple OLRs with the same report type in the same answer.

---

From: <[email-masked]>
Date: Thu, 5 Dec 2013 00:08:03 +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 Realm", so why will the reacting node not support one of them?

Regards,

Lionel

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de Ben Campbell
Envoyé : mercredi 4 décembre 2013 22:44
À : Wiehe, Ulrich (NSN - DE/Munich)
Cc : [email-masked] list
Objet : Re: [Dime] DOIC: Self-Contained OLRs

---

From: <[email-masked]>
Date: Thu, 5 Dec 2013 00:42:43 +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 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:[email-masked]] 
Envoyé : mercredi 4 décembre 2013 22:55
À : MORAND Lionel IMT/OLN
Cc : [email-masked]
Objet : Re: [Dime] DOIC: Self-Contained OLRs

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Thu, 5 Dec 2013 02:22:55 +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 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:[email-masked]] On Behalf Of [email-masked]
Sent: jueves, 05 de diciembre de 2013 1:43
To: Ben Campbell
Cc: [email-masked]
Subject: Re: [Dime] DOIC: Self-Contained OLRs

Hi Ben,

Regards,

Lionel

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 5 Dec 2013 08:55:23 +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 corresponding request would have matched) and that is the OLR the reacting node 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 order to let the reacting node detect without referring back to the original request 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 exchange 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 anything 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') between A and S. The different DOIC associations d and d' may have different advertised/negotiated features and must be strictly separated. An host-type OLR sent from S to A is in-context for d' but not for d and therefore must not be forwarded transparently to C (it can be forwarded but then it must be marked as "out-of-context"). 

Ulrich

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]] 
Sent: Thursday, December 05, 2013 1:03 AM
To: Ben Campbell; Wiehe, Ulrich (NSN - DE/Munich)
Cc: [email-masked]
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Hi Ben, Ulrich,

Please see below.

Lionel

---

From: "Nirav Salot (nsalot)" <[email-masked]>
Date: Thu, 5 Dec 2013 09:29:29 +0000

> 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 define the current solution with all the future imagination which may or may not come true. 

Regards,
Nirav.

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Ben Campbell
Sent: Wednesday, December 04, 2013 4:14 AM
To: Maria Cruz Bartolome
Cc: [email-masked]
Subject: Re: [Dime] DOIC: Self-Contained OLRs

> De : DiME [mailto:[email-masked]] De la part de 
> [email-masked] Envoyé : vendredi 29 novembre 2013 15:32 À : 
> Nirav Salot (nsalot); Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); 
> [email-masked] list Cc : Ben Campbell Objet : Re: [Dime] DOIC: 
> Self-Contained OLRs
> 
> De : DiME [mailto:[email-masked]] De la part de Nirav Salot 
> (nsalot) Envoyé : vendredi 29 novembre 2013 12:24 À : Jouni Korhonen; 
> Wiehe, Ulrich (NSN - DE/Munich); [email-masked] list Cc : Ben Campbell 
> - 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?
>> 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.
>> _____________________________________________________________________
>> _ ___________________________________________________
>>

---

From: "Nirav Salot (nsalot)" <[email-masked]>
Date: Thu, 5 Dec 2013 09:29:33 +0000

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 f…
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.

---

From: "Nirav Salot (nsalot)" <[email-masked]>
Date: Thu, 5 Dec 2013 09:29:36 +0000

I fully agree with Lionel, below.

Besides, in future, if and when we have to define a new dedicated application for conveying OC-OLR, we may have to define lot of new aspects from scratch. And lets worry about all of those aspects at that point of time instead of trying to solve some of those aspects today - e.g. we may be able to carry the OC-OLR defined today in a new dedicated application in future.

Regards,
Nirav.

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, December 04, 2013 5:20 AM
To: Ben Campbell
Cc: [email-masked]
Subject: Re: [Dime] DOIC: Self-Contained OLRs

Regards,

Lionel

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de [email-masked] Envoyé : mercredi 4 décembre 2013 00:18 À : Ben Campbell Cc : [email-masked] Objet : Re: [Dime] DOIC: Self-Contained OLRs

Hi Ben,

Regards,

Lionel

-----Message d'origine-----
De : Ben Campbell [mailto:[email-masked]] Envoyé : mardi 3 décembre 2013 23:56 À : MORAND Lionel IMT/OLN Cc : Steve Donovan; [email-masked] Objet : Re: [Dime] DOIC: Self-Contained OLRs

---

From: "Nirav Salot (nsalot)" <[email-masked]>
Date: Thu, 5 Dec 2013 09:29:39 +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 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:[email-masked]] On Behalf Of Maria Cruz Bartolome
Sent: Thursday, December 05, 2013 7:53 AM
To: [email-masked]
Subject: Re: [Dime] DOIC: Self-Contained OLRs

Dear all,

Regards
/MCruz

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: jueves, 05 de diciembre de 2013 1:43
To: Ben Campbell
Cc: [email-masked]
Subject: Re: [Dime] DOIC: Self-Contained OLRs

Hi Ben,

Regards,

Lionel 

-----Message d'origine-----
De : Ben Campbell [mailto:[email-masked]] Envoyé : mercredi 4 décembre 2013 22:55 À : MORAND Lionel IMT/OLN Cc : [email-masked] Objet : Re: [Dime] DOIC: Self-Contained OLRs

> De : Ben Campbell [mailto:[email-masked]] Envoyé : mardi 3 décembre 
> 2013 23:56 À : MORAND Lionel IMT/OLN Cc : Steve Donovan; [email-masked]

---

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Thu, 5 Dec 2013 11:14:20 +0000

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:[email-masked]] De la part de Ben Campbell
Envoyé : mercredi 4 décembre 2013 22:55
À : ext [email-masked]
Cc : [email-masked]
Objet : Re: [Dime] DOIC: Self-Contained OLRs

---

From: Steve Donovan <[email-masked]>
Date: Thu, 05 Dec 2013 06:48:25 -0600

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

---

From: Steve Donovan <[email-masked]>
Date: Thu, 05 Dec 2013 06:55:40 -0600

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

---

From: <[email-masked]>
Date: Thu, 5 Dec 2013 12:56:46 +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:[email-masked]] De la part de Steve Donovan
Envoyé : jeudi 5 décembre 2013 13:48
À : [email-masked]
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

Ben,

Regards,

Nirav.

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

To: Nirav Salot (nsalot)

Cc: Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); [email-masked]<mailto:[email-masked]> list

On Nov 29, 2013, at 5:24 AM, Nirav Salot (nsalot) <[email-masked]><mailto:[email-masked]> wrote:

Jouni, Ben,

Regards,

Nirav.

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

Cc: Ben Campbell

- JOuni

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

;)

Hi,

another question:

Ulrich

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

Hi,

Lionel

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

Hi,

Ulrich

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

Korhonen

To: Ben Campbell

Hi,

- Jouni

Thanks!

Ben.

DiME mailing list

DiME mailing list

DiME mailing list

Thank you.

DiME mailing list

DiME mailing list

DiME mailing list

---

From: Steve Donovan <[email-masked]>
Date: Thu, 05 Dec 2013 07:05:34 -0600

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

---

From: Steve Donovan <[email-masked]>
Date: Thu, 05 Dec 2013 07:09:47 -0600

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, [email-masked] wrote:
> *De :*DiME [mailto:[email-masked]] *De la part de* Steve Donovan
> *Envoyé :* jeudi 5 décembre 2013 13:48
> *À :* [email-masked]
> *Objet :* Re: [Dime] DOIC: Self-Contained OLRs
>
>  
>
> All,
>
> 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
>
>     Cc: Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); [email-masked] <mailto:[email-masked]> list
>
>     On Nov 29, 2013, at 5:24 AM, Nirav Salot (nsalot) <[email-masked]> <mailto:[email-masked]> wrote:
>
>      
>
>         Jouni, Ben,
>
>          
>
>         To: Wiehe, Ulrich (NSN - DE/Munich); [email-masked] <mailto:[email-masked]> list
>
>         Cc: Ben Campbell
>
>         On Nov 28, 2013, at 12:40 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]> <mailto:[email-masked]> wrote:
>
>          
>
>             Hi,
>
>              
>
>             another question:
>
>              
>

---

From: <[email-masked]>
Date: Thu, 5 Dec 2013 13:28:06 +0000

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:[email-masked]] De la part de Steve Donovan
Envoyé : jeudi 5 décembre 2013 14:06
À : [email-masked]
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

Hi

Best regards

JJacques

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

À : ext [email-masked]<mailto:[email-masked]>

Cc : [email-masked]<mailto:[email-masked]>

On Dec 3, 2013, at 5:17 PM, [email-masked]<mailto:[email-masked]> wrote:

Hi Ben,

Regards,

Lionel

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

2013 23:56 À : MORAND Lionel IMT/OLN Cc : Steve Donovan; [email-masked]<mailto:[email-masked]>

On Dec 2, 2013, at 10:18 AM, [email-masked]<mailto:[email-masked]> wrote:

Hi Steve,

Regards,

Lionel

À : [email-masked]<mailto:[email-masked]>

Steve

Regards,

Lionel

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

Cc : Ben Campbell

Jouni, Ben,

Regards,

Nirav.

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

Cc: Ben Campbell

- JOuni

Hi,

another question:

Ulrich

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

Hi,

Lionel

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

Hi,

Ulrich

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

Korhonen

To: Ben Campbell

Hi,

- Jouni

Thanks!

Ben.

DiME mailing list

DiME mailing list

DiME mailing list

Thank you.

DiME mailing list

DiME mailing list

Thank you.

DiME mailing list

Thank you.

DiME mailing list

Thank you.

DiME mailing list

DiME mailing list

DiME mailing list

---

From: "Nirav Salot (nsalot)" <[email-masked]>
Date: Thu, 5 Dec 2013 13:49:17 +0000

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:[email-masked]] On Behalf Of Steve Donovan
Sent: Thursday, December 05, 2013 6:26 PM
To: [email-masked]
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

Regards,

Nirav.

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

To: [email-masked]<mailto:[email-masked]>

Dear all,

Regards

/MCruz

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

From: DiME [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>

To: Ben Campbell

Cc: [email-masked]<mailto:[email-masked]>

Hi Ben,

Regards,

Lionel

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

De : Ben Campbell [mailto:[email-masked]] Envoyé : mercredi 4 décembre 2013 22:55 À : MORAND Lionel IMT/OLN Cc : [email-masked]<mailto:[email-masked]> Objet : Re: [Dime] DOIC: Self-Contained OLRs

Hi Ben,

Regards,

Lionel

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

Hi Steve,

Regards,

Lionel

Steve

Regards,

Lionel

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

Cc : Ben Campbell

Jouni, Ben,

Regards,

Nirav.

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

Cc: Ben Campbell

- JOuni

Hi,

another question:

Ulrich

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

Hi,

Lionel

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

Hi,

Ulrich

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

Korhonen

To: Ben Campbell

Hi,

- Jouni

Thanks!

Ben.

DiME mailing list

DiME mailing list

DiME mailing list

Thank you.

DiME mailing list

DiME mailing list

Thank you.

DiME mailing list

Thank you.

DiME mailing list

Thank you.

DiME mailing list

Thank you.

DiME mailing list

DiME mailing list

DiME mailing list

---

From: Steve Donovan <[email-masked]>
Date: Thu, 05 Dec 2013 07:51:54 -0600

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, [email-masked] 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.
>
>  
>
> Could everyone live/survive with the "implicit approach" with the
> extensibility mechanism allowing future extensions if needed?
>
>  
>
> *Envoyé :* jeudi 5 décembre 2013 14:06
> *À :* [email-masked]
> 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
>
>     À : ext [email-masked] <mailto:[email-masked]>
>
>     Cc : [email-masked] <mailto:[email-masked]>
>
>     On Dec 3, 2013, at 5:17 PM, [email-masked] <mailto:[email-masked]> wrote:
>
>      
>
>         Hi Ben,
>
>          
>
>         2013 23:56 À : MORAND Lionel IMT/OLN Cc : Steve Donovan; [email-masked] <mailto:[email-masked]> 
>
>         On Dec 2, 2013, at 10:18 AM, [email-masked] <mailto:[email-masked]> wrote:
>
>          
>
>             Hi Steve,
>
>              
>
>             À : [email-masked] <mailto:[email-masked]>
>
>             On 11/29/13 8:31 AM, [email-masked] <mailto:[email-masked]> wrote:
>
>             À : Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); [email-masked] <mailto:[email-masked]> list
>
>             Cc : Ben Campbell
>

---

From: "Nirav Salot (nsalot)" <[email-masked]>
Date: Thu, 5 Dec 2013 13:59:38 +0000

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

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.

Regards,
Nirav.

From: DiME [mailto:[email-masked]] On Behalf Of Steve Donovan
Sent: Thursday, December 05, 2013 7:22 PM
To: [email-masked]
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, [email-masked]<mailto:[email-masked]> wrote:
All,

Regards,

Lionel

Steve

Hi

Best regards

JJacques

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

Hi Ben,

Regards,

Lionel

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

Hi Steve,

Regards,

Lionel

Steve

Regards,

Lionel

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

Cc : Ben Campbell

Jouni, Ben,

Regards,

Nirav.

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

Cc: Ben Campbell

- JOuni

Hi,

another question:

Ulrich

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

Hi,

Lionel

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

Hi,

Ulrich

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

Korhonen

To: Ben Campbell

Hi,

- Jouni

Thanks!

Ben.

DiME mailing list

DiME mailing list

DiME mailing list

Thank you.

DiME mailing list

DiME mailing list

Thank you.

DiME mailing list

Thank you.

DiME mailing list

Thank you.

DiME mailing list

DiME mailing list

DiME mailing list

Thank you.

DiME mailing list

---

From: <[email-masked]>
Date: Thu, 5 Dec 2013 14:01:08 +0000

Hi Steve,

So let's go on the discussion.

As individual below...

De : DiME [mailto:[email-masked]] De la part de Steve Donovan
Envoyé : jeudi 5 décembre 2013 14:52
À : [email-masked]
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?

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.

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

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.

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

Regards,

Lionel

Steve

Hi

Best regards

JJacques

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

Hi Ben,

Regards,

Lionel

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

Hi Steve,

Regards,

Lionel

Steve

Regards,

Lionel

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

Cc : Ben Campbell

Jouni, Ben,

Regards,

Nirav.

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

Cc: Ben Campbell

- JOuni

Hi,

another question:

Ulrich

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

Hi,

Lionel

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

Hi,

Ulrich

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

Korhonen

To: Ben Campbell

Hi,

- Jouni

Thanks!

Ben.

DiME mailing list

DiME mailing list

DiME mailing list

Thank you.

DiME mailing list

DiME mailing list

Thank you.

DiME mailing list

Thank you.

DiME mailing list

Thank you.

DiME mailing list

DiME mailing list

DiME mailing list

Thank you.

DiME mailing list

---

From: Steve Donovan <[email-masked]>
Date: Thu, 05 Dec 2013 08:08:16 -0600

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:[email-masked]] *On Behalf Of *Steve Donovan
> *Sent:* Thursday, December 05, 2013 6:26 PM
> *To:* [email-masked]
> 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
>
>     To: [email-masked] <mailto:[email-masked]>
>
>     From: DiME [mailto:[email-masked]] On Behalf Of [email-masked] <mailto:[email-masked]>
>
>     Cc: [email-masked] <mailto:[email-masked]>
>
>     De : Ben Campbell [mailto:[email-masked]] Envoyé : mercredi 4 décembre 2013 22:55 À : MORAND Lionel IMT/OLN Cc : [email-masked] <mailto:[email-masked]> Objet : Re: [Dime] DOIC: Self-Contained OLRs
>
>      
>

---

From: Steve Donovan <[email-masked]>
Date: Thu, 05 Dec 2013 08:14:57 -0600

Lionel,

Please see my responses inline.

Steve

On 12/5/13 8:01 AM, [email-masked] wrote:
> *Envoyé :* jeudi 5 décembre 2013 14:52
> *À :* [email-masked]
> */[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.
> */[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.
>
> 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.
> */[LM] and I would say "NO"/*
>
> Steve
>
>     *À :* [email-masked] <mailto:[email-masked]>
>     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
>

---

From: "Nirav Salot (nsalot)" <[email-masked]>
Date: Thu, 5 Dec 2013 14:25:29 +0000

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:[email-masked]]
Sent: Thursday, December 05, 2013 7:38 PM
To: Nirav Salot (nsalot); [email-masked]
Subject: Re: [Dime] DOIC: Self-Contained OLRs

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

Regards,
Nirav.

Steve

Regards,

Nirav.

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

Dear all,

Regards

/MCruz

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

To: Ben Campbell

Hi Ben,

Regards,

Lionel

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

Hi Ben,

Regards,

Lionel

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

Hi Steve,

Regards,

Lionel

Steve

Regards,

Lionel

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

Cc : Ben Campbell

Jouni, Ben,

Regards,

Nirav.

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

Cc: Ben Campbell

- JOuni

Hi,

another question:

Ulrich

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

Hi,

Lionel

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

Hi,

Ulrich

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

Korhonen

To: Ben Campbell

Hi,

- Jouni

Thanks!

Ben.

DiME mailing list

DiME mailing list

DiME mailing list

Thank you.

DiME mailing list

DiME mailing list

Thank you.

DiME mailing list

Thank you.

DiME mailing list

Thank you.

DiME mailing list

Thank you.

DiME mailing list

DiME mailing list

DiME mailing list

---

From: Steve Donovan <[email-masked]>
Date: Thu, 05 Dec 2013 08:37:22 -0600

Nirav,

Please see comments inline.

Regards,

Steve

On 12/5/13 7:59 AM, Nirav Salot (nsalot) wrote:
> 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. 
> *Sent:* Thursday, December 05, 2013 7:22 PM
> *To:* [email-masked]

---

From: Steve Donovan <[email-masked]>
Date: Thu, 05 Dec 2013 08:46:38 -0600

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:[email-masked]]
> *Sent:* Thursday, December 05, 2013 7:38 PM
> *To:* Nirav Salot (nsalot); [email-masked]
>     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).
>
>     values are different for any reason... what means that it may
>     always be required to check both implicit and explicit data.
>
>      
>
>     Regards,
>
>     Nirav.
>
>      
>
>     *To:* [email-masked] <mailto:[email-masked]>
>     If we equating "complexity" with work done by a Diameter node,
>     then there is added "complexity" for both proposals.
>
>     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
>

---

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Thu, 5 Dec 2013 15:00:50 +0000

Hi Steve, Ben

I come back to the few months ago discussion  on the Roach-Draft where there 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 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 proceed, which drove to the current draft content. 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 approach . There is  no reason currently to add further complexity with self contained 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 characteristics 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 discussion 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 scopes with draft roach, we may efectively endanger the schedule.

Best regards

JJacques

De : DiME [mailto:[email-masked]] De la part de Steve Donovan
Envoyé : jeudi 5 décembre 2013 15:47
À : Nirav Salot (nsalot); [email-masked]
Objet : Re: [Dime] DOIC: Self-Contained OLRs

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

Regards,
Nirav.

From: Steve Donovan [mailto:[email-masked]]
Sent: Thursday, December 05, 2013 7:38 PM
To: Nirav Salot (nsalot); [email-masked]<mailto:[email-masked]>
Subject: Re: [Dime] DOIC: Self-Contained OLRs

Steve

Regards,
Nirav.

Steve

Regards,

Nirav.

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

Dear all,

Regards

/MCruz

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

To: Ben Campbell

Hi Ben,

Regards,

Lionel

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

Hi Ben,

Regards,

Lionel

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

Hi Steve,

Regards,

Lionel

Steve

Regards,

Lionel

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

Cc : Ben Campbell

Jouni, Ben,

Regards,

Nirav.

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

Cc: Ben Campbell

- JOuni

Hi,

another question:

Ulrich

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

Hi,

Lionel

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

Hi,

Ulrich

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

Korhonen

To: Ben Campbell

Hi,

- Jouni

Thanks!

Ben.

DiME mailing list

DiME mailing list

DiME mailing list

Thank you.

DiME mailing list

DiME mailing list

Thank you.

DiME mailing list

Thank you.

DiME mailing list

Thank you.

DiME mailing list

Thank you.

DiME mailing list

DiME mailing list

DiME mailing list

---

From: <[email-masked]>
Date: Thu, 5 Dec 2013 15:13:52 +0000

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

Lionel

Nirav,

Steve

Regards,
Nirav.

Steve

Regards,
Nirav.

Steve

Regards,

Nirav.

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

Dear all,

Regards

/MCruz

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

To: Ben Campbell

Hi Ben,

Regards,

Lionel

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

Hi Ben,

Regards,

Lionel

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

Hi Steve,

Regards,

Lionel

Steve

Regards,

Lionel

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

Cc : Ben Campbell

Jouni, Ben,

Regards,

Nirav.

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

Cc: Ben Campbell

- JOuni

Hi,

another question:

Ulrich

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

Hi,

Lionel

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

Hi,

Ulrich

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

Korhonen

To: Ben Campbell

Hi,

- Jouni

Thanks!

Ben.

DiME mailing list

DiME mailing list

DiME mailing list

Thank you.

DiME mailing list

DiME mailing list

Thank you.

DiME mailing list

Thank you.

DiME mailing list

Thank you.

DiME mailing list

Thank you.

DiME mailing list

DiME mailing list

DiME mailing list

---

From: Ben Campbell <[email-masked]>
Date: Thu, 5 Dec 2013 18:13:15 -0600

> 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…

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.

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

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.

---

From: Ben Campbell <[email-masked]>
Date: Thu, 5 Dec 2013 18:23:19 -0600

> Could everyone live/survive with the "implicit approach" with the extensibility mechanism allowing future extensions if needed?

I can grudgingly "live with it", as long as our extensibility features allow us to create future extensions that work differently. 

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. 

 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 Korhonen <[email-masked]>
Date: Fri, 6 Dec 2013 12:31:30 +0200

> 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

---

From: Ben Campbell <[email-masked]>
Date: Fri, 6 Dec 2013 15:37:20 -0600

> approach: allocate a new feature flag and define how to use it.

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.

---

From: "Shishufeng (Susan)" <[email-masked]>
Date: Mon, 9 Dec 2013 09:51:03 +0000

Hello all,

I'm trying to follow up all these discussions.

Firstly quick answer to Steve's following question, "Strongly No" to have self-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 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 I'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 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:[email-masked]]
Sent: Thursday, December 05, 2013 10:00 PM
To: Steve Donovan; [email-masked]
Subject: Re: [Dime] DOIC: Self-Contained OLRs

Steve,

Strongly NO.

Regards,
Nirav.

Lionel,

Steve

Regards,

Lionel

Steve

Hi

Best regards

JJacques

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

Hi Ben,

Regards,

Lionel

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

Hi Steve,

Regards,

Lionel

Steve

Regards,

Lionel

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

Cc : Ben Campbell

Jouni, Ben,

Regards,

Nirav.

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

Cc: Ben Campbell

- JOuni

Hi,

another question:

Ulrich

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

Hi,

Lionel

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

Hi,

Ulrich

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

Korhonen

To: Ben Campbell

Hi,

- Jouni

Thanks!

Ben.

DiME mailing list

DiME mailing list

DiME mailing list

Thank you.

DiME mailing list

DiME mailing list

Thank you.

DiME mailing list

Thank you.

DiME mailing list

Thank you.

DiME mailing list

DiME mailing list

DiME mailing list

Thank you.

DiME mailing list

---

From: "Shishufeng (Susan)" <[email-masked]>
Date: Mon, 9 Dec 2013 10:29:58 +0000

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:[email-masked]] 
Sent: Thursday, November 28, 2013 6:30 PM
To: ext [email-masked]; ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: Re: [Dime] DOIC: Self-Contained OLRs

Lionel,

We have two cases:

Ulrich

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]]
Sent: Thursday, November 28, 2013 10:31 AM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Hi,

Lionel

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

Hi,

Ulrich

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext Jouni Korhonen
Sent: Wednesday, November 27, 2013 11:44 PM
To: Ben Campbell
Cc: [email-masked] list
Subject: Re: [Dime] DOIC: Self-Contained OLRs

- Jouni

---

From: "Shishufeng (Susan)" <[email-masked]>
Date: Mon, 9 Dec 2013 10:35:51 +0000

Hi Ulrich,

As replied in another thread, from my point of view, realm-type OLR is always the additional information.

Best Regards,
Susan

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:[email-masked]] 
Sent: Monday, December 02, 2013 3:38 AM
To: ext Nirav Salot (nsalot); ext [email-masked]; ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: Re: [Dime] DOIC: Self-Contained OLRs

Hi Nirav,

Best regards
Ulrich 

-----Original Message-----
From: ext Nirav Salot (nsalot) [mailto:[email-masked]]
Sent: Friday, November 29, 2013 4:49 PM
To: Wiehe, Ulrich (NSN - DE/Munich); ext [email-masked]; ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Hi Ulrich,

Regards,
Nirav.

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
Sent: Friday, November 29, 2013 5:36 PM
To: ext [email-masked]; ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: Re: [Dime] DOIC: Self-Contained OLRs

Hi Lionel,

Ulrich

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]]
Sent: Friday, November 29, 2013 11:13 AM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Hi Ulrich,

Lionel

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

Lionel,

We have two cases:

Ulrich

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]]
Sent: Thursday, November 28, 2013 10:31 AM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Hi,

Lionel

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

Hi,

Ulrich

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext Jouni Korhonen
Sent: Wednesday, November 27, 2013 11:44 PM
To: Ben Campbell
Cc: [email-masked] list
Subject: Re: [Dime] DOIC: Self-Contained OLRs

- Jouni

---

From: "Shishufeng (Susan)" <[email-masked]>
Date: Mon, 9 Dec 2013 10:38:29 +0000

Hi Nirav,

I would agree that Report-Type AVP is kind of optimization and I'm fine with Lionel's proposal if it is ok with others.

Best Regards,
Susan

-----Original Message-----
From: Nirav Salot (nsalot) [mailto:[email-masked]] 
Sent: Monday, December 02, 2013 2:05 PM
To: Wiehe, Ulrich (NSN - DE/Munich); ext [email-masked]; ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: Re: [Dime] DOIC: Self-Contained OLRs

Ulrich,

Regards,
Nirav.

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:[email-masked]]
Sent: Monday, December 02, 2013 1:08 AM
To: Nirav Salot (nsalot); ext [email-masked]; ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Hi Nirav,

Best regards
Ulrich 

-----Original Message-----
From: ext Nirav Salot (nsalot) [mailto:[email-masked]]
Sent: Friday, November 29, 2013 4:49 PM
To: Wiehe, Ulrich (NSN - DE/Munich); ext [email-masked]; ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Hi Ulrich,

Regards,
Nirav.

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
Sent: Friday, November 29, 2013 5:36 PM
To: ext [email-masked]; ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: Re: [Dime] DOIC: Self-Contained OLRs

Hi Lionel,

Ulrich

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]]
Sent: Friday, November 29, 2013 11:13 AM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Hi Ulrich,

Lionel

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

Lionel,

We have two cases:

Ulrich

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]]
Sent: Thursday, November 28, 2013 10:31 AM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Hi,

Lionel

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

Hi,

Ulrich

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext Jouni Korhonen
Sent: Wednesday, November 27, 2013 11:44 PM
To: Ben Campbell
Cc: [email-masked] list
Subject: Re: [Dime] DOIC: Self-Contained OLRs

- Jouni

---

From: "Shishufeng (Susan)" <[email-masked]>
Date: Mon, 9 Dec 2013 10:46:00 +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:[email-masked]] 
Sent: Monday, December 02, 2013 11:58 PM
To: [email-masked]
Subject: Re: [Dime] DOIC: Self-Contained OLRs

Dear all,

Best regards
/MCruz

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Sent: viernes, 29 de noviembre de 2013 16:05
To: [email-masked]
Subject: Re: [Dime] DOIC: Self-Contained OLRs

Dear all

Best regards 

JJacques 

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

Regards,

Lionel

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

Jouni, Ben,

Regards,
Nirav.

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

- JOuni

---

From: "Shishufeng (Susan)" <[email-masked]>
Date: Mon, 9 Dec 2013 10:48:35 +0000

I totally agree with Lionel.

Best Regards,
Susan

From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, December 03, 2013 12:19 AM
To: Steve Donovan; [email-masked]
Subject: Re: [Dime] DOIC: Self-Contained OLRs

Hi Steve,

Regards,

Lionel

Steve

Regards,

Lionel

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

Cc : Ben Campbell

Jouni, Ben,

Regards,

Nirav.

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

Cc: Ben Campbell

- JOuni

Hi,

another question:

Ulrich

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

Hi,

Lionel

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

Hi,

Ulrich

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

Korhonen

To: Ben Campbell

Hi,

- Jouni

Thanks!

Ben.

DiME mailing list

DiME mailing list

DiME mailing list

Thank you.

DiME mailing list

DiME mailing list

Thank you.

DiME mailing list

Thank you.

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Mon, 9 Dec 2013 10:50:52 +0000

Hello,

Trying to focus on getting conclusions here.
I totally agree with Nirav and Lionel: against to "self-contained" OLRs.

/MCruz

From: DiME [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: jueves, 05 de diciembre de 2013 16:14
To: Steve Donovan; Nirav Salot (nsalot); [email-masked]
Subject: Re: [Dime] DOIC: Self-Contained OLRs

Hi Steve,

Lionel

De : DiME [mailto:[email-masked]] De la part de Steve Donovan
Envoyé : jeudi 5 décembre 2013 15:47
À : Nirav Salot (nsalot); [email-masked]<mailto:[email-masked]>
Objet : Re: [Dime] DOIC: Self-Contained OLRs

Nirav,

Steve

Regards,
Nirav.

Steve

Regards,
Nirav.

Steve

Regards,

Nirav.

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

Dear all,

Regards

/MCruz

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

To: Ben Campbell

Hi Ben,

Regards,

Lionel

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

Hi Ben,

Regards,

Lionel

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

Hi Steve,

Regards,

Lionel

Steve

Regards,

Lionel

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

Cc : Ben Campbell

Jouni, Ben,

Regards,

Nirav.

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

Cc: Ben Campbell

- JOuni

Hi,

another question:

Ulrich

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

Hi,

Lionel

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

Hi,

Ulrich

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

Korhonen

To: Ben Campbell

Hi,

- Jouni

Thanks!

Ben.

DiME mailing list

DiME mailing list

DiME mailing list

Thank you.

DiME mailing list

DiME mailing list

Thank you.

DiME mailing list

Thank you.

DiME mailing list

Thank you.

DiME mailing list

Thank you.

DiME mailing list

DiME mailing list

DiME mailing list

Thank you.

---

From: Jouni Korhonen <[email-masked]>
Date: Mon, 9 Dec 2013 13:09:15 +0200

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 <[email-masked]> wrote:

> I totally agree with Nirav and Lionel: against to “self-contained” OLRs.
>  
> /MCruz
>  
>  
> I repeat one of my comments… 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.
>  
> Lionel
>

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 9 Dec 2013 11:43:26 +0000

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:[email-masked]] 
Sent: Monday, December 09, 2013 11:30 AM
To: Wiehe, Ulrich (NSN - DE/Munich); ext [email-masked]; ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Hi Ulrich,

Best Regards,
Susan

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:[email-masked]] 
Sent: Thursday, November 28, 2013 6:30 PM
To: ext [email-masked]; ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: Re: [Dime] DOIC: Self-Contained OLRs

Lionel,

We have two cases:

Ulrich

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]]
Sent: Thursday, November 28, 2013 10:31 AM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Hi,

Lionel

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

Hi,

Ulrich

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext Jouni Korhonen
Sent: Wednesday, November 27, 2013 11:44 PM
To: Ben Campbell
Cc: [email-masked] list
Subject: Re: [Dime] DOIC: Self-Contained OLRs

- Jouni

---

From: Ben Campbell <[email-masked]>
Date: Mon, 9 Dec 2013 17:53:15 -0600

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.

---

From: "Shishufeng (Susan)" <[email-masked]>
Date: Tue, 10 Dec 2013 03:01:40 +0000

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:[email-masked]] 
Sent: Monday, December 09, 2013 7:43 PM
To: Shishufeng (Susan); ext [email-masked]; ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Hi Susan,

Best regards
Ulrich

-----Original Message-----
From: ext Shishufeng (Susan) [mailto:[email-masked]]
Sent: Monday, December 09, 2013 11:30 AM
To: Wiehe, Ulrich (NSN - DE/Munich); ext [email-masked]; ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Hi Ulrich,

Best Regards,
Susan

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:[email-masked]]
Sent: Thursday, November 28, 2013 6:30 PM
To: ext [email-masked]; ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: Re: [Dime] DOIC: Self-Contained OLRs

Lionel,

We have two cases:

Ulrich

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]]
Sent: Thursday, November 28, 2013 10:31 AM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Hi,

Lionel

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

Hi,

Ulrich

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext Jouni Korhonen
Sent: Wednesday, November 27, 2013 11:44 PM
To: Ben Campbell
Cc: [email-masked] list
Subject: Re: [Dime] DOIC: Self-Contained OLRs

- Jouni

---

From: "Shishufeng (Susan)" <[email-masked]>
Date: Tue, 10 Dec 2013 03:58:17 +0000

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:[email-masked]]
Sent: Tuesday, December 10, 2013 7:53 AM
To: [email-masked] list
Subject: Re: [Dime] DOIC: Self-Contained OLRs

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 <[email-masked]<mailto:[email-masked]>> wrote:

- Jouni

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 10 Dec 2013 10:15:27 +0000

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:[email-masked]] 
Sent: Tuesday, December 10, 2013 4:02 AM
To: Wiehe, Ulrich (NSN - DE/Munich); ext [email-masked]; ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Hi Ulrich,

Best Regards,
Susan

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:[email-masked]] 
Sent: Monday, December 09, 2013 7:43 PM
To: Shishufeng (Susan); ext [email-masked]; ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Hi Susan,

Best regards
Ulrich

-----Original Message-----
From: ext Shishufeng (Susan) [mailto:[email-masked]]
Sent: Monday, December 09, 2013 11:30 AM
To: Wiehe, Ulrich (NSN - DE/Munich); ext [email-masked]; ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Hi Ulrich,

Best Regards,
Susan

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:[email-masked]]
Sent: Thursday, November 28, 2013 6:30 PM
To: ext [email-masked]; ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: Re: [Dime] DOIC: Self-Contained OLRs

Lionel,

We have two cases:

Ulrich

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]]
Sent: Thursday, November 28, 2013 10:31 AM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Hi,

Lionel

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

Hi,

Ulrich

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext Jouni Korhonen
Sent: Wednesday, November 27, 2013 11:44 PM
To: Ben Campbell
Cc: [email-masked] list
Subject: Re: [Dime] DOIC: Self-Contained OLRs

- Jouni

---

From: "Shishufeng (Susan)" <[email-masked]>
Date: Wed, 11 Dec 2013 06:24:08 +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 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:[email-masked]] 
Sent: Tuesday, December 10, 2013 6:15 PM
To: Shishufeng (Susan); ext [email-masked]; ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Hi Susan,

Best regards
Ulrich

-----Original Message-----
From: ext Shishufeng (Susan) [mailto:[email-masked]]
Sent: Tuesday, December 10, 2013 4:02 AM
To: Wiehe, Ulrich (NSN - DE/Munich); ext [email-masked]; ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Hi Ulrich,

Best Regards,
Susan

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:[email-masked]]
Sent: Monday, December 09, 2013 7:43 PM
To: Shishufeng (Susan); ext [email-masked]; ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Hi Susan,

Best regards
Ulrich

-----Original Message-----
From: ext Shishufeng (Susan) [mailto:[email-masked]]
Sent: Monday, December 09, 2013 11:30 AM
To: Wiehe, Ulrich (NSN - DE/Munich); ext [email-masked]; ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Hi Ulrich,

Best Regards,
Susan

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:[email-masked]]
Sent: Thursday, November 28, 2013 6:30 PM
To: ext [email-masked]; ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: Re: [Dime] DOIC: Self-Contained OLRs

Lionel,

We have two cases:

Ulrich

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]]
Sent: Thursday, November 28, 2013 10:31 AM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Hi,

Lionel

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

Hi,

Ulrich

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext Jouni Korhonen
Sent: Wednesday, November 27, 2013 11:44 PM
To: Ben Campbell
Cc: [email-masked] list
Subject: Re: [Dime] DOIC: Self-Contained OLRs

- Jouni

---

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Wed, 11 Dec 2013 08:27:38 +0000

Hi Ben and all

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

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

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

Best regards

JJacques

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

Hi Ben,

Best Regards,
Susan

Self-Contained OLRS:

Pros:

Implicit OLRs:

Pros:

- Jouni

---

From: Steve Donovan <[email-masked]>
Date: Wed, 11 Dec 2013 07:19:31 -0600

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.
>
> 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:[email-masked]] *De la part de* Shishufeng
> (Susan)
> *Envoyé :* mardi 10 décembre 2013 04:58
> *À :* Ben Campbell; [email-masked] list
> 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.
>
>  
>
> -          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:[email-masked]]
> *Sent:* Tuesday, December 10, 2013 7:53 AM
> *To:* [email-masked] <mailto:[email-masked]> list
> 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.
>
>  
>
> *Self-Contained OLRS:*
>   * 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 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: 
>
>  
>
> *Implicit OLRs:*
>   * 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.]

---

From: Steve Donovan <[email-masked]>
Date: Wed, 11 Dec 2013 07:27:21 -0600

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

---

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Wed, 11 Dec 2013 18:01:47 +0000

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:[email-masked]] De la part de Steve Donovan
Envoyé : mercredi 11 décembre 2013 14:20
À : [email-masked]
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

Best regards

JJacques

De : DiME [mailto:[email-masked]] De la part de Shishufeng (Susan)
Envoyé : mardi 10 décembre 2013 04:58
À : Ben Campbell; [email-masked]<mailto:[email-masked]> list
Objet : Re: [Dime] DOIC: Self-Contained OLRs

Hi Ben,

Best Regards,
Susan

Self-Contained OLRS:

Pros:

Implicit OLRs:

Pros:

- Jouni

DiME mailing list

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Wed, 11 Dec 2013 18:22:05 +0000

Hello,

From: DiME [mailto:[email-masked]] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Sent: miércoles, 11 de diciembre de 2013 19:02
To: [email-masked]
Subject: Re: [Dime] DOIC: Self-Contained OLRs

Hi Steve

Where is the difference?

Best regards

JJacques

JJacques,

Steve

Best regards

JJacques

Hi Ben,

Best Regards,
Susan

Self-Contained OLRS:

Pros:

Implicit OLRs:

Pros:

- Jouni

DiME mailing list

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Wed, 11 Dec 2013 18:25:10 +0000

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:

Best regards
/MCruz

Hi Steve

Where is the difference?

Best regards

JJacques

JJacques,

Steve

Best regards

JJacques

Hi Ben,

Best Regards,
Susan

Self-Contained OLRS:

Pros:

Implicit OLRs:

Pros:

- Jouni

DiME mailing list

---

From: Steve Donovan <[email-masked]>
Date: Wed, 11 Dec 2013 13:04:36 -0600

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?
>
>  
>
> *Envoyé :* mercredi 11 décembre 2013 14:20
> *À :* [email-masked]
> 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
>
>     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.
>
>     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.
>
>      
>
>     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:[email-masked]] *De la part de*
>     Shishufeng (Susan)
>     *À :* Ben Campbell; [email-masked] <mailto:[email-masked]> list
>     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.
>
>      
>
>     -          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
>
>      
>
>     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.
>
>      
>
>     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.
>
>      
>
>       * 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 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 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.]

---

From: Steve Donovan <[email-masked]>
Date: Wed, 11 Dec 2013 13:09:22 -0600

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)
>
>  
>
> 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
> 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:[email-masked]] *On Behalf Of *TROTTIN,
> JEAN-JACQUES (JEAN-JACQUES)
> *Sent:* miércoles, 11 de diciembre de 2013 19:02
> *To:* [email-masked]

---

From: Ben Campbell <[email-masked]>
Date: Wed, 11 Dec 2013 16:35:39 -0600

> So the drawbacks identified for the scope approach also apply with the self contained approach

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 Campbell <[email-masked]>
Date: Wed, 11 Dec 2013 16:42:07 -0600

> -          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 i…

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

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

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Thu, 12 Dec 2013 07:26:41 +0000

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:[email-masked]] On Behalf Of Steve Donovan
Sent: miércoles, 11 de diciembre de 2013 20:09
To: [email-masked]
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

Best regards
/MCruz

Hi Steve

Where is the difference?

Best regards

JJacques

JJacques,

Steve

Best regards

JJacques

Hi Ben,

Best Regards,
Susan

Self-Contained OLRS:

Pros:

Implicit OLRs:

Pros:

- Jouni

DiME mailing list

DiME mailing list

---

From: "Shishufeng (Susan)" <[email-masked]>
Date: Thu, 12 Dec 2013 08:37:38 +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 or adding a dedicated application as listed in your last two pros when needed in the future. 

There might be some benefit with use of self-contained OLR if we are sure that the use cases for out-of-band transmission and dedicated application need to be addressed. While so far the implicit OLRs can satisfy the requirements from 3GPP, and other use cases for out-of-band transmission and dedicated application are not clear to 3GPP and may never be addressed. A right solution is what we need for now.

Best Regards,
Susan

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]] 
Sent: Thursday, December 12, 2013 6:42 AM
To: Shishufeng (Susan)
Cc: [email-masked] list
Subject: Re: [Dime] DOIC: Self-Contained OLRs

> for overload, without a new format. (Yes, I think there's still a use 
> case for that, and I will detail it shortly.)
> Cons: 
>  
> OK. Lets call this thread concluded then. I keep the old OC-OLR  
> semantics regarding its information context then unmodified.
> 
> - Jouni
> 
>

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 12 Dec 2013 11:17:27 +0000

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:[email-masked]] On Behalf Of ext Steve Donovan
Sent: Wednesday, December 11, 2013 2:27 PM
To: [email-masked]
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.

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.

Regards,

Steve

Hi Ulrich,

Best Regards,

Susan

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

To: Shishufeng (Susan); ext [email-masked]<mailto:[email-masked]>; ext Jouni Korhonen; Ben Campbell

Hi Susan,

Best regards

Ulrich

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

To: Wiehe, Ulrich (NSN - DE/Munich); ext [email-masked]<mailto:[email-masked]>; ext Jouni Korhonen; Ben Campbell

Hi Ulrich,

Best Regards,

Susan

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

To: Shishufeng (Susan); ext [email-masked]<mailto:[email-masked]>; ext Jouni Korhonen; Ben Campbell

Hi Susan,

Best regards

Ulrich

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

To: Wiehe, Ulrich (NSN - DE/Munich); ext [email-masked]<mailto:[email-masked]>; ext Jouni Korhonen; Ben Campbell

Hi Ulrich,

Best Regards,

Susan

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

Lionel,

We have two cases:

Ulrich

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

Hi,

Lionel

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

De : DiME [mailto:[email-masked]] De la part de Wiehe, Ulrich (NSN - DE/Munich) Envoyé : jeudi 28 novembre 2013 10:26 À : ext Jouni Korhonen; Ben Campbell Cc : [email-masked]<mailto:[email-masked]> list Objet : Re: [Dime] DOIC: Self-Contained OLRs

Hi,

Ulrich

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

To: Ben Campbell

Hi,

- Jouni

Thanks!

Ben.

DiME mailing list

DiME mailing list

DiME mailing list

Thank you.

DiME mailing list

---

From: Steve Donovan <[email-masked]>
Date: Thu, 12 Dec 2013 07:46:07 -0600

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.
>
> 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
>
>  
>
> *Sent:* miércoles, 11 de diciembre de 2013 20:09
> *To:* [email-masked]
> 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. 
>
> 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
>
>     Hello (and something else now J, fast key combination, I won't be
>     able to repeat,  was the responsible)
>
>      
>
>     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
>
>      
>
>     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
>     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
>
>         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.
>
>         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
>
>          
>
>          
>
>         select a right one which could satisfy the requirements but
>         with less resource consuming.
>
>          
>
>         which we are still arguing if these optimization are worth
>         doing or not, since such optimization brings extra cost.
>
>         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
>         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.
>
>          
>
>           * Allows an easy, generic solution to Maria's
>             "all-application" scoped overload use case.
>           * Allows an easy solution to our "loss" algorithm corner
>             case of not being able to signal the end of a 100%
>             overload condition
>             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 can infer the OLR scope from a combination
>             of the transaction context and the report type. [I don't
>         On Dec 9, 2013, at 5:09 AM, Jouni Korhonen
>         <[email-masked] <mailto:[email-masked]>> wrote:
>
>

---

From: Steve Donovan <[email-masked]>
Date: Thu, 12 Dec 2013 07:52:24 -0600

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)
>
> 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.
>
> *Sent:* Wednesday, December 11, 2013 2:27 PM
> *To:* [email-masked]
> 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.
>
>     To: Shishufeng (Susan); ext [email-masked] <mailto:[email-masked]>; ext Jouni Korhonen; Ben Campbell
>
>     To: Wiehe, Ulrich (NSN - DE/Munich); ext [email-masked] <mailto:[email-masked]>; ext Jouni Korhonen; Ben Campbell
>
>     To: Shishufeng (Susan); ext [email-masked] <mailto:[email-masked]>; ext Jouni Korhonen; Ben Campbell
>
>     To: Wiehe, Ulrich (NSN - DE/Munich); ext [email-masked] <mailto:[email-masked]>; ext Jouni Korhonen; Ben Campbell
>
>     De : DiME [mailto:[email-masked]] De la part de Wiehe, Ulrich (NSN - DE/Munich) Envoyé : jeudi 28 novembre 2013 10:26 À : ext Jouni Korhonen; Ben Campbell Cc : [email-masked] <mailto:[email-masked]> list Objet : Re: [Dime] DOIC: Self-Contained OLRs
>
>      
>
>     Hi,
>
>      
>

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 12 Dec 2013 16:21:25 +0000

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:[email-masked]]
Sent: Thursday, December 12, 2013 2:52 PM
To: Wiehe, Ulrich (NSN - DE/Munich); [email-masked]
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

Ulrich

Susan,

Regards,

Steve

Hi Ulrich,

Best Regards,

Susan

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

Hi Susan,

Best regards

Ulrich

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

Hi Ulrich,

Best Regards,

Susan

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

Hi Susan,

Best regards

Ulrich

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

Hi Ulrich,

Best Regards,

Susan

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

Lionel,

We have two cases:

Ulrich

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

Hi,

Lionel

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

Hi,

Ulrich

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

To: Ben Campbell

Hi,

- Jouni

Thanks!

Ben.

DiME mailing list

DiME mailing list

DiME mailing list

Thank you.

DiME mailing list

---

From: "Nirav Salot (nsalot)" <[email-masked]>
Date: Thu, 12 Dec 2013 16:36:52 +0000

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

Regards,
Nirav.

From: DiME [mailto:[email-masked]] On Behalf Of Steve Donovan
Sent: Thursday, December 12, 2013 7:16 PM
To: [email-masked]
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

Cheers
/MCruz

Maria Cruz,

Steve

Best regards
/MCruz

Hi Steve

Where is the difference?

Best regards

JJacques

JJacques,

Steve

Best regards

JJacques

Hi Ben,

Best Regards,
Susan

Self-Contained OLRS:

Pros:

Implicit OLRs:

Pros:

- Jouni

DiME mailing list

DiME mailing list

DiME mailing list

---

From: Steve Donovan <[email-masked]>
Date: Mon, 16 Dec 2013 07:23:35 -0600

Nirav,

See my response inline.

Regards,

Steve

On 12/12/13 10:36 AM, Nirav Salot (nsalot) wrote:
> What if the reacting node supports two applications and in the message
> for application-X it receives the overload-report for application-Y?
>
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". 
> *Sent:* Thursday, December 12, 2013 7:16 PM
> *To:* [email-masked]
> 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
>
>     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.
>
>     I don't agree with the assertion that self-contained OLRs results
>     in the potential for data inconsistency.  If a reactor receives an
>     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
>
>         Hello (and something else now J, fast key combination, I won't
>         be able to repeat,  was the responsible)
>
>          
>
>         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:[email-masked]] *On Behalf Of
>         *TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
>         I am sorry, Steve,  I do not see the difference between the
>         Draft Roach scope approach and the self contained OLRs.
>
>          
>
>         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
>         Steve Donovan
>         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
>
>             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
>             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
>
>              
>
>              
>
>             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.
>
>              
>
>             -          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.
>
>             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
>
>              
>
>             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.
>
>              
>
>             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
>               * Allows an overloaded node to signal overload for
>                 multiple applications at once, instead of having to
>                 signal each one separately.
>                 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.  
>               * 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.]

---

From: Steve Donovan <[email-masked]>
Date: Mon, 16 Dec 2013 07:43:23 -0600

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:[email-masked]]
> *Sent:* Thursday, December 12, 2013 2:52 PM
> *To:* Wiehe, Ulrich (NSN - DE/Munich); [email-masked]
>     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
>     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.
>
>     *From:*DiME [mailto:[email-masked]] *On Behalf Of *ext
>     Steve Donovan
>     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.
>
>     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.
>

---

From: "Nirav Salot (nsalot)" <[email-masked]>
Date: Mon, 16 Dec 2013 15:50:03 +0000

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:[email-masked]]
Sent: Monday, December 16, 2013 6:54 PM
To: Nirav Salot (nsalot); [email-masked]
Subject: Re: [Dime] DOIC: Self-Contained OLRs

Nirav,

See my response inline.

Regards,

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.

Maria Cruz,

Steve

Cheers
/MCruz

Maria Cruz,

Steve

Best regards
/MCruz

Hi Steve

Where is the difference?

Best regards

JJacques

JJacques,

Steve

Best regards

JJacques

Hi Ben,

Best Regards,
Susan

Self-Contained OLRS:

Pros:

Implicit OLRs:

Pros:

- Jouni

DiME mailing list

DiME mailing list

DiME mailing list

---

From: Steve Donovan <[email-masked]>
Date: Mon, 16 Dec 2013 10:11:58 -0600

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:
> 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.
>
>  
>
> *Sent:* Monday, December 16, 2013 6:54 PM
>     What if the reacting node supports two applications and in the
>     message for application-X it receives the overload-report for
>     application-Y?
>
> 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.
>
>  
>

---

From: "Nirav Salot (nsalot)" <[email-masked]>
Date: Mon, 16 Dec 2013 16:32:00 +0000

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. The 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:[email-masked]]
Sent: Monday, December 16, 2013 9:42 PM
To: Nirav Salot (nsalot); [email-masked]
Subject: Re: [Dime] DOIC: Self-Contained OLRs

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

Regards,
Nirav.

Nirav,

See my response inline.

Regards,

Steve

Regards,
Nirav.

Maria Cruz,

Steve

Cheers
/MCruz

Maria Cruz,

Steve

Best regards
/MCruz

Hi Steve

Where is the difference?

Best regards

JJacques

JJacques,

Steve

Best regards

JJacques

Hi Ben,

Best Regards,
Susan

Self-Contained OLRS:

Pros:

Implicit OLRs:

Pros:

- Jouni

DiME mailing list

DiME mailing list

DiME mailing list

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Mon, 16 Dec 2013 16:37:49 +0000

Steve, Nirav, all,

I totally agree with Nirav.
I think we need to focus on requirements fulfillment, and avoid any extra complexity that is not required.

Regards
/MCruz

From: DiME [mailto:[email-masked]] On Behalf Of Nirav Salot (nsalot)
Sent: lunes, 16 de diciembre de 2013 17:32
To: Steve Donovan; [email-masked]
Subject: Re: [Dime] DOIC: Self-Contained OLRs

Steve,

Regards,
Nirav.

Nirav,

Regards,

Steve

Regards,
Nirav.

Nirav,

See my response inline.

Regards,

Steve

Regards,
Nirav.

Maria Cruz,

Steve

Cheers
/MCruz

Maria Cruz,

Steve

Best regards
/MCruz

Hi Steve

Where is the difference?

Best regards

JJacques

JJacques,

Steve

Best regards

JJacques

Hi Ben,

Best Regards,
Susan

Self-Contained OLRS:

Pros:

Implicit OLRs:

Pros:

- Jouni

DiME mailing list

DiME mailing list

DiME mailing list

---

From: Ben Campbell <[email-masked]>
Date: Mon, 16 Dec 2013 15:31:48 -0600

> This main drawback was highlighted earlier as well but was conveniently ignored while preparing the pros and cons list for the self-contained OLR.

As I have argued in the past, I don't think overload reports are application data. They are protocol data.

---

From: Ben Campbell <[email-masked]>
Date: Mon, 16 Dec 2013 15:34:54 -0600

> 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 an…

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: Steve Donovan <[email-masked]>
Date: Mon, 16 Dec 2013 16:02:19 -0600

> 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 enclo…
I agree that it SHOULD, I don't see how we can make it a MUST.