Subject: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example

From: "dime issue tracker" <[email-masked]>
Date: Fri, 05 Sep 2014 07:49:32 -0000

#70: Appendix B - Example

 In the example included in Appendix B, it is considered that the Agent
 reports Host overload directly back to the Client, when the Client request
 was for the Realm, withouth Destination Host (or direct connection).
 I do not agree about this behaviour.
 Agent will provide Host overload to the Client only when the request was
 sent to one specific host.

 Example shall be modified.

 Proposed modification:

         Client     Agent      S1        S2        S3
            |         |         |         |         |
            |(1) Request (DR:realm)       |         |
            |-------->|         |         |         |
            |         |         |         |         |
            |         |         |         |         |
            |         |Agent selects S1   |         |
            |         |         |         |         |
            |         |         |         |         |
            |         |         |         |         |
            |         |(2) Request (DR:realm)       |
            |         |-------->|         |         |
            |         |         |         |         |
            |         |         |         |         |
            |         |         |S1 overloaded, returns OLR
            |         |         |         |         |
            |         |         |         |         |
            |         |         |         |         |
            |         |(3) Answer (OH:S1,OLR:RT=DH)
            |         |<--------|         |         |
            |         |         |         |         |
            |         |         |         |         |
            |         |sees OLR,routes next DR traffic to S2&S3
            |         |         |         |         |
            |(5) Request (DR:realm)       |         |
            |-------->|         |         |         |
            |         |         |         |         |
            |         |         |         |         |
            |         |Agent selects S2   |         |
            |         |         |         |         |
            |         |         |         |         |
            |         |         |         |         |
            |         |(6) Request (DR:realm)       |
            |         |------------------>|         |
            |         |         |         |         |
            |         |         |         |         |
            |         |         |         |S2 is overloaded...
            |         |         |         |         |
            |         |         |         |         |
            |         |         |         |         |
            |         |(7) Answer (OH:S2, OLR:RT=DH)|
            |         |<------------------|         |
            |         |         |         |         |
            |         |         |         |         |
            |         |Agent sees OLR, realm now overloaded
            |         |         |         |         |
            |         |         |         |         |
            |         |         |         |         |
            |(8) Answer (OLR: RT=R)
            |<--------|         |         |         |
            |         |         |         |         |
            |         |         |         |         |
            |Client throttles DR:realm
            |         |         |         |         |
            |         |         |         |         |
            |         |         |         |         |
            |         |         |         |         |
            |         |         |         |         |

       Figure 8: Mix of Destination-Host and Destination-Realm Routed
                                  Requests

    1.  The client sends a request with no Destination-Host AVP (that is,
        a Destination-Realm routed request.)

    2.  The agent follows local policy to select a server from its peer
        table.  In this case, the agent selects S2 and forwards the
        request.

    3.  S1 is overloaded.  It sends an answer indicating success, but also
        includes an overload report.  Since the overload report only
        applies to S1, the ReportType is "Destination-Host".

    4.  The agent sees the overload report, and records that S1 is
        overloaded by the value in the Reduction-Percentage AVP.  It
        begins diverting the indicated percentage of realm-routed traffic
        from S1 to S2 and S3.

    5.  The client sends another Destination-Realm routed request.

    6.  The agent selects S2, and forwards the request.

    7.  It turns out that S2 is also overloaded, perhaps due to all that
        traffic it took over for S1.  S2 returns an successful answer
        containing an overload report.  Since this report only applies to
        S2, the ReportType is "Destination-Host".

    8.  The agent sees that S2 is also overloaded by the value in
        Reduction-Percentage.  This value is probably different than the
        value from S1's report.  The agent diverts the remaining traffic
        to S3 as best as it can, but it calculates that the remaining
        capacity across all three servers is no longer sufficient to
        handle all of the realm-routed traffic.  This means the realm
        itself is overloaded.  The realm's overload percentage is most
        likely different than that for either S1 or S2.
        The agent generates a new report for the realm of
        "realm", and inserts that report into the answer.  The client
        throttles requests with no
        Destination-Host AVP at requested rate.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:  draft-ietf-dime-
  [email-masked]  |  [email-masked]
     Type:  defect                   |     Status:  new
 Priority:  minor                    |  Milestone:
Component:  draft-ietf-dime-ovli     |    Version:
 Severity:  Active WG Document       |   Keywords:
-------------------------------------+-------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket/70>
dime <http://tools.ietf.org/wg/dime/>

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 8 Sep 2014 14:20:59 +0000

Maria Cruz,

I share your concern.

Please find some comments attached.

Best regards
Ulrich

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext dime issue tracker
Sent: Friday, September 05, 2014 9:50 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example

 Proposed modification:

         Client     Agent      S1        S2        S3
            |         |         |         |         |

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

---

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Tue, 9 Sep 2014 10:01:26 +0000

Hi MCruz, Ulrich

I think we already had some discussion on the OLRs to be reported by DA to clients in this type of use cases.

a) In step 4), in the existing draft wording, the DA sends a successful answer to the client with origin host = S1 and an Host type OLR related to S1. As the client will have further Host routed requests to this S1 host, it seemed good for the client to be immediately informed of the S1 host overload, so to apply throttling to further S1 host requests. This has no impact on Realm routed requests.

In Step 8), the DA has determined a realm overload and send a realm type OLR in the answer and also, as in step 4) the Host type OLR related to the Origin Host S2. This works. The point that was discussed in our previous discussions, is that the answer will contains two OLRs  a realm type one and a host type one, which was accepted at this time. Is it this point you consider as an issue, and why? 

b) this drives to some other remarks. The IETF draft indicates that, in 5.3, when a reporting node requests traffic reduction, it sends OLRs in all answer messages (with the additional MCRuz proposal that if not present this means no change), so this drives to have a realm type  OLR  related to the Origin-Realm AVP (when overloaded) of an answer and a Host type OLR related to the Origin-Host  AVP (when overloaded) of the same answer. The example in a) is one such case. Do you want to modify 5.3 to introduce additional rules, which ones?

Best regards

JJacques 

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de Wiehe, Ulrich (NSN - DE/Munich)
Envoyé : lundi 8 septembre 2014 16:21
À : [email-masked]; [email-masked]; [email-masked]
Objet : Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example

Maria Cruz,

I share your concern.

Best regards
Ulrich

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext dime issue tracker
Sent: Friday, September 05, 2014 9:50 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example

 In the example included in Appendix B, it is considered that the Agent  reports Host overload directly back to the Client, when the Client request  was for the Realm, withouth Destination Host (or direct connection).
 I do not agree about this behaviour.
 Agent will provide Host overload to the Client only when the request was  sent to one specific host.

 Proposed modification:

         Client     Agent      S1        S2        S3
            |         |         |         |         |

-- 
-------------------------------------+----------------------------------
-------------------------------------+---
 Reporter:                           |      Owner:  draft-ietf-dime-
  [email-masked]  |  [email-masked]
     Type:  defect                   |     Status:  new
 Priority:  minor                    |  Milestone:
Component:  draft-ietf-dime-ovli     |    Version:
 Severity:  Active WG Document       |   Keywords:
-------------------------------------+----------------------------------
-------------------------------------+---

---

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Tue, 9 Sep 2014 10:48:27 +0000

Dear all

Another remark on this type of use cases.

There is a realm overload, the DA receives a realm routed request and decide to throttle it and generates a Diameter error (congestion or too busy under discussion). The request was not sent to any server; which Origin-Host AVP does the DA puts in the unsuccessful answer to the client. RFC6733 6.3 states that "Origin-Host AVP MUST be present in all Diameter messages. This AVP identifies the endpoint that originated the Diameter message". 

Another clarification, in our discussions, we speak of OLRs put in successful answers;  my understanding is that OLRs may also be present in unsuccessful answers (with a Diameter error). Do we agree on this?

Best regards

Jacques    

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Envoyé : mardi 9 septembre 2014 12:01
À : [email-masked]; Wiehe, Ulrich (NSN - DE/Munich); [email-masked]; [email-masked]
Objet : Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example

Hi MCruz, Ulrich

Best regards

JJacques 

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de Wiehe, Ulrich (NSN - DE/Munich) Envoyé : lundi 8 septembre 2014 16:21 À : [email-masked]; [email-masked]; [email-masked] Objet : Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example

Maria Cruz,

I share your concern.

Best regards
Ulrich

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext dime issue tracker
Sent: Friday, September 05, 2014 9:50 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example

 Proposed modification:

         Client     Agent      S1        S2        S3
            |         |         |         |         |

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 9 Sep 2014 10:57:36 +0000

Dear JJacques,

assume the following example:
In step 1 (realm routed request sent from Client to Agent), the client indicates that it supports loss.
In step 2 (host routed request send from agent to S1), the agent indicates that it supports loss and rate.
In step 3 (answer from S1 to agent, containing a host type OLR), S1 indicates that it selected rate.

Now in step 4 there is no point in forwarding the host-type OLR from agent to client as the client does not support rate. Similar for step 8 where no host type OLR of rate shall be sent in addition to the realm-type OLR of loss.

Also note that the answer in step 8 can contain only one Supported-Features AVP i.e. can only contain one selected algorithm. Even when the agent supports loss and realm, you cannot say in one answer "use loss for realm routed requests and rate for host routed requests"

Furthermore the client may never send host routed requests to S1. (And if it does, it will learn the host type OLR and selected algorithm in the corresponding answer).

I'm aware that there may be cases where agent and server select the same algorithm and the problem described above disappears, but even then we should not mandate including the host-type OLR in the answer that corresponds to a realm type request.

Best regards
Ulrich

-----Original Message-----
From: ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES) [mailto:[email-masked]] 
Sent: Tuesday, September 09, 2014 12:01 PM
To: [email-masked]; Wiehe, Ulrich (NSN - DE/Munich); [email-masked]; [email-masked]
Subject: RE: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example

Hi MCruz, Ulrich

Best regards

JJacques 

-----Message d'origine-----

Maria Cruz,

I share your concern.

Best regards
Ulrich

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext dime issue tracker
Sent: Friday, September 05, 2014 9:50 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example

 Proposed modification:

         Client     Agent      S1        S2        S3
            |         |         |         |         |

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 9 Sep 2014 11:16:12 +0000

Jacques,

in this scenario where the client supports DOIC my understanding is:
If there is a realm overload, the agent will receive only those realm routed requests that survived a throttling at the client. There is no point for the agent to throttle again.

Anyway this seems not to be related to #70.

See also inline.

Ulrich

-----Original Message-----
From: ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES) [mailto:[email-masked]] 
Sent: Tuesday, September 09, 2014 12:48 PM
To: [email-masked]; Wiehe, Ulrich (NSN - DE/Munich); [email-masked]; [email-masked]
Subject: RE: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example

Dear all

Another clarification, in our discussions, we speak of OLRs put in successful answers;  my understanding is that OLRs may also be present in unsuccessful answers (with a Diameter error). Do we agree on this?
[Wiehe, Ulrich (NSN - DE/Munich)] I agree.

Best regards

Jacques    

-----Message d'origine-----

Hi MCruz, Ulrich

Best regards

JJacques 

-----Message d'origine-----

Maria Cruz,

I share your concern.

Best regards
Ulrich

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext dime issue tracker
Sent: Friday, September 05, 2014 9:50 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example

 Proposed modification:

         Client     Agent      S1        S2        S3
            |         |         |         |         |

---

From: Ben Campbell <[email-masked]>
Date: Tue, 9 Sep 2014 21:37:31 -0500

We had exactly that example in the draft discussed in Toronto ( draft-donovan-doic-agent-cases ).

Comments inline:

> Now in step 4 there is no point in forwarding the host-type OLR from agent to client as the client does not support rate. Similar for step 8 where no host type OLR of rate shall be sent in addition…

I agree there is no point forwarding the OLR per se. However, the agent may still indicate that it supports "loss" back to the client, and send loss-based reports if the client sends too much traffic for the agent to comply with the max rate without throttling.

