Re: [Dime] Issue#35 conclusion

[Steve Donovan <[e-mail]>]

Ulrich,

I am communicating the consensus in the room at the DIME meeting in
London.  The consensus was that this issue should be dealt with in an
extension.

Regards,

Steve


On 3/21/14 3:22 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
> Steve,
>
>  
>
> while I understand and agree that we should not delay the base DOIC
> specification, I do not understand why "stop thinking" is the way to
> achieve this.
>
>  
>
> Is it that you don't want to spend time on identified issues (if so,
> which issues?), or that you don't want to spend time on the proposal?
>
> I still don't know what the issues with this proposal are.
>
> On the other hand I have indicated what the issue is when addressing
> client specific throttling with an extension: Clients which are not
> aware of the extension are still clients and therefore support client
> specific throttling but do not indicate so to reporting nodes which
> (when supporting the extension) cannot make use of client specific
> throttling although supported by both reacting and reporting nodes.
>
>  
>
> Ulrich
>
>  
>
> *From:*ext Steve Donovan [mailto:[e-mail]]
> *Sent:* Thursday, March 20, 2014 2:29 PM
> *To:* Wiehe, Ulrich (NSN - DE/Munich); [e-mail]
> *Subject:* Re: [Dime] Issue#35 conclusion
>
>  
>
> Ulrich,
>
> The reason for this being an extension is so that we do not delay the
> base DOIC specification spending time thinking through those issues. 
> The same argument has been made about the agent overload extension.
>
> Let's focus on getting the base specification done, then we can
> address this and other extensions that are considered important.
>
> Steve
>
> On 3/20/14 2:45 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
>     Steve,
>
>      
>
>     please be more specific.
>
>     What are the issues?
>
>      
>
>     If there are issues, they need to be solved anyway, no matter
>     whether we chose for a separate extension or not.
>
>      
>
>     Ulrich
>
>      
>
>     *From:*ext Steve Donovan [mailto:[e-mail]]
>     *Sent:* Wednesday, March 19, 2014 6:53 PM
>     *To:* Wiehe, Ulrich (NSN - DE/Munich); [e-mail]
>     <mailto:[e-mail]>
>     *Subject:* Re: [Dime] Issue#35 conclusion
>
>      
>
>     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] <mailto:[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
>
>          
>
>      
>
>  
>