Re: [Dime] Issue#30 status

Ulrich,

An OLR is included in every answer message only when the reporting node
is in an overload state.  There are no overload reports when the
reacting node is not overloaded.

Steve

On 2/26/14 3:23 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> Steve, Ben, all,
>
> on 1) we seem to agree that OC-Supported-Features in answers is not required for loss i.e. not required for  draft-ietf-dime-ovli. We can  leave it up to drafts associated with new abatement algorithms to specify the requirement to include OC-Supported-Features in answers if so needed (I still don't see the need even for rate or other algorithms); that needs to be discussed when discussing those drafts.
>
> On 2) I understand the usecase, but I'm not sure whether we have this requirement of selective proactive throttling (see e-mail from Lionel). Anyway, given the conclusion on #31, OLR will be included in all answer messages (exept when the reporting node is aware that the reacting node already knows). Therefore the reacting node can deduce support of DOIC by the reporting node from the presence of OLR (if OLR is present then DOIC is supported by the reporting node; if OLR is absent, then reacting node already knows whether or not DOIC is supported by the reporting node).
>
> Ulrich
>
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Ben Campbell
> Sent: Tuesday, February 25, 2014 12:02 AM
> To: Steve Donovan
> Cc: dime@ietf.org list
> Subject: Re: [Dime] Issue#30 status
>
>
> On Feb 24, 2014, at 2:12 PM, Steve Donovan <srdonovan@usdonovans.com> wrote:
>
>> I can see two additional reasons for requiring OC-Supported-Features:
>>
>> 1) If the reacting node needs to know in advance whether the type of overload abatement the reporting node will ask for.
>>
>> this is not needed in the case of the loss abatement algorithm as the reacting node can just immediately start throttling the appropriate number of requests.  It does not require prior knowledge of the traffic sent.
>>
>> There are abatement algorithms that do require the client to keep state about traffic sent to specific destinations.  We can, if we choose, leave it up to the drafts associated with the new abatement algorithms to specify the requirement to include OC-Supported-Features, as proposed by Ulrich.
>>
>> 2) If the reacting node can use the absence of the OC-Supported-Features AVP in answer messages to know that there is no Diameter overload supported in the network and thus take other measures to protect the Diameter network.  For example, I can envision a client implementation that adapts to the knowledge of whether servers support overload.  In the case that the server does support overload the client can send unlimited traffic to the server, up to the point that the server sends an OLR.  If the client determines that the server does not support overload then it might have a configured maximum rate that it will send to the server.
>>
>> My inclination is to include the OC-Supported-Features AVP in answers because most abatement algorithms will need it and because it can lead to better implementation client implementations.
> +1 on both points
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>