Subject: [Dime] Issue#35 conclusion

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 20 Feb 2014 12:41:39 +0000

#35: additional report types are proposed

Dear all,

I believe we can conclude, not to add additional report types. However, we agreed to add clarifying text to clause 5.5 as follows:

When an agent received an OLR in response to a request initiated by a client not supporting DOIC, this agent needs to bind the received OLR to the origin-host of the client.

Ulrich

---

From: Ben Campbell <[email-masked]>
Date: Thu, 20 Feb 2014 16:54:49 -0600

> When an agent received an OLR in response to a request initiated by a client not supporting DOIC, this agent needs to bind the received OLR to the origin-host of the client.

I do not agree.

You proposal implies that the server's OLR only applies to that client. If there's an intervening DOIC agent, then the agent, not the client, is the reacting node from the server's perspective. But, short of adding an origin-host type, nothing binds the OLR to a particular client, regardless of DOIC support at the clients.

 Whether or not the client also supports DOIC doesn't change that. For DOIC-supporting clients, the agent has the additional option of reducing traffic by asking the clients to reduce traffic (making them reacting nodes from the perspective of the _agent_, but not the server.)  It doesn't have that option for non-DOIC clients.

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 21 Feb 2014 10:48:32 +0000

Ben,

the proposed conclusion was based on comments received so far (from Lionel, Nirav, Steve, MCruz, JJ). 
Now you seem to address two points:
a) There is no dependency to DOIC support of the client.
To address this I would like to propose rewording of the clarifying text for 5.5. as follows:

When an agent takes the role of a reacting node, the agent needs to bind a received OLR to the origin host of the client that initiated the request which corresponds to the answer containing the OLR. 

This would cover not only the case where an agent takes the role of the reacting node on behalf of a (or several) non supporting client, but also the case where an agent is configured to take the role of a reporting node (for realm-type reports) towards the client and at the same time the role of a reacting node towards the server.

b) There is no binding of the OLR to the orig-host of the client
Here I disagree. We have the 3GPP requirement to allow requesting different amount of reduction from different clients, and I think we have 3 options:
1. ignore the 3GPP requirement
2. introduce new report types as originally proposed in #35
3. introduce the binding between OLR and orig-host of the client.

So far I understood that people favoured option 3.

See also inline.

Ulrich

-----Original Message-----
From: ext Ben Campbell [mailto:[email-masked]] 
Sent: Thursday, February 20, 2014 11:55 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: [email-masked]
Subject: Re: [Dime] Issue#35 conclusion

I do not agree.

You proposal implies that the server's OLR only applies to that client.
<Ulrich>exactly, that was the intention</Ulrich>
 If there's an intervening DOIC agent, then the agent, not the client, is the reacting node from the server's perspective.
<Ulrich> the server's perspective is agnostic. The server does not know whether it's the client or an agent on the path that takes the role of the reacting node</Ulrich>
 But, short of adding an origin-host type, nothing binds the OLR to a particular client, regardless of DOIC support at the clients.
<Ulrich> the binding is always there, regardless of DOIC support at the client</Ulrich>

---

From: Ben Campbell <[email-masked]>
Date: Fri, 21 Feb 2014 09:43:49 -0600

> So far I understood that people favoured option 3.

That approach implies the 3GPP requirement is the _only_ case. The result is, a DOIC agent cannot apply a single OLR to requests from multiple clients, ever. I don't think that's what we want. 

I agree there may be times the server wants to send an OLR for a specific client, but I don't think it's the default case. I think that case would be better handled by a new report type, or by a new optional AVP that includes the targeted client's, so that an agent can apply the report to requests that include that identity as the Origin-Host.

---

From: Steve Donovan <[email-masked]>
Date: Fri, 21 Feb 2014 09:52:57 -0600

Ulrich,

I have a couple of concerns with this approach, as currently outlined. 

First, how do we handle the case where there are multiple DOIC
supporting agents between the non supporting client and the reporting
node.  This, I guess, is a general question, not just applying to this
proposal.  I suggest we capture in the agent behavior section that is
currently missing wording indicating that the first supporting agent
that receives the request must be the reacting node for that
non-supporting client.  Subsequent DOIC supporting agents must not be
the reacting node for the non-supporting client.

We need to think through the ramifications of having multiple agents
being the reacting node for the same non supporting clients, as this
could easily happen in networks where multiple agents are involved in a
single transaction.  On the surface it doesn't seem to be an issue for
the loss algorithm, but this might not be the case with other algorithms.

My other concern is that this puts a lot of extra onus on the agent even
for the case where the reporting node does not want to differentiate
overload reports.  To this end I suggest we add an indication in the OLR
marking the reports that are specific to just the Origin-Host in the
request.  Absence of the "single-client-only" AVP would mean that the
report applies to all clients.  Presence of the AVP would indicate that
the OLR applies to the Origin-Host.

Steve

On 2/21/14 4:48 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime
>

---

From: Ben Campbell <[email-masked]>
Date: Fri, 21 Feb 2014 14:18:02 -0600

On Feb 21, 2014, at 9:52 AM, Steve Donovan <[email-masked]> wrote:

> My other concern is that this puts a lot of extra onus on the agent even for the case where the reporting node does not want to differentiate overload reports.  To this end I suggest we add an indication in the OLR marking the reports that are specific to just the Origin-Host in the request.  Absence of the "single-client-only" AVP would mean that the report applies to all clients.  Presence of the AVP would indicate that the OLR applies to the Origin-Host.

I support this approach. And of course, being me, I would like that AVP to contain the Diameter Identity of the client in question.

But I wonder--should this be limited to clients? Should it be possible for the server to bind an OLR to a particular _agent_? That is, some node on the message path that is not the Origin-Host? For adjacent agents, this is easy--the server only sends the OLR to that agent. But that won't work for non-adjacent agents.

---

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Mon, 24 Feb 2014 10:14:40 +0000

Hi

When a reporting node puts an OC-OLR an answer, this OLR is to be sent to the origin Host of the corresponding request (eg  client 1). For eg a client 2, the reporting node  will put an OC-OLR in  an answer going to client 2 . I do not see why an OC-OLR that was put  in answer to client  1 will be put  later in the path  in an answer to client 2 or even  to answers to all clients and to distinguish these behaviors by extra indicators,  these are new things not needed in the baseline .

If a DA is acting on behalf of client 1, it will receive an OLR in  an answer towards client 1 and will apply the traffic reduction to the traffic coming from client 1 .  The same if it is acting on behalf of client 2. So no difference for the reporting node which is an objective.
Other approaches are new things that I do not yet  understand the need  and that are  not part of the baseline.

So I remain in line with the  conclusions (and his hereafter mail) that  Ulrich  proposed and I think  supported  by several  of us.

Best regards

Jacques

De : DiME [mailto:[email-masked]] De la part de Steve Donovan
Envoyé : vendredi 21 février 2014 16:53
À : [email-masked]
Objet : Re: [Dime] Issue#35 conclusion

Ulrich,

First, how do we handle the case where there are multiple DOIC supporting agents between the non supporting client and the reporting node.  This, I guess, is a general question, not just applying to this proposal.  I suggest we capture in the agent behavior section that is currently missing wording indicating that the first supporting agent that receives the request must be the reacting node for that non-supporting client.  Subsequent DOIC supporting agents must not be the reacting node for the non-supporting client.

We need to think through the ramifications of having multiple agents being the reacting node for the same non supporting clients, as this could easily happen in networks where multiple agents are involved in a single transaction.  On the surface it doesn't seem to be an issue for the loss algorithm, but this might not be the case with other algorithms.

Steve

Ben,

See also inline.

Ulrich

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

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

On Feb 20, 2014, at 6:41 AM, Wiehe, Ulrich (NSN - DE/Munich) <[email-masked]><mailto:[email-masked]> wrote:

Dear all,

I do not agree.

DiME mailing list

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

---

From: <[email-masked]>
Date: Mon, 24 Feb 2014 10:41:32 +0000

I agree.
Agent should not assume that the received OLR is valid for all the clients below it. It does not preclude an agent to do so when it is know that for an application all the received are independent of the clients. But this is something not required as per the base solution for me and can be defined per application use.

Regards,

