Subject: Re: [Dime] WGLC #1 for draft-ietf-dime-agent-overload-05

From: "A. Jean Mahoney" <[email-masked]>
Date: Wed, 1 Jun 2016 18:11:18 -0500

Hi Steve,

I think the draft is in pretty good shape, but I have a few comments 
(mostly nits) and I did get confused in Section 5.1.2 --

Minor issues:

Section 5.1.1

   "When relaying a request that includes a SourceID AVP in the OC-
    Supported-Features AVP, a DOIC node that supuports the OC_PEER_REPORT
    feature must remove the received SourceID AVP and replace it with a
    SourceID AVP containing its own Diameter identity."

Shouldn't "must" be "MUST"?

Section 5.1.2

   "When relaying an answer message, a reporting node that supports the
    OC_PEER_REPORT feature MUST strip any SourceID AVP from the OC-
    Supported-Features AVP."

And replace it with a SourceID AVP containing its own Diameter identity? 
Or does an answer with an OC-Supported-Features AVP that does not have a 
SourceID AVP mean the peer is an agent? Section 5 doesn't cover how to 
interpret an OC-Supported-Features AVP without a SourceID, only when a 
SourceID doesn't match the peer.

Section 5.1.2

   "If the peer supports the OC_PEER_REPORT feature then the reporting
    node MUST indicate support for the feature in the Supported-Features
    AVP."

Should be "OC-Supported-Features".

Section 6.1

Should the AVP Code for OC-Supported-Features be 621 instead of TBD1? (I 
wasn't sure if, when extending an AVP of type Grouped, you needed to 
give the AVP a new AVP Code, and I couldn't find guidance in RFC 6733 or 
RFC 7423) Also, AVP Code TBD1 is used for OC-Peer-Algo AVP in Section 
6.1.2 and for SourceID in Section 6.4. TBD2 is used for OC-OLR in 6.2 
(should it be 623?), SourceID in 6.3, and OC-Peer-Algo in 6.4.

Section 6.2

   "The overload report must also include the Diameter identity of the
    agent that generated the report."

Shouldn't "must" be "MUST"?

Nits:

Section 3 - s/"suited controlling traffic"/"suited to controlling traffic"

Section 5.2.4 - s/"reporting nodes transaction state"/"reporting node's 
transaction state"

Section 6.1 - s/"handling by the agents peer."/"handling by the agent's 
peer."

Section 6.1.2 - s/"reused in for this AVP."/"reused for this AVP."

Section 6.2 - s/non supporting/non-supporting

Thanks!

Jean

On 5/23/16 2:12 PM, Jouni Korhonen wrote:
> Folks,
>
> This email starts the WGLC #1 for draft-ietf-dime-agent-overload-05.
> Please, review the document, post your comments to the mailing list and
> also insert them into the Issue Tracker with your proposed resolution.
>
> WGLC starts: 5/23/2016
>        ends: 6/6/2016 EOB PDT
>
> - Jouni & Lionel
>
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Fri, 3 Jun 2016 11:17:06 +0000

Hello,
Not sure this email was distributed since I did not receive the corresponding copy and I have not received any comments.
Just resending, sorry if you receive it twice.
Cheers
/MCruz

-----Original Message-----
From: Maria Cruz Bartolome 
Sent: viernes, 27 de mayo de 2016 14:30
To: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Dime] WGLC #1 for draft-ietf-dime-agent-overload-05

Hello all,

I would like to provide some questions, proposed changes and typos, see in different sections to ease reading.
Best regards
/MCruz

===========  SOME QUESTIONS ===========:

1. Clause 2
Why for the definition of Diameter Node and Endpoint there is an specific mention of the RFC6733?

2. Clause 5.2.3
  "In all cases, if the reacting node is a relay then it MUST strip the
   OC-OLR AVP from the message."

   But, will the relay react against the overload report received? i.e. is it a "reacting node" or it is just relaying the message?

=========== PROPOSED CHANGES ===========:

1. Clause 2:
   Reacting Node
      A DOIC Node that receives and acts on a Diameter overload report.

  Proposed:
      A DOIC Node that receives and acts on a DOIC overload report.
  
2. Clause 3:

Now:
   This section outlines representative use cases for the peer report
   used to communicate agent overload.
   There are two primary classes of use cases currently identified,
   those involving the overload of agents and those involving overload
   of Diameter endpoints (Diameter Clients and Diameter Servers) that
   wish to use an overload algorithm suited controlling traffic sent
   from a peer.

Proposed:
   This section outlines representative use cases for the peer report
   used.
   There are two primary classes of use cases currently identified,
   those involving the overload of agents and those involving overload
   of Diameter endpoints that
   wish to use an overload algorithm that requires controlling traffic sent
   towards peers.

Reasoning:
  For the second use case considered the peer report does not communicate agent overload, but Diameter server overload.
  Diameter Endpoint is already defined.
 Last sentence as it is, it is a bit difficult to understand.

3. Clause 3.1.1

Now:
This will result in the throtting of the abated traffic
   that would have been sent to the agent, as there is no alternative
   route, with the appropriate indication given to the service request
   that resulted in the need for the Diameter transaction.

Proposed:
  This will result in the queuing (temporally at least) and/or the throttling of the abated traffic
   that would have been sent to the agent, as there is no alternative
   route.

Reasoning:
   Traffic could be queued, at least temporally, before being throttled.
   I do not think it is required to inform about what is sent back to the originator of the initial request. 

4. Clause 3.1.2

Now:
The second case, in Figure 4, illustrates the case where the
   connections to the agents are both actively used.  In this case, the
   client will have local distribution policy to determine the
   percentage of the traffic sent through each client.

Proposed:
The second case, in Figure 4, illustrates the case where the
   connections to the agents are both actively used.  In this case, the
   client will have local distribution policy to determine the
   traffic sent through each client.

Reasoning:
Avoid using "percentage of traffic" since it seems to imply that the "selection" of each agent is based in an algorithm that bases the distribution in traffic percentages, what is just a particular case.

5. Clause 3.1.2

"In the case where one of the agents in the above scenarios become
   overloaded, the client should reduce the amount of traffic sent to
   the overloaded agent by the amount requested. "

This paragraph only applies to Figure 4, it does not apply to the Active/Standby case. 

6. Clause 3.1.2

   In the case where both agents are reporting overload, the client may
   need to start decreasing the total traffic sent to the agents.  This
   would be done in a similar fashion as discussed in section *3.1.*

   *3.1* should be *3.1.1*

7. Clause 3.1.3

"Another example of this type of
   deployment is when there are multiple sets of servers, each
   supporting a subset of the Diameter traffic."

  This example does not include an "agent chain", since for each Client-Server connection there is only one single Agent in the chain, right?

8. Clause 4

"Any messages that survive throttling due
   to host or realm reports should then go through abatement for the
   peer overload report."

  There is an interaction between PEER and HOST reports. The reduction of traffic towards a HOST reduces as well the traffic through the agents in the path. This should be taken into account when applying reduction for that particular PEER. However, depending on the routing schema it may not be straight forward to identify what is the reduction for each agent path when reducing traffic towards a HOST.

9. Clause 5.1.2
 Now:  
 The following are indications that the peer does not support the
   OC_PEER_REPORT feature:

      The request does not contain an OC-Supported-Features AVP.

      The received request contains an OC-Supported-Features AVP with no
      OC-Feature-Vector.

      The received request contains an OC-Supported-Features AVP with a
      OC-Feature-Vector with the OC_PEER_REPORT feature bit cleared.

      The received request contains an OC-Supported-Features AVP with a
      OC-Feature-Vector with the OC_PEER_REPORT feature bit set but with
      a SourceID AVP with a DiameterIdentity that does not match the
      DiameterIdentity of the peer from which the request was received.

