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

From: Hugh LaMaster <[email-masked]>
Date: Wed, 3 Nov 1999 16:48:32 -0800 (PST)

On Wed, 3 Nov 1999, Vishwanath Edavayyanaamath wrote:

Apologies for reviving an old argument here, but, 
apparently the following perspective is missing.

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

In my view, at the most basic level (in an advertising-free world),
most traffic, unicast or multicast, benefits the receiver, rather
than the sender.  Or, since often they work together, both.

[Aside: and, you can still argue the same w/ advertising,
although it is uglier: e.g., I choose to pay the price of downloading
advertising junk from Altavista, say, because I consider the value
of using their search-engine to outweigh the cost.  The exception,
of course, is the SPAM I will receive for sending or posting anything
anywhere, sigh...]

For example, if I download linux from a linux ftp server
somewhere, I'm getting the benefit: nice of the site to provide
adequate bandwidth to me, the public.

And, I'm already paying an ISP for the service on the receiving side.  
So, just like multicast, which is *explicitly* receiver-driven, unicast 
is implicitly receiver-driven.

You should consider this when you consider multicast fan-out,
or, how customers should pay for priority service.

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

Personally, I think this is a bad idea, not only because
multicast is receiver-driven, but also, because it is
too complicated.  Steve Deering already said this, but,
I have to repeat it: don't try to turn the Internet into
the telephone system by paying for every flow/packet/cell/etc.:
the cost of billing to that level vastly outweighs the cost
of forwarding IP packets.  

In my view, to date, no one has demonstrated any (economic) 
benefit to charging for anything other than the size of
the pipe.

Diffserv was supposed to make a modest improvement on that to allow
a sender (and, implicitly, the real customer, the receiver), 
to *prioritize* traffic within a network, and, hand over the
simple priority information to a downstream provider.
That *relative* prioritization will be possible for a downstream
provider to honor.

Please don't try turn it into a telephone-like billing system.
I don't want to pay 20 cents/minute for a 1 cent/minute call,
just so that I can be billed for it.  I'd rather pay a flat rate.

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

Yes.  Native multicast is fairly widely deployed in backbones today,
although, few consumer-level ISPs support it, so, consumer-oriented
content is lacking.  But, adequate technology is there, and high-bandwidth
flows are not uncommon, and, many universities are connected.  The main
technological hurdles left have to do with scalability to very large numbers
of senders.  (Scalability to *any* number of receivers is already present).

Additions/corrections/refutations welcome.

--
 Hugh LaMaster, M/S 233-21,    Email: [email-masked]
 NASA Ames Research Center     Or:    [email-masked]
 Moffett Field, CA 94035-1000  Or:    [email-masked]
 Phone: 650/604-1056           Disc:  Unofficial, personal *opinion*.

_______________________________________________
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: Wed, 03 Nov 1999 23:29:39 -0500

> of forwarding IP packets.
Hmmm, i thought Steve Deering suggested counting pkts.
(BTW, we don't count pkts in our proposal, so i'm very puzzled by your
comment).

> That *relative* prioritization will be possible for a downstream
Yes... the sender set the TOS in pkts.

> just so that I can be billed for it.  I'd rather pay a flat rate.
I don't follow this, how is it being turned into a telephone-like
billing system?

cheers,
cyl

---

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

>Hmmm, i thought Steve Deering suggested counting pkts.

No, that was someone else.  I just said how to do it better, and then
went on to question the wisdom of doing it at all.

>(BTW, we don't count pkts in our proposal, so i'm very puzzled by your

I think it was in response to messages from people other than you.

Steve