Diameter Congestion and Filter Attributes
draft-ietf-dime-congestion-flow-attributes-02

[Ballot comment]
Thanks for addressing my comments. I still think the abstract is overly long (the first paragraph would have been enough), but that's up to you.  Otherwise, I think all my comments have been covered.

[Ballot comment]
the opsdir reviewer noted some questions which I think fall in line with some observations about document improvement:

from linda dunbar:

> I have reviewed this document as part of the Operational directorate's> ongoing effort to review all IETF documents being processed by the IESG.> These comments were written primarily for the benefit of the operational> area directors. Document editors and WG chairs should treat these> comments just like any other last call comments.> >  > > I have some questions for the proposed AVPs by this document.> > -          The ECN is marked on packets by network nodes in the middle.> Is it the Receiver of ECN marked data packets sending the proposed AVPs> to the Diameter Server?> > -          If no ECN marked data packets are received, does it mean the> receiver won’t send the AVPs being proposed by the draft?> > -          Diameter is the protocol for Authentication, Authorization,> and Accounting.  Is it the “originator” sending the AAA request? If yes,> the “Originator” may not even have any ECN marked packets, how does the> flow “Originator” constructed the proposed AVPs?>

[Ballot comment]
With some DIAMETER background, I can understand what the document specifies.
However, I agree with Martin's COMMENT, and Stephen's abstract-related COMMENT. The document should be improved

[Ballot discuss]
No general objection to the publication of the document. However, I am relaying a question from David Black as a DISCUSS point.

I assume that the draft is more than unclear in Section 3.2  about what traffic means. Is it a particular flow, a single packet, etc?

"I found an ECN concern, and hence added the TSV ADs to the CC line.

Section 3.2 says:

  The Congestion-Treatment AVP (AVP Code TBD) is of type Grouped and
  indicates how congested traffic, i.e., traffic that has Explicit
  Congestion Notification Congestion Experienced marking set or some
  other administratively defined criteria, is treated. 

That appears to say that the congestion treatment may be applied
solely to packets that have the CE (Congestion Experienced) marking.
That would be a problem, because the defined semantics of a CE marking
is that it applies to the entire flow (e.g., causes TCP to react as if
a packet has been dropped), hence the congestion treatment ought
to apply to the entire flow.

In other words, one wants to be able to use the ECN-IP-Codepoint
AVP as part of the condition that determines whether the filter rule
matches, but ignore that AVP (i.e., wildcard it) in determining what
traffic the action applies to, so that the response to detecting a
congested flow (i.e., packets with ECN field containing CE) applies
to all packets in the flow, regardless of the value in the CE field.

Otherwise, the result may be ineffective, as it won't encompass packets
in the congested flow that aren't CE-marked.

Am I reading the draft correctly?"

[Ballot comment]
Section 1, 1st paragraph:
It says "The first AVP provides direct support for ECN [RFC3168] in the IP header“. I am  sure that your draft is  ot providing any support for ECN in the IP header, as we have ECN in the IP header already, isn't it.
I guess you mean something like this "The first AVP provides direct support for filtering ECN marked traffic[RFC3168]“

[Ballot comment]
If this means folks are using ECN more then I'm glad to hear it. :)

In Section 5.1 there are three instances of "ECP-IP-Codepoint." I think these are meant to be "ECN-IP-Codepoint" right?

In Section 6, I had the same thought as Ben. There could be some sensitivity about the fact that a particular user experienced congestion, and that's worth calling out.

Comment for the WG: I note that RFC 6733 requires Diameter nodes to be able to negotiate TLS_RSA_WITH_RC4_128_MD5 and TLS_RSA_WITH_RC4_128_SHA (among other cipher suites) for use with TLS and DTLS. Given the publication of RFC 7465, those requirements should be revisited.

[Ballot comment]
This mostly looks good. I have a few comments that are not show stoppers:

substantive:

-- Abstract: I concur with Stephen that the abstract doesn't really address the heart of the matter. (It also seems longer than needed.)

