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

[Maria Cruz Bartolome <[e-mail]>]

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: [e-mail]; [e-mail]; [e-mail]
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:[e-mail]] On Behalf Of Jouni Korhonen
Sent: lunes, 23 de mayo de 2016 21:13
To: [e-mail]; Jouni; [e-mail]
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

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