Proposal
	(remove)

Reasoning
   This explanation is not required, this is covered by the following paragraph:
   "The peer supports the OC_PEER_REPORT feature if the received request
   contains an OC-Supported-Features AVP with the OC-Feature-Vector with
   the OC_PEER_REPORT feature bit set and with a SourceID AVP with a
   Diameter ID that matches the DiameterIdentity of the peer from which
   the request was received."

10. Clause 5.2

  Now
	5.2.  Peer Report Overload Report Handling

Proposed:
	5.2.  Peer Overload Report Handling

11. Clause 5.2.1.1
Now:
   If different abatement specific contents are sent to each peer then
   the reporting node MUST maintain a separate *peer* node peer report OCS
   entry per peer to which a peer overload report is sent.

Proposed:
   If different abatement specific contents are sent to each peer then
   the reporting node MUST maintain a separate *reporting* node peer report OCS
   entry per peer to which a peer overload report is sent.

12. Clause 5.2.1.2
Is any reason why "Validity Duration" is not included as possible information?

13. Clause 5.2.2
Now:   
A reporting node SHOULD create a new Reporting Node Peer Report OCS
   entry Section 5.2.1.1 in an overload condition *and* sending a peer
   overload report to a peer for the first time.

Proposed: 
   A reporting node SHOULD create a new Reporting Node Peer Report OCS
   entry Section 5.2.1.1 in an overload condition *when* sending a peer
   overload report to a peer for the first time.

=========== TYPOS========:
1. Clause 2:
Reporting Node
      A DOIC Node that sends *and* overload report in a Diameter answer
      message.
    
    *and* should be *an*   

2. Clause 2:
*DIOC* Node
*DIOC* should be *DOIC*

3. Clause 3.1.1
This will result in the *throtting* of the abated traffic

4. Clause 3.1.3
   The handling of peer overload reports is similar to that discussed in
   section *2.2*.  
  *2.2* is incorrect, not sure though which is the right section.

5. Clause 5.1.1
      Note: The sender of a request can be a Diameter Client or Diameter
      Server that originates the *Diamter* request or a Diameter Agent
      that relays the request.

6. Clause 5.1.1
    Supported-Features AVP, a DOIC node that *supuports* the OC_PEER_REPORT

7. Clause 5.2.5
If the request matches *and* active OCS then

8. Clause 5.2.5
meaning that *it* the reporting node

9. Clause 6.3
In the case of peer reports, the SourceID AVP indicates the node that
   support *for* this feature

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Jouni Korhonen
Sent: lunes, 23 de mayo de 2016 21:13
To: [email-masked]; Jouni; [email-masked]
Subject: [Dime] WGLC #1 for draft-ietf-dime-agent-overload-05

Folks,

This email starts the WGLC #1 for draft-ietf-dime-agent-overload-05. 
Please, review the document, post your comments to the mailing list and also insert them into the Issue Tracker with your proposed resolution.

WGLC starts: 5/23/2016
        ends: 6/6/2016 EOB PDT

- Jouni & Lionel

---

From: Steve Donovan <[email-masked]>
Date: Fri, 03 Jun 2016 09:03:03 -0400

Maria Cruz,

Thanks for the review.

I did get the original. I hope to be able to respond today.

Regards,

Steve

On June 3, 2016 7:17:11 AM Maria Cruz Bartolome 
<[email-masked]> wrote:

> Hello,
> Not sure this email was distributed since I did not receive the 
> corresponding copy and I have not received any comments.
>    But, will the relay react against the overload report received? i.e. is it 
>    a "reacting node" or it is just relaying the message?
>
>
>
>   For the second use case considered the peer report does not communicate 
>   agent overload, but Diameter server overload.
> Avoid using "percentage of traffic" since it seems to imply that the 
> "selection" of each agent is based in an algorithm that bases the 
> distribution in traffic percentages, what is just a particular case.
>
>
> 5. Clause 3.1.2
>
>   This example does not include an "agent chain", since for each 
>   Client-Server connection there is only one single Agent in the chain, right?
>
>
> 8. Clause 4
>
>   There is an interaction between PEER and HOST reports. The reduction of 
>   traffic towards a HOST reduces as well the traffic through the agents in 
>   the path. This should be taken into account when applying reduction for 
>   that particular PEER. However, depending on the routing schema it may not 
>   be straight forward to identify what is the reduction for each agent path 
>   when reducing traffic towards a HOST.
>
>
> 9. Clause 5.1.2
>  Now:

---

From: Steve Donovan <[email-masked]>
Date: Fri, 3 Jun 2016 10:59:48 -0500

Maria Cruz,

Thanks again for the thorough review.

Please see my responses inline.

Regards,

Steve

> Why for the definition of Diameter Node and Endpoint there is an specific mention of the RFC6733?
SRD> Because the concepts of Diameter Server, Diameter Client and 
Diameter Agent are defined in RFC6733.
>     But, will the relay react against the overload report received? i.e. is it a "reacting node" or it is just relaying the message?
SRD> That is determined by the other statements in that section. If the 
SourceID received in the message matches that of a peer then the relay 
is a reacting node.  If it doesn't match then it is not a reacting 
node.  Either way, the OC-OLR AVP is stripped.
>        A DOIC Node that receives and acts on a DOIC overload report.
SRD> Okay.
>   Last sentence as it is, it is a bit difficult to understand.
SRD> I agree to removing the parenthetical.

SRD> I propose changing the paragraph to the following:

    There are two primary classes of use cases currently identified,
    those involving the overload of agents and those involving overload
    of Diameter endpoints.  In both cases the goal is to use an overload
    algorithm that controls traffic sent towards peers.

>     I do not think it is required to inform about what is sent back to the originator of the initial request.
SRD> This talks about the abated traffic.  As such, any queuing that 
might have been used as already been done.

SRD> I also think that we should be explicit that a response is sent 
back to the originator of the request.  It would do more harm if 
throttling were interpreted as just dropping the message on the floor.
> Avoid using "percentage of traffic" since it seems to imply that the "selection" of each agent is based in an algorithm that bases the distribution in traffic percentages, what is just a particular…
SRD> Agreed.
> This paragraph only applies to Figure 4, it does not apply to the Active/Standby case.
SRD> Agreed.  I've changed "scenarios" to "scenario".
>     would be done in a similar fashion as discussed in section *3.1.*
SRD> Agreed
>    This example does not include an "agent chain", since for each Client-Server connection there is only one single Agent in the chain, right?
SRD> I don't understand why there would be a single agent in the chain.  
It is valid (and done) to have multiple agents between clients and 
servers in this scenario.
>    There is an interaction between PEER and HOST reports. The reduction of traffic towards a HOST reduces as well the traffic through the agents in the path. This should be taken into account when…
SRD> The goal of this statement is to say that when a Diameter node is 
applying overload abatement algorithms, the order in which active 
overload reports are applied is host/realm report first and then peer 
report.  In other words, abatement is done for traffic being sent to a 
host and then independent abatement is done for the peer to which the 
request is to be routed.  If these are treated as independent actions 
then I don't understand the issue you are raising.
>     the request was received."
SRD> Agreed.
> 	5.2.  Peer Overload Report Handling
SRD> Agreed
>     entry per peer to which a peer overload report is sent.
SRD> Agreed.
> Is any reason why "Validity Duration" is not included as possible information?
SRD> I've added it.  I'm not sure why it wasn't there.
>     overload report to a peer for the first time.
SRD> Agreed.
>    *2.2* is incorrect, not sure though which is the right section.
SRD> Changed to 3.1.2.
>     support *for* this feature
SRD> I've addressed all of the editorial issues listed.

---

From: Steve Donovan <[email-masked]>
Date: Sun, 5 Jun 2016 20:58:34 -0500

Jean,

Thanks for the review.

