Re: [Dime] DOIC #70

Steve,

please see inline.

Ulrich

-----Original Message-----
From: ext Steve Donovan [mailto:srdonovan@usdonovans.com] 
Sent: Wednesday, October 01, 2014 3:28 PM
To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
Subject: Re: [Dime] DOIC #70 - Proposed resolution to core issue

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.
<Ulrich> yes that was the original proposal; however during discussion
 we came up with a compromise that allows (rather than mandates) the
 agent to strip host type OLRs. </Ulrich>
  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.
<Ulrich> still valid. </Ulrich>

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.
<Ulrich> saving is not in logic to be implemented but in processing
 to be performed. This brings me to another (but related) issue: When
 receiving an answer the client (that supports DOIC without extensions)
 must be prepared to find lots of OC-OLR AVPs in the answer. The client
 needs to check every single OLR to see whether it is valid (sequence-
 number) and supported (report-type). If neither valid nor supported
 the OLR is silently discarded. An optimization for processing to be
 performed by the client would be to a) prohibit nodes to send OLRs to
 clients which the clients do not support, and b) allow clients that
 do not support any extension to check only the first OLR and silently
 discard all other received OLRs.</Ulrich> 

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.
<Ulrich> I do not think ist a good idea to spam the client with useless
 Information </Ulrich>

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."
<Ulrich> ...should save all... is ok (for all received valid and
 supported OLRs), but then ...may silently discard subsequent (i.e. all
 except the first) OLRs. Agents that add realm-type OLRs must add them
 before the non stripped host-type OLR; nodes that add extension-type
 OLRs must not add them before host-type or realm-type OLRs </Ulrich>  

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:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
> Sent: Tuesday, September 30, 2014 4:44 PM
> To: dime@ietf.org
> 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
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime