Subject: Re: [Dime] Issue#35 conclusion

From: Maria Cruz Bartolome <[email-masked]>
Date: Thu, 6 Mar 2014 07:59:51 +0000

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

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 6 Mar 2014 09:11:30 +0000

Dear MCruz,

for my clarification:
what you say about Host reports is also true for Realm-Routed-Request reports. Can you please confirm.

Proposal b) does not address the 3GPP requirement from TR 29.809 clause 6.4.7.  please confirm.

Also proposal b)  impacts the reporting node which must not send client specific OLRs (with separate sequence number streams for different clients)

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.

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.

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

Best regards
Ulrich

From: DiME [mailto:[email-masked]] On Behalf Of ext Maria Cruz Bartolome
Sent: Thursday, March 06, 2014 9:00 AM
To: [email-masked]
Subject: Re: [Dime] Issue#35 conclusion

Dear all,

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Thu, 6 Mar 2014 13:58:08 +0000

Dear Ulrich,

See below please
Best regards
/MCruz

From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:[email-masked]]
Sent: jueves, 06 de marzo de 2014 10:12
To: Maria Cruz Bartolome; [email-masked]
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.

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)".

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, and then there are not separate sequence number streams).

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:

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.

Best regards
Ulrich

From: DiME [mailto:[email-masked]] On Behalf Of ext Maria Cruz Bartolome
Sent: Thursday, March 06, 2014 9:00 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [Dime] Issue#35 conclusion

Dear all,

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 7 Mar 2014 08:07:39 +0000

Dear MCruz,

please see below

Best regards
Ulrich
From: ext Maria Cruz Bartolome [mailto:[email-masked]]
Sent: Thursday, March 06, 2014 2:58 PM
To: Wiehe, Ulrich (NSN - DE/Munich); [email-masked]
Subject: RE: [Dime] Issue#35 conclusion

Dear Ulrich,

See below please
Best regards
/MCruz

From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:[email-masked]]
Sent: jueves, 06 de marzo de 2014 10:12
To: Maria Cruz Bartolome; [email-masked]<mailto:[email-masked]>
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>

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

Also, shouldn't b) read:

Also, you say:

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>

Best regards
Ulrich

Dear all,

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Fri, 7 Mar 2014 16:30:56 +0000

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

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.

[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:

Also, you say:

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

Dear all,

---

From: Steve Donovan <[email-masked]>
Date: Tue, 18 Mar 2014 15:33:46 -0500

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:
> 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:[email-masked]]
> *Sent:* jueves, 06 de marzo de 2014 10:12
> *To:* Maria Cruz Bartolome; [email-masked] <mailto:[email-masked]>
> *Subject:* RE: [Dime] Issue#35 conclusion
>
>  
>
> Dear MCruz,
>
>  
>
> for my clarification:
>
> [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.
>
>  
>
> [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)".
>
> 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>
>
> [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.
>
> 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.
>
> 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).
>
> [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:[email-masked]] *On Behalf Of *ext Maria
> Cruz Bartolome
> *Sent:* Thursday, March 06, 2014 9:00 AM
> *To:* [email-masked] <mailto:[email-masked]>
> *Subject:* Re: [Dime] Issue#35 conclusion
>
>  
>
>  
>
>  
>
> Dear all,
>
>  
>
> 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*
>
> 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*
>
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 19 Mar 2014 08:35:54 +0000

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:[email-masked]] On Behalf Of ext Steve Donovan
Sent: Tuesday, March 18, 2014 9:34 PM
To: [email-masked]
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

Best regards
/MCruz

Dear MCruz,

for my clarification:

Also, shouldn't b) read:

Also, you say:

Best regards
Ulrich

Dear all,

DiME mailing list

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

---

From: Steve Donovan <[email-masked]>
Date: Wed, 19 Mar 2014 12:52:38 -0500

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.
>
>  
>
> 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:[email-masked]] *On Behalf Of *ext Steve
> Donovan
> *Sent:* Tuesday, March 18, 2014 9:34 PM
> *To:* [email-masked]
> changes will be made to the DOIC specification, with the statement
> that it needs to be addressed in an extension.
>
> Regards,
>
> Steve
>
>     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
>
>      
>
>     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] 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)".
>
>     [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:
>
>     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>
>
>     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:
>
>     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).
>
>     *From:*DiME [mailto:[email-masked]] *On Behalf Of *ext
>     Maria Cruz Bartolome
>     *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*
>
>     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_
>     [email-masked] <mailto:[email-masked]>
>

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 20 Mar 2014 07:45:13 +0000

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:[email-masked]]
Sent: Wednesday, March 19, 2014 6:53 PM
To: Wiehe, Ulrich (NSN - DE/Munich); [email-masked]
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

Best regards
Ulrich

All,

Regards,

Steve

Best regards
/MCruz

Dear MCruz,

for my clarification:

Also, shouldn't b) read:

Also, you say:

Best regards
Ulrich

Dear all,

DiME mailing list

---

From: Steve Donovan <[email-masked]>
Date: Thu, 20 Mar 2014 08:29:26 -0500

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:[email-masked]]
> *Sent:* Wednesday, March 19, 2014 6:53 PM
> *To:* Wiehe, Ulrich (NSN - DE/Munich); [email-masked]
>     Steve Donovan
>     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.
>
>         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
>
>          
>
>         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.
>
>          
>
>         [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)".
>
>         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
>         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>
>
>         [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.
>
>         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.
>
>         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).
>
>         [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
>
>          
>
>          
>
>          
>
>         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*
>
>         "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*
>

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 21 Mar 2014 08:22:07 +0000

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:[email-masked]]
Sent: Thursday, March 20, 2014 2:29 PM
To: Wiehe, Ulrich (NSN - DE/Munich); [email-masked]
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

please be more specific.
What are the issues?

Ulrich

From: ext Steve Donovan [mailto:[email-masked]]
Sent: Wednesday, March 19, 2014 6:53 PM
To: Wiehe, Ulrich (NSN - DE/Munich); [email-masked]<mailto:[email-masked]>
Subject: Re: [Dime] Issue#35 conclusion

Ulrich,

Regards,

Steve

Best regards
Ulrich

All,

Regards,

Steve

Best regards
/MCruz

Dear MCruz,

for my clarification:

Also, shouldn't b) read:

Also, you say:

Best regards
Ulrich

Dear all,

DiME mailing list

---

From: Steve Donovan <[email-masked]>
Date: Fri, 21 Mar 2014 08:17:23 -0500

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?
>
> 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
>
>  
>
> *Sent:* Thursday, March 20, 2014 2:29 PM
> Let's focus on getting the base specification done, then we can
> address this and other extensions that are considered important.
>
> Steve
>
>     If there are issues, they need to be solved anyway, no matter
>     whether we chose for a separate extension or not.
>
>      
>
>     Ulrich
>
>      
>
>     <mailto:[email-masked]>
>     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
>
>         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.
>
>          
>
>         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
>
>          
>
>         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
>
>             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
>
>              
>
>             [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.
>
>             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
>             [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)".
>
>             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:
>
>             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>
>
>             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
>             realm-routed-request type report to any
>             *non-DOIC-supporting* client that is sending requests
>             towards this host/realm.
>
>             "implicit" that agents would do the per client behaviour
>             as a default.
>
>             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).
>
>             [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:[email-masked]] *On Behalf Of
>             *ext Maria Cruz Bartolome
>             This mail thread started proposing new OLR reports to
>             request reduction for one specific client.
>
>             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*
>
>             But here we have one more option: allow the reporting node
>             to choose whether it prefers to apply this host-report to