Please find my comments inline.

Regards,

Steve

> Shouldn't "must" be "MUST"?
SRD> Yes.  I've made the change.
> And replace it with a SourceID AVP containing its own Diameter 
> identity? Or does an answer with an OC-Supported-Features AVP that 
> does not have a SourceID AVP mean the peer is an agent? Section 5 
> doesn't cover how to interpret an OC-Supported-Features AVP without a 
> SourceID, only when a SourceID doesn't match the peer.
SRD> The next two paragraphs address when the SourceID is included.  
Maybe I need to change the next paragraph to the following:

From:

    When sending an answer message, a reporting node that supports the
    OC_PEER_REPORT feature MUST determine if the peer to which the answer
    is to be sent supports the OC_PEER_REPORT feature.

To:

    When sending *or relaying* an answer message, a reporting node that 
supports the
    OC_PEER_REPORT feature MUST determine if the peer to which the answer
    is to be sent supports the OC_PEER_REPORT feature.
SRD> Agreed.
>
>
> Section 6.1
>
> Should the AVP Code for OC-Supported-Features be 621 instead of TBD1? 
> (I wasn't sure if, when extending an AVP of type Grouped, you needed 
> to give the AVP a new AVP Code, and I couldn't find guidance in RFC 
> 6733 or RFC 7423) Also, AVP Code TBD1 is used for OC-Peer-Algo AVP in 
> Section 6.1.2 and for SourceID in Section 6.4. TBD2 is used for OC-OLR 
> in 6.2 (should it be 623?), SourceID in 6.3, and OC-Peer-Algo in 6.4.
SRD> Yes, good catch.  This was a cut and paste from before the DOIC AVP 
codes were assigned.  I've cleaned it up to have TBD1 apply to 
OC-Peer-Algo and TBD2 apply to SourceID.
> Shouldn't "must" be "MUST"?
SRD> Yes.
> Section 3 - s/"suited controlling traffic"/"suited to controlling 
SRD> This was fixed when rewording this section based on Maria Cruz's 
comments.
>
> Section 5.2.4 - s/"reporting nodes transaction state"/"reporting 
> node's transaction state"
>
> Section 6.1 - s/"handling by the agents peer."/"handling by the 
> agent's peer."
>
SRD> Changes made for the above.

---

From: "A. Jean Mahoney" <[email-masked]>
Date: Mon, 6 Jun 2016 14:10:12 -0500

Hi Steve,

Thanks for taking care of my comments. I've trimmed the closed issues 
below. I'm still confused on section 5.1.2. though. Comments below -

On 6/5/16 8:58 PM, Steve Donovan wrote:
>> "When relaying an answer message, a reporting node that supports
>> the OC_PEER_REPORT feature MUST strip any SourceID AVP from the
>> OC- Supported-Features AVP."
>>
>> doesn't cover how to interpret an OC-Supported-Features AVP without
>> a SourceID, only when a SourceID doesn't match the peer.
> OC_PEER_REPORT feature MUST determine if the peer to which the
> answer is to be sent supports the OC_PEER_REPORT feature.
>
> To:
>
> supports the OC_PEER_REPORT feature MUST determine if the peer to
> which the answer is to be sent supports the OC_PEER_REPORT feature.

Are agents and servers equivalent then? Should the definition of 
reporting node be updated?

From:

       A DOIC Node that sends an overload report in a Diameter answer
       message.

To:

       A DOIC Node that sends *or relays* an overload report in a
       Diameter answer message.

Thanks,

Jean

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Tue, 7 Jun 2016 06:54:37 +0000

Hello Steve,
Thanks for your reply.
See some comments below, just keeping relevant parts of my first email, those that still need clarification.
Best regards
/MCruz

SRD> That is determined by the other statements in that section. If the
SourceID received in the message matches that of a peer then the relay is a reacting node.  If it doesn't match then it is not a reacting node.  Either way, the OC-OLR AVP is stripped.

MCRUZ> But a relay can't be a "reacting node", can it? A relay does not read or understand any AVP apart from routing related AVPs.

MCRUZ> Ok

MCRUZ> Ok, but I suggest we rephrase a bit the sentence, is a bit blurry.  Like e.g.:
  This will result in the throttling of the abated traffic
   that would have been sent to the agent, as there is no alternative
   route. An appropriate error response is sent back to the originator of the request.

MCRUZ> The possibility to have multiple agents in a chain is covered by the previous sentence in same paragraph. This sentence here seems to point out that 
There may be different set of servers, and my understanding is that there may be a chain of agents for each set. 
Therefore, I think this sentence here can be removed, or clarified.

MCRUZ> If you think the PEER algorithm is RATE, then there is not interaction, as long as when PEER abatement is performed after HOST/REALM, it simply keeps a RATE. However, if the PEER algorithm is LOSS, when performed after HOST/REALM it should be stated that it is the initial traffic (before any HOST/REALM abatement) the one that should be taken into account. Then, I think a clarification is required.

---

From: Steve Donovan <[email-masked]>
Date: Wed, 8 Jun 2016 13:23:45 -0500

>       A DOIC Node that sends *or relays* an overload report in a
SRD> Actually, I would rather change the requirement to refer to a DOIC 
node instead of a reporting node as follows:

    When sending *or relaying* an answer message, a DOIC node that
    supports the OC_PEER_REPORT feature MUST determine if the peer to
    which the answer is to be sent supports the OC_PEER_REPORT feature.

---

From: Steve Donovan <[email-masked]>
Date: Wed, 8 Jun 2016 14:06:06 -0500

> MCRUZ> But a relay can't be a "reacting node", can it? A relay does not read or understand any AVP apart from routing related AVPs.
SRD> Yes a relay is the reacting node for any next hop that generates a 
peer overload report.  As with base DOIC, a relay must be able to handle 
DOIC AVPs, in addition to the routing AVPs.
>     route. An appropriate error response is sent back to the originator of the request.
SRD> I'm okay with this change.
> Therefore, I think this sentence here can be removed, or clarified.
SRD> I agree, it can be removed.
> MCRUZ> If you think the PEER algorithm is RATE, then there is not interaction, as long as when PEER abatement is performed after HOST/REALM, it simply keeps a RATE. However, if the PEER algorithm i…
SRD> While it is true that, as stated, the presence of a HOST LOSS 
report and a peer LOSS report could result in extra messages being 
abated, I would prefer to keep the definition of the interaction as 
simple as possible and not change the requirement. My reasoning is that 
there is value in keeping it simple, especially given that it a self 
correcting scenario.  The next hop will see more of a reduction than it 
was expecting and will subsequently update the requested reduction.  If 
there isn't consensus on this approach we can do a special case on this 
scenario.

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Thu, 9 Jun 2016 06:16:42 +0000

Hello Steve,
See some responses below
Thanks
/MCruz

> SRD> That is determined by the other statements in that section. If 
> SRD> the
SRD> Yes a relay is the reacting node for any next hop that generates a
peer overload report.  As with base DOIC, a relay must be able to handle DOIC AVPs, in addition to the routing AVPs.
MCRUZ> In DOIC this is not explicitly mentioned, and I do not see the need. Moreover, this changes the definition of what a relay is. 

SRD> While it is true that, as stated, the presence of a HOST LOSS
report and a peer LOSS report could result in extra messages being abated, I would prefer to keep the definition of the interaction as simple as possible and not change the requirement. My reasoning is that there is value in keeping it simple, especially given that it a self correcting scenario.  The next hop will see more of a reduction than it was expecting and will subsequently update the requested reduction.  If there isn't consensus on this approach we can do a special case on this scenario.

MCRUZ> I think we need to cover these cases, since having extra throttling even if it is compensated later will cause first unnecessary drop messages and second traffic oscillations. Both things should be avoided.

---

