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

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) <ulrich.wiehe@nsn.com> wrote:

> Hi Ben,
> 
> attached is the fie converted to pdf. Let me know if this works for you.
> 
> Ulrich
> 
> -----Original Message-----
> From: ext Ben Campbell [mailto:ben@nostrum.com] 
> Sent: Tuesday, May 06, 2014 4:13 PM
> To: Wiehe, Ulrich (NSN - DE/Munich)
> Cc: ext Steve Donovan; dime@ietf.org
> Subject: Re: [Dime] DOIC: Proposed resolution to issue #35
> 
> 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) <ulrich.wiehe@nsn.com> wrote:
> 
>> 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
>> 
>> -----Original Message-----
>> From: ext Ben Campbell [mailto:ben@nostrum.com] 
>> Sent: Monday, May 05, 2014 4:09 PM
>> To: Wiehe, Ulrich (NSN - DE/Munich)
>> Cc: ext Steve Donovan; dime@ietf.org
>> Subject: Re: [Dime] DOIC: Proposed resolution to issue #35
>> 
>> 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) <ulrich.wiehe@nsn.com> wrote:
>> 
>>> 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:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
>>> Sent: Friday, May 02, 2014 3:24 PM
>>> To: dime@ietf.org
>>> 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.
>>> 
>>> 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
>>> _______________________________________________
>>> DiME mailing list
>>> DiME@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dime
>> 
>> <draft-ietf-dime-ovli-02 Client specific Throttling.docx>
> 
> <draft-ietf-dime-ovli-02 Client specific Throttling.pdf>