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

From: [email-masked]
Date: Wed, 3 Nov 1999 17:46:36 -0500

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

No, not as envisioned by that RFC.  The SLS reflects a long-lived contract
covering a large number of flows.  It would not in general be 
negotiated on the fly, although it (or more likely parts of it) could be.
See draft-ietf-issll-diffserv-rsvp-03.txt for one approach to this sort of
dynamic negotiation, but with a caveat: that draft describes one of
a number of ways that diffserv can be used/deployed, and there will
be diffserv deployments that don't support the mechanisms described there.
I would expect that most unicast flows in current networks will be
covered under prenegotiated SLSs, not ones that are set up as part of
deciding whether to initiate the flow.  If such a flow exceeds the
prenegotiated SLS, then the excess traffic is handled as specified
by the SLS.

--David (one of the RFC's authors)

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

---

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

David Black wrote:

> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: [Diffserv] Re: Problems with IP-Multicast in
> DiffServ-Networks
>
>
> > SLA). ... At least, that's how

> covering a large number of flows.

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?

The charges should probably be much as Steve described. That is, a
charge on packets per egress and maybe also packets at the source.

I don't think there is any consensus yet to morph diffserv into
something else in support of multicast?

Bert
[email-masked]

---

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

> charge on packets per egress and maybe also packets at the source.
Do you mean counting pkts?

> something else in support of multicast?
May i know what exactly is being morphed?

thanks,
cyl