> Also note that the answer in step 8 can contain only one Supported-Features AVP i.e. can only contain one selected algorithm. Even when the agent supports loss and realm, you cannot say in one answ…

One approach is where you end up with is "loss" is supported between the client and agent, and "rate" is supported between the agent and server.

Don't get me wrong, I'm not saying that's a _required_ approach, but it should be allowed.

> Furthermore the client may never send host routed requests to S1. (And if it does, it will learn the host type OLR and selected algorithm in the corresponding answer).

I don't follow this. Do you mean "might never"? (I read "may never" as "is never allowed to").

The agent has to ensure that any OLRs that get back to the client match the capabilities the client advertised, and received. It could do that by stripping all OC-S-F and OLR avps in answers, or it could act as as an algorithm "gateway" and (statefully) translate between the capabilities selected on either side. 

> I'm aware that there may be cases where agent and server select the same algorithm and the problem described above disappears, but even then we should not mandate including the host-type OLR in the…

I don't see that following. We should prevent a server from putting any host reports into answers to realm routed requests. Otherwise, you have use cases that just want work. For example, consider how a server could report any overload at all for an application that is exclusively realm-routed.

Also, consider that with the recently discussed distinction between realm-routed requests and host-routed requests, we consider a request to be host-routed if it has a Destination-Host _or_ if a node has other knowledge that the request will go to specific server (e.g., if the peer-selection decision would send a request to the specific host. ) In the second case, the server itself cannot distinguish a host-routed request from a host-routed request.

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Wed, 10 Sep 2014 13:59:19 +0000

Dear JJ, 
I agree with Ulrich comments below.
But this is not related to #70

Cheers
/MCruz

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:[email-masked]] 
Sent: martes, 09 de septiembre de 2014 13:16
To: ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES); Maria Cruz Bartolome; [email-masked]; [email-masked]
Subject: RE: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example

Jacques,

See also inline.

Ulrich

-----Original Message-----
From: ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES) [mailto:[email-masked]]
Sent: Tuesday, September 09, 2014 12:48 PM
To: [email-masked]; Wiehe, Ulrich (NSN - DE/Munich); [email-masked]; [email-masked]
Subject: RE: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example

Dear all

Best regards

Jacques    

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de TROTTIN, JEAN-JACQUES (JEAN-JACQUES) Envoyé : mardi 9 septembre 2014 12:01 À : [email-masked]; Wiehe, Ulrich (NSN - DE/Munich); [email-masked]; [email-masked]
Objet : Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example

Hi MCruz, Ulrich

Best regards

JJacques 

-----Message d'origine-----

Maria Cruz,

I share your concern.

Best regards
Ulrich

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext dime issue tracker
Sent: Friday, September 05, 2014 9:50 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example

 Proposed modification:

         Client     Agent      S1        S2        S3
            |         |         |         |         |

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Wed, 10 Sep 2014 14:02:38 +0000

Hello,

In my opinion, the main reason to answer realm-routed requests with only Realm OLR is because specific host(s) OLR may never be used by this reacting node, since this client may never send a request routed to these hosts
If ever the reacting node sends a request to any host, it will receive back corresponding host OLR, and from then on it could apply corresponding abatement.

Regards
/MCruz

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]] 
Sent: miércoles, 10 de septiembre de 2014 4:38
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES); Maria Cruz Bartolome; [email-masked]; [email-masked]
Subject: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example

Comments inline:

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 10 Sep 2014 14:09:33 +0000

Ben,

please see comments inline.

Ulrich

-----Original Message-----
From: ext Ben Campbell [mailto:[email-masked]] 
Sent: Wednesday, September 10, 2014 4:38 AM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES); [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example

Comments inline:

I agree there is no point forwarding the OLR per se. However, the agent may still indicate that it supports "loss" back to the client, and send loss-based reports if the client sends too much traffic for the agent to comply with the max rate without throttling.
<Ulrich> I think the agent shall indicate that it supports "loss" back to the client. In addition, are you proposing that the agent may translate the rate based host-type OLR received from S1 into a loss based host type OLR and forward it to the client?</Ulrich>

Don't get me wrong, I'm not saying that's a _required_ approach, but it should be allowed.
<Ulrich> I'm ok with "loss" for realm type OLRs sent from agent to client and "rate" for host type OLRs sent from Server to agent in this scenario (steps 8 and 7). 
However, if we allow an agent to translate a received host type OLR of "rate" into a sent host type OLR of "loss" we may end up in situations where the client receices out of sync OLRs from different agents on different paths between client and server.</Ulrich>

I don't follow this. Do you mean "might never"? (I read "may never" as "is never allowed to").
<Ulrich>yes sorry I meant "might never"</Ulrich>

The agent has to ensure that any OLRs that get back to the client match the capabilities the client advertised, and received. It could do that by stripping all OC-S-F and OLR avps in answers
<Ulrich>I agree</Ulrich>
, or it could act as as an algorithm "gateway" and (statefully) translate between the capabilities selected on either side. 
<Ulrich> this sounds complex to me and is absolutely unnecessary</Ulrich>

> I'm aware that there may be cases where agent and server select the same algorithm and the problem described above disappears, but even then we should not mandate including the host-type OLR in the…

I don't see that following. 
<Ulrich> I did not say "shall forbid" but "should not mandate" </Ulrich>
We should prevent a server from putting any host reports into answers to realm routed requests. Otherwise, you have use cases that just want work.
<Ulrich>how can a server receive a realm routed request? I can understand that a server may receive a request that does not contain a Destination-Host AVP, but that's not the definition of realm-routed request</Ulrich>
 For example, consider how a server could report any overload at all for an application that is exclusively realm-routed.

Also, consider that with the recently discussed distinction between realm-routed requests and host-routed requests, we consider a request to be host-routed if it has a Destination-Host _or_ if a node has other knowledge that the request will go to specific server (e.g., if the peer-selection decision would send a request to the specific host. ) In the second case, the server itself cannot distinguish a host-routed request from a host-routed request.
<Ulrich> I don't follow this. Do you mean "from a realm-routed request"? My interpretation of the definition is that a server will never receive a realm-routed request as the previous direct peer always has the knowledge that the request will go to that server.</Ulrich>

---

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Wed, 10 Sep 2014 16:17:36 +0000

Hi MCruz, Ulrich

I agree this is not related to  #70 as the DA does not do throttling , but my question still applies for a DOIC DA acting on behalf of clients not supporting DOIC. This DA  throttles a Realm routed  request. What does it send as Origin Host in the unsuccesfull answer to the client. This question may be more a RFC 6733 one.

I may generate a ticket if this generates discussion.

Best regards

JJacques 

-----Message d'origine-----
De : Maria Cruz Bartolome [mailto:[email-masked]] 
Envoyé : mercredi 10 septembre 2014 15:59
À : Wiehe, Ulrich (NSN - DE/Munich); TROTTIN, JEAN-JACQUES (JEAN-JACQUES); [email-masked]; [email-masked]
Objet : RE: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example

Dear JJ, 

Cheers
/MCruz

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:[email-masked]] 
Sent: martes, 09 de septiembre de 2014 13:16
To: ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES); Maria Cruz Bartolome; [email-masked]; [email-masked]
Subject: RE: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example

