Subject: RE: [Diffserv] Re: Problems with IP-Multicast in DiffServ-Network s

From: Vishwanath Edavayyanaamath <[email-masked]>
Date: Wed, 3 Nov 1999 16:47:25 -0600

1. Assist with charging from a provider's perspective. Presumably,
   the charging is based on some notion of the resource level
   utilized by the traffic stream -either based on BW, PHB etc.

   In multicast, depending on the # of receivers & breadth of the
   tree, more resources will be utilized. Traditional 
   classifiers (source IP/dest IP etc) cannot tell us whether 
   a multicast tree causes traffic to go through 1,2, 15 or 100
   routers in a particular provider's domain.  Are we assuming
   that providers will charge the sender the same amount
   of money regardless of whether the tree goes through
   5 routers or 100? 

   The draft mentioned by cyl provides an example of 
   network mechanisms that enable SLAs to either
   charge extra based on # of receivers or to limit
   the # of receivers.

-----------
I am not sure of how exactly provider can charge multicast, as Host
memberships are dynamically changing in the multicast tree. Did read couple
of papers long back, but then Multicast as in MBone works through tunnels
(Unicast). Is native multicast a complete reality as of now?

-vishwa

---

From: [email-masked]
Date: Wed, 3 Nov 1999 19:18:34 -0500

> Well, if diffserv does not provide for real-time acceptance or
> rejection of new flows at the ingress points, based on local
> congestion criteria, then I am with Steve Deering on this issue.
> What makes multicast different? Just that there _might_ be several
> branches in the diffserv net?

I agree with the conclusion but want to point out that diffserv is
neutral on the underlying issue.  The architecture neither requires
nor forbids "real-time acceptance ..." -- in fact,  the traffic conditioning
mechanisms that are currently under discussion and the available
DSCP values are clearly sufficient to support this in some fashion.

The issll draft I referred to earlier describes one approach to supporting
this sort of functionality, but there are other approaches that have
been discussed on this list and/or written up as drafts.  In all cases,
they are extensions to the basic diffserv architecture and functionality;
some care was taken in RFC 2474 to make this sort of experimentation
possible.  

--David 

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140, FAX: +1 (508) 497-6909
[email-masked]
---------------------------------------------------

_______________________________________________
diffserv mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/diffserv
Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/