Subject: [Dime] [dime] #72 (draft-ietf-dime-ovli): Reporting Node Behaviour when OC-OLR is not received

From: "dime issue tracker" <[email-masked]>
Date: Fri, 05 Sep 2014 08:03:41 -0000

#72: Reporting Node Behaviour when OC-OLR is not received

 A clarification is required to consider that an answer message may not
 include OC-OLR and still the reporting node be  overloaded, since it is
 considered as "no change", as documented in 4.2.1.3:

     Reacting nodes do not delete an OCS when receiving an answer message
     that does not contain an OC-OLR AVP (i.e. absence of OLR means "no
     change").

 Original text:

 5.3.  Reporting Node Behavior (Normative)

    The method a reporting nodes uses to determine the amount of traffic
    reduction required to address an overload condition is an
    implementation decision.

    When a reporting node that has selected the loss abatement algorithm
    determines the need to request a traffic reduction it must include an
    OC-OLR AVP in all response messages.

 Proposed addition:

 5.3.  Reporting Node Behavior (Normative)

    The method a reporting nodes uses to determine the amount of traffic
    reduction required to address an overload condition is an
    implementation decision.

    When a reporting node that has selected the loss abatement algorithm
    determines the need to request a traffic reduction it must include an
    OC-OLR AVP in all response messages. OC-OLR AVP is not included when
 reporting node expectations on traffic reduction are not modified. That
 is, if OC-OLR AVP is not included it is interpreted as “no change”.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:  draft-ietf-dime-
  [email-masked]  |  [email-masked]
     Type:  enhancement              |     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/72>
dime <http://tools.ietf.org/wg/dime/>

---

From: Steve Donovan <[email-masked]>
Date: Fri, 05 Sep 2014 09:30:43 -0500

Maria Cruz,

I'm not sure I agree with this proposed change.

The wording to indicate that absence of an overload report was to handle 
unusual situations.  Your proposed wording implies that it is acceptable 
for a reporting node to not include the OLR in every answer message.

I think it is better to specify the behavior of the reporting node to 
always include the OLR in every answer message for as long as there is 
an overload condition at the reporting node.

Regards,

Steve

---

From: "Nirav Salot (nsalot)" <[email-masked]>
Date: Mon, 8 Sep 2014 04:48:06 +0000

Steve,

> I think it is better to specify the behavior of the reporting node to always include the OLR in every answer message for as long as there is an overload condition at the reporting node.
I don’t think this is necessary. The reporting may include the OLR in every answer message but we don’t have to put that as mandatory requirement, e.g. if the reporting node knows (and keeps track of) if the target reacting node has already received currently active OLR.

Regards,
Nirav.

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Steve Donovan
Sent: Friday, September 05, 2014 8:01 PM
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Dime] [dime] #72 (draft-ietf-dime-ovli): Reporting Node Behaviour when OC-OLR is not received

Maria Cruz,

The wording to indicate that absence of an overload report was to handle unusual situations.  Your proposed wording implies that it is acceptable for a reporting node to not include the OLR in every answer message.

I think it is better to specify the behavior of the reporting node to always include the OLR in every answer message for as long as there is an overload condition at the reporting node.

Regards,

Steve

>   is, if OC-OLR AVP is not included it is interpreted as “no change”.

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

---

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

Dear all

I think we are restarting a discussion we had a few months ago. 
The question is how frequently the OLR (with same seq number, so no change)is sent?
a) current text in the draft is that the reporting node (in overload condition)  must include an  OC-OLR AVP in all response messages
b) it can also be said it is only sent once when a change occurs in the OLR. It is in theory enough
c) in the middle , it can be sent in a few / many messages 

b) is not secure, as the answer conveying the new OLR can be lost. c) is OK for me if when there is a change in the OLR, the reporting node rapidly  send a significant amount of answers with the same seq number  so to consider with a high probability that the reacting node  has well received the new  OLR. (Note: With the current draft, apart this way, I do not well see how the reporting node knows that the reacting node has well received the new OLR)

I think that it was  considered simpler  to always send OLR in each answer than to have to take a decision at each answer to send it or not. We also had a similar debate about the OC-Supported-Features) to be always present or not.

So a) is OK for me as simple. I accept the idea of some tolerance, with Mcruz proposal that the absence of the OLR simply means no change. But this tolerance should not drive to a b) behavior. 