-- 5.2: I don’t see the Congestion-Treatment AVP actually used in the example. At least if it is, it’s not called out. I think it would be helpful to explicitly show it. Also, can you add a reference for Excess-Treatment?

"If Excess-Treatment or Congestion-Treatment has occurred..."

Does this mean “if the conditions associated with Excess-Treatment or Congestion-Treatment have occurred”, or “Excess-Treatment or Congestion-Treatment have been sent in a Diameter message”?

--6, first sentence.

I’d like to see a little more “show your work" here. These AVPs carry new kinds of content. That, in itself, might add new security considerations (e.g. is the content privacy-sensitive, especially damaging if tampered with, etc). Please consider adding a few sentences describing the new content, and why you believe that content does or does not have new security considerations. You kind of do that for ECN-IP-Codepoint and Congestion-Treatment, but I don't see anything for the other two new AVPs.

(I'm probably the other person that Stephen mentioned consider such sentences as a red flag.)


Editorial:

-- Abstract: Please expand ECN and AVP on first mention (both in abstract and in body.)

-- 3.2, first paragraph "In case..."

I suggest either "If..." or "In the case that..."

-- 5.1: There are several instances of "ECP-IP-Codepoint" that I assume should be "ECN..."

[Ballot comment]
This mostly looks good. I have a few comments that are not show stoppers:

substantive:

-- Abstract: I concur with Stephen that the abstract doesn't really address the heart of the matter. (It also seems longer than needed.)

-- 5.2: I don’t see the Congestion-Treatment AVP actually used in the example. At least if it is, it’s not called out. I think it would be helpful to explicitly show it. Also, can you add a reference for Excess-Treatment?

"If Excess-Treatment or Congestion-Treatment has occurred..."

Does this mean “if the conditions associated with Excess-Treatment or Congestion-Treatment have occurred”, or “Excess-Treatment or Congestion-Treatment have been sent in a Diameter message”?

--6, first sentence.

I’d like to see a little more “show your work here. These AVPs carry new kinds of content. That, in itself, might add new security considerations (e.g. is the content privacy-sensitive, especially damaging if tampered with, etc). Please consider adding a few sentences describing the new content, and why you believe that content does or does not have new security considerations. You kind of do that for ECN-IP-Codepoint and Congestion-Treatment, but I don't see anything for the other two new AVPs.

(I'm probably the other person that Stephen mentioned consider such sentences as a red flag.)


Editorial:

-- Abstract: Please expand ECN and AVP on first mention (both in abstract and in body.)

-- 3.2, first paragraph "In case..."

I suggest either "If..." or "In the case that..."

-- 5.1: There are several instances of "ECP-IP-Codepoint" that I assume should be "ECN..."

[Ballot comment]
I think IANA gets what they need to do, but the RFC Editor will have to replace four different "TBD" with four different values.  It'd have been better to use "TBD1", "TBD2", "TBD3", and "TBD4", to make it less likely that something will go amiss.  It's probably fine to just say that you need to check it closely during AUTH48, to make sure that the right values got into the right places.

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

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

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

- 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?

- 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?

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

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

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

(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)

- 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?

=== 1. Summary ===

The document shepherd is Lionel Morand.
The responsible Area Director is Kathleen Moriarty.

This document defines optional Explicit Congestion Notification (ECN) and filter related attributes that can be used for improved traffic identification, support of ECN and minimized filter administration within Diameter. 

RFC 5777 (Traffic Classification and QoS Attributes for Diameter) defines a Filter-Rule AVP that accommodates extensions for classification, conditions and actions.

In this draft, the Classifier Grouped AVP contained in the Filter-Rule AVP is extended with the new ECN-IP-Codepoint AVP which gives the Explicit Congestion Notification (ECN) codepoint values (defined in RFC3168) to match in the IP header. Moreover, the Filter-Rule Grouped AVP itself is extended with a new Congestion-Treatment AVP that indicates how congested traffic should be treated.
The Flow-Count and Packet-Count AVPs are also defined in this document to be sent to report in application specific command information of the group of flows described by the Filter-Rule, IPFilterRule or other Diameter traffic filters. This information can be used by the application for improved decision making, Charging and rudimentary traffic profiling.

=== 2. Review and Consensus ===

The proposed extensions for RFC5777 are simple (definition of new AVPs in extendable Grouped AVPs), and there was no difficulty in coming to consensus on all points.
As it is only about defining new optional AVPs, there were no real discussion in the WG, considering that the proposed AVP definitions were OK.
Comments received in the meeting or on the mailing list have been taken into account and the document is seen as ready for publication. No concern/comment was received during the WGLC.

=== 3. Intellectual Property ===

Each author has confirmed conformance with BCP 78/79.  There are no IPR disclosures on the document.

=== 4. Other Points ===

The extensions to the RFC5777 regarding the use of the Filter-Rule and the Classifier Grouped AVPs proposed in this document are optional  and compatible with the existing RFC5777. No update of the RFC577 is required.

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

IANA has reviewed draft-ietf-dime-congestion-flow-attributes-01.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA's reviewer has the following comments/questions:

IANA understands that upon approval of this document, there is a single action which needs to be completed.

In the AVP Codes registry under the Authentication, Authorization, and Accounting (AAA) Parameters heading at

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

four new AVP codes are to be registered as follows:

AVP Code: [ TBD-at-registration ]
Attribute Name: ECN-IP-Codepoint
Reference: [ RFC-to-be ]

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

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

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

As this document requests registrations in an Expert Review 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 that needs 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.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Diameter Congestion and Filter Attributes) to Proposed Standard


The IESG has received a request from the Diameter Maintenance and
Extensions WG (dime) to consider the following document:
- 'Diameter Congestion and Filter Attributes'
  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 2015-06-01. 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


  This document defines optional ECN and filter related attributes that
  can be used for improved traffic identification, support of ECN and
  minimized filter administration within Diameter.

  RFC 5777 defines a Filter-Rule AVP that accommodates extensions for
  classification, conditions and actions. It 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.

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

  These optional attributes are forward and backwards compatible with
  RFC 5777.



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

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-dime-congestion-flow-attributes/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 Kathleen Moriarty.

This document defines optional Explicit Congestion Notification (ECN) and filter related attributes that can be used for improved traffic identification, support of ECN and minimized filter administration within Diameter. 

RFC 5777 (Traffic Classification and QoS Attributes for Diameter) defines a Filter-Rule AVP that accommodates extensions for classification, conditions and actions.

In this draft, the Classifier Grouped AVP contained in the Filter-Rule AVP is extended with the new ECN-IP-Codepoint AVP which gives the Explicit Congestion Notification (ECN) codepoint values (defined in RFC3168) to match in the IP header. Moreover, the Filter-Rule Grouped AVP itself is extended with a new Congestion-Treatment AVP that indicates how congested traffic should be treated.
The Flow-Count and Packet-Count AVPs are also defined in this document to be sent to report in application specific command information of the group of flows described by the Filter-Rule, IPFilterRule or other Diameter traffic filters. This information can be used by the application for improved decision making, Charging and rudimentary traffic profiling.

=== 2. Review and Consensus ===

The proposed extensions for RFC5777 are simple (definition of new AVPs in extendable Grouped AVPs), and there was no difficulty in coming to consensus on all points.
As it is only about defining new optional AVPs, there were no real discussion in the WG, considering that the proposed AVP definitions were OK.
Comments received in the meeting or on the mailing list have been taken into account and the document is seen as ready for publication. No concern/comment was received during the WGLC.

=== 3. Intellectual Property ===

Each author has confirmed conformance with BCP 78/79.  There are no IPR disclosures on the document.

=== 4. Other Points ===

As shepherd and WG chair, I consider that this document should update the RFC5777 as this document will enhance the existing definition of the Filter-Rule and the Classifier Grouped AVP defined in this RFC.