Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling

[<[e-mail]>]

Hi all,

I don't think that a reporting node may/can/would like to ensure/choose/guarantee anything :)
I'm ok with the intention of the text but we may probably word it in a different way.

Moreover, the first sentence is somehow incorrect. Not all the reacting nodes need to be aware of the new status. Only those which have received a previous OLR are targeted. I think that the requirement is that reporting and reacting nodes share the most up-to-date info and therefore it is recommended to send the OLR in every answer.

I have a comment anyway on the following note:

Note - the reporting node may also include the overload report in answer messages sent to non reacting nodes if that is more efficient.  The overload report will just be ignored by a Diameter node that does not support DOIC.

This is contradicting the statement given in 5.3.2:

   The answer message initiating endpoint MUST NOT include any overload
   control solution defined AVPs into its answer messages if the request
   message initiating endpoint has not indicated support at the
   beginning of the created session (or transaction in a case of non-
   session state maintaining applications).  The same also applies if
   none of the announced capabilities match between the two endpoints.

Regards,

Lionel

***********************

De : DiME [mailto:[e-mail]] De la part de Nirav Salot (nsalot)
Envoyé : vendredi 14 février 2014 10:06
À : Maria Cruz Bartolome; [e-mail]
Objet : Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling

Maria-Cruz,

I am fine with the proposal below.

Regards,
Nirav.

From: Maria Cruz Bartolome [mailto:[e-mail]] 
Sent: Thursday, February 13, 2014 8:38 PM
To: Nirav Salot (nsalot); [e-mail]
Subject: RE: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling

Nirav,

Let me know if following rephrasing still conveys the meaning you want to cover:

Note – In some cases (e.g. when there are one or multiple agents in the path between reporting and reacting nodes, or when overload reports are discarded by reacting nodes) the reporting node may not be able to guarantee that the reacting node has received the report.


From: Nirav Salot (nsalot) [mailto:[e-mail]] 
Sent: jueves, 13 de febrero de 2014 15:56
To: Maria Cruz Bartolome; [e-mail]
Subject: RE: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling

Maria-Cruz,

May be following formatting of the note helps?
A reporting node MAY choose to not send an overload report to a reacting node if it can guarantee that this overload report is already active in the reacting node.

Note – In some cases (e.g. when there are one or multiple agents in the path between reporting and reacting nodes, overload reports may be discarded by reacting nodes) the reporting node may not be able to guarantee that the reacting node has received the report.

Regards,
Nirav.

From: DiME [mailto:[e-mail]] On Behalf Of Maria Cruz Bartolome
Sent: Thursday, February 13, 2014 6:50 PM
To: [e-mail]
Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling

Nirav,

Do you consider that overload reports can only be discarded by reacting nodes when there are agents in the path?


From: Nirav Salot (nsalot) [mailto:[e-mail]] 
Sent: jueves, 13 de febrero de 2014 13:58
To: Maria Cruz Bartolome; [e-mail]
Subject: RE: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling

Maria-Cruz,

Reporting note may use very simple mechanism – as pointed out by Lionel – to conclude that report has reached the reacting node, i.e. all the intra-session messages need not contain the same overload report, if the session establishment message contains the overload report.

So your note regarding the reporting node to take into account the network deployment etc. is not 100% correct.
Let me simplify, hoping it will satisfy your concern.

A reporting node MAY choose to not send an overload report to a reacting node if it can guarantee that this overload report is already active in the reacting node.

Note – In some cases, e.g. when there are one or multiple agents in the path between reporting and reacting nodes; overload reports may be discarded by reacting nodes, the reporting node may not be able to guarantee that the reacting node has received the report.

Regards,
Nirav.

From: DiME [mailto:[e-mail]] On Behalf Of Maria Cruz Bartolome
Sent: Thursday, February 13, 2014 2:31 PM
To: [e-mail]
Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling

Dear all,

I think then we agree on the proposed text:

A reporting node MUST ensure that all reacting nodes receive new overload reports.

It is recommended that a reporting node include overload reports in all answer messages sent to reacting nodes.  

Note - the reporting node may also include the overload report in answer messages sent to non reacting nodes if that is more efficient.  The overload report will just be ignored by a Diameter node that does not support DOIC.

A reporting node MAY choose to not send an overload report to a reacting node if it can guarantee that the reacting node already has received the overload report.

But still there are some discrepancies about the note.
My proposal is to keep it just as an indication of potential (maybe not all) situations that should be taken into account if ever any implementation may consider to do not follow the recommendation that a reporting node include overload reports in all answer messages. 
Being a recommendation and not a must, at least I think we need to indicate what may imply to do not follow the recommendation. 
Then my proposal is the following, that includes a modification to last sentence above:

A reporting node MAY choose to not send an overload report to a reacting node if it can guarantee that this overload report is already active in the reacting node.

Note –the reporting node may need to take into account network deployment and potential errors in order to be able to guarantee that sent overload report is active in the reacting node, e.g. there may be one or multiple agents in the path between reporting and reacting nodes; overload reports may be discarded by reacting nodes…



_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.