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

[Steve Donovan <[e-mail]>]

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 
<[e-mail]> wrote:

> 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