Re: [Dime] Issue#35 conclusion

[Steve Donovan <[e-mail]>]

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:
>
> 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:[e-mail]] *On Behalf Of *Maria Cruz
> Bartolome
> *Sent:* lunes, 24 de febrero de 2014 19:19
> *To:* [e-mail]
> *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.
>
>  
>
> Let me know your opinions.
>
> Best regards
>
> /MCruz
>
>  
>
>  
>
> *From:*DiME [mailto:[e-mail]] *On Behalf Of *Steve Donovan
> *Sent:* lunes, 24 de febrero de 2014 16:56
> *To:* [e-mail]
> *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.
>
> 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
>
> On 2/24/14 8:06 AM, [e-mail]
> <mailto:[e-mail]> wrote:
>
>     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-----
>
>     De : DiME [mailto:[e-mail]] De la part de Maria Cruz Bartolome
>
>     Envoyé : lundi 24 février 2014 14:27
>
>     À : [e-mail] <mailto:[e-mail]>
>
>     Objet : Re: [Dime] Issue#35 conclusion
>
>      
>
>     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:[e-mail]] 
>
>     Sent: lunes, 24 de febrero de 2014 14:19
>
>     To: Maria Cruz Bartolome; [e-mail] <mailto:[e-mail]>
>
>     Subject: RE: [Dime] Issue#35 conclusion
>
>      
>
>     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:[e-mail]] On Behalf Of ext Maria Cruz Bartolome
>
>     Sent: Monday, February 24, 2014 2:02 PM
>
>     To: [e-mail] <mailto:[e-mail]>
>
>     Subject: Re: [Dime] Issue#35 conclusion
>
>      
>
>     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:[e-mail]] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
>
>     Sent: lunes, 24 de febrero de 2014 13:43
>
>     To: [e-mail] <mailto:[e-mail]>
>
>     Subject: Re: [Dime] Issue#35 conclusion
>
>      
>
>     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:[e-mail]] De la part de Maria Cruz Bartolome Envoyé : lundi 24 février 2014 13:21 À : [e-mail] <mailto:[e-mail]> Objet : Re: [Dime] Issue#35 conclusion
>
>      
>
>     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:[e-mail]] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
>
>     Sent: lunes, 24 de febrero de 2014 12:28
>
>     To: ext Steve Donovan; [e-mail] <mailto:[e-mail]>
>
>     Subject: Re: [Dime] Issue#35 conclusion
>
>      
>
>     Steve,
>
>      
>
>     please see inline.
>
>      
>
>     Ulrich
>
>      
>
>     From: DiME [mailto:[e-mail]] On Behalf Of ext Steve Donovan
>
>     Sent: Friday, February 21, 2014 4:53 PM
>
>     To: [e-mail] <mailto:[e-mail]>
>
>     Subject: 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.
>
>     <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
>
>     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
>
>      
>
>      
>
>     _______________________________________________
>
>     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
>
>      
>
>     _______________________________________________
>
>     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
>
>      
>
>  
>
>
>
> _______________________________________________
> DiME mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dime