Jacques,

See also inline.

Ulrich

-----Original Message-----
From: ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES) [mailto:[email-masked]]
Sent: Tuesday, September 09, 2014 12:48 PM
To: [email-masked]; Wiehe, Ulrich (NSN - DE/Munich); [email-masked]; [email-masked]
Subject: RE: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example

Dear all

 Question Another remark on this type of use cases.

Best regards

Jacques    

-----Message d'origine-----

Hi MCruz, Ulrich

Best regards

JJacques 

-----Message d'origine-----

Maria Cruz,

I share your concern.

Best regards
Ulrich

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext dime issue tracker
Sent: Friday, September 05, 2014 9:50 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example

 Proposed modification:

         Client     Agent      S1        S2        S3
            |         |         |         |         |

---

From: Ben Campbell <[email-masked]>
Date: Wed, 10 Sep 2014 15:12:12 -0500

> In my opinion, the main reason to answer realm-routed requests with only Realm OLR is because specific host(s) OLR may never be used by this reacting node, since this client may never send a reques…

If the reacting node never sends a request to that host, then it never cares. No harm done. Bytes on the wire are cheap.

> If ever the reacting node sends a request to any host, it will receive back corresponding host OLR, and from then on it could apply corresponding abatement.

Again-A restriction against the reporting-node sending a host-report in response to a realm-routed request is incompatible with our current definition of ream-routing vs host-routing. 

It also prevents servers from sending any OLRs at all for applications that are entirely realm-routed, unless the server can generate authoritative realm-reports. While that may be true sometimes, it will not be true in the general case.

---

From: Ben Campbell <[email-masked]>
Date: Wed, 10 Sep 2014 15:34:46 -0500

On Sep 10, 2014, at 9:09 AM, Wiehe, Ulrich (NSN - DE/Munich) <[email-masked]> wrote:

> <Ulrich> I think the agent shall indicate that it supports "loss" back to the client.

I wouldn't put it as strongly as "shall", but I think there are circumstances where it makes sense to do so. (see next comment). There may also be circumstances where it decides to handle OC control locally, in which case it may chose not to send any OC-O-F at all back to the client.

> In addition, are you proposing that the agent may translate the rate based host-type OLR received from S1 into a loss based host type OLR and forward it to the client?</Ulrich>

Not quite. I would use the term "gateway" rather than "translate". 

I think it highly unlikely one can translate any given rate-based OLR into a loss-based OLR in a useful way. But, I do think that the agent may choose to locally enforce the rate limit, and send lost-based OLRs back to the client in an attempt to reduce the number of requests that the agent might have to throttle.

For example, if the agent can achieve the rate limit at the current load offered by the client without throttling, it need send no OLRs to the client at all. In this case, the client doesn't need to know about the overload condition. But if the agent has to throttle, it might (maybe should) delegate the required throttling back to the client as much as it can. The loss algorithm is sort of clumsy for that purpose, but it would still be better than nothing.

> However, if we allow an agent to translate a received host type OLR of "rate" into a sent host type OLR of "loss" we may end up in situations where the client receices out of sync OLRs from differe…

That's a good point. If your load is reasonably balanced across agents, it might not matter. If it _does_ matter, then something like an agent-overload report (as in Steve's draft) from the agent to the client might work better.

I think we are going to need a better understanding of the rate algorithm to really specify how this should work. I just want to make sure we don't make  choices now that prevent us from solving that later.

> <Ulrich> this sounds complex to me and is absolutely unnecessary</Ulrich>

I didn't say it had to, I said it could. I think it's a reasonable implementation choice that we should not forbid, but probably also should not require.

> <Ulrich> I did not say "shall forbid" but "should not mandate" </Ulrich>

I think others were arguing for "shall forbid".

> <Ulrich>how can a server receive a realm routed request? I can understand that a server may receive a request that does not contain a Destination-Host AVP, but that's not the definition of realm-ro…

That's actually the point I was trying to make. If a node is a pure server, then by our current definition it never ever receives a realm-routed request. So a prohibition against having it put host-reports in responses to realm-routed requests is both non-constraining and non-sensical.

Now, if a previous hop Agent handled server selection, then it's up to that agent whether to pass through an existing host-report, if the original request had been realm-routed from _its_ perspective.  We should neither require or forbid that.  (And I actually don't think that's specific to realm-routed requests. It's true for all request and report types.)

But if we allow the agent to pass through a host-report, then the client must be prepared to receive it.

> <Ulrich> I don't follow this. Do you mean "from a realm-routed request"?

Yes.

> My interpretation of the definition is that a server will never receive a realm-routed request as the previous direct peer always has the knowledge that the request will go to that server.</Ulrich>

Agreed, so by the time the request gets to the server, it's host routed--even if it may have been previously realm-routed. I think we are proving the routing type to be at least somewhat hop-by-hop.

My main point was that the server has no knowledge that the request might have been realm-routed prior to the agent's peer selection.

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Thu, 11 Sep 2014 08:19:32 +0000

