Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysis

[Steve Donovan <[e-mail]>]

All,

My recommendation on this alternative 1 as it give operators the ability 
to discover when there is an issue associated with "Origin-Host Munging" 
agents.  The operators can then take any administrative action necessary 
to fix the issue.  It is also a more general solution that does not rely 
on one industries interop procedures.

If we can get agreement on this then we can start making progress on the 
remainder of the document.

Steve

On 8/12/14, 3:05 PM, Steve Donovan wrote:
> Are there other thoughts on the pros and cons of the three proposals 
> for resolution of issue #66?
>
> Steve
>
> On 8/8/14, 1:43 PM, Ben Campbell wrote:
>> On Aug 8, 2014, at 9:48 AM, Steve Donovan <[e-mail]> 
>> wrote:
>>
>>> All,
>>>
>>> The issue with pre-DOIC agents changing origin-host was been 
>>> discussed in this thread:
>>>
>>> http://www.ietf.org/mail-archive/web/dime/current/msg07618.html
>>>
>>> One example of the impact of the issue is defined in this message:
>>>
>>> http://www.ietf.org/mail-archive/web/dime/current/msg07660.html
>>>
>>> So far three solutions have been discussed for this issue:
>>>
>>> 1) Attribution of overload reports.
>>>   - Add diameter-id of the node that is overloaded into the OC-OLR AVP.
>>>   - Reacting node always uses the diameter-id in the OC-OLR report 
>>> when applying abatement algorithm logic.
>>>   - Reacting node detects when there is a difference between the 
>>> diameter-id in the OC-OLR report and in the Origin-Host AVP.  When 
>>> there is a difference, the reacting node should report on the 
>>> condition (event/alarm).  Local policy would determine if the 
>>> reacting node honors the overload report or ignores the overload 
>>> report.
>> I think the last entry is worth further discussion, but it's probably 
>> more important to make a high level decision first. But, at risk of 
>> getting ahead of myself: I have trouble imagining a situation where 
>> honoring the overload report will be harmful, since if there is an 
>> intervening OHMA, the reacting node will not likely have any 
>> host-routed requests to the diameter-id from the OLR. OTOH, I have 
>> trouble imagining where honoring the report would be useful, for the 
>> same reason.
>>
>>> 2) Configuration in operator's networks to turn off origin-host 
>>> munging behavior until the agent is upgraded to support DOIC.
>>>
>>> 3) Configuration of reporting nodes to not send overload reports, 
>>> either universally or for transactions that cross the origin-host 
>>> munging agent.
>>>
>>> I've compiled a starting point for a pros and cons analysis of the 
>>> three approaches.
>>>
>>> Regards,
>>>
>>> Steve
>>>
>>> ---------
>>>
>>> Option 1 Pros:
>>> ------------
>>> - Gives operators a mechanism to detect when there is a non-DOIC 
>>> origin-host-munging agent in the path of a transaction.
>>> - Gives operators ability to manage the under utilization issue 
>>> caused by the non-DOIC agent.
>>> - Gives operators the ability to keep features requiring origin-host 
>>> munging turned on while DOIC is rolled out.
>>> - Leaves the determination of which action to take in this scenario 
>>> (honor or ignore overload reports) to operator policy.
>>> - Addresses RFC 7068 requirement #6 on minimizing the amount of 
>>> configuration required.
>>> - Addresses RFC 7068 requirement #12 on minimizing the impact of a 
>>> single node overload on the traffic handled by other nodes in the 
>>> network.
>>> - Addresses RFC 7068 requirement #17 on minimizing the impact of 
>>> overload in a mixed DOIC environment on the overall capacity of the 
>>> network.
>> Specifically, it complies with the MUST NOT make things worth clause, 
>> but does not comply with the SHOULD reduce overload clause.
>>
>>> Option 1 Cons:
>>> -------------
>>> - Requires additional protocol machinery (minimal)
>>> - Does not completely fix the effects of non-DOIC agent on overload 
>>> control
>> One additional con is that, if the OHMA is there for the purposes of 
>> true topology hiding, the identity in the OLR may leak topology 
>> information.
>>
>>> Option 2 Pros:
>>> ------------
>>> - Does not require additional protocol machinery
>>> - Does the best job of three alternatives in allowing for management 
>>> of overload conditions
>>>
>>> Option 2 Cons:
>>> ------------
>>> - Requires the operator to lose any functionality enabled by the 
>>> non-DOIC agent until all agents have been upgraded to support DOIC
>>> - Requires extra configuration (against requirement #6)
>>> - There is not way to determine if all non-DOIC origin-host munging 
>>> behavior has been turned off until an overload event happens, with 
>>> potential to have significant negative effects until the offending 
>>> agent can be found and the behavior turned off.
>>> - Not always possible, as operator doesn't always have control over 
>>> non-DOIC agent as it might be in another operators network. Proposal 
>>> to address this through interop agreements but while this might work 
>>> in 3GPP scenarios, not all Diameter deployments are 3GPP driven.
>> Since you mentioned the 7068 requirements in the cons for option 1, 
>> it makes sense to mention them for others. This one misses on 6, but 
>> seems okay for 12 and 17.  (I guess we should have had a requirement 
>> about not interfering with existing network features. If we had that, 
>> Option 2 would not comply.)
>>
>>> Option 3 Pros:
>>> ------------
>>> - Does not require additional protocol machinery
>>> - Gives operators the ability to keep features requiring origin-host 
>>> munging turned on while DOIC is rolled out.
>> For very limited definitions of "rolled out."
>>
>>> Option 3 Cons:
>>> ------------
>>> - Requires extra configuration (against requirement #6)
>>> - Likely requires extra development in the reporting node that would 
>>> not otherwise be needed (ability to limit where overload reports are 
>>> sent)
>>> - Not necessarily easy to determine in advance where which requests 
>>> will traverse a the non-DOIC agent
>>> - Limits ability of operator to fully control overload
>>>
>> Seems to miss req 6 even worse than for option 2. Misses 17 in a 
>> similar way as option 1.  Partially misses 34.
>>
>>
>
> _______________________________________________
> DiME mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dime
>