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

[Steve Donovan <[e-mail]>]

Maria Cruz,

Thanks again for the thorough review.

Please see my responses inline.

Regards,

Steve

On 5/27/16 7:30 AM, Maria Cruz Bartolome wrote:
> 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?
SRD> Because the concepts of Diameter Server, Diameter Client and 
Diameter Agent are defined in 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?
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.
>
>
>
> =========== 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.
SRD> Okay.
>    
> 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.
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.


>
> 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.
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.
>
>
> 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.
SRD> Agreed.
>
> 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.
SRD> Agreed.  I've changed "scenarios" to "scenario".
>
>
> 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*
SRD> Agreed
>
> 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?
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.
>
>
> 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.
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.
>
>
> 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."
SRD> Agreed.
>
>
> 10. Clause 5.2
>
>    Now
> 	5.2.  Peer Report Overload Report Handling
>
> Proposed:
> 	5.2.  Peer Overload Report Handling
SRD> Agreed
>
>
> 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.
SRD> Agreed.
>
>
> 12. Clause 5.2.1.2
> 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.
>
> 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.
SRD> Agreed.
>
>
>
>
> =========== 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.
SRD> Changed to 3.1.2.
>
> 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
SRD> I've addressed all of the editorial issues listed.
>
>
>
> -----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
>
> _______________________________________________
> DiME mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dime