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

From: "Nabil Seddigh" <[email-masked]>
Date: Wed, 3 Nov 1999 14:00:40 -0500 (EST)

Steve Deering wrote:

>
>Why is the diff-serv list discussing provisioning for a single
>conference or per-flow resource reservations???
>

The Diffserv WG doesn't have resource provisioning as
part of its mandate. However, since this issue is important
for Diffserv deployment, it might be worth some consideration.

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.

>Diff-serv for IP multicast ought to work just like diff-serv for IP
>unicast: the sender sets some bits to indicate how it would like the
>packet to be handled; any router along the delivery tree may modify
>those bits to indicate how the packet ought be handled from that point
>onward, along one or more descendent branches of the delivery tree.
>Along any branch of the delivery tree, the packet undergoes the same
>diff-serv handling as would a unicast packet along that branch.  The
>only significant difference is that, compared to replicated unicasts,
>less provisioning is needed for multicast  What's the problem, exactly?

Not quite sure that Diffserv for unicast can work exactly the same way
as Diffserv for multicast. In unicast, the ingress nodes can
police/shape based on destination IP addresses amongst other things. In
multicast this type of policing will merely restrict/remark the traffic
load. Once the traffic is within the domain, it can replicate at will
depending on  receiver joins. As of now, the Diffserv network mechanisms

have no way of restricting the number of receivers of a multicast tree.
Depending on the number of branches and breadth of the multicast tree
within a domain, the tree will require varied resources thus making the 
traffic engineering problem more difficult. If all the receivers were
static and never changed then maybe this is isn't a problem. 

Since a key part of multicast is the dynamic nature of receiver
subscription some form of admission control appears important - or at
least more  important than in the unicast case.

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 11:57:56 -0800

>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.

>depending on  receiver joins.

And unicast traffic can go along links and/or out of egress points
that you didn't anticipate, unless you also disable the routing protocol's
ability to route around failures.  Either you need interior policing or
(better in my opinion) you limit the "guaranteed" traffic to a small
fraction of your capacity on any link, so you can meet your guarantees
no matter which path(s) the traffic takes.

>static and never changed then maybe this is isn't a problem. 

The receivers of unicast traffic are not static either, so you adjust your
traffic engineering/provisioning in response to long-term, observed trends.
The same ought to be true of multicast.

>least more  important than in the unicast case.

I disagree.  Unicast also has "dynamic receiver subscription", in that
sources dynamically change who they send packets to.  It's just that,
in the case of unicast, it's not revealed to the network like it is
with multicast.

Steve