Subject: FW: [Tsvwg] Need for volunteers forreviewing draft-ietf-tsvwg-diffserv-class-aggr

From: "Julie Ann Connary \(jconnary\)" <[email-masked]>
Date: Thu, 11 Jan 2007 14:36:19 -0800

RE-forwarding as well as I too did not see my review on the mailing
list. 

-----Original Message-----
From: Julie Ann Connary (jconnary) 
Sent: Wednesday, December 27, 2006 2:43 PM
To: 'Magnus Westerlund'
Cc: tsvwg
Subject: RE: [Tsvwg] Need for volunteers forreviewing
draft-ietf-tsvwg-diffserv-class-aggr

Review of Draft-ietf-tsvwg-diffserv-class-aggr

Overall - I am ok with the concept of this draft and believe it provides
a valuable guideline along with RFC 4594. Thus most of my comments are
editorial in nature with the exception of Unkown DSCP and discussions
surrounding them. I believe that this part should be "beefed" up
(section 4.1.4) to help provide clear guidelines to Network QoS
Architects and Designers who frequently do not appropriately plan for
what to do with traffic that is not marked with a DSCP that is to be
classified for differential treatment within their DS domain and
incorrectly assume that magically all traffic is marked/re-marked to
DSCP 0.

Thanks, JA

------------------------------------------------------

1. Introduction, Page 3, 2nd and 4th paragraphs - wording consistency

"However, sub-second surges that occur in the best-designed of networks
[14] affect real-time applications. Moreover, Dos Loads, worms, and
network disruptions such as that of 11 September 2001 affect routing
[15]. Our objective is to prevent disruption to routing (which in turn
affects all services), and jitter-sensitive services that may be
revenue-bearing" 

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

I would suggest to be consistent in the wording and utilize "real-time"
in both cases. Second would recommend to drop the "that may be
revenue-bearing" in the first citation. Services in the elastic class
like multi-media streaming may also be revenue-bearing. The protection
is for the traffic characteristics with the main differentiator between
the real-time and the assured elastic is that the first is jitter
sensitive. Both have loss/delay requirements greater than BE/Standard
and hence require special treatment throughout the network to prevent
service disruption or service quality degredation during congestion
events (whether they be at the access or momementary surges in the core
as described here.)

Might consider rewording the first to something like:

"However, sub-second surges that occur in the best-designed of networks
[14] affect real-time applications. Moreover, Dos Loads, worms, and
network disruptions such as that of 11 September 2001 affect routing
[15]. Our objective is to prevent disruption to routing (which in turn
affects all services), protect real-time jitter sensitive traffic while
minimizing loss and delay of sensitive elastic traffic" 

2. Terminology - Page 4 - is a reference needed here to RFC 2475:

"This document assumes the reader is familiar with the terms used in
differentiated services."

3. Terminology - Page 4 - Remove word "none" from second sentence, first
paragraph

"This document provides the definitions for new terms introduced by this
document and referencing information for existing none differentiated
services terms defined in existing RFCs."

4. Terminology - Page 4 - Definition of Treatment Aggregate

