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

[Steve Donovan <[e-mail]>]

Ulrich,

I was suggesting that the client is the best to understand if there is 
value in a specific OLR and, if the client knows that it will never have 
a request that is impacted by the overload report then it can choose to 
not save OCS related to the OLR.

On your four points, more comments below:


>> 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.
SRD> I don't understand the issue.  Both reports would be for the loss 
algorithm.  How agents handle interaction between loss and future 
algorithms like rate is a separate question.
>> 2. Host type OLRs received by the client may easily get out of synch.
SRD> Can you explain this.  How can host OLRs get out of sync?
>> 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.
SRD> If the client never sends to the reporting node then it can ignore 
the OLR.  If it does send to the reporting node then it should start 
applying the overload report, independent of the type of transaction 
used to receive the OLR.
>> 4. There may be negative impact for clients that are forced to maintain OCSs that are never used.
SRD> Are there negative impacts other than the state it needs to save?

Regards,

Steve