Subject: [Dime] DOIC: Proposed resolution to issue #35

From: Steve Donovan <[email-masked]>
Date: Fri, 02 May 2014 08:23:39 -0500

All,

I believe that we reached consensus on issue #35 (client specific
overload reports) that this functionality should be deferred to a follow
on extension.

To this end, I propose adding the following to appendix A:

A.4 Client specific overload reports

This specification assumes that a reporting node sends a single overload
report to all reacting nodes.  This proposed extension would allow a
reporting node to send different overload reports, with different
reduction percentages (assuming the loss algorithm) to individual clients.

If we have agreement on this text, I'll add it to the -03 version of the
spec and close this issue.

Regards,

Steve

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 5 May 2014 09:25:11 +0000

Steve,

I still believe it is better to address the issue in the base spec rather than with an extension.
I have outlined a very simple approach:

-          Reacting nodes indicate in request messages whether they are clients or agents.

-          Reporting nodes do not do client specific reporting when the reacting node is an agent.

Ulrich

From: DiME [mailto:[email-masked]] On Behalf Of ext Steve Donovan
Sent: Friday, May 02, 2014 3:24 PM
To: [email-masked]
Subject: [Dime] DOIC: Proposed resolution to issue #35

All,

I believe that we reached consensus on issue #35 (client specific overload reports) that this functionality should be deferred to a follow on extension.

This specification assumes that a reporting node sends a single overload report to all reacting nodes.  This proposed extension would allow a reporting node to send different overload reports, with different reduction percentages (assuming the loss algorithm) to individual clients.

If we have agreement on this text, I'll add it to the -03 version of the spec and close this issue.

Regards,

Steve

---

From: Ben Campbell <[email-masked]>
Date: Mon, 5 May 2014 09:09:25 -0500

I think the issue needs non-trivial thought, and it wasn't one of our initial requirements. I'm okay if it gets into the base draft, but I'd hate to delay completion of the base draft over it.

Some examples of areas that need further thought: Have we thought through all the use cases for this? Why do we assume we never need "agent-specific" overload reports? Can we do this in a way that doesn't require different normative language for agents and clients when acting as reporting nodes?

My instinct is that the real answer to this is to add a (probably optional) AVP that contains the diameter identity of the "targeted" reacting-node. But we would need to think through use cases first.

On May 5, 2014, at 4:25 AM, Wiehe, Ulrich (NSN - DE/Munich) <[email-masked]> wrote:

> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 6 May 2014 09:59:21 +0000

Ben,

I don't think we need to add an AVP that contains the diameter identity of the "targeted" reacting-node to the OC-OLR.

Please find proposed modifications attached.

Comments are welcome.

Ulrich

---

From: Ben Campbell <[email-masked]>
Date: Tue, 6 May 2014 09:12:57 -0500

Hi Ulrich,

Any chance you can send that as text, rather than an office attachment? I do much of my IETF work from devices that do not render ms office files very well.

Thanks!

Ben.

On May 6, 2014, at 4:59 AM, Wiehe, Ulrich (NSN - DE/Munich) <[email-masked]> wrote:

> <draft-ietf-dime-ovli-02 Client specific Throttling.docx>

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Tue, 6 May 2014 14:57:48 +0000

Dear Ulrich,

Your proposal seems to be generic, i.e. any node, either client or agent, will be able to support "client-specific-throttling". Is this your intention?
> -          Reporting nodes do not do client specific reporting when the reacting node is an agent.

Could you clarify please?
Best regards
/MCruz

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
Sent: martes, 06 de mayo de 2014 11:59
To: ext Ben Campbell
Cc: [email-masked]
Subject: Re: [Dime] DOIC: Proposed resolution to issue #35

Ben,

Comments are welcome.

Ulrich

---

From: Ben Campbell <[email-masked]>
Date: Tue, 6 May 2014 10:04:48 -0500

Hi Ulrich,