From: Steve Donovan <[email-masked]>
Date: Thu, 9 Jun 2016 19:46:26 -0500

Maria Cruz,

See my responses inline.

Regards,

Steve

> MCRUZ> In DOIC this is not explicitly mentioned, and I do not see the need. Moreover, this changes the definition of what a relay is.
SRD2> You are correct, it should say agent, not relay.  In my mind an 
agent that is a relay can also be a reacting node by expanding the 
definition of routing related AVPs to include DOIC AVPs.  I consider 
this valid as these AVPs, and the LOAD AVPs all impact routing 
decisions.  This, however, is somewhat academic as the practical impact 
of calling an agent that is a reacting node a relay or a proxy isn't 
meaningful.

SRD> I'll change the word in the above clause to agent.
> MCRUZ> I think we need to cover these cases, since having extra throttling even if it is compensated later will cause first unnecessary drop messages and second traffic oscillations. Both things sh…
SRD> How about if we add the following:

      Any messages that survive throttling due to host or realm reports 
should then go through abatement for the
      peer overload report.  In this scenario, when doing abatement on 
the PEER report, the reacting node SHOULD
      take into consideration the number of messages already throttled 
by the handling of the HOST/REALM report abatement.

          Note: The goal is to avoid traffic oscillations that might 
result from throttling of messages for both
          the HOST/REALM overload reports and the PEER overload 
reports.  This is especially a concern if both
          reports are of type LOSS.

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Fri, 10 Jun 2016 08:02:23 +0000

> SRD> Yes a relay is the reacting node for any next hop that generates 
> SRD> a
SRD2> You are correct, it should say agent, not relay.  In my mind an
agent that is a relay can also be a reacting node by expanding the definition of routing related AVPs to include DOIC AVPs.  I consider this valid as these AVPs, and the LOAD AVPs all impact routing decisions.  This, however, is somewhat academic as the practical impact of calling an agent that is a reacting node a relay or a proxy isn't meaningful.

SRD> I'll change the word in the above clause to agent.
MCRUZ> Thanks Steve. I think this change applies to other places in the draft.

>> SRD> The goal of this statement is to say that when a Diameter node 
>> SRD> is
>> report.  In other words, abatement is done for traffic being sent to 
>> a host and then independent abatement is done for the peer to which 
>> the request is to be routed.  If these are treated as independent 
>> actions then I don't understand the issue you are raising.
>>

      Any messages that survive throttling due to host or realm reports should then go through abatement for the
      peer overload report.  In this scenario, when doing abatement on the PEER report, the reacting node SHOULD
      take into consideration the number of messages already throttled by the handling of the HOST/REALM report abatement.

          Note: The goal is to avoid traffic oscillations that might result from throttling of messages for both
          the HOST/REALM overload reports and the PEER overload reports.  This is especially a concern if both
          reports are of type LOSS.

MCRUZ> I think this is fine. Thanks

---

From: <[email-masked]>
Date: Mon, 13 Jun 2016 13:06:16 +0000

Thank you for the useful discussion.
I'm OK with the output and the proposed changes.

regards,

Lionel

> -----Message d'origine-----
> De : DiME [mailto:[email-masked]] De la part de Maria Cruz Bartolome
> Envoyé : vendredi 10 juin 2016 10:02
> À : Steve Donovan; [email-masked]
> Objet : Re: [Dime] WGLC #1 for draft-ietf-dime-agent-overload-05
> 
> >>> 2. Clause 5.2.3
> >>>       But, will the relay react against the overload report received? i.e. is it a
> "reacting node" or it is just relaying the message?
> >> SourceID received in the message matches that of a peer then the relay is a
> reacting node.  If it doesn't match then it is not a reacting node.  Either way, the
> OC-OLR AVP is stripped.
> >>
> >> MCRUZ> But a relay can't be a "reacting node", can it? A relay does not read
> or understand any AVP apart from routing related AVPs.
> > MCRUZ> In DOIC this is not explicitly mentioned, and I do not see the need.
> Moreover, this changes the definition of what a relay is.
> agent that is a relay can also be a reacting node by expanding the definition of
> routing related AVPs to include DOIC AVPs.  I consider this valid as these AVPs,
> and the LOAD AVPs all impact routing decisions.  This, however, is somewhat
> academic as the practical impact of calling an agent that is a reacting node a
> relay or a proxy isn't meaningful.
> 
> traffic towards a HOST reduces as well the traffic through the agents in the path.
> This should be taken into account when applying reduction for that particular
> PEER. However, depending on the routing schema it may not be straight forward
> to identify what is the reduction for each agent path when reducing traffic
> towards a HOST.
> >> MCRUZ> If you think the PEER algorithm is RATE, then there is not
> interaction, as long as when PEER abatement is performed after HOST/REALM,
> it simply keeps a RATE. However, if the PEER algorithm is LOSS, when performed
> after HOST/REALM it should be stated that it is the initial traffic (before any
> HOST/REALM abatement) the one that should be taken into account. Then, I
> think a clarification is required.
> > report and a peer LOSS report could result in extra messages being abated, I
> would prefer to keep the definition of the interaction as simple as possible and
> not change the requirement. My reasoning is that there is value in keeping it
> simple, especially given that it a self correcting scenario.  The next hop will see
> more of a reduction than it was expecting and will subsequently update the
> requested reduction.  If there isn't consensus on this approach we can do a
> special case on this scenario.
> >
> > MCRUZ> I think we need to cover these cases, since having extra throttling
> even if it is compensated later will cause first unnecessary drop messages and
> second traffic oscillations. Both things should be avoided.
>       take into consideration the number of messages already throttled by the
> handling of the HOST/REALM report abatement.
> 

_________________________________________________________________________________________________________________________

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.

---

From: Steve Donovan <[email-masked]>
Date: Mon, 13 Jun 2016 15:12:30 -0500

See inline

> MCRUZ> Thanks Steve. I think this change applies to other places in the draft.
SRD> I found a couple of other places that said "when relaying" that I 
changed to "when an agent relays".

---

From: Steve Donovan <[email-masked]>
Date: Mon, 13 Jun 2016 15:14:19 -0500

Lionel,
Jouni,

I've incorporated all of the suggested changes into the draft.  I 
believe the time period for the WGLC has expired.  Please advise if I 
should publish the new version or if you want to wait for more comments.

Regards,

Steve

---

From: <[email-masked]>
Date: Mon, 13 Jun 2016 20:25:09 +0000

Hi Steve,

Reviewing the draft, I have additional comments that I will post tomorrow.

Regards,

Lionel

Envoyé de mon Orange Nura 2

Le 13 juin 2016 22:14, Steve Donovan <[email-masked]> a écrit :
Lionel,
Jouni,

Regards,

Steve

---

From: <[email-masked]>
Date: Wed, 15 Jun 2016 09:45:16 +0000

Hi,

As indicated, here is a review of the draft for discussion.
The main focus in my review is the alignment with the RFC7683.

Regards,

Lionel

*********
1.  Introduction

[LM] I would start directly the introduction with:

   This document extends the base Diameter endpoint overload
   specification to address the case when Diameter Agents become
   overloaded. [...]

[LM] followed by a brief description of the base mechanism and to better explain then why this document "defines new overload report type".

3.1.3.  Agent Chains

   There are also deployment scenarios where there can be multiple
   Diameter Agents between Diameter Clients and Diameter Servers.
   Examples of this type of deployment include when there are edge
   agents between Diameter networks.  Another example of this type of
   deployment is when there are multiple sets of servers, each
   supporting a subset of the Diameter traffic.

OLD:

   Examples of this type of deployment include when there are edge
   agents between Diameter networks.

NEW:

   Examples of this type of deployment include when there are edge
   agents between Diameter networks.

