Re: [Dime] DOIC #70 - Proposed resolution to core issue

[Steve Donovan <[e-mail]>]

Ulrich,

Yes, but the proposed resolution for #70 is that a DOIC supporting agent 
strip host overload reports from requests that did not have a 
destination-host AVP.  The justification for this has been that the 
client might not send to the host and that would cause the client to 
save extra OCS entries.

The client will need to be prepared to handle overload state received in 
this type of a request when there is not a DOIC supporting agent, so 
there is no savings in logic to be implemented in the client by having 
DOIC agents strip host reports.

In addition, the client is the best place to determine if a host report 
is useful or not.  In the many cases the client will send subsequent 
host reports to the server.  This will be the case in many session based 
applications where the first request is realm-routed and subsequent 
requests are sent to the server that handled the session initiating 
transaction.

I'm ok with adding wording to the specification along the lines of "the 
client SHOULD save the OCS state for all received host overload 
reports.  The client MAY not save the state if it knows that it will 
never send a host-routed request to the server.   This might be the 
case, for instance, when the client always sends realm-routed request 
for the application."

Regards,

Steve

On 10/1/14, 3:38 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> Steve,
>
> I agree that there may be cases where the agent that selects the server does not support DOIC, and consequently transparently forwards a host-type OLR to the client which then receives a host-type OLR in response to a realm-type request.
>
> The example flow in Appendix B, however, assumes that the agent supports DOIC.
>
> Please find the proposed modification attached.
>
> Ulrich
>
>
> -----Original Message-----
> From: DiME [mailto:[e-mail]] On Behalf Of ext Steve Donovan
> Sent: Tuesday, September 30, 2014 4:44 PM
> To: [e-mail]
> Subject: [Dime] DOIC #70 - Proposed resolution to core issue
>
> All,
>
> The core issue raised in issue #70 is whether a client can receive an
> OLR of type host when the request sent by the client was realm routed.
>
> I do not support the suggested change as there are scenarios where
> clients MUST be prepared to receive the OLR of type host when the client
> does not do server selection.  This is required for the scenario where
> agents do not support DOIC.  If the request does not contain a
> Destination-Host AVP then agents will be responsible for server
> selection.   An overloaded server will send an OLR of type host that
> will find its way back to the client.
>
> It is true that this might cause unneeded OCS entries in the client in a
> scenario where the client will never do server selection for that
> overloaded server.  This concern can be addressed by making it up to
> local policy whether or not the client saves OCS for the overload
> report.  If the client knows that it will never do server selection for
> a server indicated in a host OLR then the client can choose to not save
> the overload report.
>
> Based on this, I propose that we close issue #70 without changes to the
> DOIC specification.
>
> The discussion about the handling of a mix of overload abatement
> algorithms should continue.  We can open a separate issue if needed to
> address that functionality.
>
> Regards,
>
> Steve
>
> _______________________________________________
> DiME mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dime