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

From: Steve Donovan <[email-masked]>
Date: Fri, 08 Aug 2014 09:48:25 -0500

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.

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.

Option 1 Cons:
-------------
- Requires additional protocol machinery (minimal)
- Does not completely fix the effects of non-DOIC agent on overload control

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.

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.

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

---

From: Ben Campbell <[email-masked]>
Date: Fri, 8 Aug 2014 13:43:02 -0500

On Aug 8, 2014, at 9:48 AM, Steve Donovan <[email-masked]> wrote:

> All,
> 
> The issue with pre-DOIC agents changing origin-host was been discussed in this thread:
> 
>  - 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:

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.

> - 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
> - 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.)

> - 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."

> - 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

Seems to miss req 6 even worse than for option 2. Misses 17 in a similar way as option 1.  Partially misses 34.

---

From: Steve Donovan <[email-masked]>
Date: Tue, 12 Aug 2014 15:05:07 -0500

Are there other thoughts on the pros and cons of the three proposals for 
resolution of issue #66?

Steve

---

From: Steve Donovan <[email-masked]>
Date: Mon, 18 Aug 2014 17:01:29 -0500

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
>
>>> 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.
>>>
>> Specifically, it complies with the MUST NOT make things worth clause, 
>> but does not comply with the SHOULD reduce overload clause.
>>
>>> Option 1 Cons:
>>> -------------
>> 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:
>>> ------------
>>> potential to have significant negative effects until the offending 
>>> agent can be found and the behavior turned off.
>>> 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:
>>> ------------
>>> - Likely requires extra development in the reporting node that would 
>>> not otherwise be needed (ability to limit where overload reports are 
>>> sent)
>> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime
>

---

From: Ben Campbell <[email-masked]>
Date: Mon, 18 Aug 2014 20:42:24 -0500

I support Alternative 1, but I'm not sure it's a complete solution.

As Nirav pointed out, it has the potential to leak topology information past a topology hiding proxy. (Unless we can come up with some attribution scheme that is not based on Diameter Identity or IP Address.) It may be reasonable, to do this, but we would need some guidance to warn operators that this may happen if they enable DOIC across a non-supporting, topology-hiding proxy. It would become the operator's choice to decide which is more important.

The part I find unsatisfying, is what would happen if you had some paths that supported DOIC (or did not do topology hiding), and some paths that don't support DOIC also do topology hiding. This could become a pretty big administrative hit, and violates the spirit and letter of our requirement to avoid adding lots of configuration work.

OTOH, if we had a mechanism where servers could detect the existence of a non-DOIC, topology-hiding proxy, this could be at least partially automated. I can think of multiple ways we could make it possible to tell if an immediate peer supports DOIC, but not so much for non-adjacent nodes.

On Aug 18, 2014, at 5:01 PM, Steve Donovan <[email-masked]> wrote:

> 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
> 
>> Are there other thoughts on the pros and cons of the three proposals for resolution of issue #66?
>> 
>> Steve
>>

---

From: <[email-masked]>
Date: Tue, 19 Aug 2014 09:48:46 +0000

Because a a gent modifying the Origin-host can only be a proxy and a proxy is by definition compliant with the application supporting the new OLR-related AVPs, everything else is out of scope of the standardization. Moreover, the real added-value of the addition of the diameter-id in the OLR does not seem so clear. Finally, we have agreed that the basic mechanism proposed in the draft may not cover all the use cases (existing or future) and can be enhanced if required, with or without the need for a IETF standard action.

For all these reasons, I would recommend not to add this Diameter-id in the OLR and to assume that the Origin-host is not changed by agent in the path of the Diameter messages. Some extra text could also be added to clarify that proxies modifying the Origin-host would have to be upgraded to manage consistently the OLR received in Diameter application messages.

Regards,

Lionel

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de Ben Campbell
Envoyé : mardi 19 août 2014 03:42
À : Steve Donovan
Cc : [email-masked]
Objet : Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysis

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Steve Donovan <[email-masked]>
Date: Tue, 19 Aug 2014 06:41:05 -0500

Lionel,

There are two primary reasons that I think option 1 is important:

1) This scenario can result in significant under utilization of 
resources, to the extreme of completely shutting down all traffic to the 
servers behind the Origin-Host Munging Agent (OHMA).

2) It gives operates a way to detect the unplanned or forgotten instance 
of the OHMA.

Being able to prevent number 1 is enough reason for me to add the very 
small amount of additional protocol machinery we are talking about.

More inline.

Steve

On 8/19/14, 4:48 AM, [email-masked] wrote:
> Because a a gent modifying the Origin-host can only be a proxy and a proxy is by definition compliant with the application supporting the new OLR-related AVPs, everything else is out of scope of the standardization.
SRD> I don't understand this argument.  It is perfectly valid for a 
client or server to advertise support for an application and not also 
support DOIC.  Why do you imply that it would be different for an agent?
> Moreover, the real added-value of the addition of the diameter-id in the OLR does not seem so clear.
SRD> See above.
> Finally, we have agreed that the basic mechanism proposed in the draft may not cover all the use cases (existing or future) and can be enhanced if required, with or without the need for a IETF standard action.
SRD> The reasons so far for deferring functionality was because it would 
add risk to the schedule for finishing the core DOIC solution.  That is 
not the case here.  We have a very small change to the specification 
that  addresses multiple requirements.

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Tue, 19 Aug 2014 13:17:53 +0000

Steve,

I agree, this is worth protecting against.

Regards,

Martin 

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Steve Donovan
Sent: Monday, August 18, 2014 6:01 PM
To: [email-masked]
Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysis

All,

Steve

---

From: <[email-masked]>
Date: Tue, 19 Aug 2014 13:40:51 +0000

Hi Steve,

See below.

Regards,

Lionel

-----Message d'origine-----
De : Steve Donovan [mailto:[email-masked]] 
Envoyé : mardi 19 août 2014 13:41
À : MORAND Lionel IMT/OLN; Ben Campbell
Cc : [email-masked]
Objet : Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysis

Lionel,

1) This scenario can result in significant under utilization of resources, to the extreme of completely shutting down all traffic to the servers behind the Origin-Host Munging Agent (OHMA).

2) It gives operates a way to detect the unplanned or forgotten instance of the OHMA.

Being able to prevent number 1 is enough reason for me to add the very small amount of additional protocol machinery we are talking about.

[LM] And I disagree.

More inline.
[LM] same

Steve

SRD> I don't understand this argument.  It is perfectly valid for a
client or server to advertise support for an application and not also support DOIC.  Why do you imply that it would be different for an agent?
[LM] A proxy that would modify the origin-host without taking into account the possible use of this origin-host at the application would be a badly-designed proxy and should not be used in operational network.

> Moreover, the real added-value of the addition of the diameter-id in the OLR does not seem so clear.
SRD> See above.
[LM] still unclear

SRD> The reasons so far for deferring functionality was because it would
add risk to the schedule for finishing the core DOIC solution.  That is not the case here.  We have a very small change to the specification that  addresses multiple requirements.
[LM] is there any clear description of what will be the use of this info by the reacting node? if the proxy replaces the origin-host A by origin-host B, the Diameter nodes receiving the answers will "see" B as sender of the answer and will use this id when sending new requests with origin-host AVP. So can you remind me how exactly the reacting node will use the Diameter-id received in the OLR?

> Envoyé : mardi 19 août 2014 03:42 À : Steve Donovan Cc : [email-masked] 
>>>> 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:
>>>>> ------------
>>>>> - 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
> ______________________________________________________________________
> ___________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, 
> exploites ou copies sans autorisation. Si vous avez recu ce message 
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or 
> privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.

---

From: Steve Donovan <[email-masked]>
Date: Tue, 19 Aug 2014 09:45:32 -0500

Lionel,

More inline.

Steve

> [LM] A proxy that would modify the origin-host without taking into account the possible use of this origin-host at the application would be a badly-designed proxy and should not be used in operatio…
SRD2> Consider the following timeline:

Date - Event:

Sometime in 2011 - Operator installs an agent to do topology hiding or 
load balancing or some other function and the agent modifies the 
origin-host AVP as part of its logic.  In 2011 this works perfectly well 
for all applications handled by the agent.

Sometime in 2015 - The IETF publishes the DOIC specification.

Are you asserting that the agent deployed in 2011 was badly designed 
because it did not anticipate the DOIC solution published four years later?
>> Moreover, the real added-value of the addition of the diameter-id in the OLR does not seem so clear.
SRD2> Detection of the fact that an OHMA exists so that something 
intelligent can be done before it results in a total shutdown of the 
Diameter network.
> [LM] is there any clear description of what will be the use of this info by the reacting node? if the proxy replaces the origin-host A by origin-host B, the Diameter nodes receiving the answers wil…
SRD> Scroll down an look at the details behind alternative 1.

---

From: <[email-masked]>
Date: Tue, 19 Aug 2014 15:26:59 +0000

Hi Steve,

If you decide to deploy a proxy modifying the origin-host, it would be for some specific purposes in a given context. If the context has changed, you will have to reconsider the whole mechanism. And it is not only related to DOIC.
If not done, this is what I'm calling a bad design: it is not only about the implementation of the product itself, it is also about how this product is used in the operational network.
And I don't buy the argument that an operator might have forgotten that a proxy modifying origin-host would have been deployed in the network before the introduction of DOIC.

>>>>>>    - 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 t…

The following question still remain not answered: if the proxy replaces the origin-host A by origin-host B, the Diameter nodes receiving the answers will "see" B as sender of the answer and will use this id when sending new requests with origin-host AVP. So can you remind me how exactly the reacting node will use the Diameter-id received in the OLR?

Regards,

Lionel

-----Message d'origine-----
De : Steve Donovan [mailto:[email-masked]] 
Envoyé : mardi 19 août 2014 16:46
À : MORAND Lionel IMT/OLN; Ben Campbell
Cc : [email-masked]
Objet : Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysis

Lionel,

More inline.

Steve

On 8/19/14, 8:40 AM, [email-masked] wrote:
> De : Steve Donovan [mailto:[email-masked]] Envoyé : mardi 19 
> août 2014 13:41 À : MORAND Lionel IMT/OLN; Ben Campbell Cc : 
> [email-masked] Objet : Re: [Dime] Non-DOIC Origin-Host Munging agent 
> alternatives analysis
>
> Lionel,
>

Date - Event:

Sometime in 2011 - Operator installs an agent to do topology hiding or load balancing or some other function and the agent modifies the origin-host AVP as part of its logic.  In 2011 this works perfectly well for all applications handled by the agent.

Are you asserting that the agent deployed in 2011 was badly designed because it did not anticipate the DOIC solution published four years later?
SRD2> Detection of the fact that an OHMA exists so that something
intelligent can be done before it results in a total shutdown of the Diameter network.
> SRD> The reasons so far for deferring functionality was because it 
> SRD> would
>> Envoyé : mardi 19 août 2014 03:42 À : Steve Donovan Cc : 
>> [email-masked] Objet : Re: [Dime] Non-DOIC Origin-Host Munging agent 
>> alternatives analysis
>>
>>>>> 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 
>> _____________________________________________________________________
>> _ ___________________________________________________
>>

---

From: Steve Donovan <[email-masked]>
Date: Tue, 19 Aug 2014 10:46:50 -0500

> And I don't buy the argument that an operator might have forgotten that a proxy modifying origin-host would have been deployed in the network before the introduction of DOIC.
SRD> The agent does not need to be in the "home" operators network for 
the problem to exist.
> The following question still remain not answered: if the proxy replaces the origin-host A by origin-host B, the Diameter nodes receiving the answers will "see" B as sender of the answer and will us…
SRD> See the third sub-bullet:

---

From: <[email-masked]>
Date: Tue, 19 Aug 2014 16:16:27 +0000

Hi Steve,

Please see below.

Regards,

Lionel

-----Message d'origine-----
De : Steve Donovan [mailto:[email-masked]] 
Envoyé : mardi 19 août 2014 17:47
À : MORAND Lionel IMT/OLN; Ben Campbell
Cc : [email-masked]
Objet : Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysis

[LM] it is even worst from my point of view. How do you route requests with origin-host initiated by a client in the visited domain towards the home network?

[LM] the second bullet should be read as follow: Reacting node always uses the diameter-id in the OC-OLR report when applying abatement algorithm logic to requests sent with origin-host. Right? 

> août 2014 16:46 À : MORAND Lionel IMT/OLN; Ben Campbell Cc : 
>> De : Steve Donovan [mailto:[email-masked]] Envoyé : mardi 
>> 19 août 2014 13:41 À : MORAND Lionel IMT/OLN; Ben Campbell Cc :
>>> ____________________________________________________________________
>>> _ _ ___________________________________________________
>>>
>>> confidentielles ou privilegiees et ne doivent donc pas etre 
>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu 
>>> ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>>>

---

From: Steve Donovan <[email-masked]>
Date: Tue, 19 Aug 2014 11:57:14 -0500

> [LM] it is even worst from my point of view. How do you route requests with origin-host initiated by a client in the visited domain towards the home network?
SRD2> That would presumably be up to the visited networks routing policy 
but most likely based on the realm.
> [LM] the second bullet should be read as follow: Reacting node always uses the diameter-id in the OC-OLR report when applying abatement algorithm logic to requests sent with origin-host. Right?
SRD> Yes.

---

From: "Nirav Salot (nsalot)" <[email-masked]>
Date: Wed, 20 Aug 2014 06:21:46 +0000

I agree with Lionel on multiple accounts.
I don't see any value in alternative 1. In fact, as I had already indicated, the alternative 1 breaks one or more of existing feature and hence it is not a solution by itself. 

Additionally, like any other feature, the operator does not simply enable this feature in their network without considerable planning, lab and field testing. And this is true for between two operators as well - where the bigger issue is whether to expose the overload information between two PLMNs or not.
So I don't see the need to have protocol based solution to help operator debug "what they have forgotten about their network".

Regards,
Nirav. 

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, August 19, 2014 8:57 PM
To: Steve Donovan; Ben Campbell
Cc: [email-masked]
Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysis

Hi Steve,

Regards,

Lionel

-----Message d'origine-----
De : Steve Donovan [mailto:[email-masked]] Envoyé : mardi 19 août 2014 16:46 À : MORAND Lionel IMT/OLN; Ben Campbell Cc : [email-masked] Objet : Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysis

Lionel,

More inline.

Steve

Date - Event:

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Steve Donovan <[email-masked]>
Date: Wed, 20 Aug 2014 10:54:11 -0500

Nirav,

Please see my comments inline.

Steve

> I don't see any value in alternative 1. In fact, as I had already indicated, the alternative 1 breaks one or more of existing feature and hence it is not a solution by itself.
SRD> The value is that, through a protocol solution, we can make it 
possible to prevent a complete shutdown of all traffic through a OHMA.  
It might be a small probability, but it is > 0, the impact is 
significant and the cost of the proposed protocol solution is extremely 
small.

SRD> I'm assuming that the breakage you are talking about is that the 
proposal does allow for topology information to leak across operator 
boundaries.  This is true, however, we do not, however, have a 
requirement to make DOIC work in the face of topology hiding.  Are there 
other existing features that you are concerned about?
> Additionally, like any other feature, the operator does not simply enable this feature in their network without considerable planning, lab and field testing. And this is true for between two operat…
SRD> We are designing DOIC for Diameter usage in general, not just 
3GPP.  I agree that this scenario is unlikely in a 3GPP environment, at 
least for well disciplined operators that have extensive testing as you 
point out.  I don't, however, think we can make that assumption across 
all uses of Diameter.  That's one of the reasons why we have 
requirements stating that the solution should not rely on configuration.
> So I don't see the need to have protocol based solution to help operator debug "what they have forgotten about their network".
SRD> As has been pointed out multiple times, this is not just about the 
operator's own network.  The negative impacts can result from another 
operator not upgrading their agents to support DOIC.

SRD> I look at this as a low cost insurance policy.  It doesn't hurt 
anything to add this small change and it helps prevent would could be a 
major outage.

---

From: "Nirav Salot (nsalot)" <[email-masked]>
Date: Wed, 20 Aug 2014 15:59:33 +0000

Steve,

I don't agree with your explanations.

Additionally, we may not have explicit requirement to make DOIC work in the face of topology hiding but that does not mean that "DOIC can break any existing feature - be it topology hiding - and that's fine!".

Regards,
Nirav.

-----Original Message-----
From: Steve Donovan [mailto:[email-masked]] 
Sent: Wednesday, August 20, 2014 9:24 PM
To: Nirav Salot (nsalot); [email-masked]; Ben Campbell
Cc: [email-masked]
Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysis

Nirav,

Steve

SRD> The value is that, through a protocol solution, we can make it
possible to prevent a complete shutdown of all traffic through a OHMA.  
It might be a small probability, but it is > 0, the impact is significant and the cost of the proposed protocol solution is extremely small.

SRD> I'm assuming that the breakage you are talking about is that the
proposal does allow for topology information to leak across operator boundaries.  This is true, however, we do not, however, have a requirement to make DOIC work in the face of topology hiding.  Are there other existing features that you are concerned about?
SRD> We are designing DOIC for Diameter usage in general, not just
3GPP.  I agree that this scenario is unlikely in a 3GPP environment, at least for well disciplined operators that have extensive testing as you point out.  I don't, however, think we can make that assumption across all uses of Diameter.  That's one of the reasons why we have requirements stating that the solution should not rely on configuration.
SRD> As has been pointed out multiple times, this is not just about the
operator's own network.  The negative impacts can result from another operator not upgrading their agents to support DOIC.

SRD> I look at this as a low cost insurance policy.  It doesn't hurt
anything to add this small change and it helps prevent would could be a major outage.

---

From: Dave Dolson <[email-masked]>
Date: Wed, 20 Aug 2014 16:17:21 +0000

It seems to me that this stale-mate may be addressed by observing that the host name has been introduced to distinguish between multiple reports, and that any unique key would allow this.

Would it be acceptable to make the field any arbitrary unique key rather than the host name?
(Host name is a special case of arbitrary unique key)

Then a receiver would recognize that reports are coming from multiple sources without any reveal of actual host names.

Those concerned about AVP size could use 4-byte discriminators; those concerned about global uniqueness could use the host name.

-Dave.

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Steve Donovan
Sent: Wednesday, August 20, 2014 11:54 AM
To: Nirav Salot (nsalot); [email-masked]; Ben Campbell
Cc: [email-masked]
Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysis

Nirav,

Steve

---

From: Steve Donovan <[email-masked]>
Date: Wed, 20 Aug 2014 11:25:45 -0500

Nirav,

Can you please be more specific about which of the explanations you 
don't agree with?

I agree we can't completely ignore the way that Diameter is being used.

We should also be avoiding a solution that leaves open the possibility 
of significant under utilization of Diameter network resources.  We have 
a stated requirement that the solution must not result in under 
utilization.

I must admit I'm surprised at the response the proposal is getting. It 
is a very minor change that makes the protocol more resilient.

Steve

---

From: "Nirav Salot (nsalot)" <[email-masked]>
Date: Wed, 20 Aug 2014 16:43:09 +0000

Steve,

You are proposing a change (minor or not) for a problem which does not exist (in my view at least) since the use case is
- The operator has enabled overload feature in his network and has not upgraded one of the proxy
- The operator has "forgotten" that the proxy which is not upgraded is doing topology hiding

Or between two operators, they have entered into the agreement to share the overload reports but have not bothered to upgrade all of their nodes and not done any basic testing before activating the overload feature. 

So we are defining the solution for the above use cases. And the solution you are suggesting it results in
- The client ignoring the overload report and thus the operator finds out that "he has forgotten to upgrade one of the proxy (which is doing topology hiding) with the overload feature".

Additionally, the solution breaks topology hiding feature itself and your justification is that "we haven't agreed requirement to not break this feature!".

I am sorry, but I don't see why we need any protocol based solution here.
It is simple matter operator knowing its network/deployment/nodes and existing features and enabling new feature based on "this" knowledge. And doing some basic testing/dry run before going live. 
3GPP or IETF, if we start defining solution assuming that "but the operator may have forgotten to do this or that", we are adding solutions in our product which are simply overhead. 

Finally, we should be looking at the justification to have some solution and not add some change just because it is minor.

Regards,
Nirav.

-----Original Message-----
From: Steve Donovan [mailto:[email-masked]] 
Sent: Wednesday, August 20, 2014 9:56 PM
To: Nirav Salot (nsalot); [email-masked]; Ben Campbell
Cc: [email-masked]
Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysis

Nirav,

Can you please be more specific about which of the explanations you don't agree with?

We should also be avoiding a solution that leaves open the possibility of significant under utilization of Diameter network resources.  We have a stated requirement that the solution must not result in under utilization.

