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

[Mark Jones <[e-mail]>]

Hi Lothar,

Thanks for the thorough review. Comments inline. 

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On 
> Behalf Of Reith, Lothar
> Sent: June 21, 2009 5:54 PM
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: [Dime] Last Call: draft-ietf-dime-qos-attributes 
> (Quality of Service Attributes for Diameter) to Proposed Standard
> 
>  
> 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" 
> 

Agreed. We change this to "list of QoS policy rules" in the next revision.

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

We've reused the terms from the IEEE specs wherever possible. The IEEE 802.1D-2004 spec uses "user_priority parameter" rather than "P-bits" and so we assumed this was 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.
> 

This draft does not claim exhaustive support for all ethertype flags and features. The IEEE features will contine to be a moving target and so we focused on the ones required to satisfy current SDO requirements while ensuring that all the groups AVPs can be easily extended to handle new features. 

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

Agreed. We propose keeping the existing AVPs which use the Diameter Time datatype and adding a "fractional" AVP of type Unsigned32 to add additional precision to both the absolute and relative timestamps in the draft.

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

This is a QoS AVP draft and we have purposely avoided introducing charging aspects in the actions. The AVPs that determine the charging characteristics associated with the actions can always be added by applications that use these QoS AVPs and additionally require charging.

> 4.2 Issue regarding a lack of unambiguity of the definition 
> of the shape action:
> - shape to which token bucket size and depletion rate?

This is covered in the companion I-D on QoS-Parameters (draft-ietf-dime-qos-parameters).

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

This is not defined currently in the QoS-Parameters draft. We feel this kind of detail will be ironed out when the actual deployment gets done and the operator then states which part of the traffic contributes to the depleting counters. 

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

Please see response to comment 2.

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

Agreed that we need to expand the description of these values. The QoS-Authorized is delivered by the Authorization Server. The QoS-Available is what the client is able to apply (QoS-Available < QoS-Authorized).

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

Agreed. We'll clarify this. Charging for a given QoS must not start before the QoS-Resource is reserved.

> 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 is a typo and the server responds with QoS-Authorized as shown in Figure 6.

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

Agreed that the accounting server does not authorize QoS. We'll separate these two functions onto distinct servers for clarity. 

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

We are certainly not proposing a change in DCCA behaviour. Even if the QoS was reserved, an outage could still prevent delivery as you point out. Persumably, if Granted-Units (with/without QoS-Reserved) can not be subsquently delivered then the DCCA refund procedure would apply.

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

Agreed. We have no intention of reinventing DCCA here. We'll either clarify ensuring DCCA compliance or use a non-DCCA example.

Regards
Mark

> 
> 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-attrib
> utes-12.txt
> 
> 
> IESG discussion can be tracked via
> https://datatracker.ietf.org/public/pidtracker.cgi?command=vie
> w_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. 
> _______________________________________________
> DiME mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dime
>