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

From: Klaus Wehrle <[email-masked]>
Date: Tue, 02 Nov 1999 10:22:42 +0100

Hello Dirk,

Dirk Kopplin wrote:

> Hi,
>
> I've read your IETF draft on IP multicast in diffserv networks and found the
> idea with the new field in the multicast routing table very interesting.
>

This solution of the neglected reservation subtree problem is very simple and
would not result in any scalability problems. Currently we are integrating it
into our DiffServ-Implementation KIDS.

> What I'm concerned with is the fact that IP multicast behavior contradicts
> with the diffserv specification, which in my understanding defines a
> diffserv domain as a pure transport network without any payload generating
> hosts. Traffic need to  enter the diffserv domain through border or edge
> nodes.

Thats right. It is very important to control the traffic, that enters a domain
to guarantee the 'better services'.
But thats not in opposite to support multicast traffic. It's right that
IP-multicast creates new traffic within a ds-domain, but with our solution we
can degredate this traffic to best effort (if necessary).
In RFC2475 is is also mentioned, that a host can be located within a DS-domain.
In my opinion, this host must have the same mechanisms as a boundary router:
meter, marker, policing, ...

IP-multicast has also the problem, that each host can join a multicast group,
and if a multicast flow uses a better service the new receiver would get this
service too - without reservation or payment.

> With this in mind it is difficult the define a diffserv domain since
> new flows can be generated in every multicast enabled router in the network.
> Traffic engineering becomes very difficult in those networks. Even if
> diffserv introduced a mechanism without "hard" QoS guarantees e.g. EF
> traffic shouldn't be punished within the network.

But with the solution proposed in our draft, each new receiver of a multicast
group will first get Best-Effort (or LBE) instead of the better service. Only
when a reservation has been set up for the new subtree of the multicast group,
it will get the full 'better service'. There will be no new traffic that uses a
codepoint of better services without reservation of the ressources - only best
effort (or as proposed: lower than best effort). EF or AF is not concerned by
more Best-Effort-traffic and there will be no change in their guarantees.

> Do you have any comments on that?

see above.

> /dirk

Best Regards,
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.telematik.informatik.uni-karlsruhe.de/~wehrle

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

---

From: "Cheng-Yin Lee" <[email-masked]>
Date: Tue, 02 Nov 1999 11:49:35 -0500

> service too - without reservation or payment.

You might like to take a look at :
http://www.ietf.org/internet-drafts/draft-leecy-multicast-provisioning-00.txt

which looks at the problem in a different perspective and does not have the
problem mentioned above because resource reservations are made as the multicast
tree is constructed, and all branches of the tree receives the same service level.
Receivers requiring different service level are met by other means mentioned in
the draft.

This approach does NOT require pkts to be remarked at interior routers.

A related draft is at
http://www.ietf.org/internet-drafts/draft-leecy-multicast-egress-limit-00.txt.

Policing of data pkts at the boundary router is the same as for unicast traffic,
the growth of the multicast tree (ie additional resources required within the DS
network) is controlled as the tree is being constructed.

I'll be happy to discuss your approach and this approach with you further if
you're interested.

cheers,
cyl
p.s We have a slot to discuss these drafts at the DECIDES BoF, in case you're
interested.

---

From: "Albert Manfredi" <[email-masked]>
Date: Tue, 2 Nov 1999 12:32:30 -0500

You know, this is a rather fascinating thread, because this problem
with leaf-initiated multicast, and how to accommodate potentially
different QoS requests such a multicast environment, is exactly the
same problem one would encounter in ATM's UNI 4.0 style of
leaf-initiated multicast.

It seems to me that the answers are going to look similar: either
you set up different trees at the different QoS levels as leaves
send in join requests (ugh), or you allow only less-than-or-equal-to
branches to be added to the multicast tree (which means that
multicasts will tend to degrade to BE), or you simply only construct
the multicast tree based on the source's QoS needs, potentially
meaning that some would-be sinks will never get their join messages
honored.

Bert
[email-masked]

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf
> Of Cheng-Yin Lee
> Sent: Tuesday, November 02, 1999 11:50 AM
> To: Klaus Wehrle
> Cc: Dirk Kopplin; [email-masked]
> Subject: Re: [Diffserv] Re: Problems with IP-Multicast in
> DiffServ-Networks
>
>
> Klaus Wehrle wrote:
>

---

