2008/3/8 Jeroen Massar <jeroen@xxxxxxxxx>: > 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@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf > > _______________________________________________ IETF mailing list IETF@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf