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

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

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



> 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.

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.

>    
> 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.

MCRUZ> Ok


> 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.

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.



> 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.

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.


> 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.

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.