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

["Wiehe, Ulrich (NSN - DE/Munich)" <[e-mail]>]

Ben,

please see comments inline.

Ulrich

-----Original Message-----
From: ext Ben Campbell [mailto:[e-mail]] 
Sent: Wednesday, September 10, 2014 4:38 AM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES); [e-mail]; [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.
<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>

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

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

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>