Best regards

JJacques
 
-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de Nirav Salot (nsalot)
Envoyé : lundi 8 septembre 2014 06:48
À : Steve Donovan; [email-masked]; [email-masked]; [email-masked]
Objet : Re: [Dime] [dime] #72 (draft-ietf-dime-ovli): Reporting Node Behaviour when OC-OLR is not received

Steve,

Regards,
Nirav.

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Steve Donovan
Sent: Friday, September 05, 2014 8:01 PM
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Dime] [dime] #72 (draft-ietf-dime-ovli): Reporting Node Behaviour when OC-OLR is not received

Maria Cruz,

Regards,

Steve

---

From: "Nirav Salot (nsalot)" <[email-masked]>
Date: Mon, 8 Sep 2014 15:31:38 +0000

Hi JJ,

I share your view and it is the responsibility of the reporting node to ensure that the OLR reaches the target node.
If the reporting node is not following "a" below then it has to have other means to know the target of the response and also have to keep track if the active OLR was already sent or not.
We don’t have to suggest the reporting node to do this but at the same time we need not forbid this type of implementation. 

So I am also fine to specify that if the OLR is not received by the reacting node then the previously received OLR stands valid.

Regards,
Nirav.

-----Original Message-----
From: TROTTIN, JEAN-JACQUES (JEAN-JACQUES) [mailto:[email-masked]] 
Sent: Monday, September 08, 2014 7:56 PM
To: Steve Donovan; [email-masked]; [email-masked]; [email-masked]; Nirav Salot (nsalot)
Subject: RE: [Dime] [dime] #72 (draft-ietf-dime-ovli): Reporting Node Behaviour when OC-OLR is not received

Dear all

Best regards

JJacques
 
-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de Nirav Salot (nsalot) Envoyé : lundi 8 septembre 2014 06:48 À : Steve Donovan; [email-masked]; [email-masked]; [email-masked] Objet : Re: [Dime] [dime] #72 (draft-ietf-dime-ovli): Reporting Node Behaviour when OC-OLR is not received

Steve,

Regards,
Nirav.

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Steve Donovan
Sent: Friday, September 05, 2014 8:01 PM
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Dime] [dime] #72 (draft-ietf-dime-ovli): Reporting Node Behaviour when OC-OLR is not received

Maria Cruz,

Regards,

Steve

---

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

All,

I agree with JJ that we have had this discussion and, I believe, we 
reached the conclusion that the OLR MUST be in all answer messages.

This seems a much more resilient and interoperable solution.  Anyone can 
implement a proprietary solution that doesn't address all of the MUST 
requirements, but that will not work with other implementations.  If we 
want to take away the MUST then we need to expand the solution to 
include a way for the reporting node to know for sure that the reacting 
node received the OLR.

Regards,

Steve

---

From: "Nirav Salot (nsalot)" <[email-masked]>
Date: Tue, 9 Sep 2014 15:16:12 +0000

Steve,

I don’t agree that "we need to provide the solution for the reporting node to know if the report reached the reacting node or not".
The point being, it is the responsibility of the reporting node to ensure that the report reaches the reacting node else the overload solution will not help. But this does not justify MUST requirement since this means any alternate solution is not allowed.

Many networks may have very simple topology of one PCRF connected to one PGW. Why should we enforce the PCRF/PGW to include "same" OLR in every answer message, in that case?

Regards,
Nirav.

-----Original Message-----
From: Steve Donovan [mailto:[email-masked]] 
Sent: Tuesday, September 09, 2014 8:40 PM
To: Nirav Salot (nsalot); TROTTIN, JEAN-JACQUES (JEAN-JACQUES); [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Dime] [dime] #72 (draft-ietf-dime-ovli): Reporting Node Behaviour when OC-OLR is not received

All,

I agree with JJ that we have had this discussion and, I believe, we reached the conclusion that the OLR MUST be in all answer messages.

This seems a much more resilient and interoperable solution.  Anyone can implement a proprietary solution that doesn't address all of the MUST requirements, but that will not work with other implementations.  If we want to take away the MUST then we need to expand the solution to include a way for the reporting node to know for sure that the reacting node received the OLR.

Regards,

Steve

