Re: [Dime] Stephen Farrell's No Objection on draft-ietf-dime-congestion-flow-attributes-01: (with COMMENT)

["Bertz, Lyle T [CTO]" <[e-mail]>]

Stephen,

Thank you for the review.  Our comments and suggested changes are below.

-----Original Message-----
From: DiME [mailto:[e-mail]] On Behalf Of Stephen Farrell
Sent: Monday, June 08, 2015 7:39 AM
To: The IESG
Cc: [e-mail]; [e-mail]
Subject: [Dime] Stephen Farrell's No Objection on draft-ietf-dime-congestion-flow-attributes-01: (with COMMENT)

Stephen Farrell has entered the following ballot position for
draft-ietf-dime-congestion-flow-attributes-01: No Objection

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-congestion-flow-attributes/



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


- abstract: This isn't clear enough that you're talking about using Diameter to help manage networks in which ECN may be used, as opposed to dealing with Diameter packets with the ECN bit set. While that may be obvious when one reads the text, some people will only see the abstract so I'd say maybe consider clarifying that here too.

>>>> Originally a title was suggested that included ECN.  An internal reviewer noted that at any one moment an administrator may not have ECN based Filter-Rules in place but could still use the Flow-Count and Packet-Count. We then realized that ECN was not mandatory and therefore was a bit soft in the abstract.  In fact that is why we say ' ECN or Diameter traffic', otherwise we would merely state 'ECN related'

>>> Another pass has been taken at the Intro, we included a couple of updates from other commenters and I will note that in their responses as well.
--------------  New Intro ----------------
This document defines optional Diameter attributes that can be used to help manage networks that use Explicit Congestion Notification (ECN) or Diameter traffic filters. These new attributes allow for improved data traffic identification, support of ECN and minimize Diameter filter administration.

RFC 5777 defines a Filter-Rule Attribute Value Pair (AVP) that accommodates extensions for classification, conditions and actions. It however, does not support traffic identification for packets using Explicit  Congestion Notification as defined in RFC 3168 and does not provide specific actions when the flow(s) described by the Filter-Rule are congested.

Further, a Filter-Rule can describe multiple flows but not the exact number of flows. Flow count and other associated data (e.g. packets) are not captured in Accounting applications, leaving administrators without useful information regarding the effectiveness or appropriateness of the filter definition.

The optional attributes defined in this document are forward and backwards compatible with RFC 5777.
---------------------------------------------

- intro: "the document" in 1st sentence is ambiguous - do you mean 3168 or this document? I assume s/the/this/ would be better.

>>>> We will change to "the document" to "this document".

- intro: 2nd last para: what is an "ECN application"? Maybe you mean "networks deploying/using ECN" or something?

>>>> We propose changing "ECN application" to "congestion management functions".

- 3.3: is a 64-bit counter maybe too big for a number of flows?
Would it be worth adding guidance to the effect that Diameter nodes ought have some max-believeable-flows setting just to avoid fat-finger or similar errors resulting in someone thinking there are 2^64-1 flows and trying to iterate over that number of things or allocate O(that) much memory?

>>>> This depends entirely on the scope of the filter (Classifier) put in the Filter-Rule.   There are some Diameter applications that group results and we did not want to force them into a situation where they needed a 64 bit version of a 32 bit AVP.

- 3.4: do you need to specify some kind of wrap-around rule for this? What value do I need to use if I've seen 2^64 packets?

>>>> There are numerous rules in the IETF and other standards bodies for wrap around in Diameter accounting and we felt that further specification is unnecessary.  (In fact, if we could reduce the amount and get to some consistency that would be fantastic but is out of the scope of this discussion.)

- 5.2: Please expand CCR on 1st use and provide a reference if one is needed. (Is it "Credit Control Request"?)

>>>> Yes it is Credit Control Request.   We will expand out the acronym for CCR at its first appearance (first paragraph in the section).

- 5.2: 2nd last para, last sentence: Thanks! I think it's good that folks are including this consideration in ongoing work.

>>>> You're welcome.  This is important to the authors and provides a compromise between what is necessary for congestion management and what is too much.

- Section 6: 1st sentence is not needed and is usually a red flag statement (for me, but not only me:-) Actually, you could just lose the first para entirely.

>>>> We are going to scratch the first sentence and add a bit more per Ben Campbell 's review.

(Two more quite nitty things below, but I'll ask anyway:-)

- section 6: does this define any new way in which a bad sending Diameter node could cause bad things to happen elsewhre in the network? (see comment above about section 3.3)

>>>> No. Sending more bad information to a Diameter application does not make the situation worse.  If the node was poor (and not just a bad actor) then sending more information that conflicts would be easier to detect.  However, I would not give credit to this proposal for making the detection of bad Diameter nodes easier.  I would presume if someone took the time to create a bad acting node they would have skills or clumsiness (depending upon intent) to report information in such a way that the Diameter application could not detect it regardless of the amount of information it sent.

- section 6: When I took a glance at the security considerations in 5777, it doesn't seem to consider that the "treatment" field could cause bad things to happen.  Is that worth mentioning here (if real) even if it ought be more properly handled in some kind of update of 5777 sometime in the (probably far;-) future?

>>>> Recommendations currently for the document is that it is not an update to 5777 so my concern would be that even if a discussion occurs here it would be missed by the casual reader of 5777.  As treatment action occurs based upon the larger Filter-Rule structure so I am reluctant to blame the hammer for hitting my finger but will probably do it anyway :D.  A general discussion of classifiers and actions would be good but it is far broader than this proposal (and many more pages imo but I am prone to long responses as well).
_______________________________________________
DiME mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dime

________________________________

This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.