(I can make that work, although in the future, it's much easier to respond point-by-point to plain text.)

I have a few of concerns with that approach:

1. I would like to see a solution that allows node-specific reports for any DOIC endpoint, not just for clients. (but it's not immediately clear to me how a reporting node might know to target non-adjacent agents.)

2. I do not trust that non-supporting agents will not change the origin-host AVP en route. 

3. Whether or not the identity of the targeted node goes into the OLR or not,  I would prefer a solution that identifies the targeted node somewhere in the message that actually carries the OLR, not in the associated request. Forcing reacting-nodes to refer back the original request requires extra state and extra steps.

On May 6, 2014, at 9:52 AM, Wiehe, Ulrich (NSN - DE/Munich) <[email-masked]> wrote:

> Hi Ben,
> 
> attached is the fie converted to pdf. Let me know if this works for you.
> 
> Ulrich
> 
> Sent: Tuesday, May 06, 2014 4:13 PM
> <draft-ietf-dime-ovli-02 Client specific Throttling.pdf>

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 7 May 2014 07:48:34 +0000

Dear Maria Cruz,

thank you for your comment.

Indeed, my original proposal was to limit client specific throttling support to clients (which anyway support it) and not specifying/recommending/allowing it for agents. 

The mechanism outlined, however, allows agents to implement client specific throttling, but there are issues:
- agents don't anyway support it (unlike clients do)
- complexity for agents supporting client specific throttling is quite high
- dependencies between client-specific and client-independent throttling need to be sorted out
- client-specific throttling support by agents (which do DOIC on behalf of non-DOIC clients) may not be needed in long term as more and more clients are expected to support DOIC in the future

In order to simplify things my proposal would be to say that agents are not expected to support client-specific throttling.

Best regards
Ulrich

-----Original Message-----
From: ext Maria Cruz Bartolome [mailto:[email-masked]] 
Sent: Tuesday, May 06, 2014 4:58 PM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Ben Campbell
Cc: [email-masked]
Subject: RE: [Dime] DOIC: Proposed resolution to issue #35

Dear Ulrich,

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
Sent: martes, 06 de mayo de 2014 11:59
To: ext Ben Campbell
Cc: [email-masked]
Subject: Re: [Dime] DOIC: Proposed resolution to issue #35

Ben,

Comments are welcome.

Ulrich

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 7 May 2014 09:21:08 +0000

Hi Ben,

please see inline

Ulrich

-----Original Message-----
From: ext Ben Campbell [mailto:[email-masked]] 
Sent: Tuesday, May 06, 2014 5:05 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: [email-masked] list
Subject: Re: [Dime] DOIC: Proposed resolution to issue #35

Hi Ulrich,

1. I would like to see a solution that allows node-specific reports for any DOIC endpoint, not just for clients. (but it's not immediately clear to me how a reporting node might know to target non-adjacent agents.)
<Ulrich>The 3GPP requirement from 29.809 clause 6.4.7 is "overload mitigation differentiation per client", it is not "overload mitigation differentiation per reacting node". In configurations like this:

+----+       +----+      +---+
| C1 |-------| A1 |------|   |
+----+ \   / +----+      |   |
        \ /              |   |
         X               | S |  
        / \              |   |
+----+ /   \ +----+      |   |      
| C2 |-------| A2 |------|   |
+----+       +----+      +---+
 
S may want to request a reduction of C1-to-S traffic (no matter whether routed via A1 or A2), while C2-to-S traffic (no matter whether routed via A1 or A2) is not throttled.

There is no requirement to let S request a reduction of A1-to-S traffic (no matter whether originated by C1 or C2), while A2-to-S traffic (no matter whether originated by C1 or C2) is not throttled. What would be the rational for such a requirement?</Ulrich>

2. I do not trust that non-supporting agents will not change the origin-host AVP en route. 
<Ulrich> This issue #66. Issue #66 seems to address answer messages only. Is your concern with request messages?</Ulrich>

3. Whether or not the identity of the targeted node goes into the OLR or not,  I would prefer a solution that identifies the targeted node somewhere in the message that actually carries the OLR, not in the associated request. Forcing reacting-nodes to refer back the original request requires extra state and extra steps.
<Ulrich>I agree. However, your concern is only relevant for agent-support of client specific throttling. If we agree to address only client-support of client specific throttling in the draft (see my response to MCruz), this issue disappears.  Anyway, my suggested text for clause 4.6  needs to be revised as answer messages do not contain Destination-Host/Destination-Realm.</Ulrich>

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 14 May 2014 10:21:27 +0000

Hi,

attached is an updated proposed text hopefully reflecting comments from Maria Cruz and Ben.

Ulrich

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) 
Sent: Wednesday, May 07, 2014 11:21 AM
To: 'ext Ben Campbell'
Cc: [email-masked] list
Subject: RE: [Dime] DOIC: Proposed resolution to issue #35

Hi Ben,

please see inline

Ulrich

-----Original Message-----
From: ext Ben Campbell [mailto:[email-masked]] 
Sent: Tuesday, May 06, 2014 5:05 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: [email-masked] list
Subject: Re: [Dime] DOIC: Proposed resolution to issue #35

Hi Ulrich,

+----+       +----+      +---+

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 14 May 2014 10:42:26 +0000

Sorry, I attached wrong files.
Here are correct files.

Ulrich

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) 
Sent: Wednesday, May 14, 2014 12:21 PM
To: Wiehe, Ulrich (NSN - DE/Munich); 'ext Ben Campbell'
Cc: [email-masked] list'
Subject: RE: [Dime] DOIC: Proposed resolution to issue #35

Hi,

Ulrich

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) 
Sent: Wednesday, May 07, 2014 11:21 AM
To: 'ext Ben Campbell'
Cc: [email-masked] list
Subject: RE: [Dime] DOIC: Proposed resolution to issue #35