From: "Cheng-Yin Lee" <[email-masked]>
Date: Tue, 02 Nov 1999 15:03:46 -0500

> leaf-initiated multicast.

Should we attempt to provide different QOS on a tree or should we use
other alternatives e.g layer encoding?  The latter seems easier.

> either
> send in join requests (ugh),

I don't follow why this is bad.
The network is not involved in this choice or selection, the user
selects the goup(s) it wants to join. Perhaps i missed your point?

> or you allow only less-than-or-equal-to
> multicasts will tend to degrade to BE),

i'm not  sure if requesting a service level is going to be very useful
then...

> or you simply only construct

And there is no reason to honour them if  the source has not
requested/pay for the resources required to multicast to these sinks,
assuming a model where the source 'pays' the network provider for the
network resources required for multicast and the receivers 'pay' the
source for the 'content'. The source of course could belong to the
network provider as well.

Even if you use the same service level within a multicast tree/group,
there is still the problem where
a host can join a multicast group, and get multicast data before
resources have been allocated for the branch leading to the host (as
implied by Klaus Wehrle as well). The draft i posted earlier allocates
resources (if a group requires a certain service level) as the tree is
constructed, so data is not sent on a path where resources have not been
allocated yet and there is no need to remark pkts in interior routers as
a result.

I should also mention that resources need not be allocated per flow in
the draft mentioned in my previous email.

cheers,
cyl
p.s BTW, may i know what is the solution in ATM UNI 4.0?

---

From: "Albert Manfredi" <[email-masked]>
Date: Tue, 2 Nov 1999 16:34:06 -0500

> From: Cheng-Yin Lee [mailto:[email-masked]]

> selects the goup(s) it wants to join. Perhaps i missed your point?

The problem here is scaling. In principle, you could have n users
each requesting a different QoS level, which is not the best way to
support multicast. But it's possible.

> i'm not  sure if requesting a service level is going to

I tend to agree.

> network provider as well.

Well, true enough. Regardless of who pays, it's possible that a
source could mandate that at least such a QoS is required for this
multicast, and then perhaps (in the future) some constraint-based
routing scheme would help ensure that a good path is found.
Otherwise, if the diffserv nets in the path can't support the source
requirements, too bad. That's a valid approach, I think.

> allocated yet and there is no need to remark pkts in

But the tree will not necessarily be constructed at time 0. It's a
living thing, as users come and go, is it not? You won't know ahead
of time which routers are going to come into play. So a user that
wants to join at time +x might be out of luck.

> p.s BTW, may i know what is the solution in ATM UNI 4.0?

ATM uses the "source determines QoS level" method, essentially, but
allows for a lot of flexibility in doing so. UNI 4.0 allows the root
or the leaf to initiate the join request. But if the leaf initiates
the request, this kicks off the standard source-initiated setup
handshaking, where the source (root) establishes the QoS needs and
transmits these to the leaf via SETUP or ADD PARTY signaling
messages. So a leaf-initiated join is merely one extra step to a
root-initiated join, and any QoS requirement the source has would
presumably be met by PNNI's constraint-based routing.

(In typical ATM fashion, though, a leaf-initiated join request can,
via the call identifier alone, implictly request a particular QoS
level. But how the root would match a call identifier to a QoS level
is not specified.)

In ATM UNI 4.0 multicast, if the leaf initiates the call, the
request can either go all the way to the root or the network can
grant it before it reaches the root. So the latter would be more
like RFC 1112. This would be the case if switches along the path
back to the root are already servicing that multicast.

So it seems to me that an IP implementation of QoS-aware multicast
could work similar to ATM's leaf-initiated join, where the network,
acting as the source, establishes the QoS requirement. This is
valid, I think, and will mandate that any leaf wishing to join a
multicast would be required to pay whatever the rate is for that
multicast.

Bert

---

From: "Cheng-Yin Lee" <[email-masked]>
Date: Tue, 02 Nov 1999 17:47:41 -0500

Albert Manfredi wrote:

> \> > either

There is a finite number of 'QoS level' that users would subscribe to,
if you look at typical applications.
For eg. below a certain minimum service level, the data may not be
useful to receivers.

> living thing, as users come and go, is it not?

Yes.

> You won't know ahead of time which routers are going to come into
> play. So a user that wants to join at time +x might be out of luck.

As an example, a  provider would allocate a pool of resources
statically  for multicast traffic, and as receivers join certain groups,
the tree construction can be directed on paths allocated a priori with a
sufficient pool of resources . These resources can then be shared and
dynamically provisioned for different service levels.  Unless the egress
points are fixed, there are no guarantees, but with proper path
engineering the probability of not being able to meet an SLA can be very
low.
(It seems just as important that if traffic is admitted into the
DS network, there are sufficient resources on the paths leading to the
receivers and to prevent  multicast traffic from  flowing on paths that
do not have sufficient resources).

> > p.s BTW, may i know what is the solution in ATM UNI 4.0?

Thanks for description, i'm taking a closer look. I have to say that
i've concerns about ATM style reservations though, since it maintains
reservation states per group.

cheers,
cyl

---

From: "Albert Manfredi" <[email-masked]>
Date: Tue, 2 Nov 1999 18:29:40 -0500

> From: Cheng-Yin Lee [mailto:[email-masked]]

[ ... ]

> reservation states per group.

Of course, the ATM solution is not compatible with diffserv exactly.
You certainly don't want to maintain state per flow or microflow.
But the concept of how QoS is provided in a macro sense might be
applicable. There are only so many reasonable ways of doing this.

As to only a finite number of QoS levels, although this might be
true, that number is still too large if the sinks get to choose any
value they like. So it makes sense for the source to provide one or
a small number of options somehow. Perhaps with separate trees, as
you suggest. That sounds feasible.

Bert

---

From: "Cheng-Yin Lee" <[email-masked]>
Date: Tue, 02 Nov 1999 22:45:57 -0500

> You certainly don't want to maintain state per flow or microflow.
Agree, the multicast provisioning proposal does not require state to be
maintained per group.

> applicable. 

Yes, i believe so too.

> acting as the source, establishes the QoS requirement. 
Yes, in this proposal the source determines the QOS requirement.

cheers,
cyl

---

From: Graham Cope <[email-masked]>
Date: Wed, 03 Nov 1999 10:01:51 +0000

Are there not some similar, but reverse direction problems with RSVP
shared reservations?

By multicast I assume that you mean pt-to-multipoint, and reveiving
hosts join the tree.

With RSVP you may have shared reservations 'merging' downstream towards
the reveiver. Suppose that a number of such flows merge within a
diffserv domain. It is not entirely obvious to me what the SLS would
look like, and indeed how you would provision internal resources. For
instance, an SLS could be 'another flow may join a session at this
ingress, provided that there is already another flow using resources
from another ingress'. Pt-to-pt distinct reservations are much nicer!

Graham

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 03 Nov 1999 09:25:59 -0600

Graham,

Multicast in the IP model is conceptually multipoint-to-multipoint.
I know this makes it harder, but it's not a theoretical
consideration: a 10-party conference needs to be provisioned
on a multipoint basis. (Unless you want to be bound to the
concept of a conference bar for ever.)

My personal take is that trying to solve this problem exclusively
at the network layer is a doomed enterprise; it is only the
applications that actually understand the provisioning requirement.

We will touch briefly on this in the second session next week,
to judge the sense of the WG whether we can tackle this.

   Brian

---

From: "Albert Manfredi" <[email-masked]>
Date: Wed, 3 Nov 1999 10:19:14 -0500

> Of Graham Cope

> Are there not some similar, but reverse direction

Indeed. Isn't that called the PATH message in RSVP? That's what sets
the reservation requirement. So perhaps everyone is using that basic
approach.

> By multicast I assume that you mean pt-to-multipoint, and

In leaf-initiated join in ATM UNI 4.0, yes.

> from another ingress'. Pt-to-pt distinct reservations are

Perhaps, though, in a diffserv setting, we're talking about setting
up multicast aggregate flows. Like tunnels, maybe, not individual
sinks doing RFC 1112 join requests? Not that this simplifies the
problem totally, but it does make it a little less dynamic.

Bert

---

From: "Cheng-Yin Lee" <[email-masked]>
Date: Wed, 03 Nov 1999 11:01:42 -0500

> > look like, and indeed how you would provision internal
> > resources.

Both
http://search.ietf.org/internet-drafts/draft-leecy-multicast-provisioning-00.txt

http://search.ietf.org/internet-drafts/draft-leecy-multicast-egress-limit-00.txt

have examples of SLS.

> For
> > from another ingress'.

http://search.ietf.org/internet-drafts/draft-leecy-multicast-egress-limit-00.txt
has examples of how to control the number of egress points, which i
believe is your question?

