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

Ben,

See below
Thanks
/MCruz

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

On Sep 10, 2014, at 9:02 AM, Maria Cruz Bartolome <maria.cruz.bartolome@ericsson.com> wrote:

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

> 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. 
[MCruz] Why?

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.
[MCruz] Why?

> 
> Regards
> /MCruz
> 
> -----Original Message-----
> From: Ben Campbell [mailto:ben@nostrum.com] 
> 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; dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org
> 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) <ulrich.wiehe@nsn.com> 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.
> 
> 
> 
> 
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime