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

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

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:[e-mail]] 
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; [e-mail]; [e-mail]
Subject: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example

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

Comments inline:

On Sep 9, 2014, at 5:57 AM, Wiehe, Ulrich (NSN - DE/Munich) <[e-mail]> wrote:

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

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 answer "use loss for realm routed requests and rate for host routed requests"

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 answer that corresponds to a realm type request.

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.