Diameter Routing Message Priority
draft-ietf-dime-drmp-07

[Ballot comment]
I still think this part needs further clarification mostly regarding applicability and maybe a warning as it could lead to starvation of requests that do not define a priority, e.g. because there are not supporting it (yet) while effectively having a higher priortiy than the requests that they get starved by:
"When using DRMP priority information, Diameter nodes MUST use the
  default priority for transactions that do not have priority specified
  in a DRMP AVP."

[Ballot discuss]
I fully agree with all discuss comments made by Ben and Alissa. However, the summary here might be that this information might simply be not very useful for the uses cases described. And there might be other mechanisms that do not require any trust and that can address the uses cases easier and more appropriate such a simply prioritization of a certain application in the request handler/request agent or relative priorities within one application (on sent-out).

However, the one part that does actually concern me is:
"When using DRMP priority information, Diameter nodes MUST use the
  default priority for transactions that do not have priority specified
  in a DRMP AVP."
This part could lead to starvation of requests that do not define a priority, e.g. because there are not supporting it (yet). However these starved requests could effectively have a higher priortiy than the request that they get starved by.

[Ballot comment]
I disagree with Mirja's DISCUSS point.

In Section 6: excuse my ignorance, but how can priority information be conveyed to non-supporting endpoints (in 2 places)? And what is the point,as they don't support the extension?

In 9.1: it would be better to just have a table, instead of copying and modifying lots of text.

It would be good to have a short sentence saying how this extension affects non upgraded agents.

[Ballot comment]
After reading the document and the threads related to the DISCUSSes, I'm ABSTAINing because I can't see how this mechanism can reliably work (even in "trusted environments") as described here.

[Ballot comment]
- OLD:

  This also recognizes that more
  work has already taken place for established sessions and, as a
  result, it might be more harmful if the session update and session
  ending requests were to be throttled.


NEW:
  This also recognizes that more
  work has already taken place for established sessions and, as a
  result, it might be more harmful from a signaling point of view
  if the session update and session ending requests were to be throttled.

-

1.  Request sender - The sender of a request, be it a Diameter Client
      or a Diameter Server, determines the relative priority of the
      request and includes that priority information in the request.

Question: what is the risk of DMRP ending up as the DSCP, i.e.
Every end point changes the value to best service, and in the end, it's useless, and uniquely set by the operator.

[Ballot discuss]
I fully agree with all discuss comments made by Ben and Alissa. However, the summary here might be that this information might simply be not very useful for the uses cases described. And there might be other mechanisms that do not require any trust and that can address the uses cases easier and more appropriate such a simply prioritization of a certain application in the request handler/request agent or relative priorities within one application (on sent-out).

However, the one part that does actually concern me is:
"When using DRMP priority information, Diameter nodes MUST use the
  default priority for transactions that do not have priority specified
  in a DRMP AVP."
This part seems dangerous and I would proposed to instead basically have to different queues: one if a priority is defined and another one for requests without priority indication to make sure that requests out of the second queue will be served at some point in time and cannot be starved by other low priority requests completely.

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

[Ballot 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.

[Ballot discuss]
(1) Given the two key security threats identified in Section 11 -- that authorized nodes can issue requests with artificially high priority in order to get better treatment, and that unauthorized intermediaries can modify the priorities that senders set -- I don't see how it is legitimate to claim that either 5.1 or 5.2 are appropriate use cases for DRMP. The spec seems to assume that this mechanism will only be used in scenarios where nodes and agents have some out-of-band trust relationship established with each other (the shepherd write-up talks about a "trusted environment"), but that is certainly not the case in many disaster and emergency scenarios. If that really is a limitation on the scope of applicability of this mechanism, that should be stated in the document, and those use cases should either be removed or modified to explain the limitations on their applicability. 

(2) Section 6 says:

  "The mechanism for how the agent determines which requests are
      throttled is implementation dependent and is outside the scope of
      this document."

How is a node supposed to determine how to set its priorities if each agent makes implementation-specific decisions about what those priorities mean? I understood the document to be saying that Diameter applications would have to define what he priority levels mean within their own contexts, but then I would have expected the interpretation of priorities amongst all nodes and agents implementing the same application to be the same.

(3) Section 8 says:

"Diameter nodes SHOULD use the PRIORITY_10 priority as this default value."
 
If the determination of the priority schemes are all application-specific, how is it appropriate for this spec to define what the default priority should be for all applications? Shouldn't applications specify their own defaults?

[Ballot comment]
Section 11 says: "DRMP gives Diameter nodes the ability to influence which requests are throttled during overload scenarios." But the information is not limited to use during overload scenarios, and the spec specifically allows its use for prioritized routing in absence of overload. This should be stated here too.

[Ballot comment]
In Section 6: excuse my ignorance, but how can priority information be conveyed to non-supporting endpoints (in 2 places)? And what is the point,as they don't support the extension?

In 9.1: it would be better to just have a table, instead of copying and modifying lots of text.

It would be good to have a short sentence saying how this extension affects non upgraded agents.

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-dime-drmp-04.txt. If any part of this review is inaccurate, please let us know.

IANA has a question about one of the actions requested in the IANA Considerations section of this document.

IANA understands that, upon approval of this document, there is a single action which IANA must complete.

In the AVP Codes subregistry of the Authentication, Authorization, and Accounting (AAA) Parameters registry located at:

https://www.iana.org/assignments/aaa-parameters/

a single, new AVP Code is to be registered as follows:

AVP Code: [ TBD-at-registration ]
Attribute Name: DRMP
Reference: [ RFC-to-be ]

IANA Question --> In section 9.1 of the current document 16 priority values are defined for the DRMP AVP code. Section 10.2 of the current document says that, "no new IANA registries are introduced by this document." However, are the priority values in section 9.1 intended to be AVP code specific values for the new DRMP AVP code?

As this document requests registrations in an Expert Review or Specification Required (see RFC 5226) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

IANA understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. 


Thank you,

Sabrina Tanamal
IANA Specialist
ICANN

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: draft-ietf-dime-drmp@ietf.org, lionel.morand@orange.com, dime-chairs@ietf.org, dime@ietf.org, stephen.farrell@cs.tcd.ie, "Lionel Morand"
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Diameter Routing Message Priority) to Proposed Standard


