Subject: re:[Diffserv] Re: Problems with IP-Multicast in DiffServ-Networks

From: "Nabil Seddigh" <[email-masked]>
Date: Wed, 3 Nov 1999 16:49:36 -0500 (EST)

In message "Problems with IP-Multicast in DiffServ-Networks", 
Steve Deering writes:

>At 2:00 PM -0500 11/3/99, Nabil Seddigh wrote:
>>On another note,  the resource provisioning issue for multipoint
>>to multipoint seems more difficult than single pt to multi-point.
>>Hence the initial focus on single point to multi-point.
>
>Well, I still don't see it.  The resource provisioning issue is coping
>with the total flux of traffic flowing through the network, which is
>the sum of unicast and multicast traffic of various DSCP values from
>multiple sources to multiple destinations.

Let me see if I can rephrase what I see as the problem.
Diffserv policing mechanisms (remark/drop) serve two purposes:

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.

2. Limit (or remark) the amount of traffic injected into a 
   network by sources thus shielding traffic of other users.

   In the unicast model, you can limit the amount of traffic 
   injected by a particular host based on some type of 
   classifier. In the multicast case, you can certainly limit
   the amount of traffic injected into the network. However,
   how will you limit or at least put some bounds on how
   many routers the traffic visits? With current Diffserv 
   mechanisms (edge policing/marking and simple core 
   treatment based on DSCP),  it seems as though the 
   provider is unable to prevent this. 

BTW, maybe a separate PHB or set of PHBs might be required to shield
unicast from multicast - for those providers who are concerned with the
problem. Those who are comfortable carrying multicast and unicast
together can lump them to be served by the same PHB. Others can use the

separate PHB(s). I have seen a number of presentations by people looking

to  create services. In quite a few of these, the AF classes are already

spoken for and so, despite what was mentioned some time back on the
Diffserv list, a separate PHB might be required.

-
Regards
Nabil Seddigh
[email-masked]

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

---

From: Steve Deering <[email-masked]>
Date: Wed, 3 Nov 1999 14:39:52 -0800

>   of money regardless of whether the tree goes through

If you want to charge based on fan-out, count the packets at the egress
routers, not the ingress routers.

However, I thought another point of diff-serv (as opposed to int-serv) was
to avoid all the overhead of book-keeping individual packets or flows,
to not fall into the "90% of the cost of the network is the billing system"
quagmire.

>   many routers the traffic visits?

Assuming the multicast routing protocol is loop-free, there's clearly
a bound on the number of routers any multicast packet will visit.
I guess you think that's not a useful bound.

Anyway, it sounds like at least some people are trying to morph diff-serv
into something quite different from the original goals.  That means
my context is too out-of-date for me to be barging in here, so please
excuse the interruption and carry on....

Steve