Ben,

See below
Thanks
/MCruz

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]] 
Sent: miércoles, 10 de septiembre de 2014 22:12
To: Maria Cruz Bartolome
Cc: Wiehe, Ulrich (NSN - DE/Munich); [email-masked]; [email-masked]
Subject: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example

If the reacting node never sends a request to that host, then it never cares. No harm done. Bytes on the wire are cheap.
[MCruz] When received by reacting node, it will need to create corresponding OCS, and analyze all traffic against this to determine if any of them is active.
Eventually the client may end up with several of those _never to be used_ OCS, what is far from being effective, in bandwidth, memory and processing.

[MCruz] Why?

[MCruz] Why?

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 11 Sep 2014 09:12:18 +0000

Ben,

you  worte:

I think there in no need for the server to have this knowledge. The server simply puts its host-type OLR in the answer.
The agent that handled server selection receives this OLR and makes use of it for 
a) diverting future realm routed request to other servers and 
b) calculating an aggregated realm overload (taking into account the supported algorithm at the client). 
This aggregated realm-type OLR is sent to the client. 
Open question is whether in addition also the host-type OLR generated by the server is sent to the client. Issues identified so far are:
1. Two OLRs in one answer must use the same algorithm resulting in the need for some kind of OLR conversion from one algorithm to another.
2. Host type OLRs received by the client may easily get out of synch.
3. There is no added value as the client either has no need for the host-type OLR (i.e. never sends host-type requests to the server) or will receive it with the response to the next sent host-type request.
4. There may be negative impact for clients that are forced to maintain OCSs that are never used.

Similar to this is another point recently questiond by JJ:
Whether an agent may insert a realm-type OLR to an answer which corresponds to a host-routed request, and which potentially already contains a host-type OLR. (This would only be possible if the agent supports the algorithm that was negotiated/selected between client and server).
Again I think that there is no added value as the client either has no need for the realm-type OLR (i.e. never sends realm-type requests to the realm) or will receive it with the response to the next sent realm-type request. And again there may be negative impacts for clients.

As a way forward we may think about a way to convey both OLRs in one answer but clearly indicate which OLR is the "real thing" and which is the additional one. It must however be made clear that the additional one can savely be ignored by the reacting node.

Ulrich

-----Original Message-----
From: ext Ben Campbell [mailto:[email-masked]] 
Sent: Wednesday, September 10, 2014 10:35 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: [email-masked]; [email-masked]
Subject: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example

Yes.

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 11 Sep 2014 09:35:50 +0000

Hi Jean-Jacques

It is my understanding that the agent that throttles a request on behalf of a non-DOIC supporting client populates the Origin-Host AVP in the unsuccessful answer with its own Diameter Identity and the Origin-Realm AVP with the realm the agent belongs to. 

This is independend from the request being host-routed or realm-routed. Anyway, the unsuccessful answer (in this case) shall not contain an OLR as
a) the client does not support DOIC and
b) it is not the agent that is overloaded

Can people please confirm.

Best regards
Ulrich 

-----Original Message-----
From: ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES) [mailto:[email-masked]] 
Sent: Wednesday, September 10, 2014 6:18 PM
To: Maria Cruz Bartolome; Wiehe, Ulrich (NSN - DE/Munich); [email-masked]; [email-masked]
Subject: RE: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example

Hi MCruz, Ulrich

Best regards

JJacques 

-----Message d'origine-----

Dear JJ, 

Cheers
/MCruz

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:[email-masked]] 
Sent: martes, 09 de septiembre de 2014 13:16
To: ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES); Maria Cruz Bartolome; [email-masked]; [email-masked]
Subject: RE: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example

Jacques,

See also inline.

Ulrich

-----Original Message-----
From: ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES) [mailto:[email-masked]]
Sent: Tuesday, September 09, 2014 12:48 PM
To: [email-masked]; Wiehe, Ulrich (NSN - DE/Munich); [email-masked]; [email-masked]
Subject: RE: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example

Dear all

Best regards

Jacques    

-----Message d'origine-----

Hi MCruz, Ulrich

Best regards

JJacques 

-----Message d'origine-----

Maria Cruz,

I share your concern.

Best regards
Ulrich

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext dime issue tracker
Sent: Friday, September 05, 2014 9:50 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example

 Proposed modification:

         Client     Agent      S1        S2        S3
            |         |         |         |         |

---

From: Steve Donovan <[email-masked]>
Date: Thu, 11 Sep 2014 08:54:07 -0500

All,

It seems the concern is forcing the client to save OCS state for host 
reports from servers to which the client never sends host routed 
requests.  This, I think, is only an issue for requests that do not 
contain a destination-host AVP.  Please correct me if I'm mistaken.

I think we all agree that the server has no way to differentiate host 
routed requests from realm routed requests in this case, so the solution 
cannot be server based.

That leaves two options:

1) The agent that does the server selection strips the host report for 
these types of transactions.

2) The client ignores host reports for these types of transactions.

Option 2 seems better to me, as it is the client that understands 
whether or not the host reports have value.  For some applications the 
client might never send requests with a destination-host AVP. In this 
case the client can safely ignore the OLRs.  For applications where 
there is a mix of transaction types (host-routed and realm-routed), the 
client might choose to save all OLRs in the interest of better handling 
the overload for the requests that do include the destination-host AVP.

Note that in this type of application, it will still work if the client 
ignores all host reports received on "realm-routed" transactions as the 
client will still receive a host report on host-routed transactions.  
This assumes that all answer messages have the OLR for the duration of 
the overload event.

I suggest wording something like:

A client MAY ignore OLRs of type host received in transactions where the 
request was realm-routed by the client.

    Note: In applications where there is a mix of realm-routed and 
host-routed requests it is recommended that the client save all host 
overload reports.

Regards,

Steve

---

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Thu, 11 Sep 2014 15:44:42 +0000

Hi all

In parallel of Steve,  I have written this hereafter mail related to Ulrich MCruz  and Ben comments and is not taking into account last Steve proposal, but I nevertheless submit it to you as other ways forward proposed.