Lionel
De : DiME [mailto:[email-masked]] De la part de TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Envoyé : lundi 24 février 2014 11:15
À : [email-masked]
Objet : Re: [Dime] Issue#35 conclusion

Hi

Best regards

Jacques

Ulrich,

Steve

Ben,

See also inline.

Ulrich

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

Dear all,

I do not agree.

DiME mailing list

_________________________________________________________________________________________________________________________

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: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 24 Feb 2014 11:28:18 +0000

Steve,

please see inline.

Ulrich

From: DiME [mailto:[email-masked]] On Behalf Of ext Steve Donovan
Sent: Friday, February 21, 2014 4:53 PM
To: [email-masked]
Subject: Re: [Dime] Issue#35 conclusion

Ulrich,

First, how do we handle the case where there are multiple DOIC supporting agents between the non supporting client and the reporting node.  This, I guess, is a general question, not just applying to this proposal.  I suggest we capture in the agent behavior section that is currently missing wording indicating that the first supporting agent that receives the request must be the reacting node for that non-supporting client.  Subsequent DOIC supporting agents must not be the reacting node for the non-supporting client.
<Ulrich>I fully agree</Ulrich>

We need to think through the ramifications of having multiple agents being the reacting node for the same non supporting clients, as this could easily happen in networks where multiple agents are involved in a single transaction.  On the surface it doesn't seem to be an issue for the loss algorithm, but this might not be the case with other algorithms.
<Ulrich>I agree that this is not an issue for loss; it is an issue e.g. for rate (i.e. for draft-donovan-dime-doc-rate-control)</Ulrich>

My other concern is that this puts a lot of extra onus on the agent even for the case where the reporting node does not want to differentiate overload reports.
<Ulrich> I agree </Ulrich>
To this end I suggest we add an indication in the OLR marking the reports that are specific to just the Origin-Host in the request.  Absence of the "single-client-only" AVP would mean that the report applies to all clients.  Presence of the AVP would indicate that the OLR applies to the Origin-Host.
<Ulrich>I understand that the proposal is an optimization for agents. Therefore the semantics of the marking should be reverse: unmarked OLRs are client specific, marked OLRs indicate that the reporting node does not want to differentiate, and therefore allow agents not to do the binding to the client.</Ulrich>     

Steve

See also inline.

Ulrich

-----Original Message-----
From: ext Ben Campbell [mailto:[email-masked]] 
Sent: Thursday, February 20, 2014 11:55 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: [email-masked]
Subject: Re: [Dime] Issue#35 conclusion

 
Dear all,

I do not agree.

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Mon, 24 Feb 2014 12:21:20 +0000

Hello all,

Not sure we all have the same understanding here.
Let me try to explain my concerns.

The original 3GPP requirement we want to cover is the need for a server to reduce traffic for one specific client, i.e. traffic identified by "Origin-Host" in the request.
Then, two options are under analysis about whether or not the OLR in the server answer shall be marked:

a) OLR does not need to include anything else
Receiver of the answer (and OLR) is the client that sends the request, identified by "Origin-Host" in the request.
Then, as long as the reacting node=="Origin-Host", the expected reduction is performed and requirement fulfilled.
But, when an agent is acting on behalf of a client as the reacting node, then the "Origin-Host" identifies final client, but not the reacting node.
Then, this is why the proposal is to add following clarification about agent behavior (possible clause 5.5):
"When an agent takes the role of a reacting node, the agent needs to bind a received OLR to the origin host of the client that initiated the request which corresponds to the answer containing the OLR."
But this will imply that _always_ the reacting node applies this OLR to one specific client, what is not what we need to achieve.
How will this impact the case where the agent is providing access to a Realm? E.g. C1 and C2 accesses RealmX (S1 + S2) via Agent1. Let's consider following example:
- C1 sends a Realm request via Agent, that finally reaches S1
- S1 answers with OLR (Host:50%).
- Agent is acting as reacting node on behalf of C1, if it considers this OLR only bind to C1... then... should it consider S1-OLR only as relevant for requests coming from C1? Should agent do not use this S1-OLR to calculate aggregated Realm overload?
In my opinion, in this case it does not make sense to consider OLR was only meant to C1. And this problem could be solved adding explicit information, as in b) below.

b) OLR needs to be extended (new AVP) that identifies the client ("Origin-Host" in the request) from which traffic reduction shall apply.
With this new AVP, reacting node will easy be able to identify when OLR shall be applied to any client or just to the Origin-Host identified by new AVP.

Let me know your opinions please
Best regards
/MCruz

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
Sent: lunes, 24 de febrero de 2014 12:28
To: ext Steve Donovan; [email-masked]
Subject: Re: [Dime] Issue#35 conclusion

Steve,

please see inline.

Ulrich

Ulrich,

Steve

b) There is no binding of the OLR to the orig-host of the client Here I disagree. We have the 3GPP requirement to allow requesting different amount of reduction from different clients, and I think we have 3 options:
1. ignore the 3GPP requirement
2. introduce new report types as originally proposed in #35 3. introduce the binding between OLR and orig-host of the client.

See also inline.

Ulrich

-----Original Message-----
From: ext Ben Campbell [mailto:[email-masked]]
Sent: Thursday, February 20, 2014 11:55 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: [email-masked]
Subject: Re: [Dime] Issue#35 conclusion

 
Dear all,

I do not agree.

---

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Mon, 24 Feb 2014 12:43:14 +0000

Hi Mcruz and all

I think that you are  mixing the case of the DA that is the "reporting" node which wants to indicate a realm OLR to clients, and for which will use various (non standardized ) ways to determine among which it can reuse the Host-OLR AVPs received from various servers. But in this case, clients receiving realm OLRs are supporting DOIC. 
Here I understand the on going  discussion is about the DA behavior when  clients is not supporting DOIC and to reuse the Host-OLR received for one client for other clients  .

For me I remain on  my previous mail, with a baseline solution. We may always study new extensions, optimizations, but priority should be on the baseline.

Best regards

Jacques 

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de Maria Cruz Bartolome
Envoyé : lundi 24 février 2014 13:21
À : [email-masked]
Objet : Re: [Dime] Issue#35 conclusion

Hello all,

a) OLR does not need to include anything else Receiver of the answer (and OLR) is the client that sends the request, identified by "Origin-Host" in the request.

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
Sent: lunes, 24 de febrero de 2014 12:28
To: ext Steve Donovan; [email-masked]
Subject: Re: [Dime] Issue#35 conclusion

Steve,

please see inline.

Ulrich

Ulrich,

Steve

See also inline.

Ulrich

-----Original Message-----
From: ext Ben Campbell [mailto:[email-masked]]
Sent: Thursday, February 20, 2014 11:55 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: [email-masked]
Subject: Re: [Dime] Issue#35 conclusion

 
Dear all,

I do not agree.

You proposal implies that the server's OLR only applies to that client.
<Ulrich>exactly, that was the intention</Ulrich>  If there's an intervening DOIC agent, then the agent, not the client, is the reacting node from the server's perspective.
<Ulrich> the server's perspective is agnostic. The server does not know whether it's the client or an agent on the path that takes the role of the reacting node</Ulrich>  But, short of adding an origin-host type, nothing binds the OLR to a particular client, regardless of DOIC support at the clients.
<Ulrich> the binding is always there, regardless of DOIC support at the client</Ulrich>

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Mon, 24 Feb 2014 13:02:10 +0000

Hello JJ and all,

As per email thread, the latest proposal is:
"When an agent takes the role of a reacting node, the agent needs to bind a received OLR to the origin host of the client that initiated the request which corresponds to the answer containing the OLR." 

An Ulrich comments on this:
"This would cover not only the case where an agent takes the role of the reacting node on behalf of a (or several) non supporting client, but also the case where an agent is configured to take the role of a reporting node (for realm-type reports) towards the client and at the same time the role of a reacting node towards the server."

Is your proposal limited to Host-OLR, i.e. Realm OLR is excluded? 
Best regards
/MCruz

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Sent: lunes, 24 de febrero de 2014 13:43
To: [email-masked]
Subject: Re: [Dime] Issue#35 conclusion

Hi Mcruz and all

Best regards

Jacques 

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de Maria Cruz Bartolome Envoyé : lundi 24 février 2014 13:21 À : [email-masked] Objet : Re: [Dime] Issue#35 conclusion

Hello all,

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
Sent: lunes, 24 de febrero de 2014 12:28
To: ext Steve Donovan; [email-masked]
Subject: Re: [Dime] Issue#35 conclusion

Steve,

please see inline.

Ulrich

Ulrich,

Steve

See also inline.

Ulrich

-----Original Message-----
From: ext Ben Campbell [mailto:[email-masked]]
Sent: Thursday, February 20, 2014 11:55 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: [email-masked]
Subject: Re: [Dime] Issue#35 conclusion

 
Dear all,

I do not agree.

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 24 Feb 2014 13:04:04 +0000

See inline

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext Ben Campbell
Sent: Friday, February 21, 2014 9:18 PM
To: Steve Donovan
Cc: [email-masked] list
Subject: Re: [Dime] Issue#35 conclusion

I support this approach. And of course, being me, I would like that AVP to contain the Diameter Identity of the client in question.
<Ulrich>why would there be the need to explicitly signal the the client's Diameter Identity? Isn't this information somehow available at the agent?</Ulrich>

But I wonder--should this be limited to clients? Should it be possible for the server to bind an OLR to a particular _agent_? That is, some node on the message path that is not the Origin-Host? For adjacent agents, this is easy--the server only sends the OLR to that agent. But that won't work for non-adjacent agents.
<Ulrich>this shall be limited to clients.</Ulrich>
_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 24 Feb 2014 13:19:06 +0000

Hi MCruz,
there is no reason to limit this to host type OLRs.

If we have an agent A that is configured to take the role of the reporting node for realm-type reports for realm R, A could receive host type OLRs from servers S1 and S2 (e.g. S1 requesting 10% reduction from C1 and 20% reduction from C2, S2 requesting 30% reduction from C1 and 40% reductin from C2); A then would aggregate these info and return realm type OLRs to C1 requesting 20% reduction of traffic from C1 to R, and to C2 requesting 30% reduction of traffic from C2 to R.

Best regards
Ulrich

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext Maria Cruz Bartolome
Sent: Monday, February 24, 2014 2:02 PM
To: [email-masked]
Subject: Re: [Dime] Issue#35 conclusion

Hello JJ and all,

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Sent: lunes, 24 de febrero de 2014 13:43
To: [email-masked]
Subject: Re: [Dime] Issue#35 conclusion

Hi Mcruz and all

Best regards

Jacques 

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

Hello all,

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
Sent: lunes, 24 de febrero de 2014 12:28
To: ext Steve Donovan; [email-masked]
Subject: Re: [Dime] Issue#35 conclusion

Steve,

please see inline.

Ulrich

Ulrich,

Steve

See also inline.

Ulrich

-----Original Message-----
From: ext Ben Campbell [mailto:[email-masked]]
Sent: Thursday, February 20, 2014 11:55 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: [email-masked]
Subject: Re: [Dime] Issue#35 conclusion

 
Dear all,

I do not agree.

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Mon, 24 Feb 2014 13:27:04 +0000

Hello Ulrich,

I haven't proposed to limit this to host type OLR, I just wanted to clarify if this is what JJ got in mind.

I agree it could be done as you explained in the example below, but the open question is whether it is better to add an AVP when OLR is just meant for one single client, or on the contrary the agent _always_ need to bind OLR to one specific client, even if the server simply requires same OLR for any client. 

I think having a new AVP simplifies agent behavior.

Best regards
/MCruz

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:[email-masked]] 
Sent: lunes, 24 de febrero de 2014 14:19
To: Maria Cruz Bartolome; [email-masked]
Subject: RE: [Dime] Issue#35 conclusion

Hi MCruz,

Best regards
Ulrich

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext Maria Cruz Bartolome
Sent: Monday, February 24, 2014 2:02 PM
To: [email-masked]
Subject: Re: [Dime] Issue#35 conclusion

Hello JJ and all,

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Sent: lunes, 24 de febrero de 2014 13:43
To: [email-masked]
Subject: Re: [Dime] Issue#35 conclusion

Hi Mcruz and all

Best regards

Jacques 

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

Hello all,

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
Sent: lunes, 24 de febrero de 2014 12:28
To: ext Steve Donovan; [email-masked]
Subject: Re: [Dime] Issue#35 conclusion

Steve,

please see inline.

Ulrich

Ulrich,

Steve

See also inline.

Ulrich

-----Original Message-----
From: ext Ben Campbell [mailto:[email-masked]]
Sent: Thursday, February 20, 2014 11:55 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: [email-masked]
Subject: Re: [Dime] Issue#35 conclusion

 
Dear all,

I do not agree.

---

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Mon, 24 Feb 2014 13:51:40 +0000

Hi Mcruz

I have not said my proposal was limited to Host OLR. If a DA acting as reacting node receives Realm OLRs in answers to a client of  which DA is acting on behalf, DA will apply the realm OLR throttling to requests without destination host coming from the client.

Now I am not sure that adding an AVP will simplify the DA life. The principle I have in mind is that each time we add an AVP, this multiply the combinational possibilities and so we have to be careful. To come back to Host OLRS, if DA receives an OLR in an answer for Client 1 and an OLR in another  answer for client 2 and they are marked as not binded to client, which one prevails ? I think there may be some other questions that could 	arise. So my priority remains on the baseline, with OLR binded to a client.

Best regards
   
JJacques 

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de Maria Cruz Bartolome
Envoyé : lundi 24 février 2014 14:27
À : [email-masked]
Objet : Re: [Dime] Issue#35 conclusion

Hello Ulrich,

Best regards
/MCruz

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:[email-masked]] 
Sent: lunes, 24 de febrero de 2014 14:19
To: Maria Cruz Bartolome; [email-masked]
Subject: RE: [Dime] Issue#35 conclusion

Hi MCruz,

Best regards
Ulrich

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext Maria Cruz Bartolome
Sent: Monday, February 24, 2014 2:02 PM
To: [email-masked]
Subject: Re: [Dime] Issue#35 conclusion

Hello JJ and all,

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Sent: lunes, 24 de febrero de 2014 13:43
To: [email-masked]
Subject: Re: [Dime] Issue#35 conclusion

Hi Mcruz and all

Best regards

Jacques 

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

Hello all,

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
Sent: lunes, 24 de febrero de 2014 12:28
To: ext Steve Donovan; [email-masked]
Subject: Re: [Dime] Issue#35 conclusion

Steve,

please see inline.

Ulrich

Ulrich,

Steve

See also inline.

Ulrich

-----Original Message-----
From: ext Ben Campbell [mailto:[email-masked]]
Sent: Thursday, February 20, 2014 11:55 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: [email-masked]
Subject: Re: [Dime] Issue#35 conclusion

 
Dear all,

I do not agree.

---

From: <[email-masked]>
Date: Mon, 24 Feb 2014 14:06:46 +0000

Is it implicit? 

If the agent detects that a client is not supporting DOIC, this agent will have to store the corresponding overload control state on behalf of this client and only this client (saying that other clients may support DOIC). I'm assuming then that any agent will have to store somewhere the origin-host of this client. And therefore, I don't see what would be the added-value of this AVP saying that this OLR is only for this client.

Even if this AVP is present, it would not preclude a reporting node to always put this AVP in every answer, even if the OLR is the same for all the clients.

Regards,

Lionel

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

Hello Ulrich,

Best regards
/MCruz

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:[email-masked]] 
Sent: lunes, 24 de febrero de 2014 14:19
To: Maria Cruz Bartolome; [email-masked]
Subject: RE: [Dime] Issue#35 conclusion

Hi MCruz,

Best regards
Ulrich

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext Maria Cruz Bartolome
Sent: Monday, February 24, 2014 2:02 PM
To: [email-masked]
Subject: Re: [Dime] Issue#35 conclusion

Hello JJ and all,

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Sent: lunes, 24 de febrero de 2014 13:43
To: [email-masked]
Subject: Re: [Dime] Issue#35 conclusion

Hi Mcruz and all

Best regards

Jacques 

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

Hello all,

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
Sent: lunes, 24 de febrero de 2014 12:28
To: ext Steve Donovan; [email-masked]
Subject: Re: [Dime] Issue#35 conclusion

Steve,

please see inline.

Ulrich

Ulrich,

Steve

See also inline.

Ulrich

-----Original Message-----
From: ext Ben Campbell [mailto:[email-masked]]
Sent: Thursday, February 20, 2014 11:55 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: [email-masked]
Subject: Re: [Dime] Issue#35 conclusion

 
Dear all,

I do not agree.

---

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Mon, 24 Feb 2014 14:10:03 +0000

I am in line with Lionel.

JJacques 

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de [email-masked]
Envoyé : lundi 24 février 2014 15:07
À : Maria Cruz Bartolome; [email-masked]
Objet : Re: [Dime] Issue#35 conclusion

Is it implicit? 

Regards,

Lionel

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de Maria Cruz Bartolome Envoyé : lundi 24 février 2014 14:27 À : [email-masked] Objet : Re: [Dime] Issue#35 conclusion

Hello Ulrich,

Best regards
/MCruz

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:[email-masked]]
Sent: lunes, 24 de febrero de 2014 14:19
To: Maria Cruz Bartolome; [email-masked]
Subject: RE: [Dime] Issue#35 conclusion

Hi MCruz,

Best regards
Ulrich

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext Maria Cruz Bartolome
Sent: Monday, February 24, 2014 2:02 PM
To: [email-masked]
Subject: Re: [Dime] Issue#35 conclusion

Hello JJ and all,

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Sent: lunes, 24 de febrero de 2014 13:43
To: [email-masked]
Subject: Re: [Dime] Issue#35 conclusion

Hi Mcruz and all

Best regards

Jacques 

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

Hello all,

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
Sent: lunes, 24 de febrero de 2014 12:28
To: ext Steve Donovan; [email-masked]
Subject: Re: [Dime] Issue#35 conclusion

Steve,

please see inline.

Ulrich

Ulrich,

Steve

See also inline.

Ulrich

-----Original Message-----
From: ext Ben Campbell [mailto:[email-masked]]
Sent: Thursday, February 20, 2014 11:55 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: [email-masked]
Subject: Re: [Dime] Issue#35 conclusion

 
Dear all,

I do not agree.

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: Maria Cruz Bartolome <[email-masked]>
Date: Mon, 24 Feb 2014 15:55:50 +0000

Hello JJ,
To the specific case you mentioned:  "To come back to Host OLRS, if DA receives an OLR in an answer for Client 1 and an OLR in another  answer for client 2 and they are marked as not binded to client, which one prevails ?"
If OLRs are not marked as bind to each client, then it means that they apply to any/all clients (what by the way has been our assumption from the beginning until Ulrich started this subject in order to cover 3GPP requirement). Therefore, latest received will apply (if modified). 

Best regards
/MCruz

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Sent: lunes, 24 de febrero de 2014 14:52
To: [email-masked]
Subject: Re: [Dime] Issue#35 conclusion

Hi Mcruz

Best regards
   
JJacques 

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

Hello Ulrich,

Best regards
/MCruz

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:[email-masked]]
Sent: lunes, 24 de febrero de 2014 14:19
To: Maria Cruz Bartolome; [email-masked]
Subject: RE: [Dime] Issue#35 conclusion

Hi MCruz,

Best regards
Ulrich

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext Maria Cruz Bartolome
Sent: Monday, February 24, 2014 2:02 PM
To: [email-masked]
Subject: Re: [Dime] Issue#35 conclusion

Hello JJ and all,

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Sent: lunes, 24 de febrero de 2014 13:43
To: [email-masked]
Subject: Re: [Dime] Issue#35 conclusion

Hi Mcruz and all

Best regards

Jacques 

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

Hello all,

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
Sent: lunes, 24 de febrero de 2014 12:28
To: ext Steve Donovan; [email-masked]
Subject: Re: [Dime] Issue#35 conclusion

Steve,

please see inline.

Ulrich

Ulrich,

Steve

See also inline.

Ulrich

-----Original Message-----
From: ext Ben Campbell [mailto:[email-masked]]
Sent: Thursday, February 20, 2014 11:55 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: [email-masked]
Subject: Re: [Dime] Issue#35 conclusion

 
Dear all,

I do not agree.

---

From: Steve Donovan <[email-masked]>
Date: Mon, 24 Feb 2014 09:56:13 -0600

Adding an AVP to indicate that a report applies just to the Origin-Host
in the request is not just an optimization for agents.

It had been my assumption all along that the default behavior of a
reporting node (server) would be to report a single overload value to
all reacting nodes, be they clients or agents.  If this is the default
behavior then it would be best to have the default, implicit, meaning of
an overload report to be "applies to all reacting nodes".  The real
value of this new feature is to allow a server to further throttle a
specific, overly active, reacting node when then global reduction
percentage doesn't do the job.

In addition, if the normal case is that reporting nodes have a single
global reduction percentage then requiring agents to bind an overload
report to each non supporting clients pushes a lot of extra work on
agents when it adds no value.

My proposal is the following:

- Add an optional AVP (call it something like Single-Node???) to
overload reports that indicate when an overload report applies to a
specific reacting node.

- Absence of the AVP indicates that the report applies to all reacting
nodes (clients and agents acting on behalf of non-DOIC clients).

- Reporting nodes should only include the Single-Node AVP if the
overload report contents are different from the global overload report.

- DOIC-supporting agents receiving an OLR without the Single-Node AVP
must do the following:
  - For transactions from DOIC-supporting clients the agent must not act
on the OLR.
  - For transactions from non-DOIC-supporting clients the agent must
apply the OLR to traffic from the set of non supporting clients.   This
implies that when making throttling decisions, the agent does not
differentiate which non supporting client originated the request.

- DOIC-supporting agents receiving an OLR with the Single-Node AVP for a
transaction originated by a non supporting client must bind that OLR to
that single client.

Note that the agent behavior is currently something that is missing from
the -01 version of the draft.  We will need something like this wording
independent of the resolution of this issue.

Steve

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Mon, 24 Feb 2014 18:19:25 +0000

Steve, all,

I agree with Steve.

However, I would like to share one concern. We need to avoid that existing (if any) host OLR ("all-client") in the reacting node is replaced by new host OLR (per client).
Host OLR (per client) with the new AVP requires that the server uses a new sequence number, but existing host OLR (all) shall not be replaced, on the contrary both Host OLR (all) and new Host OLR (per client) should remain.
In order to achieve this, it could be more convenient to use a dedicated OLR type (host per client), instead of a new AVP.

Let me know your opinions.
Best regards
/MCruz

From: DiME [mailto:[email-masked]] On Behalf Of Steve Donovan
Sent: lunes, 24 de febrero de 2014 16:56
To: [email-masked]
Subject: Re: [Dime] Issue#35 conclusion

Adding an AVP to indicate that a report applies just to the Origin-Host in the request is not just an optimization for agents.

It had been my assumption all along that the default behavior of a reporting node (server) would be to report a single overload value to all reacting nodes, be they clients or agents.  If this is the default behavior then it would be best to have the default, implicit, meaning of an overload report to be "applies to all reacting nodes".  The real value of this new feature is to allow a server to further throttle a specific, overly active, reacting node when then global reduction percentage doesn't do the job.

In addition, if the normal case is that reporting nodes have a single global reduction percentage then requiring agents to bind an overload report to each non supporting clients pushes a lot of extra work on agents when it adds no value.

- Add an optional AVP (call it something like Single-Node???) to overload reports that indicate when an overload report applies to a specific reacting node.

- Absence of the AVP indicates that the report applies to all reacting nodes (clients and agents acting on behalf of non-DOIC clients).

- Reporting nodes should only include the Single-Node AVP if the overload report contents are different from the global overload report.

- DOIC-supporting agents receiving an OLR without the Single-Node AVP must do the following:
  - For transactions from DOIC-supporting clients the agent must not act on the OLR.
  - For transactions from non-DOIC-supporting clients the agent must apply the OLR to traffic from the set of non supporting clients.   This implies that when making throttling decisions, the agent does not differentiate which non supporting client originated the request.

- DOIC-supporting agents receiving an OLR with the Single-Node AVP for a transaction originated by a non supporting client must bind that OLR to that single client.

Note that the agent behavior is currently something that is missing from the -01 version of the draft.  We will need something like this wording independent of the resolution of this issue.

Steve
On 2/24/14 8:06 AM, [email-masked]<mailto:[email-masked]> wrote:

Is it implicit?

Regards,

Lionel

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

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

Hello Ulrich,

Best regards

/MCruz

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

To: Maria Cruz Bartolome; [email-masked]<mailto:[email-masked]>

Hi MCruz,

Best regards

Ulrich

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

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

Hello JJ and all,

Best regards

/MCruz

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

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

Hi Mcruz and all

Best regards

Jacques

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

De : DiME [mailto:[email-masked]] De la part de Maria Cruz Bartolome Envoyé : lundi 24 février 2014 13:21 À : [email-masked]<mailto:[email-masked]> Objet : Re: [Dime] Issue#35 conclusion

Hello all,

Best regards

/MCruz

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

To: ext Steve Donovan; [email-masked]<mailto:[email-masked]>

Steve,

please see inline.

Ulrich

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

Ulrich,

Steve

Ben,

See also inline.

Ulrich

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

Dear all,

I do not agree.

DiME mailing list

DiME mailing list

DiME mailing list

DiME mailing list

DiME mailing list

DiME mailing list

Thank you.

DiME mailing list

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Mon, 24 Feb 2014 18:40:04 +0000

Hello again,

I forgot to mention something else in this thread, that I already mentioned in related thread #56.

This is all in order to take into account 3GPP requirement on overload mitigation differentiation per client. But this is a server option:

TR 29809 ch. 6.4.7.1 states "It may be up to the server/agent implementations to decide when and whether overload mitigation differentiation per client is used".

Therefore, we can even consider this new OLR out of the base draft, and be considered by 3GPP applications when required.

Best regards

/MCruz

From: DiME [mailto:[email-masked]] On Behalf Of Maria Cruz Bartolome
Sent: lunes, 24 de febrero de 2014 19:19
To: [email-masked]
Subject: Re: [Dime] Issue#35 conclusion

Steve, all,

I agree with Steve.

Steve

Is it implicit?

Regards,

Lionel

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

Hello Ulrich,

Best regards

/MCruz

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

Hi MCruz,

Best regards

Ulrich

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

Hello JJ and all,

Best regards

/MCruz

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

Hi Mcruz and all

Best regards

Jacques

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

Hello all,

Best regards

/MCruz

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

Steve,

please see inline.

Ulrich

Ulrich,

Steve

Ben,

See also inline.

Ulrich

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

Dear all,

I do not agree.

DiME mailing list

DiME mailing list

DiME mailing list

DiME mailing list

DiME mailing list

DiME mailing list

Thank you.

DiME mailing list

---

From: Steve Donovan <[email-masked]>
Date: Mon, 24 Feb 2014 12:50:17 -0600

Maria Cruz,

To the degree possible we should minimize the per application overload
logic required.  To this end, it would be better to have this as part of
the base specification, as it is likely that most/all applications will
want the same behavior.

Whether a reporting node uses per Origin-Host reports is an
implementation detail of the reporting node.  How reacting nodes respond
to per Origin-Host reports should be specified in a common way.

Steve

On 2/24/14 12:40 PM, Maria Cruz Bartolome wrote:
> This is all in order to take into account 3GPP requirement on overload
> mitigation differentiation per client. But this is a server option:
>
> TR 29809 ch. 6.4.7.1 states "It may be up to the server/agent
> implementations to decide when and whether overload mitigation
> differentiation per client is used".
>
>  
>
> Therefore, we can even consider this new OLR out of the base draft,
> and be considered by 3GPP applications when required.
>
>  
>
> Best regards
>
> /MCruz
>
>  
>
> *From:*DiME [mailto:[email-masked]] *On Behalf Of *Maria Cruz
> Bartolome
> *Sent:* lunes, 24 de febrero de 2014 19:19
> *To:* [email-masked]
> *Subject:* Re: [Dime] Issue#35 conclusion
>
>  
>
> Steve, all,
>
>
> I agree with Steve.
>
>  
>
> However, I would like to share one concern. We need to avoid that
> existing (if any) host OLR ("all-client") in the reacting node is
> replaced by new host OLR (per client).
>
> Host OLR (per client) with the new AVP requires that the server uses a
> new sequence number, but existing host OLR (all) shall not be
> replaced, on the contrary both Host OLR (all) and new Host OLR (per
> client) should remain.
>
> In order to achieve this, it could be more convenient to use a
> dedicated OLR type (host per client), instead of a new AVP.
>
>  
>
> *From:*DiME [mailto:[email-masked]] *On Behalf Of *Steve Donovan
> *Sent:* lunes, 24 de febrero de 2014 16:56
> *To:* [email-masked]
> *Subject:* Re: [Dime] Issue#35 conclusion
>
>  
>
> Adding an AVP to indicate that a report applies just to the
> Origin-Host in the request is not just an optimization for agents.
>
> behavior then it would be best to have the default, implicit, meaning
> of an overload report to be "applies to all reacting nodes".  The real
> apply the OLR to traffic from the set of non supporting clients.  
> This implies that when making throttling decisions, the agent does not
> - DOIC-supporting agents receiving an OLR with the Single-Node AVP for
> a transaction originated by a non supporting client must bind that OLR
> to that single client.
>
> Note that the agent behavior is currently something that is missing
> from the -01 version of the draft.  We will need something like this
> wording independent of the resolution of this issue.
>
> Steve
>
>     À : [email-masked] <mailto:[email-masked]>
>
>     To: Maria Cruz Bartolome; [email-masked] <mailto:[email-masked]>
>
>     To: [email-masked] <mailto:[email-masked]>
>
>     To: [email-masked] <mailto:[email-masked]>
>
>     De : DiME [mailto:[email-masked]] De la part de Maria Cruz Bartolome Envoyé : lundi 24 février 2014 13:21 À : [email-masked] <mailto:[email-masked]> Objet : Re: [Dime] Issue#35 conclusion
>
>      
>
>     Hello all,
>
>      
>
>     To: ext Steve Donovan; [email-masked] <mailto:[email-masked]>
>
>     To: [email-masked] <mailto:[email-masked]>
>
>     Cc: [email-masked] <mailto:[email-masked]>
>
>     On Feb 20, 2014, at 6:41 AM, Wiehe, Ulrich (NSN - DE/Munich) <[email-masked]> <mailto:[email-masked]> wrote:
>
>      
>
>     [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: <[email-masked]>
Date: Mon, 24 Feb 2014 18:57:14 +0000

I really don't understand but it is not the first time :)

What about the DOIC association? What about my assumption about agent maintaining overload control state for non-DOIC enabled client?
So for me, the proposal from Ulrich is a clarification on the agent behavior that was implicit if you consider the comments above.

For me, the option for the server is only to send a specific OLR for a specific client. So over two different DOIC association with the same server/reporting node, you can have two different OLRs.
But it does not change the way the OLR is handled by reacting nodes.

Lionel

De : DiME [mailto:[email-masked]] De la part de Steve Donovan
Envoyé : lundi 24 février 2014 19:50
À : [email-masked]
Objet : Re: [Dime] Issue#35 conclusion

Maria Cruz,

To the degree possible we should minimize the per application overload logic required.  To this end, it would be better to have this as part of the base specification, as it is likely that most/all applications will want the same behavior.

Whether a reporting node uses per Origin-Host reports is an implementation detail of the reporting node.  How reacting nodes respond to per Origin-Host reports should be specified in a common way.

Steve

Best regards

/MCruz

Steve, all,

I agree with Steve.

Steve

Is it implicit?

Regards,

Lionel

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

Hello Ulrich,

Best regards

/MCruz

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

Hi MCruz,

Best regards

Ulrich

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

Hello JJ and all,

Best regards

/MCruz

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

Hi Mcruz and all

Best regards

Jacques

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

Hello all,

Best regards

/MCruz

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

Steve,

please see inline.

Ulrich

Ulrich,

Steve

Ben,

See also inline.

Ulrich

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

Dear all,

I do not agree.

DiME mailing list

DiME mailing list

DiME mailing list

DiME mailing list

DiME mailing list

DiME mailing list

Thank you.

DiME mailing list

DiME mailing list

---

From: Steve Donovan <[email-masked]>
Date: Mon, 24 Feb 2014 13:24:14 -0600

Lionel,

The question is whether the reporting node is sending the overload
report per client or it is sending a global overload report that applies
to all clients. 

I still believe that the default behavior of a reporting node will be to
have a single overload reduction value for the application and that that
overload reduction value will apply to all clients.  If this is the case
then there is little benefit (and significant overhead) to requiring an
agent to maintain state per non-supporting client.

I also agree that there is value to the reporting node being able to
have a different reduction value for specific reacting nodes.  If this
is the case then the reporting node should indicate that it only applies
to the origin-host in the request and only then should agents be
required to maintain state for the non-supporting client.

Steve

On 2/24/14 12:57 PM, [email-masked] wrote:
>
> I really don't understand but it is not the first time J
>
>  
>
> What about the DOIC association? What about my assumption about agent
> maintaining overload control state for non-DOIC enabled client?
>
> So for me, the proposal from Ulrich is a clarification on the agent
> behavior that was implicit if you consider the comments above.
>
>  
>
> For me, the option for the server is only to send a specific OLR for a
> specific client. So over two different DOIC association with the same
> server/reporting node, you can have two different OLRs.
>
> *De :*DiME [mailto:[email-masked]] *De la part de* Steve Donovan
> *Envoyé :* lundi 24 février 2014 19:50
> *À :* [email-masked]
> *Objet :* Re: [Dime] Issue#35 conclusion
>
>  
>
> Maria Cruz,
>
> logic required.  To this end, it would be better to have this as part
> of the base specification, as it is likely that most/all applications
> will want the same behavior.
>
> implementation detail of the reporting node.  How reacting nodes
> respond to per Origin-Host reports should be specified in a common way.
>
> Steve
>
>     This is all in order to take into account 3GPP requirement on
>     overload mitigation differentiation per client. But this is a
>     server option:
>
>     Therefore, we can even consider this new OLR out of the base
>     draft, and be considered by 3GPP applications when required.
>
>      
>
>     Best regards
>
>     /MCruz
>
>      
>
>     *From:*DiME [mailto:[email-masked]] *On Behalf Of *Maria
>     Cruz Bartolome
>     *To:* [email-masked] <mailto:[email-masked]>
>     Host OLR (per client) with the new AVP requires that the server
>     uses a new sequence number, but existing host OLR (all) shall not
>     be replaced, on the contrary both Host OLR (all) and new Host OLR
>     (per client) should remain.
>
>     *To:* [email-masked] <mailto:[email-masked]>
>     reporting node (server) would be to report a single overload value
>     to all reacting nodes, be they clients or agents.  If this is the
>     default behavior then it would be best to have the default,
>     implicit, meaning of an overload report to be "applies to all
>     reacting nodes".  The real value of this new feature is to allow a
>     server to further throttle a specific, overly active, reacting
>     node when then global reduction percentage doesn't do the job.
>
>     In addition, if the normal case is that reporting nodes have a
>     single global reduction percentage then requiring agents to bind
>     an overload report to each non supporting clients pushes a lot of
>     extra work on agents when it adds no value.
>
>     overload reports that indicate when an overload report applies to
>     a specific reacting node.
>
>     - Absence of the AVP indicates that the report applies to all
>     reacting nodes (clients and agents acting on behalf of non-DOIC
>     clients).
>
>       - For transactions from non-DOIC-supporting clients the agent
>     must apply the OLR to traffic from the set of non supporting
>     clients.   This implies that when making throttling decisions, the
>     agent does not differentiate which non supporting client
>     originated the request.
>
>     - DOIC-supporting agents receiving an OLR with the Single-Node AVP
>     for a transaction originated by a non supporting client must bind
>     that OLR to that single client.
>
>     Note that the agent behavior is currently something that is
>     missing from the -01 version of the draft.  We will need something
>     like this wording independent of the resolution of this issue.
>
>     Steve
>

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Tue, 25 Feb 2014 09:08:54 +0000

Yes, I agree with Steve.

Best regards
/MCruz

From: DiME [mailto:[email-masked]] On Behalf Of Steve Donovan
Sent: lunes, 24 de febrero de 2014 20:24
To: [email-masked]; [email-masked]
Subject: Re: [Dime] Issue#35 conclusion

Lionel,

The question is whether the reporting node is sending the overload report per client or it is sending a global overload report that applies to all clients.

I still believe that the default behavior of a reporting node will be to have a single overload reduction value for the application and that that overload reduction value will apply to all clients.  If this is the case then there is little benefit (and significant overhead) to requiring an agent to maintain state per non-supporting client.

I also agree that there is value to the reporting node being able to have a different reduction value for specific reacting nodes.  If this is the case then the reporting node should indicate that it only applies to the origin-host in the request and only then should agents be required to maintain state for the non-supporting client.

Steve
On 2/24/14 12:57 PM, [email-masked]<mailto:[email-masked]> wrote:
I really don't understand but it is not the first time :)

Lionel

Maria Cruz,

Steve

Best regards

/MCruz

Steve, all,

I agree with Steve.

Steve

Is it implicit?

Regards,

Lionel

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

Hello Ulrich,

Best regards

/MCruz

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

Hi MCruz,

Best regards

Ulrich

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

Hello JJ and all,

Best regards

/MCruz

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

Hi Mcruz and all

Best regards

Jacques

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

Hello all,

Best regards

/MCruz

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

Steve,

please see inline.

Ulrich

Ulrich,

Steve

Ben,

See also inline.

Ulrich

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

Dear all,

I do not agree.

DiME mailing list

DiME mailing list

DiME mailing list

DiME mailing list

DiME mailing list

DiME mailing list

Thank you.

DiME mailing list

DiME mailing list

Thank you.

---

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Wed, 26 Feb 2014 07:07:09 +0000

Hi Steve, MCruz and all

On my side,  I agree with Lionel.

I  have not the  same reading of the draft where I have  not found the Steve's default case.
I agree with Lionel that the OLR for a DOIC association relates to this DOIC association  and the OLR can be different  for another DOIC association. The basic (or "default") principle is that each DOIC association has its "own life".

Then,  a server (local policy) can decide  to send  the same OLR to all its clients (so for all its DOIC associations) , or it can define  particular OLR values for   certain clients.
Another  interest  is that  when the server wants to update the OLR values towards  clients, it is  not obliged to send the new values  simultaneously  to all the clients : it may  (local server policy) progressively  change  the  value  over a certain duration  to minimize  sharp transitions.

So for DOIC supporting clients, the current text allows these possibilities, and in particular it satisfies the 3GGP client mitigation requirement.

A second step is to address DAs supporting non DOIC clients. Over time,  we may expect that clients will be more and more DOIC supporting; so, this is the main target. DAs with non DOIC client would be more for   a transition (to be considered  nevertheless and which may be long).

The current text says that DA is acting on behalf of "A" client; so principle  with host OLR per DOIC association also applies, and there is no difference for the server, as this does not make a difference  between a DOIC supporting client and a DA supporting non DOIC clients.
Nevertheless, and here I come to Steve's point,   this has a cost implying the DA to manage OLRs per client. Steve  introduces an optimization where in fact a set of clients are considered for me as a pool regarding  DOIC where only one OLR applies and where throttling  applies  to the requests of this  pool of clients.  I am not against to optimization process   but this pool concept is new and needs some further study. First about the concept of DOIC association which evolves , as now linked to a pool .

There was a MCruz remark about sequence number, a new AVP or a  new report type.  I see that  we may have to review  the processing of the seq number  handling as also dependent of the new AVP or the OLR type; so   a "collateral " effect of the optimization. I would also think that, instead of introducing a single node indication in the OLR (AVP or report type) , it should be a global indication as the optimization   is to support a global DOIC association.  To also see if there are not other collateral effects to analyze.

Ulrich  also mentioned that for realm OLRs we may also have  a different realm  OLR sent to different clients, so this is the same principle as Lionel  for  a realm OLR per DOIC association, on which I agree.

The current text due to the DOIC association principle,  allows this realm OLR per DOIC association for both  DOIC  supporting clients and  DAs acting on behalf of A client. Then I expect Steve  to do the same remark, with the same reason  to have  an optimization  where all clients receives  the  same realm OLR, but to also see the collateral effects.

As a conclusion, I think we should remain with the current text as the baseline, following the DOIC association principle that Lionel mentions, and after more investigation to assess the  optimization  for host and realm OLRs with DA supporting non DOIC,  this optimization being optional.

Best regards

JJacques

De : DiME [mailto:[email-masked]] De la part de Maria Cruz Bartolome
Envoyé : mardi 25 février 2014 10:09
À : [email-masked]
Objet : Re: [Dime] Issue#35 conclusion

Yes, I agree with Steve.

Best regards
/MCruz

From: DiME [mailto:[email-masked]] On Behalf Of Steve Donovan
Sent: lunes, 24 de febrero de 2014 20:24
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dime] Issue#35 conclusion

Lionel,

Steve

Lionel

Maria Cruz,

Steve

Best regards

/MCruz

Steve, all,

I agree with Steve.

Steve

Is it implicit?

Regards,

Lionel

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

Hello Ulrich,

Best regards

/MCruz

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

Hi MCruz,

Best regards

Ulrich

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

Hello JJ and all,

Best regards

/MCruz

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

Hi Mcruz and all

Best regards

Jacques

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

Hello all,

Best regards

/MCruz

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

Steve,

please see inline.

Ulrich

Ulrich,

Steve

Ben,

See also inline.

Ulrich

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

Dear all,

I do not agree.

DiME mailing list

DiME mailing list

DiME mailing list

DiME mailing list

DiME mailing list

DiME mailing list

Thank you.

DiME mailing list

DiME mailing list

Thank you.

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 26 Feb 2014 11:22:55 +0000

Hi JJacques,

thank you for the summary.

I think it does not matter whether we call

A)      "OLR per client" the base solution and "OLR for all clients" the optimization or

B)      "OLR for all clients" the base solution and "OLR per client" the (3GPP) extension
as long as we cover both.

I don't think there are impacts on sequence number handling, report types or DOIC associations.

My proposal then is to add a new mandatory AVP of type enumerated to OC-OLR with values

(0)    OLR per client

(1)    OLR for all clients

Reporting nodes that better like A) could allways send (0) unless they support the "optimization" and want to use it;
Reporting nodes that better like B) could allways send (1) unless they support the "(3GPP) extension" and want to use it.
Clients can safely ignore the new AVP.
Agents taking the role of the reacting node on behalf of a client must do the binding when receiving (0).

We also need to say something on interactions e.g.:
A fresh OLR of type (1) makes all old OLRs of any type invalid
A fresh OLR of type (0) makes an old OLR of type (0) bound to the same client invalid
A fresh OLR of type (0) makes an old OLR of type (1) invalid

(i.e. change of type is allowed, mixture is not allowed)

Ulrich

From: DiME [mailto:[email-masked]] On Behalf Of ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Sent: Wednesday, February 26, 2014 8:07 AM
To: [email-masked]
Subject: Re: [Dime] Issue#35 conclusion

Hi Steve, MCruz and all

Best regards

JJacques

Yes, I agree with Steve.

Best regards
/MCruz

Lionel,

Steve

Lionel

Maria Cruz,

Steve

Best regards

/MCruz

Steve, all,

I agree with Steve.

Steve

Is it implicit?

Regards,

Lionel

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

Hello Ulrich,

Best regards

/MCruz

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

Hi MCruz,

Best regards

Ulrich

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

Hello JJ and all,

Best regards

/MCruz

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

Hi Mcruz and all

Best regards

Jacques

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

Hello all,

Best regards

/MCruz

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

Steve,

please see inline.

Ulrich

Ulrich,

Steve

Ben,

See also inline.

Ulrich

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

Dear all,

I do not agree.

DiME mailing list

DiME mailing list

DiME mailing list

DiME mailing list

DiME mailing list

DiME mailing list

Thank you.

DiME mailing list

DiME mailing list

Thank you.

---

From: Steve Donovan <[email-masked]>
Date: Wed, 26 Feb 2014 06:31:39 -0600

+1
On 2/26/14 5:22 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> Reporting nodes that better like A) could allways send (0) unless they
> support the "optimization" and want to use it;
>
> Reporting nodes that better like B) could allways send (1) unless they
> support the "(3GPP) extension" and want to use it.
>
> *From:*DiME [mailto:[email-masked]] *On Behalf Of *ext TROTTIN,
> JEAN-JACQUES (JEAN-JACQUES)
> *Sent:* Wednesday, February 26, 2014 8:07 AM
> *To:* [email-masked]
> I agree with Lionel that the OLR for a DOIC association relates to
> this DOIC association  and the OLR can be different  for another DOIC
> association. The basic (or "default") principle is that each DOIC
> association has its "own life".
>
>  
>
> Then,  a server (local policy) can decide  to send  the same OLR to
> all its clients (so for all its DOIC associations) , or it can define
>  particular OLR values for   certain clients.
>
> Another  interest  is that  when the server wants to update the OLR
> values towards  clients, it is  not obliged to send the new values
>  simultaneously  to all the clients : it may  (local server policy)
> progressively  change  the  value  over a certain duration  to
> minimize  sharp transitions.
>
>  
>
> So for DOIC supporting clients, the current text allows these
> possibilities, and in particular it satisfies the 3GGP client
> mitigation requirement.
>
>  
>
> A second step is to address DAs supporting non DOIC clients. Over
> time,  we may expect that clients will be more and more DOIC
> supporting; so, this is the main target. DAs with non DOIC client
> would be more for   a transition (to be considered  nevertheless and
> which may be long).
>
>  
>
> The current text says that DA is acting on behalf of "A" client; so
> principle  with host OLR per DOIC association also applies, and there
> is no difference for the server, as this does not make a difference
>  between a DOIC supporting client and a DA supporting non DOIC clients.
>
> Nevertheless, and here I come to Steve's point,   this has a cost
> implying the DA to manage OLRs per client. Steve  introduces an
> optimization where in fact a set of clients are considered for me as a
> pool regarding  DOIC where only one OLR applies and where throttling
>  applies  to the requests of this  pool of clients.  I am not against
> to optimization process   but this pool concept is new and needs some
> further study. First about the concept of DOIC association which
> evolves , as now linked to a pool .
>
>  
>
> There was a MCruz remark about sequence number, a new AVP or a  new
> report type.  I see that  we may have to review  the processing of the
> seq number  handling as also dependent of the new AVP or the OLR type;
> so   a "collateral " effect of the optimization. I would also think
> that, instead of introducing a single node indication in the OLR (AVP
> or report type) , it should be a global indication as the optimization
>   is to support a global DOIC association.  To also see if there are
> not other collateral effects to analyze.
>
>  
>
> Ulrich  also mentioned that for realm OLRs we may also have  a
> different realm  OLR sent to different clients, so this is the same
> principle as Lionel  for  a realm OLR per DOIC association, on which I
> agree.
>
>  
>
> The current text due to the DOIC association principle,  allows this
> realm OLR per DOIC association for both  DOIC  supporting clients and
>  DAs acting on behalf of A client. Then I expect Steve  to do the same
> remark, with the same reason  to have  an optimization  where all
> clients receives  the  same realm OLR, but to also see the collateral
> effects.
>
>  
>
> As a conclusion, I think we should remain with the current text as the
> baseline, following the DOIC association principle that Lionel
> mentions, and after more investigation to assess the  optimization 
> for host and realm OLRs with DA supporting non DOIC,  this
> optimization being optional.
>
>  
>
> Best regards
>
>  
>
> JJacques
>
>  
>
> *De :*DiME [mailto:[email-masked]] *De la part de* Maria Cruz
> Bartolome
> *Envoyé :* mardi 25 février 2014 10:09
> *À :* [email-masked] <mailto:[email-masked]>
> *Sent:* lunes, 24 de febrero de 2014 20:24
> *To:* [email-masked] <mailto:[email-masked]>;
> [email-masked] <mailto:[email-masked]>
> report per client or it is sending a global overload report that
> applies to all clients. 
>
> I still believe that the default behavior of a reporting node will be
> to have a single overload reduction value for the application and that
> that overload reduction value will apply to all clients.  If this is
> the case then there is little benefit (and significant overhead) to
> requiring an agent to maintain state per non-supporting client.
>
> is the case then the reporting node should indicate that it only
> applies to the origin-host in the request and only then should agents
> be required to maintain state for the non-supporting client.
>
> Steve
>
>     What about the DOIC association? What about my assumption about
>     agent maintaining overload control state for non-DOIC enabled client?
>
>     So for me, the proposal from Ulrich is a clarification on the
>     agent behavior that was implicit if you consider the comments above.
>
>      
>
>     For me, the option for the server is only to send a specific OLR
>     for a specific client. So over two different DOIC association with
>     the same server/reporting node, you can have two different OLRs.
>
>     *À :* [email-masked] <mailto:[email-masked]>
>     To the degree possible we should minimize the per application
>     overload logic required.  To this end, it would be better to have
>     this as part of the base specification, as it is likely that
>     most/all applications will want the same behavior.
>
>         *From:*DiME [mailto:[email-masked]] *On Behalf Of
>         *Maria Cruz Bartolome
>         However, I would like to share one concern. We need to avoid
>         that existing (if any) host OLR ("all-client") in the reacting
>         node is replaced by new host OLR (per client).
>
>         Host OLR (per client) with the new AVP requires that the
>         server uses a new sequence number, but existing host OLR (all)
>         shall not be replaced, on the contrary both Host OLR (all) and
>         new Host OLR (per client) should remain.
>
>         It had been my assumption all along that the default behavior
>         of a reporting node (server) would be to report a single
>         overload value to all reacting nodes, be they clients or
>         agents.  If this is the default behavior then it would be best
>         to have the default, implicit, meaning of an overload report
>         to be "applies to all reacting nodes".  The real value of this
>         new feature is to allow a server to further throttle a
>         specific, overly active, reacting node when then global
>         reduction percentage doesn't do the job.
>
>         single global reduction percentage then requiring agents to
>         bind an overload report to each non supporting clients pushes
>         a lot of extra work on agents when it adds no value.
>
>         - Add an optional AVP (call it something like Single-Node???)
>         to overload reports that indicate when an overload report
>         applies to a specific reacting node.
>
>         reacting nodes (clients and agents acting on behalf of
>         non-DOIC clients).
>
>         - Reporting nodes should only include the Single-Node AVP if
>         the overload report contents are different from the global
>         overload report.
>
>           - For transactions from non-DOIC-supporting clients the
>         agent must apply the OLR to traffic from the set of non
>         supporting clients.   This implies that when making throttling
>         decisions, the agent does not differentiate which non
>         supporting client originated the request.
>
>         - DOIC-supporting agents receiving an OLR with the Single-Node
>         AVP for a transaction originated by a non supporting client
>         must bind that OLR to that single client.
>
>         missing from the -01 version of the draft.  We will need
>         something like this wording independent of the resolution of
>         this issue.
>
>         Steve
>

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Thu, 27 Feb 2014 16:12:33 +0000

