Re: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for Reporting Nodes - Expiry Time

["TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[e-mail]>]

Dear all

I suggest to have a look at what is foreseen with GTP overload control, where there is a validity timer with a recommended handling (TR 29.807 6.2.2.1.2. and 6.2.2.1.3). I think for Diameter and GTP overload we should have the same handling of the Validity period (and also the seq number) as I do not see a reason/justification them to be different.

For both cases the important point is that the timer (in the reacting node) is restarted only when a new sequence number is received (as Steve indicated, the IETF draft  is clear here: in 6.3 "The validity time MUST NOT be updated after reception of subsequent OC-OLR AVPs with the same sequence number") 

If the reacting node wants to recalculate the value at each answer, why not (as Steve said this is an implementation choice, probably not the best one), but if the reporting node wants the reacting node to take the new value sent in the OLR into account, it has to change the seq number. The frequency at which the reporting node updates the validity period is also implementation specific and depends  of the overload characteristics.
 
Another remark is that as the OLRs may be received out of order, if the reporting node changes the validity period  value (without changing the seq number) in OLR it sends, the reporting cannot be sure of the value  that the reacting node will use, for this it will have to change the seq number. So better to send the same value in OLRs if the same seq number. I think the principle is that the OLR content if the same (same AVPS with same values) if the seq number is not modified. This point is not clearly stated in the draft, may be good to indicate this. Otherwise, I do not think  we have to modify the OCS.

Best regards

JJacques 

 



-----Message d'origine-----
De : DiME [mailto:[e-mail]] De la part de Steve Donovan
Envoyé : vendredi 5 septembre 2014 20:39
À : Wiehe, Ulrich (NSN - DE/Munich); [e-mail]
Objet : Re: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for Reporting Nodes - Expiry Time

Ulrich,

What the reporting node does is an implementation decision.  If the reporting node wants to have precise control over when overload reports end on all reacting nodes then it can calculate the duration for every answer message sent.  If it considers it ok to have a staggered end of the OLR, or if it sends explicit end-of-overload OLRs then it might choose to not recalculate.  I don't see the need to specify that behavior in the DOIC specification.

The reacting node MUST NOT recalculate the expiration time because the sequence number is the same.  The reacting node will ignore the overload report and not bother to even look at any parameters in the report other then the sequence number.

Regards,

Steve

On 9/5/14, 10:32 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> Steve,
>
> if - as proposed by MCruz - the validity duration is not stored at the reporting node, the reporting node always has to calculate the duration (e.g. 4 min) from current time (e.g. 10:01) and expiration time (e.g. 10:05) and the reacting node has to calculate the expiration time from reception time and duration. Would it not be more straight forward to transmit the expiry time rather than the duration? This avoids the need to send different values depending on sending time.
>
> Regards
> Ulrich
>
> -----Original Message-----
> From: ext Steve Donovan [mailto:[e-mail]]
> Sent: Friday, September 05, 2014 5:16 PM
> To: Wiehe, Ulrich (NSN - DE/Munich); [e-mail]
> Subject: Re: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for 
> Reporting Nodes - Expiry Time
>
> Ulrich,
>
> My interpretation is that two OLRs with the same sequence number apply 
> to the same overload event at the reporting node.  The contents do not 
> need to be the same, although the only item in a loss report that is 
> likely to change is the validation time.
>
> The important behavior is that the reacting node ignores an overload 
> report with a sequence number it has already seen.  If that behavior 
> is followed then it doesn't matter if the contents of the report is an 
> exact replay of a previous report.
>
> Regards,
>
> Steve
>
> On 9/5/14, 10:01 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>> Steve,
>>
>> I would have thought that two OLRs with same sequence number must have same OLR content, especially same duration.
>> A replay is either an exact replay or its not a replay.
>> Regards
>> Ulrich
>>
>> -----Original Message-----
>> From: DiME [mailto:[e-mail]] On Behalf Of ext Steve 
>> Donovan
>> Sent: Friday, September 05, 2014 3:59 PM
>> To: [e-mail]
>> Subject: Re: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for 
>> Reporting Nodes - Expiry Time
>>
>> Ulrich,
>>
>> I think it would be correct for the OLR sent at 10:01 to indicate 
>> that the OLR expires in four minutes.
>>
>> A reacting node that has already received the OLR will ignore it 
>> because the sequence number is unchanged.  A reacting node that has 
>> not already received the OLR will treat it as a new report and get 
>> the correct expiration time.
>>
>> It is certainly possible to implement it so that the OLR sent to a 
>> specific reacting node always gets an exact replay until the report 
>> changes or expires but I don't see that as a requirement.
>>
>> Regards,
>>
>> Steve
>>
>> On 9/5/14, 3:20 AM, Maria Cruz Bartolome wrote:
>>> Dear Ulrich,
>>>
>>> Not sure if I understand your point.
>>> Is it your intention to send Validity-Duration AVP = OCS Validity Duration (in your example 300 s) until timer expires (in your example until 10:05)?
>>> Could you elaborate a bit further please?
>>>
>>> Thanks
>>> /MCruz
>>>
>>> -----Original Message-----
>>> From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:[e-mail]]
>>> Sent: viernes, 05 de septiembre de 2014 10:15
>>> To: [e-mail]; [e-mail]; Maria Cruz 
>>> Bartolome
>>> Subject: RE: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for 
>>> Reporting Nodes - Expiry Time
>>>
>>> Dear Maria Cruz,
>>>
>>> I do not agree.
>>> As an example assume that the reporting node creates an overload state at 10:00 with a duration of 5 minutes. This means that Validity duration is 5 minutes and expiry time is 10:05.
>>> If only expiration time but not validity duration is stored at the reporting node, this will result in the following:
>>> For an answer message that is sent immediately (i.e. at 10:00) validity duration will be calculated as 5 minutes (which I think is correct).
>>> For an answer message that is sent at 10:01 validity duration will be calculated as 4 minutes, which I think is not correct. The answer message sent at 10:01 should contain a replay of the OLR already sent at 10:00, not an updated OLR.
>>>
>>> Therefore validity duration should not be removed from the OCS.
>>>
>>> Best regards
>>> Ulrich
>>>
>>>
>>> -----Original Message-----
>>> From: DiME [mailto:[e-mail]] On Behalf Of ext dime 
>>> issue tracker
>>> Sent: Friday, September 05, 2014 9:15 AM
>>> To: [e-mail]; 
>>> [e-mail]
>>> Cc: [e-mail]
>>> Subject: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for Reporting 
>>> Nodes - Expiry Time
>>>
>>> #67: OCS for Reporting Nodes - Expiry Time
>>>
>>>     What does "Validity Duration" mean as the information stored in OCS for  Reporting Nodes?
>>>
>>>     We need to store some information that allow the reporting node to  calculate a Validity-Duration value to be included in each OC-OLR AVP  Then, I presume we need just Expiry Time, and then value to be included in  each Validation-Duration AVP is calculated based on this.
>>>
>>>     Then, original text:
>>>
>>>     4.2.1.2.  Overload Control States for Reporting Nodes
>>>
>>>        A reporting node maintains per supported Diameter application and per
>>>        supported (and eventually selected) Abatement Algorithm an Overload
>>>        Control State.
>>>
>>>        An Overload Control State may be identified by the pair of
>>>        Application-Id and supported Abatement Algorithm.
>>>
>>>        The Overload Control State for a given pair of Application and
>>>        Abatement Algorithm could include the information:
>>>
>>>        o  Sequence number
>>>
>>>        o  Validity Duration and Expiry Time
>>>
>>>        o  Algorithm specific input data (e.g.  Reduction Percentage for
>>>           Loss)
>>>
>>>        Overload Control States for reporting nodes containing a validity
>>>        duration of 0 sec. should not expire before any previously sent
>>>        (stale) OLR has timed out at any reacting node.
>>>
>>>        Editor's note: This statement is unclear and contradictory with other
>>>        statements.  A validity timer of zero seconds indicates that the
>>>        overload condition has ended and abatement is no longer requested.
>>>
>>>
>>>     Proposed modification:
>>>
>>>     4.2.1.2.  Overload Control States for Reporting Nodes
>>>
>>>        A reporting node maintains per supported Diameter application and per
>>>        supported (and eventually selected) Abatement Algorithm an Overload
>>>        Control State.
>>>
>>>        An Overload Control State may be identified by the pair of
>>>        Application-Id and supported Abatement Algorithm.
>>>
>>>        The Overload Control State for a given pair of Application and
>>>        Abatement Algorithm could include the information:
>>>
>>>        o  Sequence number
>>>
>>>        o  Expiry Time
>>>
>>>        o  Algorithm specific input data (e.g.  Reduction Percentage for
>>>           Loss)
>>>
>>>        Expiry Time is used by the reporting node to calculate the value to be
>>>        included in each Validity-Duration AVP, as part of the overload report.
>>>
>> _______________________________________________
>> DiME mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dime
>>
>

_______________________________________________
DiME mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dime