It is true that the server does not distinguish a request that was realm routed by a DA from other client requests having a Destination Host (so-called host routed). I agree with Ulrich that the server has not the need to make this distinction and it simply sends a host type OLR.      

I also agree that the DA will use this host type OLR to do the a) and b) actions of Ulrich's mail. 

Then for other points:

1) on one side
Ulrich and Mcruz  argue there is no added value to add Host OLRs reports in an answer to realms  request (and  realm  OLRs in answers to Host routed requests), given Host OLRs reports will be present in answers to Host routed (and realm  OLRs in answers to realm requests). 
An additional point is that Host routed request may not go through the DA handling realm requets, so in this case there will not be a realm OLR in the answer.    
This drive to not mandate the host or realms OLRs to be sent in all answers (and the client to not expect to receive OLRs in all answers cf my #70 mail).   I am OK to accept this proposal as in any case the client will receive enough Host OLRs in answers to host routed requests , and enough realm OLRs in answers to realm routed requests so to apply the correct abatement.

2)  on the other side, current text  in draft that Ben and Steve support indicates that, when overload,  reporting nodes must inserts OLRs  in all answers. The argument is that it is a simple way to ensure/guarantee that OLRs are well taken into account by the reacting node, and  that to put a SHOULD may be the source of problems  as some implementations would not observe the should, which  finally would drive to  bad behaviors. As I said in a previous mail, my concern is that the reacting nodes receive enough answers containing the OLR (with same seq number) to secure the right abatement, and I also agree the simple described way in the draft achieves this.
 
3 way forwards to try to find a compromise
- to continue to put a MUST but with some identified exceptions (with a MAY) as in 1) allowing the DA to  remove Host OLRs and put realm OLRs only in answers to realm routed requests. It would not be forbidden to put both OLRs in answers to realm or Host routed request. But do we limit to these exceptions or have we other exceptions to list?
- to put a SHOULD for OLRs in all answers but if not observed to write that the reporting nevertheless MUST ensure that new/updated overload control information is propagated to the reacting nodes with an acceptable delay (this wording is coming from GTP overload control in TS 29.274 where it is not mandated to put new "GTP OLRs" in all messages sent to the target node doing the abatement).
- or to only say that the reporting nevertheless MUST ensure that new/updated overload control information is propagated to the reacting nodes with an acceptable delay. A possible and simple way to achieve this is to put the OLR in all answers. 

Regarding the Ulrich proposal for a way to convey both OLRs in one answer but clearly indicate which OLR is the "real thing" and which is the additional one. Here I do not see why to make this distinction, the two OLRs are valid ones and possible from the piggybacking rule, the Host type OLR referring to the Origin Host of the answer and the Realm type OLR referring to the Origin Realm of the answer. 

Best regards

JJacques

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de Steve Donovan
Envoyé : jeudi 11 septembre 2014 15:54
À : [email-masked]
Objet : Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example

All,

It seems the concern is forcing the client to save OCS state for host reports from servers to which the client never sends host routed requests.  This, I think, is only an issue for requests that do not contain a destination-host AVP.  Please correct me if I'm mistaken.

I think we all agree that the server has no way to differentiate host routed requests from realm routed requests in this case, so the solution cannot be server based.

That leaves two options:

1) The agent that does the server selection strips the host report for these types of transactions.

Option 2 seems better to me, as it is the client that understands whether or not the host reports have value.  For some applications the client might never send requests with a destination-host AVP. In this case the client can safely ignore the OLRs.  For applications where there is a mix of transaction types (host-routed and realm-routed), the client might choose to save all OLRs in the interest of better handling the overload for the requests that do include the destination-host AVP.

Note that in this type of application, it will still work if the client ignores all host reports received on "realm-routed" transactions as the client will still receive a host report on host-routed transactions.  
This assumes that all answer messages have the OLR for the duration of the overload event.

A client MAY ignore OLRs of type host received in transactions where the request was realm-routed by the client.

    Note: In applications where there is a mix of realm-routed and host-routed requests it is recommended that the client save all host overload reports.

Regards,

Steve

On 9/11/14, 4:12 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>> Cc: ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES); 
>> [email-masked]; [email-masked]; 
>> [email-masked]
>> In addition, are you proposing that the agent may translate the rate 
>> based host-type OLR received from S1 into a loss based host type OLR 
>> and forward it to the client?</Ulrich>
>> However, if we allow an agent to translate a received host type OLR 
>> of "rate" into a sent host type OLR of "loss" we may end up in 
>> situations where the client receices out of sync OLRs from different 
>> agents on different paths between client and server.</Ulrich>
>> The agent has to ensure that any OLRs that get back to the client 
>> match the capabilities the client advertised, and received. It could 
>> do that by stripping all OC-S-F and OLR avps in answers <Ulrich>I agree</Ulrich> , or it could act as as an algorithm "gateway" and (statefully) translate between the capabilities selected on either side.
>> <Ulrich>how can a server receive a realm routed request? I can 
>> understand that a server may receive a request that does not contain 
>> a Destination-Host AVP, but that's not the definition of realm-routed 
>> request</Ulrich>
> Now, if a previous hop Agent handled server selection, then it's up to 
> that agent whether to pass through an existing host-report, if the 
> original request had been realm-routed from _its_ perspective.  We 
> should neither require or forbid that.  (And I actually don't think 
> that's specific to realm-routed requests. It's true for all request 
> and report types.)
>
>> My interpretation of the definition is that a server will never 
>> receive a realm-routed request as the previous direct peer always has 
>> the knowledge that the request will go to that server.</Ulrich>

---

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Fri, 12 Sep 2014 06:48:10 +0000

Hi Ulrich 

Effectively there is a logic for the DA generating the unsuccessful answer (which will not contain any OLR as Ulrich reminded) to put its own Diameter identity (host and realm)as Origin Host /Realm. There is a small difference with the existing (when no DOIC at all) case, where a DA may also try to redirect an unsuccessful request to other servers, and if the last  one also rejects the request, it would normally be the Origin Host Realm  of the last server that DA will send back to the existing client. I would  not think this difference has particular consequences for the existing client. 

Best regards

JJacques 

-----Message d'origine-----
De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:[email-masked]] 
Envoyé : jeudi 11 septembre 2014 11:36
À : TROTTIN, JEAN-JACQUES (JEAN-JACQUES); Maria Cruz Bartolome; [email-masked]; [email-masked]
Objet : RE: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example

Hi Jean-Jacques

Best regards
Ulrich 

-----Original Message-----
From: ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES) [mailto:[email-masked]]
Sent: Wednesday, September 10, 2014 6:18 PM
To: Maria Cruz Bartolome; Wiehe, Ulrich (NSN - DE/Munich); [email-masked]; [email-masked]
Subject: RE: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example

Hi MCruz, Ulrich

Best regards

JJacques 

-----Message d'origine-----
De : Maria Cruz Bartolome [mailto:[email-masked]]
Envoyé : mercredi 10 septembre 2014 15:59 À : Wiehe, Ulrich (NSN - DE/Munich); TROTTIN, JEAN-JACQUES (JEAN-JACQUES); [email-masked]; [email-masked]
Objet : RE: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example

Dear JJ,

Cheers
/MCruz

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:[email-masked]]
Sent: martes, 09 de septiembre de 2014 13:16
To: ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES); Maria Cruz Bartolome; [email-masked]; [email-masked]
Subject: RE: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example

Jacques,

See also inline.

Ulrich

-----Original Message-----
From: ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES) [mailto:[email-masked]]
Sent: Tuesday, September 09, 2014 12:48 PM
To: [email-masked]; Wiehe, Ulrich (NSN - DE/Munich); [email-masked]; [email-masked]
Subject: RE: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example

Dear all

Best regards

Jacques    

-----Message d'origine-----

Hi MCruz, Ulrich

Best regards

JJacques 

-----Message d'origine-----

Maria Cruz,

I share your concern.

Best regards
Ulrich

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext dime issue tracker
Sent: Friday, September 05, 2014 9:50 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example

 Proposed modification:

         Client     Agent      S1        S2        S3
            |         |         |         |         |

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 12 Sep 2014 09:53:53 +0000

Steve,

please see inline.

Ulrich

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext Steve Donovan
Sent: Thursday, September 11, 2014 3:54 PM
To: [email-masked]
Subject: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example

All,

<Ulrich>
I listed 4 issues (see below). You address only half of issue 4.
The other half is forcing the client to save OCS state for realm reports
from agents (realms) to which the client never sends realm routed requests.
</Ulrich>

That leaves two options:

<Ulrich>
I agree that these are the options when the request was realm-routed.
When the request was host routed the options are

1') The agent does not insert a realm report to an answer forwarded
from server to client

2') The agent inserts a realm report and the client ignores it.

At least we should allow option 1 (and 1'); or are there any issues
with this option? Whether or not to allow option 2 (and 2') needs to be
discussed, as there are issues.
</Ulrich>

Option 2 seems better to me, as it is the client that understands 
whether or not the host reports have value.

<Ulrich>
host reports in answers that correspond to realm-routed requests
never have added value. Similarly, realm reports in answer messages that 
correspond to host-routed requestsnever have added value. See issue 3 below.
</Ulrich>

  For some applications the 

<Ulrich>
What do you mean with "better handling"?
</Ulrich>

<Ulrich>
ok, but also: 
"A client MAY ignore OLRs of type realm received in transactions where the
request was host-routed by the client."
(And maybe replace "client" with "reacting node")
</Ulrich>

<Ulrich>
I would like to see all issues solved before recommending so.
</Ulrich>
Regards,

Steve

---

From: Steve Donovan <[email-masked]>
Date: Mon, 15 Sep 2014 10:17:37 -0500

Ulrich,

I was suggesting that the client is the best to understand if there is 
value in a specific OLR and, if the client knows that it will never have 
a request that is impacted by the overload report then it can choose to 
not save OCS related to the OLR.

>> 1. Two OLRs in one answer must use the same algorithm resulting in the need for some kind of OLR conversion from one algorithm to another.
SRD> I don't understand the issue.  Both reports would be for the loss 
algorithm.  How agents handle interaction between loss and future 
algorithms like rate is a separate question.
>> 2. Host type OLRs received by the client may easily get out of synch.
SRD> Can you explain this.  How can host OLRs get out of sync?
>> 3. There is no added value as the client either has no need for the host-type OLR (i.e. never sends host-type requests to the server) or will receive it with the response to the next sent host-typ…
SRD> If the client never sends to the reporting node then it can ignore 
the OLR.  If it does send to the reporting node then it should start 
applying the overload report, independent of the type of transaction 
used to receive the OLR.
>> 4. There may be negative impact for clients that are forced to maintain OCSs that are never used.
SRD> Are there negative impacts other than the state it needs to save?

Regards,

Steve

---

From: Steve Donovan <[email-masked]>
Date: Mon, 15 Sep 2014 10:31:50 -0500

Ulrich,

A few more comments inline.

Steve

> 2') The agent inserts a realm report and the client ignores it.
SRD> There are scenarios where realm reports cannot be used. 
Partitioning of the server space is the primary example.  As such, we 
need to make sure we aren't designing a solution that depends on realm 
reports.  That's not saying that realm reports don't have value, just 
that they can't always be used.
> discussed, as there are issues.
SRD> I disagree with allowing 1.  The only time that an agent should 
strip a host report is when it knows it is the reacting node host-routed 
requests.
> correspond to host-routed requestsnever have added value. See issue 3 below.
SRD> How is it not good for a client to know about the fact that a 
server is overloaded?  How is it not good for a client to know that a 
realm is overloaded?  There is clear value for both cases, as the sooner 
a client learns about overload of a server or realm to which it sends 
requests the sooner the overload condition will be abated.

SRD> There might be times when an OLR isn't useful to a client/reacting 
node.  I disagree with the assertion that there is never added value.
> What do you mean with "better handling"?
SRD> I mean that the sooner a reacting node learns about an overload 
condition the sooner the overload condition can be properly handled.
> (And maybe replace "client" with "reacting node")
SRD> Yes, it should say reacting node.
> I would like to see all issues solved before recommending so.
SRD> I don't understand issues 1 and 2.  I think my proposal addresses 
issues 3 and 4.

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Thu, 25 Sep 2014 16:01:38 +0000

Dear Ulrich, Steve, JJ,

I think Ulrich summarized this discussion very clearly and even proposed a way forward as a compromise. I agree with his argumentations and with the proposal.

I only do not understand issue 2 (Host type OLRs received by the client may easily get out of synch), I would appreciate some clarification.

>> 4. There may be negative impact for clients that are forced to maintain OCSs that are never used.

Steve, you mentioned your proposal focusses on 3 and 4, could you explain it further?
Best regards
/MCruz

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Steve Donovan
Sent: lunes, 15 de septiembre de 2014 17:32
To: Wiehe, Ulrich (NSN - DE/Munich); [email-masked]
Subject: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example

Ulrich,

Steve

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 26 Sep 2014 06:57:28 +0000

Dear Maria Cruz,

thank you for your support.

With regard to issue 2 I was thinking of e.g.the following configuration:

+---+                                          +---+
|   |------------------------------------------|   |
| C |            +---+                         | S | 
|   |------------| A |-------------------------|   |
+---+            +---+                         +---+  |
 
C supports loss
A supports loss and rate
S supports loss and rate

1. for a host routed request from C to S (that possibly does not transit A (and if so, A would be transparent with regard to OC-AVPs)), S would send a host type OLR for loss to C.
2. for a realm routed request sent from C to A where A then selects S, S would send a host type OLR of rate to A and A would send a realm type OLR of loss to C.

I hope this is not contentious so far.

The open question is whether the answer send from A to C which contains the realm type OLR of loss must also contain a host type OLR. It seems clear that A cannot just transparently forward the received host type OLR of rate to C as C does not support rate. It has then been proposed that A would somehow calculate a host type OLR of loss on behalf of S and insert it into the anser sent from A to C. 
This means that C in step 1 receives a host type OLR of loss from S and in step 2 C receives a host type OLR of loss from S (actually from A on behalf of S, but C cannot know), and these two OLRs cannot easily be in sync.   

Best regards
Ulrich

-----Original Message-----
From: ext Maria Cruz Bartolome [mailto:[email-masked]] 
Sent: Thursday, September 25, 2014 6:02 PM
To: Steve Donovan; Wiehe, Ulrich (NSN - DE/Munich); [email-masked]
Subject: RE: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example

Dear Ulrich, Steve, JJ,

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Steve Donovan
Sent: lunes, 15 de septiembre de 2014 17:32
To: Wiehe, Ulrich (NSN - DE/Munich); [email-masked]
Subject: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example

Ulrich,

Steve

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Fri, 26 Sep 2014 08:00:14 +0000

Dear Ulrich,

Therefore, issue 2 is a consequence of 1. In case there is not a need for conversion, I presume this out of synch situation is avoided.
Thanks for the explanation.
Cheers
/MCruz

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:[email-masked]] 
Sent: viernes, 26 de septiembre de 2014 8:57
To: Maria Cruz Bartolome; Steve Donovan; [email-masked]
Subject: RE: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example

Dear Maria Cruz,

+---+                                          +---+
 
C supports loss
A supports loss and rate
S supports loss and rate

Best regards
Ulrich

-----Original Message-----
From: ext Maria Cruz Bartolome [mailto:[email-masked]]
Sent: Thursday, September 25, 2014 6:02 PM
To: Steve Donovan; Wiehe, Ulrich (NSN - DE/Munich); [email-masked]
Subject: RE: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example

Dear Ulrich, Steve, JJ,

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Steve Donovan
Sent: lunes, 15 de septiembre de 2014 17:32
To: Wiehe, Ulrich (NSN - DE/Munich); [email-masked]
Subject: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example

Ulrich,

Steve

On 9/12/14, 4:53 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> The other half is forcing the client to save OCS state for realm 
> reports from agents (realms) to which the client never sends realm routed requests.
> </Ulrich>
>
> routed requests from realm routed requests in this case, so the 
> solution cannot be server based.
>
> That leaves two options:
>
SRD> There are scenarios where realm reports cannot be used. 
Partitioning of the server space is the primary example.  As such, we need to make sure we aren't designing a solution that depends on realm reports.  That's not saying that realm reports don't have value, just that they can't always be used.
> with this option? Whether or not to allow option 2 (and 2') needs to 
> be discussed, as there are issues.
> </Ulrich>
SRD> I disagree with allowing 1.  The only time that an agent should
strip a host report is when it knows it is the reacting node host-routed requests.
> host reports in answers that correspond to realm-routed requests never 
> have added value. Similarly, realm reports in answer messages that 
SRD> How is it not good for a client to know about the fact that a
server is overloaded?  How is it not good for a client to know that a realm is overloaded?  There is clear value for both cases, as the sooner a client learns about overload of a server or realm to which it sends requests the sooner the overload condition will be abated.

> there is a mix of transaction types (host-routed and realm-routed), 
> the client might choose to save all OLRs in the interest of better 
> handling the overload for the requests that do include the destination-host AVP.
>
> <Ulrich>
>
> Note that in this type of application, it will still work if the 
> client ignores all host reports received on "realm-routed" 
> transactions as the client will still receive a host report on host-routed transactions.
> A client MAY ignore OLRs of type host received in transactions where 
> the request was realm-routed by the client.
>
> <Ulrich>
> ok, but also:
> "A client MAY ignore OLRs of type realm received in transactions where 
> the request was host-routed by the client."
> (And maybe replace "client" with "reacting node") </Ulrich>
>>> a Destination-Host AVP, but that's not the definition of 
>>> realm-routed request</Ulrich>
>> Now, if a previous hop Agent handled server selection, then it's up 
>> to that agent whether to pass through an existing host-report, if the 
>>> receive a realm-routed request as the previous direct peer always 
>>> has the knowledge that the request will go to that server.</Ulrich>