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

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 1 Oct 2014 08:38:39 +0000

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

---

From: Steve Donovan <[email-masked]>
Date: Wed, 01 Oct 2014 08:27:49 -0500

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

---

From: Steve Donovan <[email-masked]>
Date: Wed, 01 Oct 2014 08:33:57 -0500

Ulrich,

I'm ok with your proposed wording for step 4 in the diagram that the 
agent MAY removed the host overload report.  I just don't think it 
should be a MUST.

Regards,

Steve

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 2 Oct 2014 08:31:04 +0000

Steve,

please see inline.

Ulrich

-----Original Message-----
From: ext Steve Donovan [mailto:[email-masked]] 
Sent: Wednesday, October 01, 2014 3:28 PM
To: Wiehe, Ulrich (NSN - DE/Munich); [email-masked]
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> 

<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

---

From: Ben Campbell <[email-masked]>
Date: Fri, 3 Oct 2014 16:09:42 -0500

One comment inline.

> agent to strip host type OLRs. </Ulrich>

Steve sent in a separate email that he would be okay saying that an agent MAY strip the host report. Do I read this comment correctly to mean that you agree with that? (I would also be okay with a MAY, but would oppose anything stronger.)

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 6 Oct 2014 09:33:03 +0000

Ben,

yes, the agent that takes the role of the reporting node for realm reports MAY strip host reports. This is independent from whether or not the realm is actually overloaded (i.e. whether or not a realm report is actually sent).

Actually I am more concerned with complexity at the client side.

Ideally I would like to see a solution where the client (which does not support any extension) is not required to do more than just processing the first OLR within an answer, and may safely ignore additional OLRs. This would mean that the agent that takes the option not to strip the host report must insert its realm report (if any) before the host report.
I hope that is acceptable.

Ulrich

-----Original Message-----
From: ext Ben Campbell [mailto:[email-masked]] 
Sent: Friday, October 03, 2014 11:10 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: ext Steve Donovan; [email-masked]
Subject: Re: [Dime] DOIC #70 - Proposed resolution to core issue

One comment inline.