Hi Ben,

please see inline

Ulrich

-----Original Message-----
From: ext Ben Campbell [mailto:[email-masked]] 
Sent: Tuesday, May 06, 2014 5:05 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: [email-masked] list
Subject: Re: [Dime] DOIC: Proposed resolution to issue #35

Hi Ulrich,

+----+       +----+      +---+

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Sun, 18 May 2014 12:18:34 +0000

Hello Ulrich,

In the following description in your text:

   OLR_CLIENT_SPECIFIC_THROTTLING (0x0000000000000002)

      When this flag is set by the reacting overload control endpoint it
      means that client specific throttling is supported. When this flag
      is set by the reporting overload control endpoint it means that
      client specific throttling is requested. When the reacting overload
      control endpoint did not indicate support of client specific throttling,
      the reporting overload control endpoint shall not request client
      specific throttling.
      Note: Reacting nodes which are clients trivially do support client
      specific throttling. Similarly, reacting nodes which are agents that
      perform throttling on behalf of a single client do support client 
      specific throttling. In contrast, reacting nodes which are agents
      that perform throttling on behalf of several clients are not required
      to support client specific throttling.

I have a concern on the Note, since there is one more case we should consider:
An agent that provides service to a realm is not throttling traffic on behalf of its clients but it is anyway the reacting node.
In this case, I expect agent is not supporting client-specific throttling but just default "all-client" throttling.

A part from that, not sure why this is a "note", rather than regular normative text. Not sure how "notes" are interpreted in IETF drafts/RFCs.

Thanks
/MCruz

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
Sent: miércoles, 14 de mayo de 2014 12:42
To: Wiehe, Ulrich (NSN - DE/Munich); ext Ben Campbell
Cc: [email-masked] list
Subject: Re: [Dime] DOIC: Proposed resolution to issue #35

Ulrich

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich)
Sent: Wednesday, May 14, 2014 12:21 PM
To: Wiehe, Ulrich (NSN - DE/Munich); 'ext Ben Campbell'
Cc: [email-masked] list'
Subject: RE: [Dime] DOIC: Proposed resolution to issue #35

Hi,

Ulrich

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich)
Sent: Wednesday, May 07, 2014 11:21 AM
To: 'ext Ben Campbell'
Cc: [email-masked] list
Subject: RE: [Dime] DOIC: Proposed resolution to issue #35

Hi Ben,

please see inline

Ulrich

-----Original Message-----
From: ext Ben Campbell [mailto:[email-masked]]
Sent: Tuesday, May 06, 2014 5:05 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: [email-masked] list
Subject: Re: [Dime] DOIC: Proposed resolution to issue #35

Hi Ulrich,

1. I would like to see a solution that allows node-specific reports for any DOIC endpoint, not just for clients. (but it's not immediately clear to me how a reporting node might know to target non-adjacent agents.) <Ulrich>The 3GPP requirement from 29.809 clause 6.4.7 is "overload mitigation differentiation per client", it is not "overload mitigation differentiation per reacting node". In configurations like this:

+----+       +----+      +---+

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 20 May 2014 15:16:46 +0000

Hi Maria Cruz,

I'm not sure to correctly understand your case.
I thought that an agent either does not perform throttling or performs throttling on behalf of a non supporting client.

Can you please clarify.

With regard to the note I'm ok to remove "Note: ".

Best regards
Ulrich

-----Original Message-----
From: ext Maria Cruz Bartolome [mailto:[email-masked]] 
Sent: Sunday, May 18, 2014 2:19 PM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Ben Campbell
Cc: [email-masked] list
Subject: RE: [Dime] DOIC: Proposed resolution to issue #35

Hello Ulrich,

Thanks
/MCruz

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
Sent: miércoles, 14 de mayo de 2014 12:42
To: Wiehe, Ulrich (NSN - DE/Munich); ext Ben Campbell
Cc: [email-masked] list
Subject: Re: [Dime] DOIC: Proposed resolution to issue #35

Ulrich

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich)
Sent: Wednesday, May 14, 2014 12:21 PM
To: Wiehe, Ulrich (NSN - DE/Munich); 'ext Ben Campbell'
Cc: [email-masked] list'
Subject: RE: [Dime] DOIC: Proposed resolution to issue #35

Hi,

Ulrich

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich)
Sent: Wednesday, May 07, 2014 11:21 AM
To: 'ext Ben Campbell'
Cc: [email-masked] list
Subject: RE: [Dime] DOIC: Proposed resolution to issue #35

Hi Ben,

please see inline

Ulrich

-----Original Message-----
From: ext Ben Campbell [mailto:[email-masked]]
Sent: Tuesday, May 06, 2014 5:05 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: [email-masked] list
Subject: Re: [Dime] DOIC: Proposed resolution to issue #35

Hi Ulrich,

+----+       +----+      +---+