On 9/8/14, 10:31 AM, Nirav Salot (nsalot) wrote:
> From: TROTTIN, JEAN-JACQUES (JEAN-JACQUES) 
> [mailto:[email-masked]]
> To: Steve Donovan; [email-masked]; [email-masked]; 
> [email-masked]; Nirav Salot (nsalot)
> a) current text in the draft is that the reporting node (in overload 
> condition)  must include an  OC-OLR AVP in all response messages
> b) is not secure, as the answer conveying the new OLR can be lost. c) 
> is OK for me if when there is a change in the OLR, the reporting node 
> rapidly  send a significant amount of answers with the same seq number  
> so to consider with a high probability that the reacting node  has 
> well received the new  OLR. (Note: With the current draft, apart this 
> way, I do not well see how the reporting node knows that the reacting 
> node has well received the new OLR)
>
> De : DiME [mailto:[email-masked]] De la part de Nirav Salot 
> (nsalot) Envoyé : lundi 8 septembre 2014 06:48 À : Steve Donovan; 
> [email-masked]; [email-masked]; 
> [email-masked] Objet : Re: [Dime] [dime] #72 
> (draft-ietf-dime-ovli): Reporting Node Behaviour when OC-OLR is not 
> received
>
> Steve,
>

---

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

Nirav,

My concern is with interoperability.  I'm also concerned with agent 
based cases where the reporting node doesn't know if it is the client 
for the transaction or an agent that is the reacting node. We also need 
to address the fact that both the client and an agent will be reacting 
nodes for host reports in agent based deployments.

I think we can achieve what you are looking for with the following. This 
is just the concept, not the formal wording.

-----

The reporting node MUST ensure that all reacting nodes for the 
transaction receive all new and updated overload reports.  This includes 
the client for the transaction and agents involved in the transaction 
that have a direct connection to the reporting node.

The recommended method to achieve this is to send OLRs in all answer 
messages sent while the reporting node has an active overload report.  
Out-of-band mechanisms can also be used by reporting nodes to determine 
that reacting nodes have received overload reports but these SHOULD NOT 
be used in cross vendor deployments.

-----

Regards,

Steve

---

From: "Nirav Salot (nsalot)" <[email-masked]>
Date: Tue, 9 Sep 2014 17:31:02 +0000

Steve,

The principle of your proposal is fine with me.

For the wording, I don’t think it is correct to say "SHOULD NOT be used in cross vendor deployments" since there is nothing vendor specific here.
Perhaps, "MAY BE used in specific cases, e.g. when the reporting node is aware about the network topology".

Regards,
Nirav.

-----Original Message-----
From: Steve Donovan [mailto:[email-masked]] 
Sent: Tuesday, September 09, 2014 10:44 PM
To: Nirav Salot (nsalot); TROTTIN, JEAN-JACQUES (JEAN-JACQUES); [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Dime] [dime] #72 (draft-ietf-dime-ovli): Reporting Node Behaviour when OC-OLR is not received

Nirav,

My concern is with interoperability.  I'm also concerned with agent based cases where the reporting node doesn't know if it is the client for the transaction or an agent that is the reacting node. We also need to address the fact that both the client and an agent will be reacting nodes for host reports in agent based deployments.

I think we can achieve what you are looking for with the following. This is just the concept, not the formal wording.

-----

The reporting node MUST ensure that all reacting nodes for the transaction receive all new and updated overload reports.  This includes the client for the transaction and agents involved in the transaction that have a direct connection to the reporting node.

The recommended method to achieve this is to send OLRs in all answer messages sent while the reporting node has an active overload report.  
Out-of-band mechanisms can also be used by reporting nodes to determine that reacting nodes have received overload reports but these SHOULD NOT be used in cross vendor deployments.

-----

Regards,

Steve

On 9/9/14, 10:16 AM, Nirav Salot (nsalot) wrote:
> To: Nirav Salot (nsalot); TROTTIN, JEAN-JACQUES (JEAN-JACQUES); 
> [email-masked]
>> rapidly  send a significant amount of answers with the same seq 
>> number so to consider with a high probability that the reacting node  
>> has well received the new  OLR. (Note: With the current draft, apart 
>> this way, I do not well see how the reporting node knows that the 
>> reacting node has well received the new OLR)
>>

---

From: Ben Campbell <[email-masked]>
Date: Tue, 9 Sep 2014 21:50:12 -0500

On Sep 9, 2014, at 12:14 PM, Steve Donovan <[email-masked]> wrote:

> The recommended method to achieve this is to send OLRs in all answer messages sent while the reporting node has an active overload report.  Out-of-band mechanisms can also be used by reporting nodes to determine that reacting nodes have received overload reports but these SHOULD NOT be used in cross vendor deployments.

This is degenerating into weasel wording.

Sending the OLR in every answer solves the issue for all cases. I can't imagine a case where it does harm. Can someone suggest one? Do people really think that  making an _overloaded_ reporting node jump through hoops with methods (whether proprietary or standardized) to determine which reacting nodes have received the reports would every be a reasonable implementation?

Sending in every answer is cheap and easy. We should just do it.

The text to make the reacting node handle getting an answer with no OLR was there to handle weird corner cases. For example, e.g. two physical hosts with same diameter identity. (Yes, those exist.)

---

From: "Nirav Salot (nsalot)" <[email-masked]>
Date: Wed, 10 Sep 2014 05:18:31 +0000

Ben,

> Sending in every answer is cheap and easy. We should just do it.
I woundnt agree on cheap since redundant information is sent in every answer message. I already mentioned the simple topology of one PGW connected to one PCRF directly where even DRA is not used.

> The text to make the reacting node handle getting an answer with no OLR was there to handle weird corner cases. For example, e.g. two physical hosts with same diameter identity. (Yes, those exist.)
Nothing is changing from the reacting node since "absent of OLR should still mean that the previously received OLR is active".
The idea is just to not "force" reporting node with a particular behavior.

Regards,
Nirav.

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]] 
Sent: Wednesday, September 10, 2014 8:20 AM
To: Steve Donovan
Cc: Nirav Salot (nsalot); TROTTIN, JEAN-JACQUES (JEAN-JACQUES); [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Dime] [dime] #72 (draft-ietf-dime-ovli): Reporting Node Behaviour when OC-OLR is not received

>> I don't agree that "we need to provide the solution for the reporting node to know if the report reached the reacting node or not".
>>> We don't have to suggest the reporting node to do this but at the same time we need not forbid this type of implementation.
>>> 
>>> Subject: RE: [Dime] [dime] #72 (draft-ietf-dime-ovli): Reporting 
>>> Node Behaviour when OC-OLR is not received
>>> 
>>> 
>>> Dear all
>>> 
>>> b) is not secure, as the answer conveying the new OLR can be lost. 
>>> c) is OK for me if when there is a change in the OLR, the reporting 
>>> node rapidly  send a significant amount of answers with the same seq 
>>> I don't think this is necessary. The reporting may include the OLR in every answer message but we don't have to put that as mandatory requirement, e.g. if the reporting node knows (and keeps track of) if the target reacting node has already received currently active OLR.
>>> 
>>> Regards,
>>> Nirav.
>>> 
>>> Subject: Re: [Dime] [dime] #72 (draft-ietf-dime-ovli): Reporting 
>>> Node Behaviour when OC-OLR is not received
>>> 
>>> Maria Cruz,
>>> 
>>>>    is, if OC-OLR AVP is not included it is interpreted as "no change".
>>>>

---

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

> I woundnt agree on cheap since redundant information is sent in every answer message. I already mentioned the simple topology of one PGW connected to one PCRF directly where even DRA is not used.

I guess cheap is relative. A few extra bytes on the wire is going to be cheap compared to almost any workable feedback-based mechanism of determining that all the reacting nodes actually got the OLR.

> The idea is just to not "force" reporting node with a particular behavior.

Every time we offer this sort of choice, we add complexity to the protocol. (This is why you see a lot of IETF-wide pushback on SHOULDs without guidance on when it might make sense to do something different.).  Some times that complexity is worth it. In this case, I am convinced it is not. I am especially convinced of this when we find the need to normatively distinguish between same-vendor and cross-vendor communication.

Does anyone have a concrete example of a different alternative that they might really use?

---

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Thu, 11 Sep 2014 07:14:13 +0000

Dear all 