> > Pt-to-pt distinct reservations are much nicer!
>
> sinks doing RFC 1112 join requests?

You can still send join requests and reserve for aggregate flows, to the
resource provisioning entity the resource allocation is analogous to
memory allocation, it doesn't need to know the groups it's reserving
because we can leverage the tree construction protocol (multicast rtg
protocol) to terminate those reservations.
This is described in Appendix A of
http://search.ietf.org/internet-drafts/draft-leecy-multicast-provisioning-00.txt

> Not that this simplifies the

If a mechanism similar to Appendix A is used, it can still be dynamic.

cheers,
cyl

---

From: Steve Deering <[email-masked]>
Date: Wed, 3 Nov 1999 08:01:24 -0800

The subject line of this thread caught my eye...

>Multicast in the IP model is conceptually multipoint-to-multipoint.

No, the IP multicast model is that of point-to-multipoint datagrams.
Higher layers can build multipoint-to-multipoint applications out of
the IP pt-to-mpt service.

>on a multipoint basis.

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

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?

Steve

---

From: "Albert Manfredi" <[email-masked]>
Date: Wed, 3 Nov 1999 11:46:34 -0500

> Of Steve Deering

I wonder why, Steve.

> the IP pt-to-mpt service.

I had misread what Brian wrote. Indeed, mpt-mpt as allowed in IP
multicast is pt-mpt from any number of sources to the same set of
group members. This is in part _why_ the problem is not trivial,
when QoS is entered into the equation. It's why I brought up UNI 4.0
to begin with. Because now the problem is more similar to what ATM
has to do than it is to your RFC 1112. In the sense that _merging_
flows become as much a problem here as they are for the virtual
circuit-switched ATM. But the solution in diffserv must be entirely
different, I think.

> or per-flow resource reservations???

Not necessarily on a per flow basis.

> less provisioning is needed for multicast  What's the

I, for one, agree with you, which is why I have problems with
suggestions that the service provider has to set aside assets for
the multicast tree. Just like unicast, diffserv has to show that
merging multicast flows can have QoS provided only on the basis of
per hop behavior.

Bert

---

From: "Cheng-Yin Lee" <[email-masked]>
Date: Wed, 03 Nov 1999 11:23:12 -0500

> concept of a conference bar for ever.)

Yes, each source can specify the service level it requires in multipoint to
multipoint communications. It's mp2mp at L3, but the service level need not
be specified as mp2mp service, that makes the problem easier for diffserv, i
believe. The drafts i posted have examples of mp2mp,  pls let me know if you
have concerns or if it's not clear.

> applications that actually understand the provisioning requirement.

Agree. For eg sources may specify/negotiate the service level required.

> to judge the sense of the WG whether we can tackle this.

I think it's feasible, but we'll see what the WG says.

cheers,
cyl

---

From: Jon Crowcroft <[email-masked]>
Date: Wed, 03 Nov 1999 16:45:15 +0000

Brian

in steve deering's model (see his response)
each sender is independant - however, in many applications, senders
are not, and you require a level of traffic engineering, or
reservation, or whatever, for each source in a multicast session for
it to be useable - but you don't need the same level - but you might
not want to indulge in an n*(n-1)/2 negotiation before knowing....
the models of rsvp present what were thouht to be a common subset of
useful patterns of multiple source....(well, a very small subset) coz
we havnt seen much multicpast deployment, we havent really got an idea
for multiple source sessions beyond some of those models - games might
be quite diffeent from conferences - as steve says, single source is
easy - it all just works..

other evidence its hard:
given we haev no real clue how to do multi-source multicast congestion
control, having only just an inkling how to do single source multicast
congestion control (e..g pt-multipoint), how could we really haev a 
plusible claim to know how to provision a reservation

---

From: "Albert Manfredi" <[email-masked]>
Date: Wed, 3 Nov 1999 12:07:47 -0500

Steve Deering wrote:

> > The only significant difference is that, compared to
> replicated unicasts,
> How to provision for multicast groups?

You don't, Cheng-Yin. In a diffserv environment, in principle,
you're not supposed to provision anything after you've installed the
network hardware. Unless you want to make multicast dramatically
different from unicast in the diffserv network. Which sort of
defeats the purpose, I think.

Bert

---

From: "Cheng-Yin Lee" <[email-masked]>
Date: Wed, 03 Nov 1999 11:44:44 -0500

> or per-flow resource reservations???

i think we are discussing aggregated resource reservations.

> packet to be handled;

yes.

> any router along the delivery tree may modify

i'm not clear  how this will work in a diffserv network. Could you elaborate
pls?

> diff-serv handling as would a unicast packet along that branch.

Agree.

> The only significant difference is that, compared to replicated unicasts,

cheers,
cyl

---

From: Steve Deering <[email-masked]>
Date: Wed, 3 Nov 1999 09:29:18 -0800

>i think we are discussing aggregated resource reservations.

Cyl,

What I saw was Brian's comment about "a 10-party conference needs to be
provisioned on a multipoint basis", and Albert drawing analogies to
ATM pt-to-mpt flows, which made me think you were talking about
per-(micro)flow reservations.  That's what I get for dropping in
without sufficient context.

By then why are you discussing "reservations" at all?  Isn't that the
domain of int-serv?

>i'm not clear  how this will work in a diffserv network. Could you elaborate

I would elaborate if I understood what you think the problem is.  You
provision resources in your networks for certain amounts of traffic
labelled in certain ways.  Multicast packets carrying such labels consume
the corresponding resources along the branches of their delivery trees,
and are accounted for, just like unicast packets that happen to flow along
the same paths.

>How to provision for multicast groups?

You don't provision for multicast groups.  You provision for aggregate
flows of traffic, to a potential multiplicity of destinations, both
unicast and multicast.

Steve

---

From: "Cheng-Yin Lee" <[email-masked]>
Date: Wed, 03 Nov 1999 12:42:04 -0500

> By then why are you discussing "reservations" at all?  Isn't that the

I think i have a terminology problem here.

> and are accounted for, just like unicast packets that happen to flow along

Yes i understand your explanation above.
But i 'm not sure of modifying bits in interior /core routers.

> flows of traffic, to a potential multiplicity of destinations, both

Yes, i see the misunderstanding, i meant provisioning for multicast groups for
aggregated traffic which was what i think we are discussing. Actually the
proposal i posted allows provisioning for aggregate flows of traffic, but
leverages multicast tree construction to do this.

cheers,
cyl

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 03 Nov 1999 11:59:51 -0600

Exactly. As long as you don't think about provisioning,
senders are independent - my point that Steve reacted to is
that in a group with multiple senders, as soon as you add QOS
provisioning to the mix, you have to consider mp2mp provisioning
for the diffserv traffic class concerned.

The reason we are discussing it here is that it is a real
problem; however one very plausible option IMHO is to spin off
a separate activity or kick the problem over to the TE working
group, rather than follow up in diffserv. As Steve correctly
observed, it doesn't affect the atomic forwarding behaviour
of diffserv routers.

  Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter (IAB Chair)
Program Director, Internet Standards & Technology, IBM 
On assignment for IBM at http://www.iCAIR.org 
Non-IBM email: [email-masked]

---

From: Steve Deering <[email-masked]>
Date: Wed, 3 Nov 1999 10:01:20 -0800

>But i 'm not sure of modifying bits in interior /core routers.

It was my understanding (is it still correct?) that routers were allowed
to modify the diff-serv (DHCP) bits in transit, particularly routers at
administrative boundaries.  Thus, multicast packets traveling along a
delivery branch that crossed such a router would undergo DHCP modification
just like unicast packets.  That's all I was referring to.

>leverages multicast tree construction to do this.

