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

[Steve Donovan <[e-mail]>]

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

On 9/11/14, 4:12 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> Ben,
>
> you  worte:
> 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.
>
> 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:[e-mail]]
> Sent: Wednesday, September 10, 2014 10:35 PM
> To: Wiehe, Ulrich (NSN - DE/Munich)
> Cc: [e-mail]; [e-mail]
> Subject: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example
>
>
> On Sep 10, 2014, at 9:09 AM, Wiehe, Ulrich (NSN - DE/Munich) <[e-mail]> wrote:
>
>> 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.
> 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.
>
>
>>> 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>
> 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.
>
>>> 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 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.
>
>>> 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>
> I think others were arguing for "shall forbid".
>
>> 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>
> 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.
>
>
>> 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"?
> 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.
>
> _______________________________________________
> DiME mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dime
>