Subject: [Diffserv] I-D ACTION:draft-bless-diffserv-multicast-02.txt

From: [email-masked]
Date: Wed, 28 Nov 2001 05:56:31 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: IP Multicast in Differentiated Services Networks
	Author(s)	: R. Bless, K. Wehrle
	Filename	: draft-bless-diffserv-multicast-02.txt
	Pages		: 31
	Date		: 27-Nov-01
	
Besides providing basic building blocks for enabling different 
quality of service levels for unicast applications, the 
Differentiated Services (DiffServ) approach will also bring benefits 
for multicast applications which need quality of service support. 
For instance, a highly reliable multicast service can be provided 
based on the EF PHB [8]. However, current efforts mainly concentrate 
on unicast services, whereas provision and deployment of multicast 
services using Differentiated Services needs some clarification.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-bless-diffserv-multicast-02.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-bless-diffserv-multicast-02.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-bless-diffserv-multicast-02.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: Roland Bless <[email-masked]>
Date: Thu, 29 Nov 2001 23:25:51 +0100

Hi,

for those who are interested in the changes of 
draft-bless-diffserv-multicast-02.txt to the previous version.

- we added a short section (sec. 4) about scalability issues
- we added an appendix B with results from various simulation
  scenarios which show the described problems and the successful
  application of the proposed solution by using Limited Effort
  prior to any resource reservation.

Best regards,
 Roland

-- 
Roland Bless -- e-Mail: [email-masked]
Institute of Telematics, University of Karlsruhe, Germany  
Zirkel 2, D-76128 Karlsruhe -- Office: Bld. 20.20, 3rd floor, R 358
Phone: +49 721 608-6413 Fax: +49 721 388097

_______________________________________________
diffserv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html

---

From: Aaron D Striegel <[email-masked]>
Date: Fri, 30 Nov 2001 13:22:49 -0600

Roland,

Just a few comments on the draft that I am a bit concerned about:

- The draft mentions that if IP multicast is considered to be scalable, 
therefore the approach is scalable.  It seems to me that the per-group 
routing information and all of its associated timers/soft-state information 
essentially amounts to state information in the core.  If the goal of 
DiffServ is to keep per-flow state information out of the core, IP 
multicast seems to violate this.  This seems to steer away from the notion 
of a high-speed simple core router.

What about an edge-based solution whereby the tree would be encapsulated in 
the packet?  That would keep the core stateless but would come at the cost 
of additional bandwidth.  Plus, if you keep the core stateless, you could 
essentially keep the core multicast protocol independent and free of any 
timers, soft-state, or protocol complexity beyond just simple data 
forwarding according to packet information, similar to the DSCP.

- On the issue of further heterogeneity in multicast groups, would it be 
possible to have a node continue forwarding the join request (providing 
that IP Multicast was allowed in the core) towards the ingress router if 
PHB if of a better service class?  This would be subject to the fact that 
such a request would have to be approved by the BB.

For example, suppose a group exists with AF13 and AF12 codepoints.  Suppose 
a new request comes in requesting AF11 service and the path to the ingress 
node (single source tree) coincides with part of the AF12 path to the 
ingress node.  If such a path was promoted to AF11, the new receiver is 
receiving the QoS they asked for.  If the portion of the tree stays AF12, 
the new receiver gets some but not all of the service they requested.  Is 
this something to be concerned about?

Also related to that, from our simulation studies it seems that if you do 
allow such a path to be promoted, it is possible to get out-of-order 
delivery for the flow (AF2x to AF1x).  In addition, such prioritizing would 
have the problem of deciding which PHB is really best.  For example, AF 
might actually be better than EF in a low loaded network with rate 
limitation on EF.   Any thoughts on this?

Aaron

Aaron Striegel
Dept. of Electrical & Computer Engineering
Iowa State University

E-mail: [email-masked]
Webpage: http://www.public.iastate.edu/~magico