Re: [Dime] Proposed Example Text for draft-docdt-dime-ovli-01

Jouni,

with regard to 2) I agree with Ben and you.

For 3) I find it beneficial to distinguish between a) an Overload Report that requests a traffic reduction for traffic destined to a specific Host and b) an Overload Report that requests a traffic reduction for traffic to (an unspecified Host within) a specific Realm. 
It may however be possible to implicitly derive the ReportType (Host or Realm) from the presence/absence of a Destination Host in the corresponding request message. That means: only one OLR in an anwer, no explicit ReportType in the OLR. I think this proposal is more inline with the end-point concept.

Ulrich

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Jouni Korhonen
Sent: Wednesday, November 27, 2013 12:59 PM
To: Ben Campbell; dime@ietf.org
Subject: Re: [Dime] Proposed Example Text for draft-docdt-dime-ovli-01

On Nov 26, 2013, at 10:20 PM, Ben Campbell <ben@nostrum.com> wrote:

> 2)  Lionel argued that OLRs are best used to describe overload for the realm as a whole. Overload for specific nodes would be better handled by sending Diameter error codes, either by fixing one or more existing error codes to have the correct semantics, or introducing new ones. If we did this, we would not need different report types.
> 
> My opinion is that I would like a consistent way of reporting overload, that is, I don't like using OLRs for one kind of overload, and error result codes for another. In particular, I would like to be able to report overload before reaching the point that I need to fail a transaction, i.e. I would like to be able to report any kind of overload in a Diameter answer message with a result code of DIAMETER_SUCCESS.

I am towards Ben's conclusion here.

> 3) Are we allowed to put more than one OLRs in a single answer, as my example shows in step 8?
> 
> It might be possible to construct an example where you never see more than one OLR in a single answer. But I don't see what purpose would be served by such a limitation, as long as multiple OLRs do not contradict each other. Since the reports in the example have different report types, there is no conflict. On disadvantage of _not_ allowing multiple reports in one answer is that, if the servers choose to send reports in every answer, life gets complicated for the agent when trying to find a place to put the "realm" report.  It either needs to strip the server reports (which is hard given that the server overload conditions are best handled by the clients.) Or it needs to originate its own answers, which means forcing the failure of at least some transactions.

My recollection was that we want to get rid off the ReportType in the baseline. That would also imply a single OLR in an answer. I might remember wrong, though.

Anyway, just to be on the safe side the current draft-ietf-*-01 still has the ReportType.

Could we conclude this point asap? Removing the ReportType has implications in multiple places.

- Jouni

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime