Subject: [Dime] Ben Campbell's Discuss on draft-ietf-dime-drmp-05: (with DISCUSS and COMMENT)

From: "Ben Campbell" <[email-masked]>
Date: Tue, 03 May 2016 19:31:24 -0700

Ben Campbell has entered the following ballot position for
draft-ietf-dime-drmp-05: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dime-drmp/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I have a few concerns that I think need some discussion. 

1) Priority between applications: The fact that agents can apply priority
for messages from multiple applications without knowledge of those
applications seems dangerous. Let's say application A is a critical
infrastructure application, and application B is not. But clients for
application B might set requests to have a higher priority than do
clients for application A.  Further, application B could become a DoS
vector for application A. One potential (and likely half-baked) way to
mitigate this would be to say that nodes that are not "application aware"
can only apply priority among messages for the same application.

2) Priority between clients of the same application: If you have multiple
clients for the same application, don't they need to use the same
prioritization strategy? How is this to be managed?

3) Out of order requests: The draft explicitly allows agents to re-route
and even explicitly re-order messages. Is it safe to have a
non-application aware node change the order of messages?

4) I am nervous about the idea that clients and servers would use a
generic message priority mechanism to manage the allocation of resources
that result from a requests and answers. It seems like that should be
based on application specific rules and information. (Now, if the point
is that these same AVPs might be used in an application according to
application specific rules, that might be okay--but then you might run
into issues where application-agnostic agents don't know the difference.)

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

General: I approached this assuming prioritization would matter only in
overload scenarios. But I gather you envision using this in non-overload
scenarios? (This interacts with my discuss point about the use of DRMP to
prioritize resource allocation that result result from successful
diameter transactions.) Use case 5.3 is a bit worrisome in this context.

-6, list item 4: Are there really use cases for answer senders to set a
different priority on the answer than was on the request? That seems to
add quite a bit of complexity.

- 6, list item 8: I'm not sure what it means for a client to prioritize
answers to it's own requests.

-8,  "Diameter nodes SHOULD
   include Diameter routing message priority in the DRMP AVP in all
   Diameter request messages." : 
Does that apply to all nodes that touch a request, or just the request
originator?

-- "Diameter nodes MUST use the priority indicated in the DRMP AVP
carried in the answer message, if it exists."
The MUST seems odd, since paying attention to the priority in the initial
request was only SHOULD. 

-- "Another is to use the Proxy-Info
      mechanism defined in [RFC6733].":
That probably needs some elaboration.

---

From: Steve Donovan <[email-masked]>
Date: Wed, 4 May 2016 11:25:33 -0500

My comments inline.

Steve

> https://datatracker.ietf.org/doc/draft-ietf-dime-drmp/
SRD> This is similar to saying that priority setting across applications 
need to be set in a consistent way.  We might need to define the 
"priority scheme" or some similar concept as sketched out in my response 
to Alissa's DISCUSS.
> prioritization strategy? How is this to be managed?
SRD> It is not directly defined.  This is back to the question of 
whether or not the mechanism is constrained to only work in a trusted 
environment.
> non-application aware node change the order of messages?
SRD> This mechanism doesn't change the need for Diameter nodes to handle 
messages arriving out of order.  This exists in any protocol that has 
agents/proxies.
> into issues where application-agnostic agents don't know the difference.)
SRD> The definition of what different priority levels mean will reflect 
the application specific knowledge.  Agents just route requests and with 
the introduction of DOIC, sometimes throttle them.  The agent doesn't 
need anything but the priority value, as long as the priority values are 
defined consistently across all applications.
SRD> I don't understand the concern.
> add quite a bit of complexity.
SRD> This was an explicit conversation within the working group. I don't 
recall the specific use case off the top of my head, but this was 
changed to the current wording after discussions within the working 
group.  I can go back to the email archive to refresh my memory if 
necessary.
> answers to it's own requests.
SRD> The client could choose to complete the transaction, and initiate 
other dependent actions, based on the priority received in the answer 
message.  It is those dependent actions -- setting up a data channel, 
authorizing call completion, etc -- that would be impacted by the 
priorities received in the answer.
> Does that apply to all nodes that touch a request, or just the request
SRD> This statement was meant to apply to the request originator.  The 
statement should be updated.
> The MUST seems odd, since paying attention to the priority in the initial
SRD> The wording here is cumbersome.  The full paragraph is as follows:

    When determining the priority to apply to answer messages, Diameter
    nodes MUST use the priority indicated in the DRMP AVP carried in the
    answer message, if it exists.  Otherwise, the Diameter node MUST use
    the priority indicated in the DRMP AVP of the associated request
    message.

This is meant to say that a Diameter node receiving an answer message 
MUST use the priority value in the answer message when processing the 
message.  If there is no DRMP AVP in the answer message then the 
receiving node uses the priority that was in the request message.  I'd 
be happy to re-craft this to be more clear.
> That probably needs some elaboration.
SRD> A reference to the document that defines Proxy-Info isn't sufficient?

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 04 May 2016 22:58:01 -0500

(oops, sent this earlier, but it just went to Steve. Resending to full 
list)

Thanks for the quick response. Further discussion inline:

Ben.

On 4 May 2016, at 11:25, Steve Donovan wrote:

[...]

> SRD> This is similar to saying that priority setting across 
> applications need to be set in a consistent way.  We might need to 
> define the "priority scheme" or some similar concept as sketched out 
> in my response to Alissa's DISCUSS.

That would probably help. Am I correct in assuming that would require 
some WG discussion?
It occurs to me after sleeping on it that, in congestion cases, this 
would leave things no worse than when a relay agent throttles requests 
with even less information. But it's a little more worrisome when used 
in non-congested circumstances, assuming they leave the possibility of 
throttling or otherwise rejecting requests under normal processing 
conditions.

> whether or not the mechanism is constrained to only work in a trusted 

The potential "priority scheme" might help here. But why does a trusted 
environment matter? Lets say you have trusted clients from vender A and 
from vendor B, but they select priorities differently?

> SRD> This mechanism doesn't change the need for Diameter nodes to 
> handle messages arriving out of order.  This exists in any protocol 
> that has agents/proxies.

Okay, I will withdraw that part. (How quick one forgets...)

> SRD> The definition of what different priority levels mean will 
> reflect the application specific knowledge.  Agents just route 
> requests and with the introduction of DOIC, sometimes throttle them.  
> The agent doesn't need anything but the priority value, as long as the 
> priority values are defined consistently across all applications.

My concern was more about client and server behavior, but it may be 
impacted by relays. I assume that a relay agent would not be making 
decisions about resource allocation, at least beyond transactions state.

My concern is twofold: In the case of servers, this seems to give a 
server leave to send a successful answer, but not allocate any necessary 
resources to support that success. This seems to lead to circumstances 
where the server thinks something failed but the client thinks it 
worked. (I have no problem with saying that a resource-constrained 
server might include priority as a factor in it's decisions about which 
requests to reject.)

In the case of clients, I think we are talking about a client abandoning 
some task even though the server thinks it worked. I don't see that as a 
problem per se, but I would expect a server to do that based on some 
local knowledge of priority. It seems a stretch that it would do so 
based on a priority value inserted by the server. But even if that makes 
sense, I understand that this draft allows relay agents with no 
knowledge of the application semantics to insert, remove, or change 
priority values in answer messages. (Maybe the answer here is stricter 
guidance on when relay agents can change priority values, and allowing 
the client to ignore priority values in answers (especially success 
answers)

> SRD> I don't understand the concern.

I'm concerned that this could effectively induce overload for lower 
priority messages, when the nodes would normally be able to handle all 
messages. In use case 5.3, does the platinum customer buy the right to 
cause other customer's requests to fail?

> SRD> This was an explicit conversation within the working group. I 
> don't recall the specific use case off the top of my head, but this 
> was changed to the current wording after discussions within the 
> working group.  I can go back to the email archive to refresh my 
> memory if necessary.

I am willing to accede to working group consensus on this. But one 
question: Does this apply to answers that indicate success, as well as 
failure?

> priorities received in the answer.

See the comments on item 4 from my discuss.

> statement should be updated.

Okay.

> be happy to re-craft this to be more clear.

Part of my concern is that the MUST vs SHOULD bit is different for 
requests and answers. statements of the form "If you use the mechanism, 
you MUST do X" do not mean the same as "SHOULD do X", even if the 
reasoning behind the SHOULD is that a node might not use the mechanism.

> SRD> A reference to the document that defines Proxy-Info isn't 

On a re-read, it's probably good enough, although on reflection, I don't 
think this draft needs to tell relay agents how to manage transaction 
state. But it doesn't hurt either way.

---

From: Steve Donovan <[email-masked]>
Date: Fri, 6 May 2016 14:48:32 -0500

Ben,

See my comments inline.

Steve

> throttling or otherwise rejecting requests under normal processing 
SRD> See my proposed changes to the draft sent in a separate email.  I 
think this addresses the above concern and is currently waiting WG 
discussion.
> The potential "priority scheme" might help here. But why does a 
> trusted environment matter? Lets say you have trusted clients from 
> vender A and from vendor B, but they select priorities differently?
SRD> They aren't trusted if they aren't using the defined standards.  In 
addition, trusted environment generally means operated by a single 
entity.  That operator has the job of ensuring that what you are 
proposing would not happen.
>> The agent doesn't need anything but the priority value, as long as 
>> the priority values are defined consistently across all applications.
>
> server leave to send a successful answer, but not allocate any 
> necessary resources to support that success. This seems to lead to 
> circumstances where the server thinks something failed but the client 
> thinks it worked. (I have no problem with saying that a 
> resource-constrained server might include priority as a factor in it's 
> decisions about which requests to reject.)
SRD> DRMP does not change application server behavior.  It just 
influences the order in which requests are processed.  As such, I don't 
see how DRMP would cause the server to falsely send a success response.
>
> In the case of clients, I think we are talking about a client 
> abandoning some task even though the server thinks it worked. I don't 
> see that as a problem per se, but I would expect a server to do that 
> based on some local knowledge of priority. It seems a stretch that it 
> would do so based on a priority value inserted by the server. But even 
> if that makes sense, I understand that this draft allows relay agents 
> with no knowledge of the application semantics to insert, remove, or 
> change priority values in answer messages. (Maybe the answer here is 
> stricter guidance on when relay agents can change priority values, and 
> allowing the client to ignore priority values in answers (especially 
> success answers)
SRD> Clients abandoning things can happen without DRMP.  It's up to the 
application to define the correct behavior when this happens.  DRMP 
doesn't change anything on that front.  As such, I don't see the concern.
> cause other customer's requests to fail?
SRD> It is certainly possible that higher priority messages could starve 
lower priority messages.  The only case when this would result in a 
lower priority message not getting service in non congestion scenarios 
is if the lower priority message times out. This is a recognized side 
effect of priority based schemes like this.  An operator offering a 
service like 5.3 would have to take this into consideration.  I would 
expect that in a well thought out priority scheme the percentage of high 
priority messages will be significantly less than low priority messages, 
reducing the probability of starving the low priority messages.  How 
this is done, however, is out side the scope of this document.
> question: Does this apply to answers that indicate success, as well as 
SRD> Yes.
>> SRD> The client could choose to complete the transaction, and 
>> initiate other dependent actions, based on the priority received in 
>> the answer message.  It is those dependent actions -- setting up a 
>> data channel, authorizing call completion, etc -- that would be 
>> impacted by the priorities received in the answer.
>
SRD> See my response.  Is there something else that I'm missing?
>> SRD> This statement was meant to apply to the request originator.  
>> The statement should be updated.
>
> Okay.
>
>>>
>> receiving node uses the priority that was in the request message.  
>> I'd be happy to re-craft this to be more clear.
>
> requests and answers. statements of the form "If you use the 
> mechanism, you MUST do X" do not mean the same as "SHOULD do X", even 
> if the reasoning behind the SHOULD is that a node might not use the 
> mechanism.
SRD> There are no SHOULD statements in this paragraph.  This requirement 
only applies "When determining the priority to apply to __received__ 
answer messages".  I don't see the conflict.
> On a re-read, it's probably good enough, although on reflection, I 
> don't think this draft needs to tell relay agents how to manage 
> transaction state. But it doesn't hurt either way.
SRD> This draft doesn't, it lists two options.  The Proxy-Info qualifier 
was inserted because there was a suggestion that the wording indicate 
the state is stored locally by the agent.

---

From: "Ben Campbell" <[email-masked]>
Date: Fri, 06 May 2016 15:45:43 -0500

On 6 May 2016, at 14:48, Steve Donovan wrote:

[...]

>> would leave things no worse than when a relay agent throttles 
>> requests with even less information. But it's a little more worrisome 
>> when used in non-congested circumstances, assuming they leave the 
>> possibility of throttling or otherwise rejecting requests under 
>> normal processing conditions.

See my comment in that thread. For the record, I think the proposal is 
on the right track, but may still need some tweaks.

>>> whether or not the mechanism is constrained to only work in a 
>>> trusted environment.
>>
> SRD> They aren't trusted if they aren't using the defined standards.

What standard? The application specification? (See my question in 
Alissa's thread about whether DRMP can be applied to legacy applications 
that don't (yet) define it's use.)

> In addition, trusted environment generally means operated by a single 

I can accept if that is the case, but it's not a very satisfying answer. 
It leads to having profiles for each operator. (I realize that the 
primary users of Diameter have always had operator-specific profiles of 
standards, so maybe there's nothing to do here.) This might at least 
imply a requirement that priority definitions need to be configurable.

[...]

>> resource-constrained server might include priority as a factor in 
>> it's decisions about which requests to reject.)
> influences the order in which requests are processed.  As such, I 
> don't see how DRMP would cause the server to falsely send a success 
> response.

I agree, but I thought the language in DRMP seemed to allow for it. 
Maybe, rather than saying that a server could use DRMP to decide whether 
the allocate resources for a request, it would be better to say the 
server could use DRMP to decide whether to process or fail a request.

>> would do so based on a priority value inserted by the server. But 
>> even if that makes sense, I understand that this draft allows relay 
>> agents with no knowledge of the application semantics to insert, 
>> remove, or change priority values in answer messages. (Maybe the 
>> answer here is stricter guidance on when relay agents can change 
>> priority values, and allowing the client to ignore priority values in 
>> answers (especially success answers)
> SRD> Clients abandoning things can happen without DRMP.  It's up to 
> the application to define the correct behavior when this happens.  
> DRMP doesn't change anything on that front.  As such, I don't see the 
> concern.

I think that's fine if only application-aware nodes are involved (and 
the application defines how to use DRMP). My concern is that a relay 
agent is allowed to change the priority. So imagine a client sends a 
request with a high priority, and gets back a successful answer with a 
low priority. Section 8 says it MUST use the priority in the answer over 
it's local idea of what the priority was. How does it know a relay 
didn't change the priority in the answer.

(Even if nothing changes the answer en route, is it really reasonable 
for the server's idea of priority to always override the client's?)
>> priority messages, when the nodes would normally be able to handle 
>> all messages. In use case 5.3, does the platinum customer buy the 
>> right to cause other customer's requests to fail?
> SRD> It is certainly possible that higher priority messages could 
> starve lower priority messages.  The only case when this would result 
> in a lower priority message not getting service in non congestion 
> scenarios is if the lower priority message times out. This is a 
> recognized side effect of priority based schemes like this.  An 
> operator offering a service like 5.3 would have to take this into 
> consideration.  I would expect that in a well thought out priority 
> scheme the percentage of high priority messages will be significantly 
> less than low priority messages, reducing the probability of starving 
> the low priority messages.  How this is done, however, is out side the 
> scope of this document.

It's probably worth mentioning in the draft text that a naive approach 
to priority can introduce transaction failure in cases where all 
transactions might have succeeded without it, and that operators and 
implementers need to consider that.

[...]

>>> This is meant to say that a Diameter node receiving an answer 
>>> message MUST use the priority value in the answer message when 
>>> processing the message.  If there is no DRMP AVP in the answer 
>>> message then the receiving node uses the priority that was in the 
>>> request message.  I'd be happy to re-craft this to be more clear.
>>
> SRD> There are no SHOULD statements in this paragraph.  This 
> requirement only applies "When determining the priority to apply to 
> __received__ answer messages".  I don't see the conflict.

So this may be down to a nit--but the text as written says that the 
receiver of a _request_ "SHOULD" use the included priority, but the 
receiver of a response "MUST" use the priority. Now, maybe these are 
just different ways of encoding the idea that the node may not implement 
DRMP. But the former seems to allow the node to override the priority in 
the message if it has good reason, but the latter does not allow the 
same for a response.

As I mention in the discussion about my last discuss point, it seems odd 
that a client cannot choose it's own idea of priority over the servers 
if it thinks it has a good reason.

[...]

---

From: Steve Donovan <[email-masked]>
Date: Tue, 10 May 2016 08:38:43 -0500

See inline.

On 5/6/16 3:45 PM, Ben Campbell wrote:
>>>> define the "priority scheme" or some similar concept as sketched 
>>>> out in my response to Alissa's DISCUSS.
>>>
>>> That would probably help. Am I correct in assuming that would 
>>> require some WG discussion?
>>> requests with even less information. But it's a little more 
>>> worrisome when used in non-congested circumstances, assuming they 
>>> leave the possibility of throttling or otherwise rejecting requests 
>>> under normal processing conditions.
>> SRD> See my proposed changes to the draft sent in a separate email.  
>> I think this addresses the above concern and is currently waiting WG 
>> discussion.
>
> Alissa's thread about whether DRMP can be applied to legacy 
> applications that don't (yet) define it's use.)
SRD> I mean application specification or operator policy.  DRMP can 
apply to legacy applications in two ways.  First, the default priority 
applies if no priority is explicitly included in the message.  Second, 
operators can define their own priority scheme.
> I can accept if that is the case, but it's not a very satisfying 
> answer. It leads to having profiles for each operator. (I realize that 
> the primary users of Diameter have always had operator-specific 
> profiles of standards, so maybe there's nothing to do here.) This 
> might at least imply a requirement that priority definitions need to 
> be configurable.
SRD> I don't see that it means a profile per operator.  3GPP is likely 
to create a profile that spans all of its applications and could be used 
by all operators following the 3GPP standards.
>>>> requests and with the introduction of DOIC, sometimes throttle 
>>>> them.  The agent doesn't need anything but the priority value, as 
>>>> long as the priority values are defined consistently across all 
>>>> applications.
>>>
>>> circumstances where the server thinks something failed but the 
>>> client thinks it worked. (I have no problem with saying that a 
> Maybe, rather than saying that a server could use DRMP to decide 
> whether the allocate resources for a request, it would be better to 
> say the server could use DRMP to decide whether to process or fail a 
> request.
SRD> OK.
>>> abandoning some task even though the server thinks it worked. I 
>>> don't see that as a problem per se, but I would expect a server to 
>>> do that based on some local knowledge of priority. It seems a 
>>> stretch that it would do so based on a priority value inserted by 
>>> the server. But even if that makes sense, I understand that this 
>>> draft allows relay agents with no knowledge of the application 
>>> semantics to insert, remove, or change priority values in answer 
>>> messages. (Maybe the answer here is stricter guidance on when relay 
>>> agents can change priority values, and allowing the client to ignore 
>>> priority values in answers (especially success answers)
> low priority. Section 8 says it MUST use the priority in the answer 
> over it's local idea of what the priority was. How does it know a 
> relay didn't change the priority in the answer.
>
SRD> I don't see the negative impact of having the transaction priority 
changed by either the server or the agent.  If it truly breaks something 
then we could go back to having priority applying to a transaction but I 
don't see what breaks.
> implementers need to consider that.
SRD> OK
>>> mechanism, you MUST do X" do not mean the same as "SHOULD do X", 
>>> even if the reasoning behind the SHOULD is that a node might not use 
>>> the mechanism.
> just different ways of encoding the idea that the node may not 
> implement DRMP. But the former seems to allow the node to override the 
> priority in the message if it has good reason, but the latter does not 
> allow the same for a response.
>
> As I mention in the discussion about my last discuss point, it seems 
> odd that a client cannot choose it's own idea of priority over the 
> servers if it thinks it has a good reason.
SRD> Thanks for bearing with me on this one.  I see your point now and 
agree it should be reworded to include allowing for local policy to 
override what is carried in the message.

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 10 May 2016 12:49:26 -0400

I'm going to clear the discuss at this point--I wanted discussion to 
happen and it is happening. More inline:

[...]

> operators can define their own priority scheme.

Okay. That seems to imply a need for configurability, but I'll leave it 
to you whether that should be a standard requirement, or a market 
requirement.

>>
>>> In addition, trusted environment generally means operated by a 
>>> single entity.  That operator has the job of ensuring that what you 
>>> are proposing would not happen.
>>
>> answer. It leads to having profiles for each operator. (I realize 
>> that the primary users of Diameter have always had operator-specific 
> to create a profile that spans all of its applications and could be 
> used by all operators following the 3GPP standards.

Sure, but it still _might_ require per-operator profiles, right? Even 
3GPP networks tend to have operator specific "flavors" of protocols.

But I recognize this is not unusual for most (if not all) of the 
environments that Diameter is used in.

[...]

>> implement DRMP. But the former seems to allow the node to override 
>> the priority in the message if it has good reason, but the latter 
>> does not allow the same for a response.
>>
Thanks--I realize my first round of comments obscured the point a bit 
:-)

---

From: Steve Donovan <[email-masked]>
Date: Tue, 10 May 2016 16:09:41 -0500

Comments inline...

Steve

On 5/10/16 11:49 AM, Ben Campbell wrote:
>> apply to legacy applications in two ways.  First, the default 
>> priority applies if no priority is explicitly included in the 
>> message.  Second, operators can define their own priority scheme.
>
> Okay. That seems to imply a need for configurability, but I'll leave 
> it to you whether that should be a standard requirement, or a market 
> requirement.
SRD> I don't see the need to make configurability a standards level 
requirement.
>> SRD> I don't see that it means a profile per operator.  3GPP is 
>> likely to create a profile that spans all of its applications and 
>> could be used by all operators following the 3GPP standards.
>
SRD> Per operator profiles can exist.  This mechanism certainly doesn't 
mandate them.
>> SRD> Thanks for bearing with me on this one.  I see your point now 
>> and agree it should be reworded to include allowing for local policy 
>> to override what is carried in the message.
>>>
> Thanks--I realize my first round of comments obscured the point a bit :-)