Re: [Dime] Fwd: New Version Notification for draft-donovan-dime-drmp-00.txt

[Janet P Gunn <[e-mail]>]

Steve,

For instance, in the current draft, section 4 (Problem Statement) has a 
"Note":
      Note: There are a number of application specific definitions
      indicating various views of application level priority for
      different requests.  Using these application specific priority
      AVPs as input to throttling and other Diameter routing decisions
      would require Diameter agents to understand all applications and
      do application specific parsing of all messages in order to
      determine the priority of individual messages.  This is considered
      an unacceptable level of complexity to put on elements whose
      primary responsibility is to route Diameter messages.

I think that this is MUCH more important than just a "Note", and could be 
restated as a requirement, such as

"The marking scheme SHOULD NOT require the Diameter Agents to understand 
all application specific AVPs"

That made me think that there are probably other such ground rules which 
should be made prominent in the problem statement. Rather that 
re-inventing the wheel, what can be reused form previous efforts.

For instance. I think this requirement from RFC 3689, is probably relevant 
here

     " Policy MUST be kept separate from label(s).  This topic has
      generated a fair amount of debate, and so we provide additional
      guidance from the following:

      A set of labels may be defined as being related to each other.
      Characteristics (e.g., drop precedence) may also be attributed to
      these labels.  [11] is an example of a related set of labels based
      on a specific characteristic.

      However, the mechanisms used to achieve a stated characteristic
      MUST NOT be stated in the definition of a label.  Local policy
      determines mechanism(s) used to achieve or support a specific
      characteristic.  This allows for the possibility of different
      mechanisms to achieve the same stated characteristic.

      The interaction between unrelated labels MUST NOT be embedded
      within the definition of a label.  Local policy states the actions
      (if any) to be taken if unrelated labeled traffic merges at a
      node.

      Finally, labels may have additional characteristics added to them
      as a result of local policy."

And so on.

I am NOT suggesting a separate requirements document, and I am NOT 
suggesting "specifying how to set those priorities."  I agree that   "this 
is up to the individual applications to specify."

I am suggesting setting some basic "ground rules" in the "Problem 
Statement".

I am working on detailed comments, but since this is essentially a 
"meta-comment", I wanted to get it out separately.

Janet



This is a PRIVATE message. If you are not the intended recipient, please 
delete without copying and kindly advise us by e-mail of the mistake in 
delivery. NOTE: Regardless of content, this e-mail shall not operate to 
bind CSC to any order or other contract unless pursuant to explicit 
written agreement or government initiative expressly permitting the use of 
e-mail for such purpose.



From:   Steve Donovan <[e-mail]>
To:     Janet P Gunn/USA/CSC@CSC
Cc:     "[e-mail]" <[e-mail]>, DiME <[e-mail]>
Date:   04/24/2015 12:03 PM
Subject:        Re: [Dime] Fwd: New Version Notification for 
draft-donovan-dime-drmp-00.txt



Janet,

The core requirement is to give Diameter applications the ability to 
specify a priority that can then be used to drive Overload abatement 
behavior.  

I am open to making this crisper in the next version of the draft.

I don't envision this draft specifying how to set those priorities.  This 
is up to the individual applications to specify.

Steve

On 4/24/15 10:25 AM, Janet P Gunn wrote:
I am finally looking at this document in detail. 

At the highest level, what strikes me is that it doesn't have a lot of 
specificity on the requirements it is intended to meet. 

Since you reference the analogy with SIP RPH (RFC4412), it might make 
sense to look at the requirements specs that led to RPH (RFC -3487 
“Requirements for Resource Priority Mechanisms for the Session Initiation 
Protocol (SIP)” and RFC-3689 “ETS General Requirements” - which is more 
generally about priority marking), and see which, if any, are relevant for 
Diameter. 

Janet

This is a PRIVATE message. If you are not the intended recipient, please 
delete without copying and kindly advise us by e-mail of the mistake in 
delivery. 
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to 
any order or other contract unless pursuant to explicit written agreement 
or government initiative expressly permitting the use of e-mail for such 
purpose. 


Steve Donovan <[e-mail]> 
Sent by: "DiME" <[e-mail]> 
03/06/2015 11:52 AM 


To
"[e-mail]" <[e-mail]> 
cc

Subject
[Dime] Fwd: New Version Notification for       
 draft-donovan-dime-drmp-00.txt








All,

I have submitted a draft proposing work on defining Diameter routing 
message priority.  The primary use case for the draft is to give the 
ability to mark different requests with different priorities, giving 
Diameter nodes making DOIC throttling decisions additional information on 
which requests should be throttled first.

The draft outlines a number of considerations on the design of the 
mechanism, should the working group decide to take on the work.

I will be requesting adding this as a DIME working group milestone at the 
Dallas IETF meeting.

Regards,

Steve 


-------- Forwarded Message -------- 
Subject: 
New Version Notification for draft-donovan-dime-drmp-00.txt 
Date: 
Fri, 06 Mar 2015 08:47:36 -0800 
From: 
[e-mail] 
To: 
Steve Donovan <[e-mail]>, Steve Donovan 
<[e-mail]>



A new version of I-D, draft-donovan-dime-drmp-00.txt
has been successfully submitted by Steve Donovan and posted to the
IETF repository.

Name:                                  draft-donovan-dime-drmp
Revision:                 00
Title:                                  Diameter Routing Message Priority
Document date:                 2015-03-06
Group:                                  Individual Submission
Pages:                                  11
URL:            
http://www.ietf.org/internet-drafts/draft-donovan-dime-drmp-00.txt
Status:         https://datatracker.ietf.org/doc/draft-donovan-dime-drmp/
Htmlized:       http://tools.ietf.org/html/draft-donovan-dime-drmp-00


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

                                                                          
       


Please note that it may take a couple of minutes from the time of 
submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat




_______________________________________________
DiME mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dime