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

From: Brian E Carpenter <[email-masked]>
Date: Wed, 05 Jul 2006 08:31:34 +0200

> 9.  Acknowledgements
> 
>    This document have benefitted from discussions with numerous people,
>    especially Shane Amante and Brian Carpenter.

That's pretty generous, considering how negative my comments on
draft-chan-tsvwg-diffserv-class-aggr-00 were :-)

I like this version. I still believe that these constraints
on treatment aggregates are automatically implied by the diffserv
architecture, but I think it's useful to write down this
concrete guidance.

I found the last sentence of the security considerations
hard to understand.

>    To the best of the authors' 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.

I think this is saying that if someone spoofs admission control,
there's nothing the network can do about it. Surely that can be said
more simply?

     Brian

---

From: "Kwok-Ho Chan" <[email-masked]>
Date: Fri, 07 Jul 2006 12:54:01 -0400

Brian:
Please see inline below.
Thanks!
-- Kwok --

>architecture, but I think it's useful to write down this

We take all comments positively to provide us guidance and try to improve,
we do know we are not perfect, but try to do our best for the 
Internet community.

>there's nothing the network can do about it. Surely that can be said

IMHO, we can improve this also.  We can try to do that in our next version.

---

From: Dave McDysan <[email-masked]>
Date: Mon, 10 Jul 2006 09:25:38 -0400

I agree with much of this draft. Regarding the sevice class aggregation
section 3, I have the following comments/ suggestions. I made these comments
verbally in Dallas and am submitting them to the list for your
consideration.

I suggest a mention the issue of pt-pt vs pt-mpt vs mpt-mpt traffic
knowledge for a particular set of aggregated Diffserv classes. In general
the patterns of these types of traffic would have more and less
predictability, respectively. Pt-pt is more predicatable, especially if
admission control (e.g., RSVP) or provisioning and policing at the ingress
is employed. This draft appears to implicitly assume that packets from these
traffic patterns are combined and only the Diffserv code points are used as
a basis for aggregation. If pt-pt and pt-mpt traffic matrix data were
analyzed, what would be meaningful statistics to the community to determine
the complexity/benefit of a (potentially) different aggregation for pt-pt
versus pt-mpt?

Suggest mention of additional means to match resources to the offered
traffic for a particular aggregate, for example ECN and its proposed
extensions, as well as dynamic allocation of TE capacity and/or dynamic
metric adjustment.

Dave

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Friday, June 30, 2006 3:50 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Tsvwg] I-D 
> ACTION:draft-ietf-tsvwg-diffserv-class-aggr-00.txt
> 
> 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.
>