Re: [Dime] Last Call: draft-ietf-dime-qos-attributes (Quality of Service Attributes for Diameter) to Proposed Standard

["Reith, Lothar" <[e-mail]>]

 
Dear all,

please find below a list of comments regarding the Last Call on: draft-ietf-dime-qos-attributes (Quality of Service Attributes for Diameter) to Proposed Standard

Where applicable, I have stated the issue and a proposed solution to fix the issue.

1. issue:  in Section 3.1 it is stated that
"QoS Resources AVP .......describes a list of policies" 

however, the ABNF definition in the line below specifies that the QoS Resource AVP contains a list of QoS-Rules. 

proposed solution: replace "describes a list of policies" by  "contains a list of QoS-Rules"

Background:
The question is if the term policies and QoS-Rules are meant synonymous in the context of the document. If that is the case, I suggest to replace the term "policies" with "Qos-Rules", as it is the only occurance of that term within the document. If that is not the case,  the meaning of the term policy in this document needs be defined, given that the term "policy" is somewhat overloaded. For example, one could define, that the terms "policy" and "QoS-Rule" are being used synonymously in the context of the document, except when referring to RFC5226 as a policy. Or one could state that a "QoS-Rule" is a type of "policy". 

Alternative Solution: replace "describes a list of policies" by "contains a list of policy rules" 

2.  issue: section 4.1.8.23 discusses Ethernet "user-priority".  I would recommend to review with IEEE on this to verify if "user-priority" or "P-bits" would be the most appropriate term. In addition, there seems to no consideration yet for the "drop eligibility indicator" contained in an S-Tag with Ethertype 0x88a8. It should be possible to formulate a QoS-Rule which considers the "drop eligibility indicator". Also it should be possible to formulate a mark action, which sets the value of the  "drop eligibility indicator" bit to 1. Along these lines, it should also be possible to formulate a QoS-Rule which considers MPLS EXP Bits of an incoming packet. And it should be possible to mark MPLS EXP bits.

3. issue in section 4.2.1: charging granularity not compliant with consumer protection legislation (at least in Germany)
Proposed Solution:  I would recommend to multiply the values by 10, in order to arrive at a granularity of one tenth of a second (split-second). This would allow to comply with some consumer protection regulations in the area of charging accuracy, such as a "telecommunication customer protection law" effective in Germany. I know of one voice switch vendor, who had to reprogramm his voice-switch accounting software because of that law, as a metering granularity of one second was not good enough to meet the legal demands in all cases. This was due to the possible errors in measuring the time at the start of a call and at the end of a call could add up to more than one second, even though the time measurement itself had a granularity of one second. As a minimum, the range must be doubled to a measurement granularity of a half-second, in order to be on the safe side regarding compliance with this law.

4.issues in section 5.1 the actions drop, shape and mark may require some further scrutiny and refinement

4.1 Issue regarding the drop action: Drop action does not differentiate, if the dropped packet shall get accounted.
one possible solution (not necessary the proposed solution): differentiate between
- drop without counting, i.e. drop without charging for the delivery to the point, where the packet gets dropped, because the packet did not get delivered to the customer, such as discarding unsolicited out of profile downstream traffic from some source in the Internet.
- drop after counting, i.e. drop with charging for the delivery of the packet to the point where it got discarded (if legally allowed). This may be applicable to out of profile upstream traffic.

4.2 Issue regarding a lack of unambiguity of the definition of the shape action:
- shape to which token bucket size and depletion rate?
- which bytes of the incoming packet count for depleting the token bucket? All bytes of the layer 2 Frame in case of a QoS-Rule at the Ethernet layer, where an IP header may not even be present? In this context: Is the term bandwidth in the "bandwidth AVP" defined as "net data rate" as in ANCP, or differently defined or undefined? 

4.3. Issue regarding the completeness of the scope of the mark action:
- only TOS byte, or also MPLS EXP bits and Ethernet P-bits ?
- only absolute mark, or also remarking rule  that depends on the previous setting the field?
Proposed solution regarding the first item: split the mark action into 3 different mark actions,  mark-TOS byte, mark-MPLS_EXP-bit and mark-P-bits. Consider to allow the presence of multiple mark actions in a single QoS-Rule. 
Proposed solution regarding the second item: Add actions for re-mark-TOS byte, re-mark-MPLS_EXP-bit and re-mark-P-bits, where the result of the re-mark-action depends on the former setting of the field being re-marked.

5. Issue in section 5.4 I do not quite understand the semantic differences between QoS Available, QoS Authorized and QoS Reserved, in particular if QoS Reserved is already accounting relevant. 
Solution: Verify and make sure that there is indeed a semantic difference, and that accounting for QoS Reserved is compliant with consumer protection laws.

6. issue in section 7.5 there is an example on how this may apply in combination with Diameter Credit Control, and it is stated there that " In this case the User is charged as soon as the Service Element (CC client) receives the service request. "
Proposed solution: Verify if  a procedure which starts charging without knowing, if the the QoS-Resource can actually be allocated does not violate consumer protection laws.

7. reading further on in this short section 7.5 it states the following:
 "In this case the client uses the "QoS-Desired" QoS-Semantics parameter in the QoS-Resources AVP that it sends to the Accounitng server. The server responds with a "QoS-Available" QoS-Semantics parameter in the QoS-Resources AVP"

This raises some doubts if the "accounting server" acts as an authorization server. There should be clear separation of accounting and authorization.
Proposed solution: Change the wording to make clear, that the accounting server does not authorize anything, otherwise, do not call it an accounting server,  but rather an authorization and accounting server, which would imply that both functions are combined in one server (which in large implementations is usually not the case). 

8. reading further on, there is a  Message shown   "CCA (Granted-Units, QoS-Resources(QoS-Authorized))"  which makes me wonder, what is being authorized here with DCC. Is it an authorization for a certain number of granted-Units delivered with a higher QoS and charged extra using a one time charge because of delivering these granted units with higher QoS?

If that would be the case,   it would  in my view be a bad practice, as the one-time charge mechanism would effectively be used for session based charging, but without the reservation mechanism. What happens, if the Granted-Units cannot be delivered with the higher QoS, say in case of an outage? Session based charging can handle this by means of not confirming the reservation within a time limit.  It would require extra complex logic to handle this situation, where the One-Time charge would have to be cancelled or compensated by a one-time bonus of same amount.

Proposed solution for issue 8: Use another example, which does not suggest to re-invent session based online charging using one-time charging events.


Best Regards,


Lothar Reith

Competence Practice Communications Technology

Detecon International GmbH 
Oberkasseler Str. 2 
53227 Bonn - Germany
 
Phone: [phone]
Mobile: [phone]
Fax: [phone]
mailto:[e-mail] 
http://www.detecon.com 

Detecon International GmbH
Aufsichtsrat: Hans-Jürgen Wickenhöfer (acting)
Geschäftsführung: Dr. Klaus Hofmann, Andreas Baumann
Handelsregister: Amtsgericht Bonn HRB 2093
Sitz der Gesellschaft: Bonn

==========================================================================================================================================================================
[Dime]Last Call: draft-ietf-dime-qos-attributes (Quality of Service Attributes for Diameter) to Proposed Standard

    * To: IETF-Announce <ietf-announce at ietf.org>
    * Subject: [Dime] Last Call: draft-ietf-dime-qos-attributes (Quality of Service Attributes for Diameter) to Proposed Standard
    * From: The IESG <iesg-secretary at ietf.org>
    * Date: Mon, 8 Jun 2009 07:08:51 -0700 (PDT)
    * Cc: dime at ietf.org
    * Delivered-to: dime at core3.amsl.com
    * List-archive: <http://www.ietf.org/mail-archive/web/dime>
    * List-help: <mailto:[e-mail]?subject=help>
    * List-id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
    * List-post: <mailto:[e-mail]>
    * List-subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:[e-mail]?subject=subscribe>
    * List-unsubscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:[e-mail]?subject=unsubscribe>
    * Reply-to: ietf at ietf.org

The IESG has received a request from the Diameter Maintenance and 
Extensions WG (dime) to consider the following document:

- 'Quality of Service Attributes for Diameter '
   <draft-ietf-dime-qos-attributes-12.txt> as a 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 at ietf.org mailing lists by 2009-06-22. Exceptionally, 
comments may be sent to iesg at ietf.org instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-attributes-12.txt


IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16192&rfc_flag=0

    * Prev by Date: [Dime] WGLC Comments on draft-ietf-dime-rfc3588bis-17.txt, pp. 14-20
    * Next by Date: Re: [Dime] New draft for Diameter ERP: poll for adoption
    * Previous by thread: [Dime] WGLC Comments on draft-ietf-dime-rfc3588bis-17.txt, pp. 14-20
    * Next by thread: [Dime] Fwd: New Version Notification for draft-korhonen-dime-mip6-feature-bits-01
    * Index(es):
          o Date
          o Thread

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.