Subject: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-diffserv-class-aggr-00.txt

From: [email-masked]
Date: Fri, 30 Jun 2006 15:50:01 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Area Working Group Working Group of the IETF.

	Title		: Aggregation of DiffServ Service Classes
	Author(s)	: K. Chan, et al.
	Filename	: draft-ietf-tsvwg-diffserv-class-aggr-00.txt
	Pages		: 18
	Date		: 2006-6-30
	
   In the core of a high capacity network, service differentiation is
   still needed to support applications' utilization of the network.
   Applications with similar traffic characteristics and performance
   requirements are mapped into diffserv service classes based on end-
   to-end behavior requirements of the applications as indicated by
   Diffserv Service Classes [5].  However, some network segments may be

   configured in such a way that a single forwarding treatment may
   satisfy the traffic characteristics and performance requirements of
   two or more service classes.  In these cases, it may be desirable to
   aggregate two or more Diffserv Service Classes [5] into a single
   forwarding treatment.  This document provides guidelines for the
   aggregation of Diffserv Service Classes [5] into forwarding
   treatments.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-diffserv-class-aggr-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-tsvwg-diffserv-class-aggr-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-tsvwg-diffserv-class-aggr-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Kwok-Ho Chan" <[email-masked]>
Date: Fri, 30 Jun 2006 17:09:00 -0400

In addition to the posted draft as indicated here,
I would like to bring to your attention that the improvements/changes 
to this draft
are based on the review of the previous version of the draft by David 
Black, the
TSVWG official reviewer of this draft.

Many thanks to David on his guidance and attention to this work.

PLEASE SEE AT THE END OF THIS E-MAIL DAVID'S REVIEW COMMENTS
AND THEIR CORRESPONDING RESPONSES/RESOLUTIONS/DRAFT CHANGES.

This is a relatively long E-Mail due to this content.
But I would like to make this content available to the WG.

Please review this draft and send us any comments or questions.
Thank you very much for your attention.
-- Kwok --

At 03:50 PM 6/30/2006, [email-masked] wrote:
>Content-Type: text/plain
>Content-ID: <[email-masked]>
>
>ENCODING mime
>FILE /internet-drafts/draft-ietf-tsvwg-diffserv-class-aggr-00.txt
>
>
><ftp://ftp.ietf.org/internet-drafts/draft-ietf-tsvwg-diffserv-class-aggr-00.txt>

David Black's Review Comments and their corresponding responses below:
------------------------------------------------------------------------------------------------------------

Details of David Black's review comments and their resolutions.

I have added numbering to the review comments and have used:
<ANS> to indicate responses
<Old> to indicate original text in
       draft-chan-tsvwg-diffserv-class-aggr-03.txt.
<New> to indicate new text in
       draft-ietf-tsvwg-diffserv-class-aggr-00.txt

1. Abstract needs to make strong connection to Diffserv Service
    Classes draft.

    <ANS>
    Added connection to Diffserv Service Classes draft, please
    see the difference between the <Old> and <New> text below.

    <Old>
    In the core of a high capacity network, service differentiation is
    still needed to support applications' utilization of the network.
    Applications with similar traffic characteristics and performance
    requirements are mapped into different diffserv service classes based
    on end-to-end behavior requirements of the applications.  However,
    some network segments may be configured in such a way that a single
    forwarding treatment satisfy the traffic characteristics and
    performance requirements of two or more service classes.  For such
    cases, it may be desirable to aggregate two or more service classes
    into a forwarding treatment.  This document provides guidelines for
    aggregation of service classes into forwarding treatments.

    <New>

2. General concern - the primary value of this draft appears to
    be the MPLS details in Section 5.  Would it be better to trim
    the title/scope of this draft down to target just MPLS as opposed
    to claiming that it's a general approach to aggregation?  I'd
    at least recommend that the draft title indicate its applicability
    to MPLS (e.g., "Differentiated Service Class Aggregation,
    Including Mapping to MPLS"), as that's clearly a strong motivation
    for this design approach.

    <ANS>
    We are trying to establish a framework for performing aggregation of
    DiffServ Service Classes (DSSCs), providing guidance, not absolute
    methods.  The use of MPLS is just one possible way of doing it.
    We don't try to be authoritative on MPLS solutions or give all
    possible MPLS solution here (we only mentioned E-LSP).
    Hence Section 5 is one value this draft adds, but I would not
    make that the only or main value.
    We clarified these points in the draft as indicated by the
    change from <Old> to <New> below:

    At bottom of Introduction section at bottom of page 3 of <Old>
    <Old>
    treatment aggregate.  Notice in a given domain, we recommend the
    supported service classes be aggregated into forwarding treatment
    aggregates, this does not mean all service classes needs to be
    supported and hence not all forwarding treatment aggregates needs to
    be supported.  Which service classes and which forwarding treatement
    aggregates is supported by a domain is up to the domain
    administration and may be influenced by business reasons.  We've also
    provided some terminology and requirement for performing this
    aggregation.

    <New:Modified text>
    Note that in a given domain, we may recommend that the supported
    service classes be aggregated into forwarding treatment aggregates;
    however, this does not mean all service classes need to be supported
    and hence not all forwarding treatment aggregates need to be
    supported.  Which service classes and which forwarding treatment
    aggregates are supported by a domain is up to the domain
    administration and may be influenced by business reasons.

    In this document, we've provided:

    o  definitions for terminology we use in this document,

    o  requirements for performing this aggregation,

    o  an example of performing this aggregation over MPLS using E-LSP.

    <New:Added new paragraph at bottom of Introduction section>
    An example of aggregation over MPLS networks using E-LSP, EXP
    Inferred PHB Scheduling Class (PSC) Label Switched Path (LSP), to
    realize the treatment aggregates is provided.  Note that the MPLS
    E-LSP is just an example; this document does not exclude the use of
    other methods.

3. Introduction jumps straight from the need for differentiation
    for QoS (end of second paragraph) to aggregated classes (third
    paragraph).  It needs to spend more time on describing what
    the service classes draft did and then walk into the need to
    aggregate its classes (which the latter part of the fourth
    paragraph does a reasonable job of motivating).

    <ANS>
    Added a new third paragraph into the Introduction section as below.

    From the Introduction section on <Old> page 3 (3rd and 4th paragraph)
    (with the deletion of 3rd paragraph in the process):

    <Old:Deleted 3rd paragraph>
    The treatment aggregates recommended herein are designed to aggregate
    the service classes in Diffserv Service Classes [5] in such a manner
    as to protect real-time traffic and routing, on the assumption that
    real-time sessions are protected from each other by admission at the
    edge, and provide a staged response to stress.

    <Old:Changed 4th paragraph>
    The document Diffserv Service Classes [5] provides the basic diffserv
    classes from the points of view of the application requiring specific
    end-to-end behaviors from the network.  At some network segments of
    the end-to-end path, the number of levels of network treatment
    differentiation may be less than the number of service classes that
    the network segment needs to support.  In such situation, that
    network segment needs to use the same treatment to support more than
    one service class.  In this document we provide guidelines of how
    multiple service classes may be aggregated into a forwarding
    treatment aggregate.  Notice in a given domain, we recommend the
    supported service classes be aggregated into forwarding treatment
    aggregates, this does not mean all service classes needs to be
    supported and hence not all forwarding treatment aggregates needs to
    be supported.  Which service classes and which forwarding treatement
    aggregates is supported by a domain is up to the domain
    administration and may be influenced by business reasons.  We've also
    provided some terminology and requirement for performing this
    aggregation.

    <New:Changed 4th paragraph>
    The document "Diffserv Service Classes" [5] defines the basic
    diffserv classes from the points of view of the application requiring
    specific end-to-end behaviors from the network.  The service classes
    are differentiated based on the traffic-payload's tolerance to packet
    loss, delay, and delay variation (jitter).  Different degrees of
    these criterions form the foundation for supporting the needs of
    real-time and elastic traffic.  The Diffserv Service Classes [5]
    document also provides recommendations for the treatment method of
    these service classes.  But, at some network segments of the end-to-
    end path, the number of levels of network treatment differentiation
    may be less than the number of service classes that the network
    segment needs to support.  In such a situation, that network segment
    may use the same treatment to support more than one service class.
    In this document we provide guidelines on how multiple service
    classes may be aggregated into a forwarding treatment aggregate.
    Note that in a given domain, we may recommend that the supported
    service classes be aggregated into forwarding treatment aggregates;
    however, this does not mean all service classes need to be supported
    and hence not all forwarding treatment aggregates need to be
    supported.  Which service classes and which forwarding treatment
    aggregates are supported by a domain is up to the domain
    administration and may be influenced by business reasons.

    In this document, we've provided:

    o  definitions for terminology we use in this document,

    o  requirements for performing this aggregation,

    o  an example of performing this aggregation over MPLS using E-LSP.

    <New:Added new paragraph>
    The treatment aggregate recommendations are designed to aggregate the
    service classes [5] in such a manner as to protect real-time traffic
    and routing, on the assumption that real-time sessions are protected
    from each other by admission at the edge.

4. Section 2 - Which RFCs?  Cite them and name the sections that
    the reader should be familiar with to understand the terminology.

    <ANS>
    Please see the new Terminology section.

5. Section 3 - Why should available service differentiation be
    lower in the "middle of the network"?  For that matter "middle
    of what/which network"?  I'd just delete that phrase rather
    than try to explain it.  If this point is important, it probably
    needs to be explained in terms of diffserv domains and/or regions.

    <ANS>
    Changes made as recommended.
    Please see modified section 3 first paragraph below.

    <Old>
    In some deployments, especially in the middle of the network where
    network capacity is higher, traffic treatment differentiation may be
    less granular.  In these deployments, aggregation of the different
    service classes may be more practical.

    <New>
    In diffserv domains where less granular traffic treatment
    differentiation is provided, aggregation of the different service
    classes [5] may be required.

6. Section 3 - This is a requirements section, not a protocol
    specification section - it's stating requirements that the rest
    of the draft has to (and does) meet.  RFC 2119 terminology is
    not appropriate - change SHOULD, MUST, etc. to lower case.

    <ANS>
    Changes made as suggested.  Please see section 3 of <New>.

7. Section 4 - Rewrite first paragraph to use complete English
    sentences.  I can't parse the current text ... this is the worst
    of a number of problems with the English - an editing pass from
    a tech writer who's a native speaker of English would be a very
    good idea.

    <ANS>
    Made English language improvement to section 4 first paragraph.
    Also improved the whole document based on native-English-speaking
    reviewer suggestions.

8. Section 4.1 - First paragraph is attempting to be a summary of
    this section and its approach, but doesn't convey that well.
    Needs something like "This section explains why the use of ..."

    <ANS>
    Rewritten section 4.1 first paragraph.  Please see below.

    <Old>
    For most of today's high speed links, the use of one network control
    traffic treatment aggregate and three user traffic treatment
    aggregates is sufficient to handle the requirement of all the service
    classes indicated in Diffserv Service Classes [5].  We use the
    performance requirement (tolerance to loss, delay, and jitter) from
    the application/end user as the guidance on how to map the service
    classes into treatment aggregates.  We have also used Section 3.1 of
    RFC 1633 [6] to provide us with guidance on the definition of Real
    Time and Elastic application requirements.  An overview of the
    mapping between service classes and four treatment aggregates is
    provided by Figure 1, with the mapping based on performance
    requirement.

    <New>
    This section explains one way of performing this aggregation by using
    four treatment aggregates.  The use of four treatment aggregates
    assumes that the resources allocated to each treatment aggregate is
    sufficient to honor the required behavior of each service class [5]
    in each of the four treatment aggregates.  We use the performance
    requirement (tolerance to loss, delay, and jitter) from the
    application/end-user as a guide on how to map the service classes
    into treatment aggregates.  We have also used Section 3.1 of RFC 1633
    [6] to provide us with guidance on the definition of Real-Time and
    Elastic applications.  An overview of the mapping between service
    classes and the four treatment aggregates is provided by Figure 1,
    with the mapping being based on performance requirements.  In Figure
    1, the right side columns of "Service Class", "Tolerance to Loss/
    Delay/Jitter" are from Figure 2 of Diffserv Service Classes [5].

9. Why "high speed links"?  Reminds me of "middle of the network"
    in Section 3, and I'd delete this phrase as well.  Also note
    that slower links are more likely to bottleneck and hence
    need QoS differentiation (vs. faster links in same network,
    all other things being equal, which they almost never are ...).

    <ANS>
    Please see removal of "high speed links" sentence in <New> text
    for #8 above.

10. I presume the right hand side of Figure 1 is copied from the
     Diffserv Service Classes draft - if that's what was done, say so.

     <ANS>
     Please see change made for section 4.1 first paragraph (at bottom)
     as indicated in <New> of #8 above.

11. Section 4.1.x - All of these sections recommend preserving the
     separate DSCPs of the individual service classes that are
     aggregated.  Explain how that could/should be done.

     <ANS>
     Please see new paragraph added to the bottom of section 4.1.

     <New>
     As we are recommending to preserve the notion of the individual end-
     to-end service classes, we also recommend that the original DSCP
     field marking not be changed when treatment aggregates are used.
     Instead, classifiers that select packets based on the contents of the
     DSCP field should be used to direct packets from the member DiffServ
     Service Classes into the queue that handles each of the treatment
     aggregates, without remarking the DSCP field of the packets.  This is
     summarized in Figure 2, which shows the behavior each Treatment
     Aggregate should have, and the DSCP field marking of the packets that
     should be classified into each of the treatment aggregates.

12. Section 4.1.1 - Why CS6?  Explain.

     <ANS>
     CS6 is simply just the DSCP field value used for Network Control
     Service Class in draft-ietf-tsvwg-diffserv-service-classes-02.txt.
     Removed the mention of CS6 in the text.

13. Section 4.1.2 - Say that this is the EF PHB.  Should its
     recommended/default DSCP be used for the aggregate?

     <ANS>
     The EF recommended/default DSCP (101110) is one of the code points
     being carried by this treatment aggregate.  But it is not the only
     one (please see Figure 2 on page 8 of -00 of this draft).
     We recommend to NOT remark the other code points to 101110.
     Hence no change to text of the draft.

14. Section 4.1.3 - Say that this is one of the AF PHB groups.
     Which DSCPs should be used?

     <ANS>
     The DSCP of the packet is recommended to remain in the same
     AF PHB group as its original DSCP marking.
     Please see text change to section 4.1.3 third paragraph below.

     <Old>
     The DSCPs of the original service classes remain an important
     consideration and should be preserved during aggregation.  Traffic

     <New>
     The DSCP values belonging to the AF PHB group of the original service
     classes remain an important consideration and should be preserved
     during aggregation.  This treatment aggregate should maintain the AF
     PHB group marking of the original packet.  For example, AF3x marked
     packets should remain AF3x marked within this treatment aggregate.

15. Sections 4.1.1 and 4.1.4 - RFC 2309 is not a PHB spec.
     What are you trying to do?

     <ANS>
     This was left over from some old text.
     Changes:
     For 4.1.1, removed reference to RFC 2309.
     For 4.1.4, replaced reference to RFC 2309 with reference
     to RFC 2474 section 4.1.

16. Section 4.2 - I don't understand the DSCP lists on the right
     hand side of Table 2.  I think you need to talk about whether
     the aggregates are marked with a common DSCP vs. combining
     separate DSCPs into a common queue, which may also clear up
     my comment on preserving separate DSCPs above.

     <ANS>
     Thank you for the comment.  Made changes to clear this up.
     Please see resolution for Issue Item # 11 above.
     In addition, Figure 2 moved to end of section 4.1, added some
     text to describe the table, and deleted section 4.2.

17. Section 5 - Ask Francois LeFaucheur to look at this Section.

     <ANS>
     Will ask Francois after the updated draft is posted.

18. The footnote on Figure 3 is not explained - say how the
     drop probability differs between the two values in each case.

     <ANS>
     The example here assumes the LSPs used can transport multiple
     Ordered Aggregates, so that the EXP field of the MPLS Shim
     Header conveys to the LSR the PHB to be applied to the packet.
     This information in the EXP field includes both the packet's
     scheduling treatment and its drop precedence.  Hence using E-LSP.
     Changing the footnote as follows:

     <Old>
     Notes *: For Assured Elastic (and Elastic) Treatment Aggregate, the
     usage of 010 or 011 (000 or 001) depends on the drop probability.

     <New>
     Notes *: For Assured Elastic (and Elastic) Treatment Aggregate, the
     usage of 010 or 011 (000 or 001) as EXP field value depends on the
     drop probability.  Packets in the LSP with EXP field of 011 (001)
     have a higher probability of being dropped than packets with an EXP
     field of 010 (000).