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

From: "dime issue tracker" <[email-masked]>
Date: Fri, 05 Sep 2014 07:15:20 -0000

#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.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:  draft-ietf-dime-
  [email-masked]  |  [email-masked]
     Type:  defect                   |     Status:  new
 Priority:  minor                    |  Milestone:
Component:  draft-ietf-dime-ovli     |    Version:
 Severity:  Active WG Document       |   Keywords:
-------------------------------------+-------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket/67>
dime <http://tools.ietf.org/wg/dime/>

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 5 Sep 2014 08:14:49 +0000

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:[email-masked]] On Behalf Of ext dime issue tracker
Sent: Friday, September 05, 2014 9:15 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for Reporting Nodes - Expiry Time

 Then, original text:

    o  Sequence number

 Proposed modification:

    o  Sequence number

    o  Expiry Time

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

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Fri, 5 Sep 2014 08:20:28 +0000

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:[email-masked]] 
Sent: viernes, 05 de septiembre de 2014 10:15
To: [email-masked]; [email-masked]; 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.

Best regards
Ulrich   

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext dime issue tracker
Sent: Friday, September 05, 2014 9:15 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: [Dime] [dime] #67 (draft-ietf-dime-ovli): 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:

    o  Sequence number

 Proposed modification:

    o  Sequence number

    o  Expiry Time

-- 
-------------------------------------+----------------------------------
-------------------------------------+---
 Reporter:                           |      Owner:  draft-ietf-dime-
  [email-masked]  |  [email-masked]
     Type:  defect                   |     Status:  new
 Priority:  minor                    |  Milestone:
Component:  draft-ietf-dime-ovli     |    Version:
 Severity:  Active WG Document       |   Keywords:
-------------------------------------+----------------------------------
-------------------------------------+---

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Fri, 5 Sep 2014 10:23:17 +0000

Dear Ulrich,

If the reporting node decides to re-send an OLR, it should be because the information sent keeps being valid.
I.e. if reporting node resends "near" 10:00 (in your example) I think it could be considered that same values apply (i.e. same OC-Validity-Duration), then very same OLR could be sent, then it is a retransmission and the SeqNum could remain being the same. Then, reacting node if have already received the first OLR, it will simply ignore this new message, if not, it will store it as a new OCS.

But, if the reporting node wants to send same Reduction-Percentage a bit later, e.g. 10:03, then in my opinion, it should update OC-Validity-Duration, since the OCS indicates this overload occurrence expires at 10:05 (in this case, I understand why Expiry Time is required for). Then, OC-Validity-Duration has to be just 2 minutes and then reporting node needs to increase Seq-Number.

Is this the behavior you have in mind?

Cheers
/MCruz

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:[email-masked]] 
Sent: viernes, 05 de septiembre de 2014 10:43
To: Maria Cruz Bartolome
Subject: RE: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for Reporting Nodes - Expiry Time

Exactly.
If the OLR sent at 10:00 contains a duration of 5 minutes and the OLR sent at 10:01 contains a duration of 4 minutes, the two OLRs are different i.e. the later is not a replay but an update although it contains the same sequence number.
My understanding was that OLRs with identical sequence numbers should have identical content.

-----Original Message-----
From: ext Maria Cruz Bartolome [mailto:[email-masked]] 
Sent: Friday, September 05, 2014 10:20 AM
To: Wiehe, Ulrich (NSN - DE/Munich); [email-masked]; [email-masked]
Subject: RE: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for Reporting Nodes - Expiry Time

Dear Ulrich,

Thanks
/MCruz

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:[email-masked]] 
Sent: viernes, 05 de septiembre de 2014 10:15
To: [email-masked]; [email-masked]; 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.

Best regards
Ulrich   

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext dime issue tracker
Sent: Friday, September 05, 2014 9:15 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for Reporting Nodes - Expiry Time

 Then, original text:

    o  Sequence number

 Proposed modification:

    o  Sequence number

    o  Expiry Time

---

From: Steve Donovan <[email-masked]>
Date: Fri, 05 Sep 2014 08:59:03 -0500

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

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 5 Sep 2014 15:01:48 +0000

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:[email-masked]] On Behalf Of ext Steve Donovan
Sent: Friday, September 05, 2014 3:59 PM
To: [email-masked]
Subject: Re: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for Reporting Nodes - Expiry Time

Ulrich,

Regards,

Steve

---

From: Steve Donovan <[email-masked]>
Date: Fri, 05 Sep 2014 10:16:25 -0500

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

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 5 Sep 2014 15:32:49 +0000

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:[email-masked]] 
Sent: Friday, September 05, 2014 5:16 PM
To: Wiehe, Ulrich (NSN - DE/Munich); [email-masked]
Subject: Re: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for Reporting Nodes - Expiry Time

Ulrich,

Regards,

Steve

---

From: Steve Donovan <[email-masked]>
Date: Fri, 05 Sep 2014 13:38:36 -0500

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

---

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Mon, 8 Sep 2014 07:25:09 +0000

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:[email-masked]] De la part de Steve Donovan
Envoyé : vendredi 5 septembre 2014 20:39
À : Wiehe, Ulrich (NSN - DE/Munich); [email-masked]
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:
> 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 
>> 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.
>>

---

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Mon, 8 Sep 2014 09:35:34 +0000

HI

To complement my previous mail

Instead to refer to the 3GPP TR 29.807, I should have referred to the normative TS 29.274 v 12.5.0 integrating GTP Overload control (chapter 12)   with sections  12.3.5.1.2.1 Overload Control Sequence Number	276 and 12.3.5.1.2.2 Period of Validity and the following statement
"The sender of this information shall increment the Overload-Sequence-Number associated to a particular overload scope whenever modifying some information in the Overload-Control-Information IE. The Overload-Sequence-Number shall not be incremented otherwise."

Best regards

JJacques 

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Envoyé : lundi 8 septembre 2014 09:25
À : [email-masked]; Steve Donovan; Wiehe, Ulrich (NSN - DE/Munich)
Objet : Re: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for Reporting Nodes - Expiry Time

Dear all

 

Best regards

JJacques 

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

Ulrich,

Regards,

Steve

---

From: Ben Campbell <[email-masked]>
Date: Mon, 8 Sep 2014 16:09:29 -0500

> 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 durat…

+1

> 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…

Also, +1.

---

From: Steve Donovan <[email-masked]>
Date: Tue, 09 Sep 2014 10:12:05 -0500

JJ,

I think this is the behavior currently in the DOIC draft.  Are you 
suggesting changes to any wording in the draft?

Regards,

Steve

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Wed, 10 Sep 2014 14:15:47 +0000

Ulrich,

Yes, sending "expiry time" could be a good option, but only as long as time is synchronized between reporting and reacting nodes. Can we assure that?
Regards
/MCruz

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
Sent: viernes, 05 de septiembre de 2014 17:33
To: ext Steve Donovan; [email-masked]
Subject: Re: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for Reporting Nodes - Expiry Time

Steve,

Regards
Ulrich

-----Original Message-----
From: ext Steve Donovan [mailto:[email-masked]]
Sent: Friday, September 05, 2014 5:16 PM
To: Wiehe, Ulrich (NSN - DE/Munich); [email-masked]
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:
> not already received the OLR will treat it as a new report and get the 
> correct expiration time.
>

---

From: Ben Campbell <[email-masked]>
Date: Wed, 10 Sep 2014 15:05:41 -0500

The point of sending a validity period was to avoid a need for clock sync. Nodes may or may not have clock sync for other reasons, but I don't think we want to introduce that as a requirement for using DOIC.

In real life, I don't expect reporting nodes to have any idea how long a period of overload will last. Rather, the expiration time means "I'll update you within X seconds. If you don't get anything in that time, assume the overload is over". The point is to cause automatic clean-up of soft state, not to offer precise expiration time of the OCS.

 From that perspective, it's not all that critical that each responding node knows the "correct" expiration time. I just needs to be reasonably close.  For example, if a reporting node just reved the sequence number every X minutes as long as it's overload state has not changed, and changed nothing else, things will work reason. Not every reporting node will ramp back up at precisely the same time--but that can actually be a good thing.

If the reporting node wants to more precisely control the expiration of OCS, it should send a new with a new value (likely zero). 

(For the record, this is the way soft-state is typically handled by a number of other IETF protocols. For example, SIP.

> 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 expira…

[...]