OLD:

   Another example of this type of
   deployment is when there are multiple sets of servers, each
   supporting a subset of the Diameter traffic.

NEW:

   Another example of this type of
   deployment is when when servers of a domain are grouped in pools,
   each pool supporting a subset of the Diameter traffic received by
   front-end proxies.

3.2.  Diameter Endpoint Use Cases

[LM] In this section, it would be helpful to clearly see what is different here compared to what is possible with the RFC7683.
For instance, by emphasizing from the beginning the difference between "host" and "peer" reports and between "end-to-end" and "hop-by-hop".
Otherwise, it would be difficult to understand the title "Diameter endpoint use cases" in this document.

5.1.1.  Reacting Node Behavior

   When sending a Diameter request a DOIC node that supports the
   OC_PEER_REPORT feature MUST include an OC-Supported-Features AVP with
   an OC-Feature-Vector AVP with the OC_PEER_REPORT bit set.

[LM] the "MUST" here is not appropriate. A DOIC node MUST insert the OC-Supported-Features AVP as per RFC7683.
It is not a new requirement introduced by this document.
It should rather be: "MUST include in the OC-Supported-Features AVP an OC-Feature-Vector AVP with the OC_PEER_REPORT bit set."

      Note: The sender of a request can be a Diameter Client or Diameter
      Server that originates the Diamter request or a Diameter Agent
      that relays the request.

[LM] Not sure that the NOTE is required here.

   Support for the OC_PEER_REPORT feature does not impact the logic for
   setting of other feature bits in the OC-Feature-Vector AVP.

[LM] not sure it is relevant. If it is, could be more appropriate in section 6.1.1

   When sending a request a DOIC node that supports the OC_PEER_REPORT
   feature MUST include an OC-SourceID AVP in the OC-Supported-Features
   AVP with its own DiameterIdentity.

      Note: This allows the DOIC nodes in the path of the request to
      determine if the indication of support came from a Diameter peer
      or if the request traversed a node that does not support the
      OC_PEER_REPORT feature.

[LM] not required as it is explained in the section defining the OC-SourceID and its use is described in other sections.

   When relaying a request that includes an OC-SourceID AVP in the OC-
   Supported-Features AVP, a DOIC node that supports the OC_PEER_REPORT
   feature must remove the received OC-SourceID AVP and replace it with
   an OC-SourceID AVP containing its own Diameter identity.

[LM] if the comments are accepted, the section could be simplified as follow:

NEW:

   When sending a Diameter request, a DOIC node that supports the
   OC_PEER_REPORT feature MUST include in the OC-Supported-Features AVP
   an OC-Feature-Vector AVP with the OC_PEER_REPORT bit set. The
   OC-Supported-Features AVP MUST include an OC-SourceID AVP with the
   DOIC node sending the request.

   When relaying a request that includes an OC-SourceID AVP in the OC-
   Supported-Features AVP, a DOIC node that supuports the OC_PEER_REPORT
   feature must remove the received OC-SourceID AVP and replace it with
   an OC-SourceID AVP containing its own Diameter identity.

5.1.2.  Reporting Node Behavior

   When receiving a request a DOIC node that supports the OC_PEER_REPORT
   feature MUST update transaction state with an indication of whether
   or not the peer from which the request was received supports the
   OC_PEER_REPORT feature.

      Note: The transaction state is used when the DOIC node is acting
      as a peer-report reporting node and needs send OC-OLR reports of
      type PEER_REPORT in answer messages.  The peer overload reports
      are only included in answer messages being sent to peers that
      support the OC_PEER_REPORT feature.

[LM] Not sure of the need for the transaction state, that is not really defined in this document, compared to the OCS entry required by the RFC7683.

[LM] the base mechanism is governed by the following requirement in RFC7683:

   A reporting node MUST NOT include the OC-Supported-Features AVP,
   OC-OLR AVP, or any other overload control AVPs defined in extension
   documents in response messages for transactions where the request
   message does not include the OC-Supported-Features AVP.  Lack of the
   OC-Supported-Features AVP in the request message indicates that there
   is no reacting node for the transaction.

[LM] is there any need to modify this requirement?
[LM] the NOTE is not required if you follow the RFC7683

   When relaying an answer message, a reporting node that supports the
   OC_PEER_REPORT feature MUST strip any SourceID AVP from the OC-
   Supported-Features AVP.

[LM] I know that it was discussed by Jean but I didn't get the conclusion: does the node strip any existing sourceID and include its own?

   When sending an answer message, a reporting node that supports the
   OC_PEER_REPORT feature MUST determine if the peer to which the answer
   is to be sent supports the OC_PEER_REPORT feature. [...]

[LM] in the rest of the section, the only clarification with the basic mechanism defined in RFC7683 is on how to check the support of peer report. Some "MUST" are not appropriate as implicitly required by the support of RFC7683.

5.2.1.  Overload Control State

[LM] consistency with RFC7683 is important.

5.2.1.1.  Reporting Node Peer Report OCS

   A DOIC Node that supports the OC_PEER_REPORT feature SHOULD maintain
   Reporting Node Peer Report OCS.  This is used to record overload
   events and build overload reports at the reporting node.

[LM] in the RFC7683, it is said:

  "A reporting node maintains OCS entries per supported Diameter
   application, per supported (and eventually selected) abatement
   algorithm, and per report type.

   An OCS entry is identified by the tuple of Application-ID, report
   type, and abatement algorithm, and it includes the following
   information (the actual information stored is an implementation
   decision):

   o  Sequence number

   o  Validity duration

   o  Expiration time

   o  Input data that is algorithm specific (for example, the reduction
      percentage for the loss abatement algorithm)"

[LM] does it apply for the peer report also? If yes, why do not reuse the text from RFC7683, with a specific reference? Especially, the mean for OCS entry identification and notion of "application" disappear in this document.

   If different abatement specific contents are sent to each peer then
   the reporting node MUST maintain a separate peer node peer report OCS
   entry per peer to which a peer overload report is sent.

      Note: The rate overload abatement algorithm allows for different
      rates to be sent to each peer.

[LM] not sure that it is required if it is said that there is an OCS entry per peer from the beginning.

   The Reporting Node Peer Report OCS entry MAY include the following
   information (the actual information stored is an implementation
   decision):

[LM] see comment above

5.2.1.2.  Reacting Node Peer Report OCS

   A DOIC node that supports the OC_PEER_REPORT feature SHOULD maintain
   Reacting Node Peer Report OCS for each peer with which it
   communicates.  This is used to record overload reports received from
   peer nodes.

   A Reacting Node Peer Report OCS entry is identified by the
   DiameterIdentity of the peer as communicated during the RFC6733
   defined Capability Exchange procedure.

   The Reacting Node Peer Report OCS entry MAY include the following
   information (the actual information stored is an implementation
   decision):

   o  Sequence number

   o  Expiration Time

   o  Abatement Algorithm

   o  Algorithm specific input data (for example, the Reduction
      Percentage for the Loss Abatement Algorithm)

[LM] in RFC7683, we have:

  "A reacting node maintains the following OCS per supported Diameter
   application:

   o  a host-type OCS entry for each Destination-Host to which it sends
      host-type requests and

   o  a realm-type OCS entry for each Destination-Realm to which it
      sends realm-type requests.

   A host-type OCS entry is identified by the pair of Application-ID and
   the node's DiameterIdentity.

   A realm-type OCS entry is identified by the pair of Application-ID
   and realm.

   The host-type and realm-type OCS entries include the following
   information (the actual information stored is an implementation
   decision):

   o  Sequence number (as received in OC-OLR; see Section 7.3)

   o  Time of expiry (derived from OC-Validity-Duration AVP received in
      the OC-OLR AVP and time of reception of the message carrying
      OC-OLR AVP)

   o  Selected abatement algorithm (as received in the OC-Supported-
      Features AVP)

   o  Input data that is abatement algorithm specific (as received in
      the OC-OLR AVP -- for example, OC-Reduction-Percentage for the
      loss abatement algorithm)"

[LM] when adapted to this document, we should have:

   A reacting node maintains the following OCS per supported Diameter
   application:

   o  a peer-type OCS entry for each peer to which it sends
      host-type requests

   A peer-type OCS entry is identified by the pair of Application-ID and
   the peer's DiameterIdentity.

   The peer-type OCS entry include the following
   information (the actual information stored is an implementation
   decision):

   o  Sequence number (as received in OC-OLR; see Section 7.3)

   o  Time of expiry (derived from OC-Validity-Duration AVP received in
      the OC-OLR AVP and time of reception of the message carrying
      OC-OLR AVP)

   o  Selected abatement algorithm (as received in the OC-Supported-
      Features AVP)

   o  Input data that is abatement algorithm specific (as received in
      the OC-OLR AVP -- for example, OC-Reduction-Percentage for the
      loss abatement algorithm)

[LM] is there any reason to deviate from this approach?

5.2.2.  Reporting Node Maintenance of Peer Report OCS

   A reporting node SHOULD create a new Reporting Node Peer Report OCS
   entry Section 5.2.1.1 in an overload condition and sending a peer
   overload report to a peer for the first time.

[LM] "sending" is not part of the OCS entry maintenance

      If the reporting node knows that there are no reacting nodes
      supporting the OC_PEER_REPORT feature then the reporting node can
      choose to not create OCS entries.

   All rules for managing the reporting node OCS entries defined in
   [RFC7683] apply to the peer report.

[LM] I think that there is nothing specific to peer report here. Only the last paragraph could be kept.

5.2.3.  Reacting Node Maintenance of Peer Report OCS

   When a reacting node receives an OC-OLR AVP with a report type of
   peer it MUST determine if the report was generated by the Diameter
   peer from which the report was received.

   If the DiameterID in the SourceID contained in the OLR matches the
   DiameterIdentity of the peer from which the request was received then
   the report was received from a Diameter peer.

[LM] As discussed above, the match is performed per application in RFC7683. Any reason to deviate?

   If a reacting node receives an OC-OLR AVP of type peer and the
   SourceID does not match the ID of the Diameter peer from which the
   request was received then the reacting node MUST ignore the overload
   report.

[LM] s/SourceID/DiemeterIdentity contained in the SourceID AVP
     s/ID of the Diameter peer/DiameterIdentity

   In all cases, if the reacting node is a relay then it MUST strip the
   OC-OLR AVP from the message.

[LM] not part of the OCS entry maintenance.

   If the Peer Report OLR was received from a Diameter peer then the
   reacting node MUST determine if it is for an existing or new overload
   condition.

   The OLR is for an existing overload condition if the reacting node
   has an OCS that matches the received OLR.  For a peer report-type
   this means the DiameterIdentity received in the SourceID AVP matches
   the DiameterIdentity of an existing peer report OLR.

[LM] Based on RFC7683, For peer report, the text could be:

  "The OLR is for an existing overload condition if a reacting node has
   an OCS that matches the received OLR.

   For a peer report, this means it matches the Application-ID and the
   peer's DiameterIdentity in an existing peer OCS entry."

[LM] OK with rest of the section

[LM] No specific comment on the rest of the document.

De : Lionel MORAND<mailto:[email-masked]>
Envoyé : ‎lundi‎ ‎13‎ ‎juin‎ ‎2016 ‎22‎:‎25
À : Steve Donovan<mailto:[email-masked]>, Maria Cruz Bartolome<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>

Hi Steve,

Regards,

Lionel

Regards,

Steve

---

From: Steve Donovan <[email-masked]>
Date: Tue, 21 Jun 2016 16:47:08 -0500

Lionel,

Thanks for the review.  See my comments inline.

Regards,

Steve

On 6/15/16 4:45 AM, [email-masked] wrote:
> [LM] followed by a brief description of the base mechanism and to 
> better explain then why this document "defines new overload report type".
SRD>  I'd be happy to copy the abstract to the first paragraph of the 
introduction.  The remainder of the introduction section explains why a 
new report type is defined.
>    agents between Diameter networks.
SRD> I don't see a suggested change.
>    each pool supporting a subset of the Diameter traffic received by
SRD> This example has already been removed based on previous comments.
> [LM] In this section, it would be helpful to clearly see what is 
> different here compared to what is possible with the RFC7683.
> For instance, by emphasizing from the beginning the difference between 
> "host" and "peer" reports and between "end-to-end" and "hop-by-hop".
SRD> I'm not seeing the concern here.  The section discusses the case 
when an endpoint would send a peer report.  Can you be more specific in 
suggested wording?
> [LM] the "MUST" here is not appropriate. A DOIC node MUST insert the 
> OC-Supported-Features AVP as per RFC7683.
> It should rather be: "MUST include in the OC-Supported-Features AVP an 
> OC-Feature-Vector AVP with the OC_PEER_REPORT bit set."
SRD> It isn't saying that it must insert the OC-S-F AVP.  It is saying 
it must include the OC-S-F AVP with specific conditions.  I don't see 
the issue.
> [LM] Not sure that the NOTE is required here.
SRD> I'm okay with removing the note.
> [LM] not sure it is relevant. If it is, could be more appropriate in 
SRD> I'm okay with removing this as well.
> [LM] not required as it is explained in the section defining the 
> OC-SourceID and its use is described in other sections.
SRD> The description of SourceID (we agreed to remove the OC- prefix 
earlier) doesn't not indicate that it MUST be included.  As such, I 
think this requirement is needed.
>    an OC-SourceID AVP containing its own Diameter identity.
SRD>  I propose the following:

    When sending a request a DOIC node that supports the OC_PEER_REPORT
    feature MUST include a SourceID AVP in the OC-Supported-Features AVP
    with its own DiameterIdentity.

    When an agent relays a request that includes a SourceID AVP in the
    OC-Supported-Features AVP, a DOIC node that supports the
    OC_PEER_REPORT feature MUST remove the received SourceID AVP and
    replace it with a SourceID AVP containing its own Diameter identity.

> [LM] Not sure of the need for the transaction state, that is not 
> really defined in this document, compared to the OCS entry required by 
> the RFC7683.
>
SRD> Are you suggesting using OCS as the way to determine if the peer 
supports the peer report type?
> [LM] I know that it was discussed by Jean but I didn't get the 
> conclusion: does the node strip any existing sourceID and include its own?
SRD> A relay will strip received SourceID information.  It will include 
its own SourceID based on the requirements statement three paragraphs later.
> [LM] in the rest of the section, the only clarification with the basic 
> mechanism defined in RFC7683 is on how to check the support of peer 
> report. Some "MUST" are not appropriate as implicitly required by the 
> support of RFC7683.
SRD> All of the requirements in this section are specific to the peer 
report.  I don't see any that are implicitly required by RFC7683.  Can 
you clarify the concern?
> [LM] consistency with RFC7683 is important.
SRD>  Agreed.  In general I agree with your suggestions on this 
section.  I will clean up the section to make the reference to RFC7683 
stronger and only talk about deltas needed for the peer report.  This 
should make this section much cleaner.  I'll send the resulting text in 
a separate email.
> [LM] does it apply for the peer report also? If yes, why do not reuse 
> the text from RFC7683, with a specific reference? Especially, the mean 
> for OCS entry identification and notion of "application" disappear in 
> this document.
>
> *De :* Lionel MORAND <mailto:[email-masked]>
> *Envoyé :* ‎lundi‎ ‎13‎ ‎juin‎ ‎2016 ‎22‎:‎25
> *À :* Steve Donovan <mailto:[email-masked]>, Maria Cruz 
> Bartolome <mailto:[email-masked]>, [email-masked] 
> <mailto:[email-masked]>
>
> Hi Steve,
>
> >>> peer overload report.  As with base DOIC, a relay must be able to 
> handle DOIC
> >> AVPs, in addition to the routing AVPs.
> definition of
> abated, I
> >>        Any messages that survive throttling due to host or realm 
> reports should then
> >> go through abatement for the
> >>        peer overload report.  In this scenario, when doing 
> abatement on the PEER
> >> report, the reacting node SHOULD
> >>            Note: The goal is to avoid traffic oscillations that 
> might result from
> >> throttling of messages for both
> > 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,
> > This message and its attachments may contain confidential or 
> privileged information that may be protected by law;
> > 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.
> >
>

