Re: [Dime] Issue#35 conclusion

[Steve Donovan <[e-mail]>]

Ulrich,

I'm concerned there are issues with agents, and potentially reporting
nodes, that would lurk behind this proposal.  I think it is best to
leave this to a separate enhancement to be sure that those issues are
properly vetted.

Regards,

Steve

On 3/19/14 3:35 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
> Steve, all,
>
>  
>
> one proposal to solve the issue was to let clients indicate in
> OC-Supported-Features that they support client specific throttling
> (while agents taking the role of the reacting node on behalf of
> multiple clients would not indicate such support).
>
>  
>
> This could certainly be done by a separate extension to the DOIC
> specification, but, given that clients allways support  client
> specific throttling, clients not aware of the extension would not
> indicate so in OC-Supported Features which is realy a pitty.
>
>  
>
> Therefore I would like to ask people considering taking this small
> enhancement on board:
>
>  
>
> Clients allways indicate support of client specific throttling;
>
> Agents (taking the role of  a reacting node on behalf of multiple
> clients) never indicate support of client specific throttling;
>
> Reporting nodes may make use of this indication and request client
> specific throttling only when the reacting node indicated support.
>
>  
>
> Best regards
>
> Ulrich
>
>  
>
> *From:*DiME [mailto:[e-mail]] *On Behalf Of *ext Steve
> Donovan
> *Sent:* Tuesday, March 18, 2014 9:34 PM
> *To:* [e-mail]
> *Subject:* Re: [Dime] Issue#35 conclusion
>
>  
>
> All,
>
> As Maria Cruz indicates, the tentative conclusion in the DIME working
> group meeting in London was that this requirement be addressed in a
> separate extension to the DOIC specification.
>
> As a result, I propose that we close this issue indicating that no
> changes will be made to the DOIC specification, with the statement
> that it needs to be addressed in an extension.
>
> Regards,
>
> Steve
>
> On 3/7/14 10:30 AM, Maria Cruz Bartolome wrote:
>
>     Dear Ulrich,
>
>      
>
>     See comments below please.
>
>     Anyway, since during IETF meeting it was commented that this could
>     be considered as an extension, not sure how this should be managed
>     from now on. I presume we should confirm that in this list.
>
>      
>
>     Best regards
>
>     /MCruz
>
>      
>
>     *From:*Wiehe, Ulrich (NSN - DE/Munich) [mailto:[e-mail]]
>     *Sent:* jueves, 06 de marzo de 2014 10:12
>     *To:* Maria Cruz Bartolome; [e-mail] <mailto:[e-mail]>
>     *Subject:* RE: [Dime] Issue#35 conclusion
>
>      
>
>     Dear MCruz,
>
>      
>
>     for my clarification:
>
>     what you say about Host reports is also true for
>     Realm-Routed-Request reports. Can you please confirm.
>
>     [MCruz] I think this case is different. If we agree that realm
>     reports are only generated by agents (as an aggregated report
>     based on host reports and potentially another implementation
>     dependent criteria), then the server itself does not require a
>     traffic-to-realm reduction, on the contrary, the host only
>     requests a traffic-to-host reduction. Agent may or not (I think
>     this is up in the draft) to  forward back to the original client
>     this host-report. Then, not sure if we really need something else
>     here.
>
>     <Ulrich> I don't know whether it is still relevant, but I would
>     have thought that the agent that generates a realm-routed-request
>     report, when taking the host reports received from servers into
>     accout for the aggregation, may e.g. detect that all the severs
>     request reduction of traffic from the same a specific client.
>     Would it not be logical that the aggregated realm-routed-request
>     report in this case also only requests reduction from that client
>     (with the aggregated percentage)? </Ulrich>
>
>     [MCruz] This could be something to be considered and could provide
>     some added value, but it is up to interpretation whether this is
>     required.
>
>      
>
>     Proposal b) does not address the 3GPP requirement from TR 29.809
>     clause 6.4.7.  please confirm.
>
>     [MCruz] It does address the 3GPP requirement in general, but not
>     for one specific case:  "There is one special case here, when the
>     agent is acting on behalf of the client (i.e. for a non-supporting
>     client or for an agent SFE with topology hiding)".
>
>     <Ulrich> I'm not sure, see below</Ulrich>
>
>      
>
>     Also proposal b)  impacts the reporting node which must not send
>     client specific OLRs (with separate sequence number streams for
>     different clients)
>
>     [MCruz] I do not think so. In the case I mentioned, when the agent
>     is acting on behalf of the client, it is always the receiver of
>     the answers (i.e. from a host perspective, the client is the agent
>
>     <Ulrich>This is not correct. The host (reporting node) does not
>     know whether the reacting node is the client (identified by
>     orig-host in the request) or an agent (acting on behalf of the
>     client and possibly also on behalf of other clients); the
>     reporting node receives a request that contains an
>     OC-Supported-Features AVP; this indicates to the reporting node
>     that there is a downstream node supporting DOIC. Let me give an
>     example:
>
>     Two non-supporting clients C1 and C2 send requests via the same
>     supporting agent A to the server. Traffic from C1 increases, so S
>     requests a 10% throttling from C1 (sequence number 1). As the
>     agent A is acting on behalf of C1, A will do the throttling. As a
>     not wanted but acceptable side effect A will also throttle traffic
>     sent from C2 to S. Now the situation improves and S only requests
>     a 5% reduction from C1 (sequence number 2).  Again A will apply
>     the 5% throttling also for traffic from C2, which again is not
>     nice but acceptable. Now  Traffic from C2 increases (although
>     throttled with 5%) and S request a 50% throttling from C2
>     (sequence number 1). </Ulrich>
>
>     , and then there are not separate sequence number streams).
>
>     [MCruz] I think your example is right, and it highlights something
>     important I haven't realized. Since the server may send totally
>     different reduction requests to different clients, as in your
>     example, the key point is not even that they carry different
>     sequence numbers, but that reduction to apply to "all" clients
>     will oscillate a lot, depending on server requests towards one
>     specific client. Then, a way to solve this is that the server
>     knows whether or not an agent is acting on behalf of the final
>     client. If so, reporting node should not request reductions per
>     client (i.e. %reduction will be the same for any client).
>
>      
>
>     Also, shouldn't b) read:
>
>     We expect the agent to apply this host type / realm-routed-request
>     type report to any *non-DOIC-supporting* client that is sending
>     requests towards this host/realm.
>
>     [MCruz] Yes, any non-DOIC-supporting client.
>
>      
>
>     Also, you say:
>
>     b) does not require any changes to the actual draft
>
>      
>
>     I guess at least some clarification is required as some (Lionel,
>     Nirav, but not Steve)  think it is "natural" and "implicit" that
>     agents would do the per client behaviour as a default.
>
>     [MCruz] Agreed, at least clarification is required.
>
>      
>
>     An alternative proposal that addresses the complexity argument for
>     agents but at the same time at least partly addresses the 3GPP
>     requirement would be to make use of a feature flag: clients
>     allways set the flag, agents do not set the flag, reporting nodes
>     may send client specific OLRs when the flag in the request was
>     set. This has no big impact to clients (only always set the
>     feature flag), no impacts to agents, and allows (if so desired)
>     reporting nodes to make use of the client specific throttling (at
>     least in some cases).
>
>     <Ulrich>any comments?</Ulrich>
>
>     [MCruz] I agree this could be a way for the reporting node to know
>     that an agent is not acting on behalf of a client
>
>      
>
>     Best regards
>
>     Ulrich
>
>      
>
>      
>
>      
>
>     *From:*DiME [mailto:[e-mail]] *On Behalf Of *ext
>     Maria Cruz Bartolome
>     *Sent:* Thursday, March 06, 2014 9:00 AM
>     *To:* [e-mail] <mailto:[e-mail]>
>     *Subject:* Re: [Dime] Issue#35 conclusion
>
>      
>
>      
>
>      
>
>     Dear all,
>
>      
>
>     This mail thread started proposing new OLR reports to request
>     reduction for one specific client.
>
>     However, the discussion clarified that as it is the draft today,
>     *Host*-report is sent from a reporting node towards the client
>     from where it receives the request. Then, reduction is requested
>     per client in all cases already.
>
>     There is one special case here, when the agent is acting on behalf
>     of the client (i.e. for a non-supporting client or for an agent
>     SFE with topology hiding). In this case, the reporting node sends
>     host-report to agent. Here we have two options:
>
>      
>
>     a)      *We expect the agent to apply the host-report received in
>     an answer to specifically the client that sent the corresponding
>     request*
>
>     This requires some extra complexity at agent side.
>
>     But here we have one more option: allow the reporting node to
>     choose whether it prefers to apply this host-report to
>     "all-client" vs "one-client". That increases again the complexity
>     (at reporting node, protocol-wise, and at agent).
>
>      
>
>     b)      *We expect the agent to apply this host-report to _any_
>     client that is sending a request towards this agent*
>
>     In my opinion, this is the best approach, it reduces complexity
>     and increases robustness.
>
>      
>
>     Therefore, I will be in favor of option b), which does not require
>     any changes to the actual draft.
>
>      
>
>     Let me know your opinions.
>
>     Best regards
>
>     /MCruz
>
>      
>
>      
>
>
>
>
>     _______________________________________________
>
>     DiME mailing list
>
>     [e-mail] <mailto:[e-mail]>
>
>     https://www.ietf.org/mailman/listinfo/dime
>
>  
>