I have another questioning. If a reporting node put an OLR in all answers, does it mean that the reacting node (eg a client) will have an OLR in all answers it receives for given Origin-Realm, Origin-Host AVPS?. In  another email thread  (#70 Appendix B), for a realm request routed to an overloaded server which will put a host type OLR in its answer, Ulrich then considers that the DA receiving this Host OLR will not send it to the client, as the client will receive this host type OLR in answers to host routed request. 
 
There is also the case of realm OLRs: when realm is overloaded,  the DA will put  realm OLRs in answers  to  realm  routed requests, but is this realm OLR will be also be put in answers to host routed requests  transferred via this DA? The DA may do, (the realm OLR is also valid from the piggybacking view) or it may not.    

For a reacting node (client),  I do not think it matters in which answers (for given Origin realm- Origin  host AVPS) it receives corresponding Realm OLRs and Host OLRs, and if they are not present in some answers, as long as it receives  enough answers containing the OLRs, so to not miss a new OLR whatever their types.
 
So may be to have an additional sentence in 5.4 Reacting node behavior. 

Wording proposed 
- an OCS in the reacting node is not modified when received answers do not contain an OLR related to this OCS

To note that this proposal is valid whatever the outputs of this #72 discussion regarding if the reporting node must put an OLR in all answers, which concerns reporting node behavior (5.3).

Best regards 

JJacques

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de Ben Campbell
Envoyé : mercredi 10 septembre 2014 22:45
À : Nirav Salot (nsalot)
Cc : [email-masked]; [email-masked]
Objet : Re: [Dime] [dime] #72 (draft-ietf-dime-ovli): Reporting Node Behaviour when OC-OLR is not received

> 
>> The text to make the reacting node handle getting an answer with no 
>> OLR was there to handle weird corner cases. For example, e.g. two 
>> physical hosts with same diameter identity. (Yes, those exist.)

> Cc: Nirav Salot (nsalot); TROTTIN, JEAN-JACQUES (JEAN-JACQUES); 
> The text to make the reacting node handle getting an answer with no 
> OLR was there to handle weird corner cases. For example, e.g. two 
> physical hosts with same diameter identity. (Yes, those exist.)
> 
>> 
>> -----
>> 
>> Regards,
>> 
>> Steve
>> 
>> 
>> 
>>>> node rapidly  send a significant amount of answers with the same 
>>>> seq number so to consider with a high probability that the reacting 
>>>> node has well received the new  OLR. (Note: With the current draft, 
>>>> apart this way, I do not well see how the reporting node knows that 
>>>> the reacting node has well received the new OLR)
>>>>

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 12 Sep 2014 07:39:30 +0000

Ben,

here is an example use case which I believe is concrete and might really be used:

suppose the overload control mechanism is implemented by a server in a way that the server never sends OLRs with validity duration of more than e.g. one hour. (I think it is quite reasonable to implement a limit).

While an overload condition is active an OLR (e.g. reduction 10% and duration 30min) is included in every answer.
If the overload condition lasts longer than 20 min, a refresh is generated and sent in every answer (OLR with new sequence number, and e.g. still 10% and 30min).
If the overload condition ceases the server sends an OLR indicating "end of overload" in every answer.
If after one hour the server is still no longer overloaded, the server can safely assume that all clients are aware of the end of overload and may therefore cease sending OLRs until a new overload condition occurs.

Ulrich

---

From: Ben Campbell <[email-masked]>
Date: Mon, 15 Sep 2014 15:45:35 -0500

> If after one hour the server is still no longer overloaded, the server can safely assume that all clients are aware of the end of overload and may therefore cease sending OLRs until a new overload…

Hmm. Your example seems to be one of sending an OLR in every answer for the duration of the overload request. That's how I have even arguing it should work. I never meant to say that the server had to send an OLR in every request when it was not actually overloaded.

You do bring up an interesting point is, how long should the server keep sending an OLR that ends the overload condition? In your example, that appears to be a case of local policy. I'm okay with that, but we should probably at least mention it. (Possibly with the guidance that once a reporting node knows that all previous OLRs have expired, there's no longer any reason to send termination OLRs.)

---

From: Ben Campbell <[email-masked]>
Date: Mon, 15 Sep 2014 20:35:55 -0500

On Sep 15, 2014, at 3:45 PM, Ben Campbell <[email-masked]> wrote:

> Hmm. Your example seems to be one of sending an OLR in every answer for the duration of the overload request. That's how I have even arguing it should work.

s/"even arguing"/"been arguing"

(iPad autocorrect :-)  )

> I never meant to say that the server had to send an OLR in every request when it was not actually overloaded.
>