2008/3/8 Jeroen Massar <jeroen(_at_)unfix(_dot_)org>:
Patrik Fältström wrote:
[..]
>> I am afraid that this is the sort of reasoning that has lead to P2P
>> having such widespread use.
I fully agree, (unicast) P2P is a godsend for Transit operators.
The fun with "p2p" is though, that HTTP is also peer to peer and actually
anything unicast is p2p from a design point of view ;)
> Is not one of the problems of exchanging multicast packets that someone
> that receive a multicast packet do not know how much bandwidth in the
> internal network that packet in reality will take? If the incoming
> packet is a unicast packet, there is a 1:1 relationship between incoming
> and outgoing packets. With multicast, one might have to send >1 packet
> out over the egress after receiving a packet?
Generally a network is a tree, unicast will mean you get a packet per branch,
multicast you get 1 packet for all branches. As such your traffic is less.
Though indeed, if you get 1 packet from your transit (thus at the root of
your
network), it takes up 1 packet everywhere else in your network. But you only
pay
your transit for 1 packet, not the zillion of branches that you might have
and
thus not for a zillion of packets.
AFAIK the biggest problem with multicast is management though.
The problem with Internet Multicast is that it's an all-or-nothing
delivery solution - every router in the path must support AND have PIM
enabled or you don't get the bits. And there are too many parties
involved to coordinate deployment globally. If IGMP had been designed
as a multi-hop protocol from the beginning, early adopters would have
been able to benefit from multicast content delivery to the edge of
their domain, or their multicast providers domain. But beyond that
there are just too many edge networks to coordinate or incent to
deploy multicast for someone else's content.
Today we have AMT as a way to get multicast content from the edge of
the multicast boundary over the unicast edge network to the receivers.
I've often heard people say that the future is VOD/P2P and multicast
has missed it's opportunity. Seems to me Opra may have a different
opinion. Do you think Opra would add
draft-ietf-mboned-auto-multicast-08.txt as recommended reading to her
book club? ;-)
Not evening going
onto the subject of it being available in hardware for most platforms...
Any modern router replicates multicast traffic in hardware - some
better than others.
Greg
> If so, could not new models of charging be that if A send multicast
> packet to B, "the number of packets sent" are the number of packets
> going _out_ from B, not in to B? If it was possible to do such
> accounting...
Multicast account is simple: you do it at the place where you measure, same
as
unicast.
Thus if you have:
/----> H
/-----> I
/---> E------> J
A ---> B ---> C ---> F....
\ \---> G....
\
\
\---> D....
For multicast, if you have clients everywhere, at A you see 1 packet and at H
you see 1 packet, but that same packet is also at I J etc.
For unicast you see <clients> times packets at A and 1 packet at each client.
As such, an ISP (B) who has clients C,D,E,F,G..., will pay Transit A, in
case of
Multicast 1 packet, while for unicast he would pay Transit A for <clients>
packets. In both cases though ISP B will charge his clients for that single
packet. As such, multicast makes money for B, but not for A.
Transits thus don't like it, ISP's don't get it.
Greets,
Jeroen
(This all reminds me to put working multicast on the list again for SixXS...)
u
_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf