Re: [Dime] Issue#35 conclusion

[<[e-mail]>]

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:[e-mail]] De la part de TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Envoyé : lundi 24 février 2014 11:15
À : [e-mail]
Objet : Re: [Dime] Issue#35 conclusion

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:[e-mail]] De la part de Steve Donovan
Envoyé : vendredi 21 février 2014 16:53
À : [e-mail]
Objet : Re: [Dime] Issue#35 conclusion

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:

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:[e-mail]]

Sent: Thursday, February 20, 2014 11:55 PM

To: Wiehe, Ulrich (NSN - DE/Munich)

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

Subject: Re: [Dime] Issue#35 conclusion





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



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



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>



 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.



_______________________________________________

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.