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

[Steve Donovan <[e-mail]>]

See inline.

On 5/6/16 3:45 PM, Ben Campbell wrote:
> On 6 May 2016, at 14:48, Steve Donovan wrote:
>
>
> [...]
>
>>>
>>>>>
>>>>> ---------------------------------------------------------------------- 
>>>>>
>>>>> 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.
>>>> 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.
>> 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.
>
> See my comment in that thread. For the record, I think the proposal is 
> on the right track, but may still need some tweaks.
>
>>>
>>>>>
>>>>> 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?
>>>> 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.
>>>
>>> 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.
>
> 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.)
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.
>
>> 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.
>
> 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.
>
> [...]
>
>>>
>>>>>
>>>>> 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.)
>>>> 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.)
>> 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.
>
> 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.
SRD> OK.
>
>>>
>>> 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.
>
> 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?)
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.
>>>
>>>
>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------- 
>>>>>
>>>>> 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.
>>>> 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> 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.
SRD> OK
>
> [...]
>
>>>
>>>>>
>>>>> -- "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.
>>>> 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.
>>>
>>> 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> 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.
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.
>
> [...]