I must admit I'm surprised at the response the proposal is getting. It is a very minor change that makes the protocol more resilient.

Steve

On 8/20/14, 10:59 AM, Nirav Salot (nsalot) wrote:
> SRD> As has been pointed out multiple times, this is not just about 
> SRD> the
>> 19 août 2014 16:46 À : MORAND Lionel IMT/OLN; Ben Campbell Cc :
>>>>>>>> - Requires the operator to lose any functionality enabled by 
>>>>>>>> the non-DOIC agent until all agents have been upgraded to 
>>>>>>>> support DOIC
>>>> ___________________________________________________________________
>>>> _ _ _ ___________________________________________________
>>>>

---

From: <[email-masked]>
Date: Wed, 20 Aug 2014 16:48:13 +0000

I totally share the clear explanation given by Nirav.

Regards,

Lionel

Envoyé depuis mon Sony Xperia SP d'Orange

---- Nirav Salot (nsalot) a écrit ----

Steve,

Regards,
Nirav.

-----Original Message-----
From: Steve Donovan [mailto:[email-masked]]
Sent: Wednesday, August 20, 2014 9:56 PM
To: Nirav Salot (nsalot); [email-masked]; Ben Campbell
Cc: [email-masked]
Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysis

Nirav,

Steve

---

From: Ben Campbell <[email-masked]>
Date: Wed, 20 Aug 2014 16:17:50 -0500

Hi Dave,

I think that could help with one of the use cases for attribution--which was to determine if a stream of overload reports are coming from the same server. I'm not sure if it would help for the case of sending host-reports across a non-DOIC proxy that munges origin-host, since the reacting node needs to match the identity of the overloaded host to values used in Destination-Host in future requests. I guess it might be possible to use it to allow reacting nodes to infer that the the origin-host field in the answer carrying the report has been modified, and that the report must be treated as invalid. (I haven't wrapped my brain around that one yet.)

A unique key would have the advantage of not leaking IP addresses or Diameter identities across a topology-hiding proxy. It would still let downstream nodes infer the number of servers behind such a topology-hiding proxy, by observing the number of unique key values. I suspect sometimes that would be okay and sometimes it would not.

/Ben

---

From: Ben Campbell <[email-masked]>
Date: Wed, 20 Aug 2014 16:44:50 -0500

I'm a little confused by this discussion. We have a published DIME consensus document of DIME (RFC 7068) that has requirements that matter here, but the discussion seems content to ignore them. 

In particular, the following quoted requirements bear on this discussion.

>    REQ 6:  The solution designers SHOULD seek to minimize the amount of
>            new configuration required in order to work.  For example, it
>            is better to allow peers to advertise or negotiate support
>            for the solution, rather than to require that this knowledge
>            be configured at each node.
> 

[...]

>    REQ 16: The solution is likely to be deployed incrementally.  The
>            solution MUST support a mixed environment where some, but not
>            all, nodes implement it.
> 
>    REQ 17: In a mixed environment with nodes that support the solution
>            and nodes that do not, the solution MUST NOT result in
>            materially less useful throughput during overload as would
>            have resulted if the solution were not present.  It SHOULD
>            result in less severe overload in this environment.
> 

More inline:

> - The operator has "forgotten" that the proxy which is not upgraded is doing topology hiding

Steve is proposing a change to allow incremental deployment without breaking things (Req 16, and first part of Req 17). In this case, the incremental deployment is to allow at least some DOIC function, in spite of a legacy proxy. I believe these requirements require us to at least attempt to solve the problem. If we can't come up with a solution, we should document why, and try to keep our non-compliance as narrow as possible. (This is significantly different from saying that the problem does not need to be solved.)

> Additionally, the solution breaks topology hiding feature itself and your justification is that "we haven't agreed requirement to not break this feature!".

This is the one problem I see with the current proposal. I'd like to see comments from some of the carriers about whether it's a show stopper. We should also wrack our brains for a solution that does not have this problem. (Thanks to Dave for taking a shot at that--it would be good to see other thoughts there.)

I note that topology-hiding for it's own sake. is not the only use case for which proxies munge origin-host in answers. There are other cases (for example, having the proxy completely take over responsibility for request routing), where this leakage is not a problem. You may recall all the early discussions about server front ends (SFEs), where they _always_ did origin-host munging, but only sometimes did full-blown topology hiding.