---

From: Steve Donovan <[email-masked]>
Date: Wed, 22 Jun 2016 09:54:44 -0500

Lionel,

I have update section 5.2.1 based on your input.  It seemed easier to 
show the comments in the updated draft, especially given the number of 
changes already made.

Regards,

Steve
> should make this section much cleaner.  I'll send the resulting text 
> in a separate email.

---

From: <[email-masked]>
Date: Thu, 23 Jun 2016 09:25:24 +0000

Hi Steve,

I know that you have provided a new version of the draft (that I will check) but here are some answers that were already prepared for you ☺

Regards,

Lionel

De : Steve Donovan [mailto:[email-masked]]
Envoyé : mardi 21 juin 2016 23:47
À : MORAND Lionel IMT/OLN; Maria Cruz Bartolome; [email-masked]
Objet : Re: [Dime] RE : Re: WGLC #1 for draft-ietf-dime-agent-overload-05

Lionel,

Regards,

Steve
On 6/15/16 4:45 AM, [email-masked]<mailto:[email-masked]> wrote:
Hi,

Regards,

Lionel

*********
1.  Introduction

[LM] followed by a brief description of the base mechanism and to better explain then why this document "defines new overload report type".
SRD>  I'd be happy to copy the abstract to the first paragraph of the introduction.  The remainder of the introduction section explains why a new report type is defined.
[LM] ok

3.1.3.  Agent Chains

OLD:

NEW:

   Examples of this type of deployment include when there are edge
   agents between Diameter networks.
SRD> I don't see a suggested change.
[LM] it was a trick ☺
it is proposed:
s/edge agents between Diameter networks/Diameter agents between administrative domains

OLD:

NEW:

[LM] ok

[LM] In this section, it would be helpful to clearly see what is different here compared to what is possible with the RFC7683.
For instance, by emphasizing from the beginning the difference between "host" and "peer" reports and between "end-to-end" and "hop-by-hop".
Otherwise, it would be difficult to understand the title "Diameter endpoint use cases" in this document.
SRD> I'm not seeing the concern here.  The section discusses the case when an endpoint would send a peer report.  Can you be more specific in suggested wording?

[LM] the whole RFC7683 is about overload report exchanged between endpoints. e.g.:
   the Diameter overload indication can be conveyed (1)
   end-to-end between servers and clients or (2) between servers and the
   Diameter Agent inside the realm and then between the Diameter Agent
   and the clients

[LM] the section 3.2 in this document starts with "This section outlines use cases for the peer overload report involving Diameter Clients and Diameter Servers." whereas, in the case of server or client, host reports are expected instead of peer report. And the notion of "endpoint" when we deal in section 3.2.1 with "hop-by-hop abatement" is not crystal clear for me. Even less when it is made reference to the rate algorithm without outlining the specificity of the Rate algo compared to the Loss algo.

Not really sure, but the suggested text could be something like:

   As per RFC7683, the Diameter overload indication can be conveyed
   end-to-end between servers and clients, eventually via Diameter
   agents. In this case, the client is supposed to be responsible
   for applying overload abatement treatment on the Diameter
   traffic, such as for the loss overload abatement algorithm
   defined in RFC7683.

   However, some abatement algorithms could require that the overload
   abatement treatment need to be rather applied by a peer of the
  reporting node than by the Diameter endpoints. An example of
   such algorithm with hop-by-hop abatement treatment requirement is
   the rate abatement algorithm [I-D.ietf-dime-doic-rate-control].

   In such scenarios, the peer overload reports will be sent by the
   Diameter instead of the host/realm overload reports defined in
   the RFC7683.

At least, it is my understanding of the purpose of this section ☺

[LM] the "MUST" here is not appropriate. A DOIC node MUST insert the OC-Supported-Features AVP as per RFC7683.
It is not a new requirement introduced by this document.
It should rather be: "MUST include in the OC-Supported-Features AVP an OC-Feature-Vector AVP with the OC_PEER_REPORT bit set."
SRD> It isn't saying that it must insert the OC-S-F AVP.  It is saying it must include the OC-S-F AVP with specific conditions.  I don't see the issue.
[LM] do you see an issue with my proposal if I find it clearer?

[LM] ok

[LM] ok

[LM] not required as it is explained in the section defining the OC-SourceID and its use is described in other sections.
SRD> The description of SourceID (we agreed to remove the OC- prefix earlier) doesn't not indicate that it MUST be included.  As such, I think this requirement is needed.
[LM] Sorry. My comment was on the NOTE just above..

NEW:

      OC_PEER_REPORT feature.

[LM] fine but please consider my comments above.

[LM] is there any need to modify this requirement?
[LM] the NOTE is not required if you follow the RFC7683
SRD> Are you suggesting using OCS as the way to determine if the peer supports the peer report type?

[LM] the fact is that the Reporting node uses only the OC-Supported-Features AVP and the content or absence of the OC-Feature-Vector AVP to discover the capabilities supported by the peer. After the OCS is used to maintain the current overload state sent to a reacting node. But there is no need I think to maintain a "transaction state" to know "in advance" that a given peer support the peer report type.

[LM] I know that it was discussed by Jean but I didn't get the conclusion: does the node strip any existing sourceID and include its own?
SRD> A relay will strip received SourceID information.  It will include its own SourceID based on the requirements statement three paragraphs later.

[LM] OK

[LM] in the rest of the section, the only clarification with the basic mechanism defined in RFC7683 is on how to check the support of peer report. Some "MUST" are not appropriate as implicitly required by the support of RFC7683.
SRD> All of the requirements in this section are specific to the peer report.  I don't see any that are implicitly required by RFC7683.  Can you clarify the concern?

[LM] You are correct.

[LM] consistency with RFC7683 is important.
SRD>  Agreed.  In general I agree with your suggestions on this section.  I will clean up the section to make the reference to RFC7683 stronger and only talk about deltas needed for the peer report.  This should make this section much cleaner.  I'll send the resulting text in a separate email.
[LM] OK. thank you

   o  Sequence number

   o  Validity duration

   o  Expiration time

[LM] see comment above

   o  Sequence number

   o  Expiration Time

   o  Abatement Algorithm

Hi Steve,

Regards,

Lionel

Envoyé de mon Orange Nura 2
Le 13 juin 2016 22:14, Steve Donovan <[email-masked]><mailto:[email-masked]> a écrit :
Lionel,
Jouni,

Regards,

Steve

On 6/13/16 8:06 AM, [email-masked]<mailto:[email-masked]> wrote:
>> À : Steve Donovan; [email-masked]<mailto:[email-masked]>
>> [email-masked]<mailto:[email-masked]>

Thank you.

Thank you.

---

From: Steve Donovan <[email-masked]>
Date: Fri, 24 Jun 2016 09:57:53 -0500

See my comments inline.

