Re: [Dime] DOIC: Self-Contained OLRs

["Wiehe, Ulrich (NSN - DE/Munich)" <[e-mail]>]

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:[e-mail]] On Behalf Of ext Steve Donovan
Sent: Wednesday, December 11, 2013 2:27 PM
To: [e-mail]
Subject: Re: [Dime] DOIC: Self-Contained OLRs

Susan,

The use case for an agent that sits between a DOIC client and a DOIC server is Realm overload, which the agent might be responsible for reporting.  This will particularly be the case when there are multiple servers sitting behind the agent.  This might be considered a server farm, as you indicate, but we don't have a good definition of server farm, so I'm being explicit.

In this case, the agent must handle to types of occurrences.

1) Server overload - In this case the agent will receive a node overload report from the server.  The agent should (I'm not sure if we have defined this behavior in the draft yet) send the report unchanged to the client.  The agent will also most likely use the contents of the report to determine the realm overload state.

2) Realm overload - In this case the agent will insert an overload report into the appropriate answer messages.

Is this consistent with your thinking?

Regards,

Steve
On 12/11/13 12:24 AM, Shishufeng (Susan) wrote:

Hi Ulrich,



I'm not sure if you are taking the overload of agent into account for which we decided to not consider for the time being. If not, I couldn't understand why an agent which does not serve for a server farm needs to be a DOIC endpoint between the client and server if both of them support overload control. My understanding is that if there is the need for an agent to take a role of a DOIC endpoint between a specific server and client, it would always do that, otherwise, it just transfer the overload information of the server to the client.



Best Regards,

Susan



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

From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:[e-mail]]

Sent: Tuesday, December 10, 2013 6:15 PM

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

Cc: [e-mail]<mailto:[e-mail]> list

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



Hi Susan,



if the agent does not take the role of a DOIC endpont then the feature negotiation/adverisement is between client and server and one host type OLR is sent from server to client. For the agent this is all transparent and there is no need for the agent to support any DOIC feature.

However, if the agent takes the role of an DOIC endpoint then the feature negotiation/advertisement is between client and agent and a separate feature negotiation/advertisement is between agent and server. An OLR sent from server to agent is in-context with the supported features of server and agent but possibly not in-context with supported features of client and agent and therefore must not be (blindly) sent to the client. And in fact there is also no need to do that. For subsequent requests that contain the desination host of the server, the agent will not take the role of a DOIC endpoint.



Best regards

Ulrich



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

From: ext Shishufeng (Susan) [mailto:[e-mail]]

Sent: Tuesday, December 10, 2013 4:02 AM

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

Cc: [e-mail]<mailto:[e-mail]> list

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



Hi Ulrich,



Thanks for your clarification. I understood the scenario, while from my point of view, if the agent that selects the HSS is not configured to serve as a load balancer for the HSS, the agent should not change any supported/negotiated features between C and S, that would be the normal case. If the agent serve as a load balancer for the HSS, the subsequent request from C towards the S would always go via the agent, in this case whatever the associations between C and A, between A and S are the same or not, it doesn't matter. With an E2E solution as we agreed, I don't see the problem with it.



Best Regards,

Susan



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

From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:[e-mail]]

Sent: Monday, December 09, 2013 7:43 PM

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

Cc: [e-mail]<mailto:[e-mail]> list

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



Hi Susan,



let me come back to your S6a example.



The MME (C) sends a request without Destination-Host towards the HPLMN (realm). There must be an agent (A) in the HPLMN (realm) that selects the HSS (S).

We would have two distinct DOIC associations: one between C and A, another between A and S (see figure 5 in clause 5.1). The two DOIC associations may have different supported/negotiated features. An OLR sent from S to A based on supported/negotiated features valid for the DOIC association between A and S is at least problematic (out-of context) when sent from A to C.



When the MME (C) sends a subsequent request with Destination-Host towards the HSS (S), there is no agent that selects the HSS (as the HSS is already selected). For this session there is only one DOIC association between C and S (see figure 3 in clause 5.1) and OLRs sent from S to C are not problematic.



Best regards

Ulrich





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

From: ext Shishufeng (Susan) [mailto:[e-mail]]

Sent: Monday, December 09, 2013 11:30 AM

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

Cc: [e-mail]<mailto:[e-mail]> list

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



Hi Ulrich,



I have different views. In any case, I think the host-type OLR should not be ignored by the clients. On the contrary, the realm-type OLR can be thought as optimization, which may not even be needed at all for all cases, especially in 3GPP. Here is an example of S6a, in the case the first attach request comes from the UE to the MME, the MME can only derive the realm information, and sends a request without Destination-Host towards the HPLMN. Since the subscriber corresponding to the UE belongs to a specific HSS, and the HSS may provide its overload report to the MME, and the MME is able to know how to react regarding the requests towards the HSS, which would be the normal case. Whether Realm report will be provided by the HSS or the agent serving the HSS is kind of optimization which may help the MME to know how to react on the requests towards the realm, not specific to the HSS.



Best Regards,

Susan



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

From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:[e-mail]]

Sent: Thursday, November 28, 2013 6:30 PM

To: ext [e-mail]<mailto:[e-mail]>; ext Jouni Korhonen; Ben Campbell

Cc: [e-mail]<mailto:[e-mail]> list

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



Lionel,



my understanding was that _the_ reporting end point provides _the_ OLR.



If we go for two OLRs in the answer we should indicate which OLR is the actual OLR created by the reporting end point and which OLR is an additional OLR created by another node.



We have two cases:

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

b) The request sent by the client (reacting endpoint) contains the Destination Host. The Server (reporting node) returns a host-type OLR as the actual reporting-node-created OLR in the answer. The agent may optionally insert a realm-type OLR as additional OLR to the answer. The client may ignore the additional OLR.



Ulrich







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

From: ext [e-mail]<mailto:[e-mail]> [mailto:[e-mail]]

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

To: Wiehe, Ulrich (NSN - DE/Munich); ext Jouni Korhonen; Ben Campbell

Cc: [e-mail]<mailto:[e-mail]> 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:[e-mail]] De la part de Wiehe, Ulrich (NSN - DE/Munich) Envoyé : jeudi 28 novembre 2013 10:26 À : ext Jouni Korhonen; Ben Campbell Cc : [e-mail]<mailto:[e-mail]> 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:[e-mail]] On Behalf Of ext Jouni Korhonen

Sent: Wednesday, November 27, 2013 11:44 PM

To: Ben Campbell

Cc: [e-mail]<mailto:[e-mail]> list

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





On Nov 28, 2013, at 12:27 AM, Ben Campbell <[e-mail]><mailto:[e-mail]> 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

[e-mail]<mailto:[e-mail]>

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



_______________________________________________

DiME mailing list

[e-mail]<mailto:[e-mail]>

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

_______________________________________________

DiME mailing list

[e-mail]<mailto:[e-mail]>

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



_________________________________________________________________________________________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.





_______________________________________________

DiME mailing list

[e-mail]<mailto:[e-mail]>

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