Subject: [Diffserv-interest] DiffServ & Multicasting

From: Aaron D Striegel <[email-masked]>
Date: Wed, 08 Aug 2001 12:03:09 -0500

Has there been any efforts beyond the IETF draft by Bless & Wuerhle on 
DiffServ multicasting?  Our group has been doing a bit of research in this 
area and I'm a bit concerned about multicast in a DiffServ environment.

The two areas I am primarily concerned about are:

- Scalability of per-group information in the core router

Is it scalable to include per-group information as per traditional IP 
multicast in core routers?  Per-group information seems to go against the 
spirit of DiffServ as a whole.  Although the information is not affected by 
the number of downstream receivers, it seems that the number of multicast 
groups could get extremely large.

With a protocol such as SSM, it seems things could get even worse with even 
more state information in the core.
One of the examples I had heard was a company offering all of its objects 
on its webpage with a separate multicast stream for each object.  Although 
this is probably a bit of overkill, it seems that this could be a very real 
possibility, if even on a limited sense.

- Complexity of multicasting in the core router

This ties back in with the scalability issue but what about the various 
timing/signalling associated with multicasting (soft state, bandwidth 
negotiation (?)).  This seems like a fairly heavy burden to place on core 
routers when dealing with the potential maintenance and signalling 
associated with per-group information.  These items seem like things which 
are best left to edge routers rather than being dealt with in the core.

- Keep intelligence at edges

It seems that to really follow the spirit of DiffServ (keep the complexity 
at the edges), the tree maintenance issues and signalling should be left to 
the edge routers with core routers only routing packets (tunnel from 
edge-to-edge) or responding to information embedded in the packet 
(encapsulation approach).  Embedding the information in the packet seems to 
follow suit with the notion of per-hop behavior (how to treat the packet is 
contained in the packet and not at the core node itself).

Although there was quite a bit of discussion on multicasting some time ago 
and I would like to discuss what other people think on this issue.  I think 
the notion of keeping the multicast intelligence at the edges has 
significant benefits versus using traditional IP multicast and I think this 
is a topic that merits further discussion.

---------------------------------------
Aaron Striegel
Ph.D Candidate, Computer Engineering - Internet QoS
Dept. of Electrical & Computer Engineering
Iowa State University
Webpage: http://www.public.iastate.edu/~magico

_______________________________________________
Diffserv-interest mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/diffserv-interest

---

From: Klaus Wehrle <[email-masked]>
Date: Thu, 09 Aug 2001 00:49:28 +0200

Hy Aaron,

> multicast in core routers?  Per-group information seems to go against 
> the spirit of DiffServ as a whole.

I agree with you. This could possibly result in a scalability problem. 
We discussed about it, when writing the mc/diffserv-draft

But the first aim of our draft was to solve the problem with multicast 
and diffserv (we called it neglected reservation subtree problem - NRS).

the problem with extremely large group entries in a core router is 
independant from the NRS-problem. when moving the tree maintenance to 
the edge routers you will also have the NRS-problem.

> It seems that to really follow the spirit of DiffServ (keep the 
> complexity at the edges), the tree maintenance issues and signalling 
> should be left to the edge routers with core routers only routing 
> packets (tunnel from edge-to-edge)

this seems to me like the spirit of mpls  ;-)

bye,
klaus

-- 
  Klaus Wehrle
  Institut für Telematik, Universität Karlsruhe (TH)
  Zirkel 2, 76128 Karlsruhe, Germany
  Phone: +49 721 608 6414, Fax: +49 721 388097
  mailto:[email-masked] http://www.tm.uka.de/~wehrle