Hmm.  It sounds wrong to me to call out multicast as something that needs
separate provisioning.  I would expect a model in which you measure/predict
the amount of traffic flowing along a given link or path (regardless of
whether it's unicast or multicast), and provision the link accordingly.
Adjusting the provisioning in response to fine-grain activities such as
building multicast delivery branches in response to join/leave requests
doesn't sound like it fits within the goals of diff-serv.  Int-serv, yes.

Steve

---

From: Steve Deering <[email-masked]>
Date: Wed, 3 Nov 1999 10:19:18 -0800

>for the diffserv traffic class concerned.

Brian,

This is completely orthogonal to "multicast-ness".  The same issues
arise with multi-party applications that only use unicast.

I thought the philosophy behind diff-serv was to get beyond the level of
caring about the individual traffic patterns of particular applications
or particular instances of applications, and just deal with the
resulting aggregate traffic flows that occur as a result of all the
applications doing whatever they do.

Steve

---

From: "Cheng-Yin Lee" <[email-masked]>
Date: Wed, 03 Nov 1999 13:45:46 -0500

Steve Deering wrote:

> whether it's unicast or multicast),

Multicast groups can be dynamic, it seems difficult to predict the traffic. Could
someone provide a pointer to such models for multicast traffic?

> and provision the link accordingly.

The  resource provisioning proposed is quite generic, in the sense that it allows
provisioning from the granulariy of per group to traffic aggregates. If resources
have been allocated for a traffic aggregate at a node, no further resource
allocation is needed, ie there are no 'fine-grain activities'  for the group.

The same mechanism can be used for traffic aggregates provisioning and int-serv
fine-grain kind of reservations.

cheers,
cyl

---

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

At 1:45 PM -0500 11/3/99, Cheng-Yin Lee wrote:
>Multicast groups can be dynamic, it seems difficult to predict the traffic. 

cyl,

The set of destinations to which unicast packets are sent can also be,
and usually is, dynamic.  What's so special about multicast in this regard?

Steve

---

From: "Albert Manfredi" <[email-masked]>
Date: Wed, 3 Nov 1999 14:03:22 -0500

> arise with multi-party applications that only use unicast.

Yes, except that in a pt-mpt multicast scenario, the sender cannot
readjust his QoS desirements for every new flow. In unicast, a
sender's request might simply be rejected by the network, and the
sender can request something less demanding. In a pt-mpt multicast,
the sender is already engaged.

In  mpt-mpt scenario, merging flows become a problem that doesn't
exist with unicast. If you remember our discussions in the ION
working group (MARS, EARTH, MOON, and URANUS), you might recall that
merging flows over the NBMA network caused people to propose sending
frames, to save on VC requirements.

Well, we're up against the same fundamental problem, I think.
Proposing use of frames over NBMA was simply a way of bypassing the
QoS guarantee that the underlying NBMA net supported. It wasn't a
solution, it was a shortcut.

In support of multicast, diffserv would presumably still want to
make the QoS "guarantees," so now we have that nagging problem back
again.

Bert

---

From: Kathleen Nichols <[email-masked]>
Date: Wed, 03 Nov 1999 11:21:05 -0800

> just like unicast packets.  That's all I was referring to.

This is correct except its DSCP for Differentiated Services
CodePoint. DHCP is something different. In fact, when Van
gave Lixia and I his white board talk about diffserv QoS with
multicast, he made a reasonable argument for using different
markings where the multicast flow branched. (However, this
was two years ago, so that particular contention may have
undergone "drift".)

---

From: Steve Deering <[email-masked]>
Date: Wed, 3 Nov 1999 11:12:49 -0800

At 11:21 AM -0800 11/3/99, Kathleen Nichols wrote:
>CodePoint. DHCP is something different.

Yes, that's what I meant.  I suffer from distypia.

Steve

---

From: "Cheng-Yin Lee" <[email-masked]>
Date: Wed, 03 Nov 1999 14:10:36 -0500

> and usually is, dynamic.  What's so special about multicast in this regard?

Do we have a model that we can use to do provisioning for multicast traffic?

thanks,
cyl

---

From: Steve Deering <[email-masked]>
Date: Wed, 3 Nov 1999 11:41:29 -0800

>Do we have a model that we can use to do provisioning for multicast traffic?

Do you have a model that you can use to do provisioning for unicast traffic?

If the usefulness of diff-serv hinges on whether or not you have such a
model, what happens when the unicast traffic patterns change radically
because of some new killer app that takes over the net?

No, I am not aware of any good models for multicast traffic, presumably
because there is very little multicast traffic today from which to
construct such a model.  That means that you can mostly ignore multicast
for provisioning today, and if/when there's a lot more multicast traffic,
people will be able to start to build models for it.  But a sensible
network operator won't wait for such a model to be developed, but rather
will monitor actual traffic (unicast and multicast) and add capacity as
necessary to keep the customers satisfied (or at least enough to keep
them from defecting to the competition).

Steve

---

From: "Cheng-Yin Lee" <[email-masked]>
Date: Wed, 03 Nov 1999 14:48:21 -0500

Steve Deering wrote:

> for provisioning today,

:-), i rest my case then.

cheers,
cyl

---

From: Steve Deering <[email-masked]>
Date: Wed, 3 Nov 1999 12:05:41 -0800

>the sender is already engaged.

What's this got to do with diff-serv?  The only "rejection" that a
diff-serv network can perform on a unicast flow is to drop its packets.
(Per-flow signalling is in the int-serv domain, right?)  The same
mechanism works fine for multicast flows, too.

Steve

---

From: "Albert Manfredi" <[email-masked]>
Date: Wed, 3 Nov 1999 15:43:52 -0500

> mechanism works fine for multicast flows, too.

Diffserv does provide for access control, though: SLS (used to be
SLA). So a source can be rejected if it requests too much in setting
up its service contract with the diffserv net. This is before any
issues might arise with non-conforming traffic. At least, that's how
I read RFC 2475, Para. 2.3.

Now, take the pt-mpt (i.e. simple) multicast environment. A source
is sending its mcast traffic to one diffserv net as its first branch
or the tree, perhaps as part of a traffic aggregate. A sink
somewhere else in the world does IGMP join, which will cause a new
branch to have to be grafted onto the mcast tree, a branch which the
ISP might need to send through a different diffserv network from the
original one(s). Are the new diffserv nets capable of granting this
new flow?

I claim that this is a different scenario from the unicast scenario,
because in the unicast scenario, any failure in coming to an
agreeable contract occurs only at time 0. In this case, it can occur
at any time. No?

Mpt-mpt, as discussed previously, has the
merging-flows-while-meeting-QoS problems that we've seen before. As
I thought was the case in ION, the fundamental problem is not the
inadequacy of virtual circuits as much as it is the difficulty in
merging flows while maintaining QoS in each one.

Bert

---

From: Lloyd Wood <[email-masked]>
Date: Wed, 3 Nov 1999 23:07:28 +0000 (GMT)

> Do you have a model that you can use to do provisioning for unicast

Well, if you do, and you're switching over from *applications doing
exactly the same thing using unicast*, the Chuang-Sirbu scaling law
may be of use.

[1] Chuang, J. and Sirbu, M. "Pricing Multicast Communications: A  
    Cost-Based Approach", presented at the Internet Society INET'98
    Conference, Geneva, Switzerland, July 21-24 1998.
    http://www.cs.cmu.edu/afs/andrew/usr9/sirbu/www/pubs.html
    http://www.isoc.org/inet98/proceedings/6d/6d_2.htm
 
[2] Philips, Shenker and Tangmunarunkit, Scaling of Multicast Trees:
    "Comments on the Chuang-Sirbu scaling law", SIGCOMM '99.
    http://www.acm.org/sigcomm/sigcomm99/papers/session2-1.html

Unfortunately, as far as large-scale unicast stuff goes, Pointcast
deployment was never successful enough to reach the unicast/multicast
changeover point (probably because it _was_ unicast), and I'm not
aware of anyone e.g. running comparisons between unicast and multicast
between Squid caches or engineering a multicast NFS version 4 to
really test this law out in real networks with real provisioning.

L.

oh, you wanted a general model that would cope with paradigm shifts?
Sorry, fresh out.

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 03 Nov 1999 13:49:02 -0600

Steve,

> arise with multi-party applications that only use unicast.

It's orthogonal to "Deering multicast-ness" indeed. Which is exactly
why I said a while back that I don't believe we can solve this
purely at the network layer.
 
> applications doing whatever they do.

Absolutely. However I have to dispute the assertion made by Bert
Manfredi:

> network hardware.

There is no "supposed" about it and lots of people believe we will
evolve towards dynamic provisioning of diffserv aggregates. That is
where multi-sender applications make the provisioning computation
hard.

   Brian

---

From: Jon Crowcroft <[email-masked]>
Date: Thu, 04 Nov 1999 08:06:47 +0000

i think the issue is not one obciously of cost - the problem of
costing multicast sessions with multiple senders is that one needs to
know the value of the quality of content as a funciton of the overal
lifetime of the set of receivers and the set of senders-  for a
business phone conference call, this is easy - it realyl is onyl worth having 
if ALL the members are able to send and receive for the whole lifetime
of the session, so its a fairly simple thing to provision for whether
for diffserv or int-serv - either tyou haev video, and you need n
pt-multipoint
calls worth, or audio with 1 speaker and you need 1 senders and n
receivers worth or audio with a mixer and n unicast senders 
and 1 1-n multipoiint

but for other applications usage (e.g. ones with heterogeiy - some
media only go to some people, layered media, a lot of early
leavers and late join, etc etc) its not obvious at all how to provision
(or price).....not at all...there's nothing in the literature that i
know of gives an answer- all the work on advance reservations only
works for known groups...

In message <[email-masked]>, Ll

 >><[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

 cheers

   jon

---

From: Roland Bless <[email-masked]>
Date: Thu, 04 Nov 1999 09:11:57 +0100

> from another ingress'. Pt-to-pt distinct reservations are much nicer!

Indeed, as mentioned in our draft draft-bless-diffserv-multicast-00.txt, 
within a DiffServ environment there is no easy way to provide shared 
style reservations, because currently it cannot be assured that only one 
sender is actually sending data while all other senders are quiet.
In IntServ you don't have those problems, because every router can check
for the amount of currently used resources within a shared reservation style 
mc group.

-- 
Roland Bless -- e-Mail: [email-masked]
Institute of Telematics, University of Karlsruhe, F.R. of Germany  
Zirkel 2, D-76128 Karlsruhe -- Office: Engesserstr.2 (Bld. 20.50), 1st floor
Phone: +49 721 608-6396 Fax: +49 721 388097

---

From: Klaus Wehrle <[email-masked]>
Date: Thu, 04 Nov 1999 10:38:28 +0100

Hello,

> other alternatives e.g layer encoding?  The latter seems easier.

I agree. In my opinion, there should be used different mc-groups for
different service classes. There could also be used layered encoding, if the
data supports this, e.g. mpeg.
Each receiver can choose his quality by joining a certain group (or certain
groups when layered encoding is used)

> allocated yet and there is no need to remark pkts in interior routers as

One advantage of our draft is, that a user can join a group without
reserving ressources - but in this case he would only get
(Lower-than-)BestEffort. I call it "snooping into the group".
If the receiver want some quality later, he can make a reservation and the
entry in the mc-routing-table will be set to the service class -> he gets
the qos.

Supporting different service classes in one mc-group is no good solution,
because we still dont know how the different services of diffserv can be
mapped on each other - for example: can I "tunnel" AF over EF, if one
DS-Domain do not support AF?
What effects on the quality of AF will result. (I dont want to look on EF
over AF...)

Bye,
Klaus

--

 Klaus Wehrle

---

From: Klaus Wehrle <[email-masked]>
Date: Thu, 04 Nov 1999 10:59:17 +0100

Hello Steve,

> less provisioning is needed for multicast  What's the problem, exactly?

If a new subtree is added by a join, the router just duplicates the packet
(with the codepoint). For example it is an EF-Codepoint and the aggregated
EF-bandwidth was (before the new subtree was added) at 100% of the allowed
EF-bandwidth - that means no more EF-traffic is allowed.
Now the new mc-flow on the subtree increases the aggregated EF-bandwidth to
(lets say) 150% of the allowed EF-bandwidth. If the routers use
priority-queueing (and I think EF has the highest priority) the other
services will be disadvantaged.
If you have a look in the draft (draft-bless-diffserv-multicast-00.txt) ,
there are some meassurements described, that I made with our
DiffServ-Implementation (KIDS). You can see, that AF looses a lot of
bandwidth, because EF is over his limit.

Now, we want to change the codepoint for the new subtree, until the
ressources are reserved and free.
The provisioning of multicast in diffserv-networks is the same as for unicast
(same codepoints, same mechanisms), but we have to take a look on the
expansion of mc-trees. QoS should only be given,when a reservation is made
(it doesn't matter, if the sender or the receiver sets up the reservation.)

ciao,
Klaus

--

 Klaus Wehrle

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 04 Nov 1999 09:10:07 -0600

Folks,

We've been round this topic enough I think, for this mailing list
and WG.

There are some BOFs coming up next week (especially decides)
where these questions are of interest, which is why I didn't
try to stop this discussion sooner, and even joined in.

However as has been observed by several people, we are *not*
planning any changes to the basic diffserv model. How provisioning
will be done, in unicast and/or multicast scenarios, is another
layer above basic diffserv.

This particular discussion should probably now move over to the
diffserv-interest list.

Thanks

  Brian Carpenter
  diffserv co-chair

---

From: "Cheng-Yin Lee" <[email-masked]>
Date: Thu, 04 Nov 1999 10:27:19 -0500

Brian E Carpenter wrote:

> evolve towards dynamic provisioning of diffserv aggregates.

At this point i should reiterate that we are provisioning for traffic
aggregates in our proposal, whether resources are provisioned statically or
dynamically.

cheers,
cyl