Dear Ulrich,

Being:

(0)    OLR per client

(1)    OLR for all clients

Some comments on the interactions you mentioned:

1.      A fresh OLR of type (1) makes all old OLRs of any type invalid

2.      A fresh OLR of type (0) makes an old OLR of type (0) bound to the same client invalid

3.      A fresh OLR of type (0) makes an old OLR of type (1) invalid

I do not think 3) is right. Why an OLR per one specific client shall invalidate OLRs for rest of clients? This will imply that rest of clients will not have any overload mitigation on until they receive a new value of (1), or (0) for each of them.

Best regards
/MCruz

From: DiME [mailto:[email-masked]] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
Sent: miércoles, 26 de febrero de 2014 12:23
To: ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES); [email-masked]
Subject: Re: [Dime] Issue#35 conclusion

Hi JJacques,

(0)    OLR per client

(1)    OLR for all clients

Ulrich

Hi Steve, MCruz and all

Best regards

JJacques

Yes, I agree with Steve.

Best regards
/MCruz

Lionel,

Steve

Lionel

Maria Cruz,

Steve

Best regards

/MCruz

Steve, all,

I agree with Steve.

Steve

Is it implicit?

Regards,

Lionel

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

Hello Ulrich,

Best regards

/MCruz

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

Hi MCruz,

Best regards

Ulrich

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

Hello JJ and all,

Best regards

/MCruz

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

Hi Mcruz and all

Best regards

Jacques

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

Hello all,

Best regards

/MCruz

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

Steve,

please see inline.

Ulrich

Ulrich,

Steve

Ben,

See also inline.

Ulrich

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

Dear all,

I do not agree.

DiME mailing list

DiME mailing list

DiME mailing list

DiME mailing list

DiME mailing list

DiME mailing list

Thank you.

DiME mailing list

DiME mailing list

Thank you.

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 27 Feb 2014 17:47:08 +0000

Dear MCruz,

certainly a valid point. I don't have a strong view but I wanted to avoid the mixture to keep things simple.
Maybe we should forbid the change from 1 to 0 during an ongoing overload.

Anyway, I don't think this is a blocking point for the proposal to add the new AVP.

Best regards
Ulrich

From: DiME [mailto:[email-masked]] On Behalf Of ext Maria Cruz Bartolome
Sent: Thursday, February 27, 2014 5:13 PM
To: [email-masked]
Subject: Re: [Dime] Issue#35 conclusion

Dear Ulrich,

Being:

(0)    OLR per client

(1)    OLR for all clients

Best regards
/MCruz

From: DiME [mailto:[email-masked]] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
Sent: miércoles, 26 de febrero de 2014 12:23
To: ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES); [email-masked]<mailto:[email-masked]>
Subject: Re: [Dime] Issue#35 conclusion

Hi JJacques,

(0)    OLR per client

(1)    OLR for all clients

Ulrich

Hi Steve, MCruz and all

Best regards

JJacques

Yes, I agree with Steve.

Best regards
/MCruz

Lionel,

Steve

Lionel

Maria Cruz,

Steve

Best regards

/MCruz

Steve, all,

I agree with Steve.

Steve

Is it implicit?

Regards,

Lionel

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

Hello Ulrich,

Best regards

/MCruz

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

Hi MCruz,

Best regards

Ulrich

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

Hello JJ and all,

Best regards

/MCruz

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

Hi Mcruz and all

Best regards

Jacques

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

Hello all,

Best regards

/MCruz

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

Steve,

please see inline.

Ulrich

Ulrich,

Steve

Ben,

See also inline.

Ulrich

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

Dear all,

I do not agree.

DiME mailing list

DiME mailing list

DiME mailing list

DiME mailing list

DiME mailing list

DiME mailing list

Thank you.

DiME mailing list

DiME mailing list

Thank you.

---

From: Steve Donovan <[email-masked]>
Date: Thu, 27 Feb 2014 14:10:43 -0600

I think if you change number three to the following then it works better.

  3. A fresh OLR of type (0) makes an old OLR of type (1) invalid for
the client to which the answer message is being routed.  The agent shall
apply the OLR or type (0) for traffic from that client. The old OLR of
type (1) continues to apply for all clients that do not have a "per
client" overload report.

I think it is important for a reporting node to be able to start with an
"all clients" overload report and then transition to "per client"
reports for chatty clients.

Steve

On 2/27/14 11:47 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> *From:*DiME [mailto:[email-masked]] *On Behalf Of *ext Maria
> Cruz Bartolome
> *Sent:* Thursday, February 27, 2014 5:13 PM
> *To:* [email-masked]
> I do not think 3) is right. Why an OLR per one specific client shall
> invalidate OLRs for rest of clients? This will imply that rest of
> clients will not have any overload mitigation on until they receive a
> new value of (1), or (0) for each of them.
>
>  
>
> Best regards
>
> /MCruz
>
>  
>
>  
>
> *From:*DiME [mailto:[email-masked]] *On Behalf Of *Wiehe,
> Ulrich (NSN - DE/Munich)
> *Sent:* miércoles, 26 de febrero de 2014 12:23
> *To:* ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES); [email-masked]
> <mailto:[email-masked]>
>         *Steve Donovan