The IESG has received a request from the Diameter Maintenance and
Extensions WG (dime) to consider the following document:
- 'Diameter Routing Message Priority'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2016-03-24. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  When making routing and resource allocation decisions, Diameter nodes
  currently have no generic mechanism to determine the relative
  priority of Diameter messages.  This document addresses this by
  defining a mechanism to allow Diameter endpoints to indicate the
  relative priority of Diameter transactions.  With this information
  Diameter nodes can factor that priority into routing, resource
  allocation and overload abatement decisions.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dime-drmp/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-dime-drmp/ballot/


No IPR declarations have been submitted directly on this I-D.

1. Summary

The document shepherd is Lionel Morand. The responsible Area Director is Stephen Farrell.

This document defines a mechanism that allows Diameter nodes to indicate the relative priority of Diameter transactions.  With this information other Diameter nodes can factor the relative priority of requests into routing and throttling decisions. This mechanism is a solution to address throttling requirement introduced in Diameter overload control solution [RFC7068][RFC7683].

Intended status: Standards Track

2. Review and Consensus

The document starts by introducing the problematic to solve and describes various scenarios where the use of Diameter message priority can be useful before describing the Diameter priority mechanism.

The mechanism defined in this document is fairly simple. It consists in defining a new AVP, DRMP AVP, that can be included in Diameter requests and answers to indicate the priority of the command. 16 values are defined (from 0 to 15), Priority 0 being the highest priority. This priority value is used by Diameter nodes to determine the relative priority of the message. How to set the priority in the messages and how to use the priority information when making routing decisions or throttling is outside the scope of this document. It can be defined per application or can be implementation dependent.

The proposed solution has not been implemented yet, as vendors are waiting for IANA AVP code value assignment before implementing.  However, no issues are expected with implementation. Moreover, the solution defined in this document have been already introduced in standard specifications defined by 3GPP. It is therefore understood that the vendors implementing 3GPP specifications will implement this mechanism.

The document received a large support for adoption when initiated and it has been reviewed multiple times, with detailed comments and corrections. The version -03 addresses the last comments received after the WGLC process. There is a strong WG consensus on the content of this document, with a broad range of people, including key experts.

3. Security Considerations

The Security considerations section highlights the lack of e2e protection in Diameter. It is therefore assumed that the mechanism is used in a trusted environment.

4. IANA considerations

The IANA considerations section is consistent with the body of the document. All protocol extensions are associated
with appropriate reservations for IANA.

5. Intellectual Property

The author and contributor have confirmed conformance with IETF IPR rules (RFCs 3979, 4879, 3669, and 5378). There are no IPR disclosures on the document.

6. ID Nits

There are two IDnits that can be handled with a rev of the document when publishing the document;


  == Unused Reference: 'RFC5226' is defined on line 680, but no explicit
    reference was found in the text

  == Unused Reference: 'RFC4412' is defined on line 692, but no explicit
    reference was found in the text

7. Other points

The RFC 6735 defines the Diameter Priority AVPs that convey over Diameter a specific set of priority parameters that can be part of the user profile information retrieved by a AAA client from the AAA server.
These priority parameters are used to act on the user session managed by the Diameter client (e.g. access sessions or SIP sessions). There are not used to indicate relative priority of messages in the Diameter-based signaling networks. The RFC 6735 is therefore not linked to this new document.