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

[Steve Donovan <[e-mail]>]

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, [e-mail] wrote:
>
> Ok. We can close this discussion thread.
>
> I will review the last version of the draft.
>
> Lionel
>
> *De :*Steve Donovan [mailto:[e-mail]]
> *Envoyé :* vendredi 24 juin 2016 16:58
> *À :* MORAND Lionel IMT/OLN; Maria Cruz Bartolome; [e-mail]
> *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, [e-mail] 
> <mailto:[e-mail]> 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:[e-mail]]
>     *Envoyé :* mardi 21 juin 2016 23:47
>     *À :* MORAND Lionel IMT/OLN; Maria Cruz Bartolome; [e-mail]
>     <mailto:[e-mail]>
>     *Objet :* Re: [Dime] RE : Re: WGLC #1 for
>     draft-ietf-dime-agent-overload-05
>
>     Lionel,
>
>     Thanks for the review.  See my comments inline.
>
>     Regards,
>
>     Steve
>
>     On 6/15/16 4:45 AM, [e-mail]
>     <mailto:[e-mail]>wrote:
>
>         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".
>
>     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
>
>        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.
>
>     SRD> I don't see a suggested change.
>
>     */[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./*
>
> 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.
>
> SRD> This example has already been removed based on previous comments.
>
> */[LM] ok/*
>
> 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.
>
> 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./*
>
> */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:/*
> *//*
>
>    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 /**/J/*
>
> 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."
>
> 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?/*
>
> */SRD>  Okay, if you insist. :-)/*
>
>       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.
>
> SRD> I'm okay with removing the note.
>
> */[LM] ok/*
>
>    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
>
> SRD> I'm okay with removing this as well.
>
> */[LM] ok/*
>
>    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.
>
> 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./*
>
>    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.
>
> SRD>  I propose the following:
>
>    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.
>    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.
>       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.
>    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] fine but please consider my comments above./*
>
> */SRD> Let me know if the new draft addresses your concerns./*
>
> 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
>
> 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./*
>
>    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?
>
> SRD> A relay will strip received SourceID information.  It will 
> include its own SourceID based on the requirements statement three 
> paragraphs later.
>
> */[LM] OK/*
>
>    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.
>
> 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./*
>
>
> 5.2.1.  Overload Control State
>
> [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/*
>
> 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:[e-mail]>
> *Envoyé :* ‎lundi‎ ‎13‎ ‎juin‎ ‎2016 ‎22‎:‎25
> *À :* Steve Donovan <mailto:[e-mail]>, Maria Cruz 
> Bartolome <mailto:[e-mail]>, [e-mail] 
> <mailto:[e-mail]>
>
> 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 <[e-mail]> 
> <mailto:[e-mail]>a écrit :
>
> 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
>
> On 6/13/16 8:06 AM, [e-mail] 
> <mailto:[e-mail]> wrote:
> > Thank you for the useful discussion.
> > I'm OK with the output and the proposed changes.
> >
> > regards,
> >
> > Lionel
> >
> >> -----Message d'origine-----
> >> De : DiME [mailto:[e-mail]] De la part de Maria Cruz 
> Bartolome
> >> Envoyé : vendredi 10 juin 2016 10:02
> >> À : Steve Donovan; [e-mail] <mailto:[e-mail]>
> >> Objet : Re: [Dime] WGLC #1 for draft-ietf-dime-agent-overload-05
> >>
> >>>>> 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
> >>>> SRD> 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.
> >>> SRD> Yes a relay is the reacting node for any next hop that generates
> >>> SRD> 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.
> >> 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.
> >>
> >>
> >>>>> 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
> >>>> SRD> 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.
> >>> 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.
> >> 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.
> >>
> >> MCRUZ> I think this is fine. Thanks
> >>
> >> _______________________________________________
> >> DiME mailing list
> >> [e-mail] <mailto:[e-mail]>
> >> https://www.ietf.org/mailman/listinfo/dime
> > 
> _________________________________________________________________________________________________________________________
> >
> > 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.
> >
>
> _________________________________________________________________________________________________________________________
>   
> 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.
> _________________________________________________________________________________________________________________________
>   
> 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.
>
> _________________________________________________________________________________________________________________________
> 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.
>
> _________________________________________________________________________________________________________________________
>
> 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.