This is not theoretical. Such proxies exist in real deployments today.

> 3GPP or IETF, if we start defining solution assuming that "but the operator may have forgotten to do this or that", we are adding solutions in our product which are simply overhead. 

You seem to be ignoring Req 6. Also, while the idea that you need to test everything out in advance may make sense from a 3GPP perspective, it doesn't from an IETF perspective, where we have to worry about things like dynamic discovery (which makes Req 5 also relevant.) If you use dynamic peer discovery, you can't know in advance the features of every node you may talk to (or across.)

> Finally, we should be looking at the justification to have some solution and not add some change just because it is minor.

Again, the quoted requirements are represent existing consensus. Certainly we can change consensus--but doing so requires a consensus to do so.

If on the other hand, people think these requirements do not apply to the problem at hand, they can argue that. But if people have argued that so far, I've missed it.

---

From: <[email-masked]>
Date: Wed, 20 Aug 2014 22:21:47 +0000

Hi Ben,

I'm not ignoring the requirements.
I'm saying that most of them are fulfilled in my point of view. And we have also an.agreement that the baseline solution for DOIC may not cover everything but may be enhanced if required.

Regards,

Lionel

---- Ben Campbell a écrit ----

[...]

More inline:

---

From: Ben Campbell <[email-masked]>
Date: Wed, 20 Aug 2014 17:28:48 -0500

> I'm saying that most of them are fulfilled in my point of view. And we have also an.agreement that the baseline solution for DOIC may not cover everything but may be enhanced if required.

IMO, Putting off a requirement for later work is fine, if we document that we did so and have a reasonable path to doing it in the future.  But I'm not sure how this one can be fixed after the fact, unless we build the needed flexibility into the initial mechanism.

---

From: <[email-masked]>
Date: Thu, 21 Aug 2014 09:11:20 +0000

The flexibility is there if it is just about adding an AVP in the Grouped AVP.
As far as I understand, the question is more about the real need for such extension today.

-----Message d'origine-----
De : Ben Campbell [mailto:[email-masked]] 
Envoyé : jeudi 21 août 2014 00:29
À : MORAND Lionel IMT/OLN
Cc : Nirav Salot (nsalot); Steve Donovan; [email-masked]
Objet : Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysis

---

From: Ben Campbell <[email-masked]>
Date: Thu, 21 Aug 2014 09:22:17 -0500

> As far as I understand, the question is more about the real need for such extension today.

The problem is, this only works if the reacting node knows that it needs to pay attention to the new AVP. Would you advocate setting the M-bit?

---

From: Steve Donovan <[email-masked]>
Date: Thu, 21 Aug 2014 10:31:29 -0500

Nirav,

Thanks for the detailed response.  Please see my responses inline.

Steve

> - The operator has "forgotten" that the proxy which is not upgraded is doing topology hiding
SRD> It's not just about topology hiding.  It's about anything that 
requires changing the origin-host.

> Or between two operators, they have entered into the agreement to share the overload reports but have not bothered to upgrade all of their nodes and not done any basic testing before activating the…
SRD> I don't think we want to get into the situation where Operator A 
has to wait to turn on overload control because Operator B has not yet 
upgraded their network to support DOIC.
> - The client ignoring the overload report and thus the operator finds out that "he has forgotten to upgrade one of the proxy (which is doing topology hiding) with the overload feature".
SRD> I'm saying that in the real world strange things happen. Solution 1 
mitigates the effect of mistakes being made.

SRD> I'm not saying the client ignores the overload report.  That is 
clearly one option.  I have suggested the behavior be up to local 
policy.  I see four options, others may see others:

1) Always ignore the overload report
2) Always honor the overload report
3) Conditionally honor the overload report -- Honor anything up to some 
percentage
4) Adjusted percentage - learn the number of servers that exist behind 
the OHMA and adjust the reduction percentage accordingly.
> Additionally, the solution breaks topology hiding feature itself and your justification is that "we haven't agreed requirement to not break this feature!".
SRD> As pointed out by Dave, there are likely modifications to solution 
1 that does not break topology hiding, if we think it is a requirement 
to avoid that breakage.

SRD> Which is worse, an operator not being able to turn on DOIC because 
of other operators or breaking topology hiding?  I don't know the answer 
but I do think it is a decision that should be made by the operator.
> I am sorry, but I don't see why we need any protocol based solution here.
SRD> This is where the difference of opinion exists.  You are of the 
opinion that operators never make mistakes and, as a result, we don't 
need a protocol based solution.  I am of the opinion that in the real 
world strange things happen and a little bit of extra resiliency in the 
protocol is a good thing.
> Finally, we should be looking at the justification to have some solution and not add some change just because it is minor.
SRD> No one is making that argument.  I have articulated the 
justification.  I also pointed out that the cost of the solution is very 
small.  Cost benefit analysis is a valid aspect of any design process.

---

From: "Nirav Salot (nsalot)" <[email-masked]>
Date: Thu, 21 Aug 2014 16:49:17 +0000

Steve,

I am not sure why should operator A not turn on DOIC feature in its own network just because of operator B/C/D does not support it.
This is handled in the same way as operator A and B support the feature but have no agreement to share the overload report. And hence based on configuration host in operator A's network ensures that messages going to operator B does not contain overload report.

Regards,
Nirav. 

-----Original Message-----
From: Steve Donovan [mailto:[email-masked]] 
Sent: Thursday, August 21, 2014 9:01 PM
To: Nirav Salot (nsalot); [email-masked]; Ben Campbell
Cc: [email-masked]
Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysis

Nirav,

Steve

---

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Thu, 28 Aug 2014 10:25:31 +0000

Dear all

A long email thread on this topology  hiding topic. I Would like to come back on the use cases.
In the thread, two use cases were mentioned, are there others?

- the SFE case, where a DA in front of a set of servers presents this set of servers as one Diameter node with a unique Diameter Host identity. The reacting nodes only know this Diameter Host identity for their host requests. Regarding DOIC, as the SFE objective is to present the group of servers as one Diameter node it should apply to DOIC, meaning the DA aggregates the different OLRs received from servers to build the OLR associated to the unique Diameter Host identity.  Otherwise  this Diameter node will send inconsistent OLRs, and then we try to find a solution requesting the reacting nodes, that may be in external networks  to solve this DOIC issue internal to the servers and their SFE.   Lionel did  such a remark in his 19/08 mail " a agent modifying the Origin-host can only be a proxy and a proxy is by definition compliant with the application supporting the new OLR-related AVPs" on which I agree.
Furthermore the Steve's proposed solution would introduce a non consistent behavior from the reacting node regarding traffic reduction.   

- the external network case where the DA of  the servers network interfacing external networks  is doing topology hiding to present the servers as a unique Diameter node to external networks . I have the same remark as for SFE, where the proposed solution will request the external network to solve the issue of the non DOIC DEA.
There is also the case where the DEA modifies  the Origin-Host but on a 1 to 1 basis, so allocating a different Origin-host identity for each server. In this case, the DOIC works  well without changes. The proposed solution will, I think, here create mismatches, which do not exist. 

I share the comments from several of us, to not consider this case as an actual one to solve. If a DA presents a set of servers as a unique Diameter Host, either this overall entity (servers+DA) supports DOIC and behaves as a reporting node  towards reacting nodes or it does not. If it does not, no OC-Supported-feature AVP should be sent by this entity in answers to reacting nodes, that I think can be achieved. 

Best regards

JJacques

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de Nirav Salot (nsalot)
Envoyé : jeudi 21 août 2014 18:49
À : Steve Donovan; [email-masked]; Ben Campbell
Cc : [email-masked]
Objet : Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysis

Steve,

SRD> Which is worse, an operator not being able to turn on DOIC because
of other operators or breaking topology hiding?  I don't know the answer but I do think it is a decision that should be made by the operator.

Regards,
Nirav. 

-----Original Message-----
From: Steve Donovan [mailto:[email-masked]]
Sent: Thursday, August 21, 2014 9:01 PM
To: Nirav Salot (nsalot); [email-masked]; Ben Campbell
Cc: [email-masked]
Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysis

Nirav,

Steve

On 8/20/14, 11:43 AM, Nirav Salot (nsalot) wrote:
> Steve,
>
> You are proposing a change (minor or not) for a problem which does not 
> exist (in my view at least) since the use case is