On 6/23/16 4:25 AM, [email-masked] wrote:
>
> Hi Steve,
>
> I know that you have provided a new version of the draft (that I will 
> check) but here are some answers that were already prepared for you J
>
> Regards,
>
> Lionel
>
> *De :*Steve Donovan [mailto:[email-masked]]
> *Envoyé :* mardi 21 juin 2016 23:47
> *À :* MORAND Lionel IMT/OLN; Maria Cruz Bartolome; [email-masked]
> *Objet :* Re: [Dime] RE : Re: WGLC #1 for 
> draft-ietf-dime-agent-overload-05
>
> Lionel,
>
> On 6/15/16 4:45 AM, [email-masked] 
> <mailto:[email-masked]>wrote:
>
>     Hi,
>
> introduction.  The remainder of the introduction section explains why 
> a new report type is defined.
>
> */[LM] ok/*
>
>
> 3.1.3.  Agent Chains
>
> */[LM] it was a trick /**/J/**//*
>
> */it is proposed:/*
>
> */s/edge agents between Diameter networks/Diameter agents between 
> administrative domains/*
>
/*SRD> I'm ok with this change.*/
> *//*
> */[LM] ok/*
> when an endpoint would send a peer report.  Can you be more specific 
> in suggested wording?
>
> */[LM] the whole RFC7683 is about overload report exchanged between 
> endpoints. e.g.: /*
>
> *//*
> */[LM] the section 3.2 in this document starts with "/*This section 
> outlines use cases for the peer overload report involving Diameter 
> Clients and Diameter Servers.*/" whereas, in the case of server or client, host reports are expected 
> instead of peer report. And the notion of "endpoint" when we deal in 
> section 3.2.1 with "hop-by-hop abatement" is not crystal clear for me. 
> Even less when it is made reference to the rate algorithm without 
> outlining the specificity of the Rate algo compared to the Loss algo./*
/*SRD> If an endpoint wants to use a hop-by-hop abatement algorithm 
(e.g. rate) then it would send a peer report, not a host report.  That 
is the use case this section is addressing. */
> *//*
> */Not really sure, but the suggested text could be something like:/*
> *//*
>
> */At least, it is my understanding of the purpose of this section /**/J/**//*
>
> */[LM] do you see an issue with my proposal if I find it clearer?/*
>
/*SRD>  Okay, if you insist. :-)*/
> */[LM] ok/*
> */[LM] ok/*
> */[LM] Sorry. My comment was on the NOTE just above../*
>
/*SRD> Okay, I can remove it, however, I don't see the harm in it being 
there.*/
> */[LM] fine but please consider my comments above./*
/*SRD> Let me know if the new draft addresses your concerns.*/
> */[LM] the fact is that the Reporting node uses only the 
> OC-Supported-Features AVP and the content or absence of the 
> OC-Feature-Vector AVP to discover the capabilities supported by the 
> peer. After the OCS is used to maintain the current overload state 
> sent to a reacting node. But there is no need I think to maintain a 
> "transaction state" to know "in advance" that a given peer support the 
> peer report type./*
>
> SRD> A relay will strip received SourceID information.  It will 
> include its own SourceID based on the requirements statement three 
> paragraphs later.
>
> */[LM] OK/*
>
> */[LM] You are correct./*
>
>
> */[LM] OK. thank you/*
> *De :*Lionel MORAND <mailto:[email-masked]>
> Le 13 juin 2016 22:14, Steve Donovan <[email-masked]> 
> <mailto:[email-masked]>a écrit :
>
> Lionel,
> Jouni,
>
> On 6/13/16 8:06 AM, [email-masked] 
> <mailto:[email-masked]>wrote:
> >> À : Steve Donovan; [email-masked] <mailto:[email-masked]>
> >> [email-masked] <mailto:[email-masked]>
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie.Merci.
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie.Merci.

---

From: <[email-masked]>
Date: Fri, 24 Jun 2016 15:01:18 +0000

Ok. We can close this discussion thread.
I will review the last version of the draft.

Lionel

De : Steve Donovan [mailto:[email-masked]]
Envoyé : vendredi 24 juin 2016 16:58
À : MORAND Lionel IMT/OLN; Maria Cruz Bartolome; [email-masked]
Objet : Re: [Dime] RE : Re: WGLC #1 for draft-ietf-dime-agent-overload-05

See my comments inline.
On 6/23/16 4:25 AM, [email-masked]<mailto:[email-masked]> wrote:
Hi Steve,

Regards,

Lionel

De : Steve Donovan [mailto:[email-masked]]
Envoyé : mardi 21 juin 2016 23:47
À : MORAND Lionel IMT/OLN; Maria Cruz Bartolome; [email-masked]<mailto:[email-masked]>
Objet : Re: [Dime] RE : Re: WGLC #1 for draft-ietf-dime-agent-overload-05

Lionel,

Regards,

Steve

Regards,

Lionel

*********
1.  Introduction

3.1.3.  Agent Chains

OLD:

NEW:

SRD> I'm ok with this change.

OLD:

NEW:

[LM] the section 3.2 in this document starts with "This section outlines use cases for the peer overload report involving Diameter Clients and Diameter Servers." whereas, in the case of server or client, host reports are expected instead of peer report. And the notion of "endpoint" when we deal in section 3.2.1 with "hop-by-hop abatement" is not crystal clear for me. Even less when it is made reference to the rate algorithm without outlining the specificity of the Rate algo compared to the Loss algo.
SRD> If an endpoint wants to use a hop-by-hop abatement algorithm (e.g. rate) then it would send a peer report, not a host report.  That is the use case this section is addressing.

SRD>  Okay, if you insist. :-)

[LM] not required as it is explained in the section defining the OC-SourceID and its use is described in other sections.
SRD> The description of SourceID (we agreed to remove the OC- prefix earlier) doesn't not indicate that it MUST be included.  As such, I think this requirement is needed.
[LM] Sorry. My comment was on the NOTE just above..
SRD> Okay, I can remove it, however, I don't see the harm in it being there.

NEW:

      OC_PEER_REPORT feature.

[LM] fine but please consider my comments above.
SRD> Let me know if the new draft addresses your concerns.

[LM] OK

[LM] You are correct.

   o  Sequence number

   o  Validity duration

   o  Expiration time

[LM] see comment above

   o  Sequence number

   o  Expiration Time

   o  Abatement Algorithm

Hi Steve,

Regards,

Lionel

Regards,

Steve

Thank you.

Thank you.

Thank you.

---

From: Steve Donovan <[email-masked]>
Date: Fri, 24 Jun 2016 10:12:22 -0500

Lionel,

I did make a few small changes to the -06 draft based on your comments.  
As such, there will be a -07 once we have confirmation that all concerns 
have been addressed.

Steve

On 6/24/16 10:01 AM, [email-masked] wrote:
> *Envoyé :* vendredi 24 juin 2016 16:58
>     I know that you have provided a new version of the draft (that I
>     will check) but here are some answers that were already prepared
>     for you J
>
>     Regards,
>
>     Lionel
>
>         [LM] followed by a brief description of the base mechanism and
>         to better explain then why this document "defines new overload
>         report type".
>
>     SRD>  I'd be happy to copy the abstract to the first paragraph of
>     the introduction.  The remainder of the introduction section
>     explains why a new report type is defined.
>
>     */[LM] ok/*
>
>
>     3.1.3.  Agent Chains
>
>     */[LM] it was a trick /**/J/*
>
>     */it is proposed:/*
>
> */SRD> I'm ok with this change./*
>
> OLD:
>
> */SRD> If an endpoint wants to use a hop-by-hop abatement algorithm 
> is the use case this section is addressing. /*
>
> */At least, it is my understanding of the purpose of this section /**/J/*
>
> */SRD>  Okay, if you insist. :-)/*
>
> */SRD> Okay, I can remove it, however, I don't see the harm in it 
> being there./*
>
> */SRD> Let me know if the new draft addresses your concerns./*
>
> <mailto:[email-masked]> wrote: