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

["Nirav Salot (nsalot)" <[e-mail]>]

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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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…