This definition is slightly confusing (as the Draft does suggest
recommened standard DSCP's for the Aggregated DiffServ Classes)  and
suggest re-wording as well as well as references to RFC 2474 and RFC
3086 for the terms specified.

"Treatment Aggregate. This term is used here to indicate the aggregate
of DiffServ Service Classes. This is different from Behavior Aggregate
and Traffic Aggregate because Treatement Aggregate is only concerned
with the treatment of the aggregated traffic. It does not concern itself
with how the aggregate traffic is marked, and hence does not put a
restriction on the aggregated traffic having a signle diffserv codepoint
that have a single PHB."

To something like:

"Treatment Aggregate: is defined as the aggregate of two or more
DiffServ Service Classes[5]. A Treatment Aggregate is concerned only
with the forwarding treatment of the aggregated traffic which may be
marked with multiple DSCPs. A Treatment Aggregate differs from a
Behavior Aggregate [4] and Traffic Aggregate [RFC 3086], each of which
indicate the aggregation of traffic having the same DSCP and a utilizing
a single PHB."

5. Terminology - DiffServ Service Class - update reference to be RFC
4594 vs. the draft cited.

7. Section 3 (number 5) and Section 4.1.2 - Real Time treatment
Aggregate - reconcile use of words MUST and SHOULD.

Section 3, number 5 -- says "must" while section 4.1.2 says "should":

"5. Each treatment aggregate has limited resources, hence traffic
conditioning and/or admission control MUST be performed for each service
class aggregated into the treatment aggregate."

"Traffic in each service class that is going to be aggregated into the
treatment aggregate SHOULD be conditioned prior to aggregation...."

Section 4.1.2 includes admission control and policing of the Treatment
Aggregate as well:

"Furthermore, additional admission control and policing may be used on
the sum of all service classes aggregated."

Suggest re-wording this to the same as in section 5.2:

"Furthermore, additional admission control and policing may be used on
the sum of all traffic aggregated into this Treatment Aggregate."

8. Figure 2, Figure 3 - Default Service Class, Section 4.1.4

Inconsistency in recommendation for DSCP mapped into the Default Service
Class throughout Document. Text and Tables should be clear about
"unkown" DSCP. 

Figure 2 indicates Default or CS0 and CS1. Figure 3 indicates the same.
Section 4.1.4 indicates "All remaining elastic traffic" and indicates it
"may include the follwing service classes from the DiffServ Service
Classes [5], in addition to other locally defined classes: Standard, Low
priority Data."

[5] indicates for Standard Service Class - also Default or CS0, but
Figure 5 in [5] indicates DF(CS0) + other.

Recommend that all tables have either a row for "other" or DF(CS0) +
other for consistency with wording of text throughout this RFC and
others including [5 - 4594, RFC 2474 etc.) 

This is something that implementors and network architects struggle with
in the Industry and often forget when making a plan - i.e. the plan just
includes CS0. While an implementation "could" remark all unkown traffic
to DSCP 0 at the edge - it is not required. Many implementations today
defaultly classify all unkown traffic into the default queue with no
configuration required to achieve this behavior. 

Recommend adding some verbage to Section 4.1.4 to discuss and indication
within the recommended standard DSCP tables to indicate what is to be
done with "unkown" DSCP in this model. Especially since throughout the
document, it is stressed that the original DSCP marking should be
maintained. If a Domain does not provide all service classes - but is
inter-connected with a domain that does, it may be necessary to carry
that traffic as Elastic throughout the domain, while maintaining the
original DSCP.

9. Security Considerations, 3rd paragraph - confusing wording:

Paragraph 3 is a very important paragraph/concept that requires one DS
domain to trust the other DS domains as well as endpoints etc. to do the
right thing, not only in marking packets but adhering to admission
control when utilized. 

It is not quite understood what the author's intent of the last sentence
of the 3rd paragraph is:

"To the best of the author's knowledge, there is no known technical way
to respond to or act upon a data stream that has been admitted for
service but that it is not intended for authenticated use."

Is the author meaning how to respond to traffic that is inappropriately
marked as say real-time traffic, but that did not use admission control?

10. References:  Add RFC 3086 due to reference to Traffic Aggregate
within definitions.

-----Original Message-----
From: Magnus Westerlund [mailto:[email-masked]] 
Sent: Friday, December 08, 2006 3:07 AM
To: Magnus Westerlund
Cc: tsvwg
Subject: Re: [Tsvwg] Need for volunteers forreviewing
draft-ietf-tsvwg-diffserv-class-aggr

Hi

And we would appreciate if the reviews where done before Christmas, i.e.

within the next 2 weeks.

Cheers

Magnus

Magnus Westerlund skrev:
> Hi,
> 
> To make progress we need some reviewers to read and comment on 
> "Aggregation of DiffServ Service Classes":
>
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-diffserv-class-aggr
-01.txt 
> 
> 
> We chairs don't think we can proceed with this draft until we seen
some 
> confirming reviews from the WG participants. So please volunteer.
> 
> If you are willing to do this review please indicate so to us chairs.
> 
> Cheers
> 
> Magnus Westerlund
> 
> IETF Transport Area Director & TSVWG Chair
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVA/A
> ----------------------------------------------------------------------
> Ericsson AB                | Phone +46 8 4048287
> Torshamsgatan 23           | Fax   +46 8 7575550
> S-164 80 Stockholm, Sweden | mailto: [email-masked]
> ----------------------------------------------------------------------
> 
> 

-- 

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------